CAR Conferencing System Components

The CAR Conferencing System has many components in common with the architectures described in[#nicolaou##1#] and [#schooler##1#]. These components are shown in #fncar1#1784>.

#figure1785#
Figure: The CAR Conference System Architecture

The components all communicate using Remote Procedure Call, with the exception of the channel between the Notification Service and Car Library, which uses a Unix Pipe. The system's clients and servers have the following roles:

For a given CAR set of conferences, there is only one Switch Controller, one Switching Server, one Directory Server and one Conference Server. These are run as demons by the system (possibly on a variety of different machines, but quite possibly on a single machine). Due to the blocking synchronous nature of the version of the RPC system used, and the choice to import interfaces immediately at startup of each client, the servers must therefore be started in the correct order: Switch Controller, then Switching Server, in parallel with the Directory Server, then Conference Service; finally, conferencing applications. There is another level of indirection and cause of unreliability, to paraphrase Dijkstra: there is a trader, RPC Binder which is required by clients to locate servers, as they do not make use of well-known ports: a restart of part of the system results in deadlock because new services' locations are no longer known to old clients. This is because there is state in the client which reflects the old locations.