Need to know

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#>