Membership

To avoid an inconsistent behavior of joining stations as described above, the protocol en-sures that a station only starts delivering atomic multicasts when it is able to deliver all atomic multicasts that the other members deliver henceforth, as long as it stays valid. To achieve this, the AP delays accepting a joining station’s atomic multicast until it has en-sured that there are no more pending multicasts. The joining station, in its turn, does not deliver any atomic multicast message before its own one is accepted. When the atomic multicast of a joining station is accepted, the joining station changes its service state to joined. To ensure that this will happen whenever the joining station is valid, the first atomic multicast of the joining station is transmitted with a resiliency of OD. Determining and maintaining the pending multicasts for a joining station works as follows: When the DNS protocol signals that a new station was added to the group, the reliable multicasts exports the current set of pending multicast messages; or, to be more precise, the set of stations, that have pending multicasts. When the atomic multicast protocol receives the signal, it imports this set and stores it as the pending multicast set of the joining station.

Thus, each joining station can have its own set associated. The AP changes this set under two events: First, whenever the joining station acknowledges the multicast of a station, this station is removed from the pending multicast set of the joining station because now the joining station is able to deliver the message of this station. Second, whenever the AP de-cides to accept or reject a message, it removes the originator of the message from the pend-ing multicast set of all joinpend-ing stations; none of the joinpend-ing stations will have to deliver the message. Note that the pending set of a joining station will be empty when the atomic mul-ticast of that station has been transmitted OD+1 times. In this case, all pending mulmul-ticasts must have been accepted already. Therefore, the multicast of a joining station is never de-layed beyond the time bound ∆AtomcMC(OD) so that a bounded join delay can be guaranteed.

This protocol not only ensures that a member delivers all messages in agreement with the other group members starting from the first message it delivers, but also that the members know they are in agreement with a new member after delivering the first atomic multicast of that member.

The atomic multicast protocol achieves agreement among the members, even if not all valid members receive a message. As members process the decisions in the synchronous channel in the order in which the AP made them, it achieves total order as well. The analy-sis of the timeliness of the atomic multicast service yields a worst-case delay of

∆AtomcMC(r) = (2r + 1) × ∆Round + (OD + 1) × ∆Slot. To achieve these properties no additional frames were introduced.

4.3.7.1 Service of the Protocol

The fail-ware service of this protocol is to provide an up-to-date and agreed view on the current membership to the group members. Up-to-date means that there is a known con-stant ∆Memjoin, such that each station which tries to join the group and is valid for at least ∆Memjoin

time units becomes part of the membership view of every joined member, and a known constant ∆Memexcl, such that a member that was invalid for at least the last ∆Memexcl

time units will not be in the membership view of any joined member. When we say that views are agreed, we mean that any two joined members deliver the same sequence of membership views.

An additional property of the service, which is defined in conjunction with the atomic mul-ticast service, is the so-called virtual synchrony. Virtual synchrony ensures that all mem-bers deliver the memmem-bership views at the same position in the sequence of atomic multi-casts; or, to put it the other way round, it ensures that all members deliver the atomic mul-ticasts in the context of the same membership view. Together with the Agreement and To-tal Order properties of the atomic multicast protocol (Property 4-22 and Property 4-24), it ensures that all members share a common view on the sequence of atomic multicast mes-sages and membership changes.

For the formal definition of the protocol’s properties, we define that a membership change message is a pair (n,m), where m is a set of stations representing the membership view and n is a unique identifier. If the protocol delivers the same membership view several times ― for example, a station leaves and later rejoins the group ― the identifier allows distin-guishing the membership change messages. As the atomic multicasts are delivered at the same interface, the application observes a single sequence of atomic multicast and mem-bership change messages. We say that a station si delivers a message m if the membership protocol delivers a membership change or atomic multicast message m and that si delivers a membership view m if it delivers a membership change message containing m. Let Mi(t) be the last membership view si delivered by time t. The first two properties define the ser-vice the protocol provides at joined stations. There exist known constants ∆Memexcl and ∆Memjoin

such that the following properties hold.

