CCCP would be of very little use if it were merely
the simple protocol described above due to the inherent unreliable nature of
the Internet. Techniques for increasing the end-to-end reliability are well
known and varied, and so will not be discussed here. However, it should be
stressed that most (but not all) of the CCCP messages will be addressed to
groups. Thus a number of enhanced reliability modes may be desired:
- None. Send and forget. (an example is session management messages in a
loosely coupled system)
- At least one. The sending application wants to be sure that at least
one member of the destination group received the message. (an example is a request floor message which would not
be ACKed by anyone except the current floor folder).
- n out of m. The sending application wants to be sure that at least n
members of the destination group received the message. For this to be
useful, the application must have a fairly good idea of the destination
group size. (an example may be joining of a semi-tightly coupled
conference)
- all. The sending application wants to be sure that all members of the
destination group received the message. (an example may be ``join conference;SPM_quot; in a very tightly coupled conference)
It makes little sense for applications requiring conference control to
reimplement the schemes they require. As there are a limited number of
these messages, it makes sense to implement CCCP in a library, so an
application can send a CCCP message with a requested reliability, without
the application writer having to concern themselves with how CCCP sends the
message(s). The underlying mechanism can then be optimised later for
conditions that were not initially foreseen, without requiring a re-write of
the application software.
There are a number of ``reliable;SPM_quot; multicast schemes
available, such as [#rmp##1#] and [#isis##1#], which can be
used to build consensus and agreement protocols in asynchronous
distributed systems. However, the use of full agreement protocols is
seen to be currently limited to tightly coupled conferences, in which
the membership is known, and the first design of the CCC library will
not include reliable multicast support, although it may be added later
as additional functionality. Unlike distribute databases, or other
automated systems that might exploit causal ordered multicast
discussed in chapters 2 and 3, communications
systems for humans can exploit the users tolerance for inconsistency.
We believe that sending a message with reliability ``<#2005#> all<#2005#>'' to an
unknown group is undesirable. Even if CCCP can track or obtain the
group membership transparently to the application through the
existence of a distributed nameserver, we believe that the application
should explicitly know who it was addressing the message to. It does
not appear to be meaningful to need a message to get to all the
members of a group if we can't find out who all those members are, as
if the message fails to get to some members, the application can't
sensibly cope with the failure. Thus we intend to only support the
<#2006#> all<#2006#> reliability mode to an explicit list of fully qualified (i.e.
no wildcards) destinations. Applications such as joining a secure
(and therefore externally anonymous) conference which requires voting
can always send a message to the group with ;SPM_quot;at least one;SPM_quot;
reliability, and then an existing group member initiates a reliable
vote, and returns the result to the new member.