CCC can be run on the bus model, passing all messages around a single
multicast group per conference. This will scale reasonably, since it
scales with the number of participants in the conference. Name
resolution occurs at each host, matching the destination naming tuple
in the message against the list of tuples that are registered at this
particular host. However, it it does not scale indefinitely, because
the load on each host and the network increases with the complexity of
the conference and the number of messages. To improve scaling, the
communications should be optimised so that messages are only
propagated to the machines that are interested. Thus we need a
service that maps the naming tuples to locations, so that intelligent
mapping of message paths to locations can be performed (aka
intelligent routing and placement of multicast groups). This name
location service (or naming service as it is more generally known) has
a number of properties that differentiate it from other naming
services such as X.500 and the DNS:
The last property is important, since it allows a relaxed approach to
maintenance of consistency amongst the naming servers, saving greatly
in the messages and complexity of the internals of the service.
We intend to implement a nameserver suitable for loosely coupled conferences
as the default in the CCC library. However, CCCP will also allow the use of
an external nameserver to supplement or replace the internal nameserver
behaviour, which will allow much greater use of the nameserver to made in
more tightly coupled conferences, for instance by using the nameserver to
keep an accurate list of members.
- Dynamic and frequent updates.
- Fast propagation of changes.
- Ability to fall back to broadcast to interested parties when uncertain
about the consistency of a refined addressing group, since names are
unique per conference and are included in each message.