next up previous contents
Next: CCC Names Up: CCCP - Distributed Internet Previous: Scaling from tightly coupled

The Conference Control Channel (CCC)

To bind the conference constituents together, a common communication channel is required, which offers facilities and services for the applications to send to each other. This is akin to the inter process communication facilities offered by the operating system. The conference communication channel should offer the necessary primitives upon which heterogeneous applications can talk to each other.

The first cut would appear to be a messaging service, which can support 1-to-many communication, and with various levels of confirmation and reliability. We can then build the appropriate application protocols on top of this abstraction to allow the common functionality of conferences.

We need an abstraction to manage a loosely coupled distributed system, which can scale to as many parties as we want. In order to scale we need the underlying communication to use multicast. Many people have suggested that one way of thinking about multicast is as a multifrequency radio, in which one tunes into particular channels in which we are interested in. We extend this model to build an Inter Process Communications model, on which we can build specific conference management protocols. Thus we define an application control channel.

What do we actually want from the system?


  
Figure 7.4: CCCP Conceptual Design
\begin{figure}
\centerline{\psfig{figure=pix/cccp_concept.small.ps}}
\end{figure}

CCCP originates in the observation that in a reliable network, conference control would behave like an Ethernet or bus - addressed messages would be put on the bus, and the relevant applications will receive the message, and if necessary respond. In the internet, this model maps directly onto IP multicast. This is illustrated in figure 7.4. In fact the IP multicast groups concept is extremely close to what is required. In CCCP, applications have a tuple as their address: (instantiation, application type, address). We shall discuss exactly what goes into these fields in more detail later. In actual fact, an application can have a number of tuples as its address, depending on its multiple functions. Examples of the use of this would be:

Destination Tuple   Message   
-----------------   -------
(1, audio, localhost)    <start sending>
(*, activity_management, localhost)  <receiving audio from host:> ADDRESS
(*, session_management, *)   <I am:> NAME
(*, session_management, *)   <I have media:> {application list}
(*, session_management, *)   <Participant list:> {participant list}
(*, floor_control, *)    <REQUEST FLOOR>
(*, floor_control, *)    <I HAVE FLOOR>

and so on. The actual messages carried depend on the application type, and thus the protocol is easily extended by adding new application types.

In keeping with the underlying multicast message reception paradigm, a CCC application needs to register its interest in messages before it will receive them. Where possible, a CCC system uses the underlying multicast delivery to optimise where messages are filtered.


next up previous contents
Next: CCC Names Up: CCCP - Distributed Internet Previous: Scaling from tightly coupled
Jon CROWCROFT
1998-12-03