#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:
-
The <#1790#> Switch Controller<#1790#> acts purely as a service that exports an interface
only to the Switching Server. The former runs on a machine attached
to any hardware specific to providing switched video or audio services.
These include a digitally controlled analogue video switch and a CODEC hub,
providing multiplexing and demultiplexing of video streams.
-
The <#1791#> Switching Server<#1791#> is a client of the
Switch Controller, can run on any host in the system. It
exports an interface that is used by the Conference Server.
-
The <#1792#> Directory Server<#1792#> is purely a server, and provides user and
multimedia workstation location information for a site. This is used by the
Conference Server.
-
The <#1793#> Conference Server<#1793#> primarily provides a service for the applications.
Applications interface via the CAR standard library. The
Conference Server is also a client
of the Directory Server, the Switching Server, and the Notification Server.
-
Applications are clients of the Conference and Directory Services, but
are linked with a standard CAR library to hide this communication and
to hide their dependence on the Notification server described next.
-
Every Application is run alongside a <#1794#> Notification Server<#1794#>,
which is called by the Conference Server as a result of the actions of
other applications. The interface between the Notification Server and
the application is via a pipe. This is implemented inside the Car
Library, so that it is largely transparent to the application.
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.