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
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?
- We want to ask for services
- We want to send requests to specific entities, or groups of
entities and receive responses from some subset of them, with notifications
sent out to others.
Figure: CCCP Conceptual Design
CCCP originates in the observation that <#1944#> in a reliable network<#1944#>, 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 #fncccp1#1945>. 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
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 optimse where messages are