The original talk program has 2 parts:
The Daemon is used to find users and invite them to join a
talk. The User interface allows someone to request to talk to someone.
This causes the daemon to invite the other user to join, and then to
plug together the inviter and invitee's talks (all within the
appropriate window on the appropriate machine).
To extend this to multiple end points, we attempted two alternative
The User interface
Here we present an Open Systems approach to defining the service
interface to the conferencing system. The notation is that of the
Remote Operations service, using the Abstract Syntax Notation 1 (ASN.1)
to define the operations and parameters available between the
An outline of the objects and ports available in the various servers,
available to clients, is given later in this chapter..
For the centralised approach, we can decompose the system into three services, and analyze some
design decisions for the services:
Maintain the talk daemon approach roughly as is. This is the means by which
active or passive joins are propagated to a machine. We create a single
daemon which creates the conference clients (see below), for each conference,
and tracks them by name (which maps to machine/port), and a
corresponding list of users.
This is implemented simply by letting the Conference clients be
windows on the corresponding users' workstation consoles. In other
words, the conference is a single program which is
an X-Windows client of many display servers.
Replicated or Distributed
Allow the control of the conference to be distributed in the same way
as the conference itself. This approach entails a number of autonomous
conference programs, with some other means of communication than the
X-Protocol. We used multiple TCP Socket connections from each
conference program to all the others.
The Conference Server
This maintains the conferences for the users. It handles requests to
create or destroy a conference, to join and leave a conference, and to
send messages to the members of the conference.
There may be one instance of the conference server per site, handling
all conferences on all machines, or one per machine, or one per
The Location Server
This is used by a user program to find where another user is logged
There must be one of these per machine. However, does the client ask a
location server, and the local location server asks all the others for
the location? It may tell the user where the other location servers
are, and they have to repeat asking til they find the user. Another
design decision might be for the location servers to continually (say
every couple of minutes) inform each other of the users on their
machine. In our case, we made use of the <#1213#> rusers<#1213#>
The Ping Server
The user uses this service to ask a another user if they wish to join
the conference. In our implementation, we made use of the <#1215#> write<#1215#>
The user program is then a client of these three servers, typically
the conference server (to create and join the conference), then the
location server (to find another user), then the ping server (to ask
the other user if they want to join), then the conference again to
send messages to the set of users in the conference.