When an application sends a message, it is up to the sending application to
choose the reliability mode for the message. For example, in a large loosely
coupled conference, a floor change announcement may be multicast is an
unreliable mode. However, their may be a number of applications that
really do require to see that information. In the floor control example, the
existing floor holding applications need to see the floor change
announcements. We propose allowing a receiving application to modify the
reliability with which other applications send specific messages by allowing
messages of the form:
verbatim88
In this case the application specified by the source triple is telling all
<#2171#> floor.manager<#2171#> applications that when they send one of the specified
functions to <#2172#> (*, floor.slave, *)<#2172#>, this application would like reliable
delivery of the message.
<#2173#> NEED_TO_KNOW<#2173#> messages should be sent periodically, and will timeout if
one hasn't been received in a set amount of time. <#2174#> NEED_TO_KNOW<#2174#>
requests will also time out at a particular application if that application
ever fails to reliably deliver a message to the specified address.
Clearly <#2175#> NEED_TO_KNOW<#2175#> messages should be used sparingly, as they
adversely affect the scaling propertied of the CCC. However, there are a
number of cases where they can be useful. The same effect could be achieved
by declaring another type (for example <#2176#> floor.holder<#2176#>, which may be
desirable in some cases), but <#2177#> NEED_TO_KNOW<#2177#> also has the benefit that
it can be used to modify the behaviour of existing applications without a
requirement to access the source code.
<#2178#> Note: the authors are not entirely happy with the
NEED_TO_KNOW message concept, as it does not quite fit into the simple CCCP
model in which the sender decides both reliability and addressing. However,
allowing a potential receiver to modify the reliability of messages of which
it would be a receiver is a powerful concept if used very sparingly.<#2178#>