Many potential applications require to be able to contact a server or a token holder reliably without necessarily knowing the location of that server. An example may be a request for the floor in a conference with one roaming floor holder. The application requires that the message gets to the floor holder if it is at all possible, which may require retransmission and will require acknowledgment from the remote server, but the application writer should not have to write the re-transmission code for each new application. CCCP supports "at least one" reliability, but to address such a REQUEST_FLOOR message to all floor managers is meaningless. By supporting dynamic type-groups CCCP can let the application writer address a message to a group which is expected to have only one (or a very small number) of members, but whose membership is changing constantly.
In the example described, the application requiring the floor sends:
SRC Tuple DEST Tuple Message --------- ---------- ------- (1, floor.master, x) (*, floor.master.holder, *) REQUEST_FLOORwith "at least one" reliability. retransmissions continue until the message is acknowledged or a timeout occurs.
When the floor holder receives this message, it can then either send a grant floor or a deny floor message:
SRC Tuple DEST Tuple Message --------- ---------- ------- (1, floor.master, y) (1, floor.master, x) GRANT_FLOORThis message is sent reliably (ie, retransmitted by CCCP until an ACK is received).
On receiving the GRANT_FLOOR message, the floor manager at x expresses an interest in the type-group floor.master.holder. On sending the GRANT_FLOOR message, the floor manager at y also removes it's interest in the type-group floor.master.holder to prevent spurious acking of other REQUEST_FLOOR messages. However, if the GRANT_FLOOR message retransmissions time out, it should re-express an interest.
See section 3.9 on the Naming Service for more details of how dynamic type-groups work.
Next: Need to know Up: More complex needs Previous: More complex needs Jon CROWCROFT