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:
(SRC triple)(*, floor.manager, *) NEED_TO_KNOW (*, floor.slave, *) [list of fns]In this case the application specified by the source triple is telling all floor.manager applications that when they send one of the specified functions to (*, floor.slave, *), this application would like reliable delivery of the message.
NEED_TO_KNOW messages should be sent periodically, and will timeout if one hasn't been received in a set amount of time. NEED_TO_KNOW requests will also time out at a particular application if that application ever fails to reliably deliver a message to the specified address. Clearly NEED_TO_KNOW 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 floor.holder, which may be desirable in some cases), but NEED_TO_KNOW also has the benefit that it can be used to modify the behaviour of existing applications without a requirement to access the source code.
Next: The Naming Service Up: More complex needs Previous: Dynamic type-group membership Jon CROWCROFT