Atomic Multicast

units, the duration between the reception of the last mc frame and the time when the station changes to service state stopped is bounded by

∆'SynchCh := ∆SynchCh(1+ρ) + ∆sched . Thus, the constant ε in the above definitions can be computed as

ε = ∆'SynchCh - ∆SynchCh = ∆SynchChρ + ∆sched .

Property 4-23 (Bounded Join Delay): For all stations si, if si starts joining at t and si is valid throughout [t, t + ∆DNSjoin + ∆AtomcMC(OD)], then si is joined by t + ∆DNSjoin + ∆AtomcMC(OD).

To define the Total Order property, we define the delivery order of atomic multicasts analogously to the delivery order of the decisions. Let ≺i denote the transitive reduction of the delivery order as observed by si. That is, for two messages m and m', m ≺i m' if and only if si delivers m before m' and no other messages in between. The first message si de-livers after joining the group is defined to have no predecessor in ≺i.

Property 4-24 (Total Order): For all stations si, sj and all messages m, m', and m''', if m ≺i m' and m ≺j m'', then m'' = m'.

This property requires that any two stations that have delivered the same message m de-liver the same sequence of messages afterwards until one of them stops dede-livering mes-sages. This means that partially valid or invalid stations either stop delivering messages or they deliver the same messages in the same order as the valid stations.

4.3.6.2 Operation of the Protocol

If a message has a resiliency smaller than OD, it is not ensured that the reliable multicast protocol delivers that message at all valid members. Thus, if a station delivers a reliable multicast it cannot be sure whether all valid members will deliver this message also.

Therefore, the atomic multicast protocol does not immediately deliver the messages it re-ceives from the reliable multicast protocol to its user. Rather, it delays the delivery until the protocol entity at the AP decides whether all members shall deliver the message (ac-cept decision) or not (reject decision). So, it is up to the AP to decide whether all members received an atomic multicast, in which case it decides to accept the message, or whether this might not be the case, in which case it decides to reject the message. After making the decision, the AP multicasts it in the synchronous channel. Upon reception of the decision, the members either deliver the atomic multicast message if the decision is accept, remove it if the decision is reject, or wait for another transmission attempt if the decision is no_dec. With all members acting according to the decisions of the AP, agreement is en-sured. Furthermore, as all members deliver the atomic multicasts in the order in which the AP accepts them, total order is accomplished as well.

To decide whether to accept or reject a message, the AP must know whether or not it can expect all members to have received this message. The acknowledgement mechanism of the reliable multicast protocol provides this information. Whenever the reliable multicast protocol stops transmitting a multicast message it indicates to the atomic multicast protocol whether

1. All group members acknowledged the message;

2. The message was transmitted OD+1 times;

3. The resiliency of the message was exceeded, and the resiliency was smaller than OD.

In cases 1. and 2., the AP decides to accept the message; in case 3., it rejects the message.

In case 1., the AP is sure that all members received the message because they all acknowl-edged it. In case 2., this is ensured because each valid member must have received the message after OD+1 transmission attempts by definition.

The AP uses the synchronous channel (Sub-section 4.3.5) to multicast its decision to the members. The properties of the synchronous channel ensure that all valid members receive the decisions in bounded time. Moreover, the members deliver the decisions according to the Strong FIFO property (Property 4-20). Thus, the members deliver the atomic multicasts in the order in which the AP accepts them. When the reliable multicast protocol sends a status indication for a message of some member (say, with ID IDk) and the atomic multi-cast protocol makes the corresponding decision (say, dk), the AP is just about to transmit a mc frame on behalf of the member. Thus, the synchronous channel protocol will solicit the atomic multicast protocol to multicast a decisions on behalf of that member. The atomic multicast protocol multicasts decision dk and all valid members will deliver dk together with the ID IDk. Hence, the members know that they have to accept or reject the last mes-sage originating from the member with ID IDk.

The delay bound ∆AtomcMC(r) of the atomic multicast protocol can be determined as follows:

If a message with resiliency r is multicast at time t, the latest possible time at which the message may be received and delivered to the atomic multicast protocol by some station is t' := t + ∆RelMC(r). The AP receives the acknowledgements for the last transmission of the message by time t'' := t' + ∆Round – δm. At this time, it multicasts its decision in the syn-chronous channel. So, each valid station will deliver and process the decision by time t''' := t'' + ∆SynchCh. Thus, the time bound can be computed as:

∆AtomcMC(r) := ∆RelMC(r) + ∆Round – δm + ∆SynchCh

= 2 × r × ∆Round + 2 × δm + ∆Round – δm + δm + OD × ∆Slot

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

≤ (2r + 1) × ∆Round + (OD + 1) × ∆Slot

4.3.6.3 Dynamic Groups Extensions

Now let us consider the new challenges that appear when considering dynamic groups. The main problem here is that we can no longer assume that a client is a valid group member right from the start of every atomic multicast transmission. Rather, when the AP adds a further client to the group, several atomic multicasts may be in progress; that is, for such atomic multicasts several transmission attempts may already have taken place, such that it cannot be guaranteed that the newly added client will receive these messages. This is not so much of a problem for atomic multicasts with a resiliency smaller than OD: If the AP does not get an acknowledgement for the message from all members (including the newly added one), it rejects it and no member will deliver it. But, if such a message has a iency of OD, the AP must decide to deliver it. Thus, for all atomic multicasts with resil-iency OD that are in progress when a client is added to the group, it could happen that the message is accepted but the new member cannot deliver it; we call such messages “pend-ing multicasts” henceforth. In particular, as long as a pend“pend-ing multicast exists, it could happen that a new member delivers some atomic multicasts and some not. Of course, a situation in which a new member delivers some atomic multicasts but does not deliver oth-ers, which all the other members deliver, should be avoided at any rate.

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.