The Touring Machine System [Aran93] is a platform for teleconferencing applications that has been developed at Bellcore in the early 1990’s. The first version of the Touring Machine, com-pleted in 1990, only supported point-to-point desktop audiovisual communication. The second version, which was finished in 1992, added multipoint communication and an API, and is dis-cussed here. A third version [Coan93] based on ODP and IN principles was partially designed, but never completed, probably because it would have competed with TINA. The Touring Machine has to be understood as an attempt to explore how a multimedia infrastructure in a large public telecommunications network may look like. It tries to provide multimedia tele-communications services, from which stems its emphasis on resource management and robust-ness. The Touring Machine is object-based in the sense that it encapsulates functionality within entities that can communicate with each other. All of the Touring Machine objects are mapped one-to-one onto processes. This adds some robustness to the system, because the failure of one process affects only one object, and possibly only one user session, but it might actually also be due to limitations of the C programming language in which the Touring Machine is imple-mented. The applications developed on top of the Touring Machine have been in daily use by more than a hundred people, and over a period of almost three years [Wein94]. The Touring Machine could only be deployed on such a large scale because audio and video communication was analog.
Figure 4.1 shows the software architecture of the Touring Machine. The platform is divided into a session control level and a transport control level. Session control objects deal with log-ical representations of connections that are physlog-ically established and maintained by the trans-port control objects. Platform objects are either permanent or transient, with transient objects being dynamically created or deleted when needed. The API is implemented via the permanent station object that exists on every Touring Machine terminal. The station object receives API calls directly from client processes, or indirectly via a station manager that intercepts the com-munication between client and station object in order to introduce specific policies for the coordination of multiple clients. The station object deals mainly with client authentication and
Figure 4.1. The Touring Machine software architecture.
Station
registration, and inter-client communication. It creates a transient session object when asked by a client, and forwards all connection and session related requests to it. The session object keeps state about session membership, session policies and existing connections. It establishes connections with the help of a transient transport object that maintains a mapping between logical and physical connections. The transport object requests end-to-end connections from the resource manager which establishes them in collaboration with low-level resource objects.
The Touring Machine includes four types of resource objects. The A/V switch object estab-lishes analog audio and video connections. The data switch object estabestab-lishes digital connec-tions for inter-client communication. The trunk group object establishes trunks between different A/V switches. The bridge object finally allocates audio and video bridges for multi-way communication. The transport object talks directly to the data switch object and the A/V switch object when it needs to act on local connection endpoints. Figure 4.1 also shows a name server that can be browsed by every platform object. The name server is a repository for static and dynamic information about the system, like for instance authorized users, registered cli-ents, ongoing sessions, or Touring Machine stations.
The Touring Machine defines the connection related abstractions connector, endpoint and port. A connector is a medium specific bridge that can be of type audio, video or data and that has source and sink endpoints from participating clients attached to it. Connectors can repre-sent point-to-point as well as multipoint connections. Clients access connector endpoints via ports that are typed with medium and flow direction. The port abstraction allows clients to switch locally between different sources or sinks for the same connector endpoint. Audio and video ports exist statically, whereas data ports can be created dynamically. A multipoint data connector is realized with a data switch object that establishes TCP connections with every attached client.
The API of the Touring Machine [Mak93] is message-based. An API message consists of a length field and a set of message fields, which are either integers, strings enclosed by double quotes, or API keywords. The format of a message is described by means of a simple propri-etary syntax. Messages that require a reply contain a token that allows to match a reply with the original request. The functionality provided by the API can be divided into six categories:
• client registration: a client process registers with its name and the configuration of the station, and receives a client ID to be used in all consequent messages.
• session establishment and modification: a session is created with an initial set of participants and connections that can later be modified. Session establishment and modification requires prior negotiation with all concerned clients.
• network access control: the mapping between ports and endpoints can be con-trolled, and data ports can be dynamically created or deleted.
• name server query: the name server may be queried for users, clients, stations, ports, sessions, connectors and endpoints. Queries may contain wildcards. Cli-ents may register triggers in order to be notified when certain evCli-ents occur.
• inter-client message forwarding: a client can send a string to one or more other registered clients.
• error notification: an error notification is returned to a client if the message pre-viously sent by the client contains syntax errors.
The API defines all in all 46 messages. The number of real procedures is smaller because the Touring Machine defines for every procedure a request, an accepted and a denied message.
Two applications have been developed on top of the Touring Machine: the Cruiser telecon-ferencing application, and the Rendezvous shared workspace application. Both applications can be run on top of the same session. This is possible because there can be more than one cli-ent per station within the same session1. This is a powerful feature because it allows to create new applications by combining existing applications that were developed independently from each other2.
4.2.1 Assessment
The use of analog audio and video cannot be considered as a limitation of the Touring Machine, for it is this feature that made a large-scale deployment of the platform possible. A consequence of the analog media transmission is that the platform does not need to support inter-stream synchronization. A drawback is maybe that an application cannot control media presentation, which would be possible with digital audio and video.
The API of the Touring Machine is monolithic. Any addition of functionality to the API requires modification of the station object, and probably other platform objects. The platform itself is closed in the sense that internal interfaces are hidden, making it impossible for third parties to develop platform extensions. The Touring Machine would have greatly profited from a distributed object computing platform like CORBA. The six categories into which the API functionality is split would immediately be represented by six major CORBA interfaces. Every interface would be implemented by the object that provides the respective functionality, with the advantage that requests do not need to be routed through unconcerned platform objects. As an example, the name service would be accessed directly, possibly via the CORBA name or query services, and name service requests would not need to pass through the station object, as is happening in the Touring Machine. A problem with the API is that it is based on a propri-etary protocol. It defines a PDU format and message exchange rules that are rather complex whenever negotiation among multiple parties is involved. The message-based API could easily be reformulated in terms of RPC’s. None of the publications about the Touring Machine explains why this was not done, and it can only be assumed that the hardware infrastructure was too heterogeneous for this, meaning that there was no single RPC available on all of the involved hardware architectures. Application developers must consequently code the marshal-ling and unmarshalmarshal-ling of parameters by hand, which is not only additional work, but also a source of programming mistakes. Since internal communication is also based on messages it is likely that a considerable part of the 125K lines of C code that make up the Touring Machine could be generated automatically by a CORBA IDL compiler or ONC’srpcgen.
Inter-client communication in the Touring Machine is completely provided by the platform.
Clients are not supposed to open direct TCP connections with any peer. They use multipoint data connectors for the communication of application data, and the inter-client messaging fea-ture of the API for the construction of application-level control protocols. Both kinds of inter-client communication could be readily provided by the CORBA event service, or the future messaging service. Table 4.1 provides a summary of the features of the Touring Machine with respect to the requirements on MMC platforms developed in Chapter 2.
1. Note that a Touring Machine client is not the user. A user may have multiple clients on his station running on his behalf.
2. This feature bears some resemblance to the component framework paradigm. It would have been possible to formalize this feature, which requires inter-application signalling, but this was not done.