In a floor control policy it is important to make sure there is always one and only one participant in the moderator role. If the moderator is lost, for example due to process failure or network partition, some other participant must be chosen to become the moderator. There is a similar issue with regard to the floor holder role. If the floor holder is detected lost, then the moderator must be able to reproduce a floor so that the collaboration can continue. As specified in Figure 5, we use a soft-state protocol for this purpose. The moderator and the floor holder periodically send out a liveness report, from which the other participants know their liveness and try to repair if there is a loss.
The floor holder adds to its database the fact that it is the current holder of the floor. This fact is deleted when the role is dropped. Then a timer is set so that it multicasts a liveness report every 10 seconds.
When the moderator role is taken, the participant automatically assumes the floor holder role. Here two timers are set. The ``reporter'' sends out the liveness report every 10 seconds. And the ``checker'' checks the database records every minute. If no liveness report is received from the floor holder in one minute, the moderator itself assumes the floor holder role. When a report comes from the holder, however, the database is updated accordingly.
The aspirant role can be specified similarly. The differences are that an aspirant does not need to send the periodic liveness reports and that it must detect the moderator loss. When the moderator is discovered to be lost, a new one must be chosen from the participants. A number of policies can be applied here depending on the taste of the participants. For example, the decision can be made by voting, by the alphabetic ordering of participants' names, etc. For reasons of space, the aspirant specification is listed in [15] instead.
