Dynamic type-group membership

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 ;SPM_quot;at least one;SPM_quot; reliability, but to address such a <#2165#> REQUEST_FLOOR<#2165#> 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: verbatim86 with ;SPM_quot;at least one;SPM_quot; 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: verbatim87 This message is sent reliably (ie, retransmitted by CCCP until an ACK is received). On receiving the <#2166#> GRANT_FLOOR<#2166#> message, the floor manager at x expresses an interest in the type-group floor.master.holder. On sending the <#2167#> GRANT_FLOOR<#2167#> message, the floor manager at y also removes it's interest in the type-group floor.master.holder to prevent spurious acking of other <#2168#> REQUEST_FLOOR<#2168#> messages. However, if the <#2169#> GRANT_FLOOR<#2169#> 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.