Property 4-25 (Validity): For all stations si, sj and all times t, t' with t' ≥ t, if si is joined throughout [t, t' +ε] and

(1) sj started joining by t - ∆Memjoin and is valid during [t - ∆Memjoin,t'], then sj is in Mi(t'') for each t'' ∈ [t,t'].

(2) sj is invalid during [t - ∆Memexcl

,t'], then sj is not Mi(t'') for each t'' ∈ [t,t']

Property 4-26 (Agreement): For all stations si, and all membership change messages (n,m), if si delivers (n,m) at t, then there is a time t' such that, t' ≤ t ≤ t' + ∆SynchCh and for all station sj, if sj is joined throughout [t', t' + ∆SynchCh +ε], then sj delivers (n,m) by t' + ∆SynchCh

Like the fail-aware services of the atomic multicast and the membership protocol, the membership protocol fulfills the Justification of Fail Notifications property (Property 4-19) and a Conditional Bounded Join Delay property analogous to Property 4-18.

Property 4-27 (Bounded Join Delay): For all stations si, if si starts joining at t and si is valid throughout [t, t + ∆Memjoin

], then si is joined by t + ∆Memjoin

Like for the synchronous channel and the atomic multicast protocol, we define the delivery order of membership change messages. Let ≺i denote the transitive reduction of the deliv-ery order as observed by si. That is, for any two membership messages (n,m) and (n',m'), (n,m) ≺i (n',m') if and only if si delivers (n,m) before (n',m') and no other membership changes messages in between. The first membership change message si delivers after the membership service becomes joined is defined to have no predecessor in ≺i.

Property 4-28 (Total Order). For all stations si, sj and all membership change messages (n,m), (n',m'), and (n'',m''): If (n,m) ≺i (n',m') and (n,m) ≺j (n'',m''), then (n',m') = (n'',m'').

Total Order ensures that two stations, once they have delivered membership change mes-sages with the same identifier, deliver the same sequence of memberships henceforth until one of them is no longer joined.

Property 4-29 (Virtual Synchrony). For all stations si, sj, and all membership change messages (n,m), (n',m'): If (n,m) ≺i (n',m') and (n,m) ≺j (n',m'), then si and sj deliver the same set of atomic multicasts between (n,m) and (n',m').

4.3.7.2 Operation of the Protocol

To explain how the membership protocol accomplishes its service, we first point out how stations leaving the group are handled and then consider joining stations. There are two reasons for a station’s no longer being a part of the group. First, the station may voluntarily decide to leave the group, and second, it may become invalid. In both cases, the protocol must deliver new membership views at the remaining members. For sake of simplicity, we do not distinguish between these cases.

To handle leaving members, the main point to be addressed is how the remaining members learn that a certain station left the membership; then, they are able remove this member from their local membership view and deliver the changed view to the user. The first sta-tion that notices that one of the members became invalid is the AP. As described above (Sub-Section 4.3.3), the dynamic network scheduling entity at the AP provides an exclude notification whenever the polling entity informs it of a member that became invalid. To propagate this exclude information from the AP to the clients the membership protocol uses the synchronous channel. Actually, as explained above (Sub-Section 4.3.5), the syn-chronous channel protocol itself already distributes these change notifications for its own purposes and issues corresponding notifications at the clients. Thus, using the synchronous channel protocol, all that remains to be done for the membership protocol is to change the membership view whenever it receives an exclude indication from the synchronous chan-nel protocol and deliver the new membership view to the user. The Validity property of this protocol is ensured by the timely detection of invalid members (Property 4-8) and by the Validity of the synchronous channel (Property 4-17). Thus the bound ∆Memexcl can be de-termined as follows:

∆Memexcl := ∆Fail + ∆SynchCh := OD × ∆Round + (OD + 1) × ∆Slot

Furthermore, since the exclude decisions are transported in the synchronous channel to-gether with the AP’s accept decisions and since all members process the decisions in the order in which the AP made them, the protocol ensures virtual synchrony. To achieve timely and virtual synchronous delivery of exclusions, the membership protocol does not introduce additional frames.

The second kind of membership change that must be dealt with is the joining of new mem-bers. To understand how joining works, it is best to think of it in the following way: A sta-tion joining the group uses the atomic multicast service to multicast a message (with resil-iency OD) to the current membership plus itself. Its address is transmitted implicitly with the multicast message. When the atomic multicast service delivers the message of the join-ing station, all members as well as the joinjoin-ing station add the joinjoin-ing station to their mem-bership view, deliver a memmem-bership change message, and then deliver the atomic multicast message.

Let us now consider the joining of a new member in more detail. A station that wants to join the group calls the dynamic network scheduling protocol to allocate bandwidth. Bas-ing on the JOIN service of the pollBas-ing protocol the DNS protocol can make this allocation in bound time (∆Resjoin := (OD + 1)∆Round + 2δm, see Sub-Section 4.3.3). Once the AP made that allocation, it starts polling the joining station. Upon reception of the first polling frame, the membership at the joining station solicits its user to transmit an atomic multi-cast. The protocol sets the resiliency of this atomic multicast to OD to ensure that the AP will accept it and invokes the atomic multicast protocol to transmit it. From then on, every-thing works as for a normal atomic multicast. Sooner or later, all members plus the joining station will deliver the atomic multicast together with the address of the originating station.

Now, they add this address to their membership view and deliver it to the application fol-lowed by the atomic multicast. Thus, the delay bound ∆Memjoin

can be computed as follows:

∆Memjoin := ∆joinRes + δm + ∆AtomcMC(OD)

= (OD + 1)∆Round + 2δm + δm + (2OD + 1) × ∆Round + (OD + 1) × ∆Slot

= (3OD + 2)∆Round + (OD + 2) × ∆Slot

. The term δm accounts for the first regular polling frame the AP sends to the joining station.

When a joining station delivers its own first atomic multicast, it is expected to deliver a membership view; but, how does a joining station know which other stations are members of the group. The AP is in charge of providing the necessary membership information to joining stations. Whenever the AP sends a mc frame on behalf of a joining station, it pig-gybacks a copy of its current membership view. Thus, when a joining station has acknowl-edged its own atomic multicast message, the AP knows that the station has received the membership view together with the atomic multicast. The membership entity at the AP can stop piggybacking the membership view when it learns that the atomic multicast of a join-ing station was accepted. This information is provided by the atomic multicast protocol through a status indication. Once a joining station has received a mc frame including a current membership view, it can keep this list up-to-date using the decisions it receives in

the synchronous channel. Thus, when the station receives the accept decision for its own atomic multicast, it has an up-to-date membership view, which it can deliver to the user.

The protocol allows valid station to join the group in bounded time. Furthermore, as join-ing stations are allowed to transmit a first atomic multicast while joinjoin-ing the group, the protocol needs no additional frames as long as a joining station has indeed some applica-tion message to transmit. In this case, all informaapplica-tion is piggybacked on frames that have to be sent anyway. Virtual synchrony is efficiently achieved through the total order prop-erty of the atomic multicast protocol.