The Talk model

The original talk program has 2 parts:
  1. The Daemon
  2. The User interface
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 approaches:
  1. Centralised 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.
  2. 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.
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 conferencing programs.[ROS86][ASN85] 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:
  1. 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 conference.
  2. The Location Server This is used by a user program to find where another user is logged in. 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#> RPC service.
  3. 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#> facility. 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.