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.