Reliable Group Communication
• Reliable Multicasting– Basic Reliable Multicasting – Scalable Reliable Multicasting
• Atomic multicast– Atomic multicast build on SRM– Virtual synchrony – Message ordering– Implementing Virtual synchrony
IP Multicast (vs overlay multicast)
• Multicast: a source sends a message to a group of nodes.– Can be multiple senders in a group
• Routers run multicast routing protocols to deliver datagram. • Separate group membership protocol to maintain group
membership information• Senders can share one tree or each has a tree.
R1
R2
R3
R4
R5
R6 R7
S: source• E.g, routers build shortest path spanning tree from a source network to all networks containing members of group (Dijkstra)
Reliable Multicasting
• Basic model: We have a multicast channel c with two (possibly overlapping) groups:– The sender group SND(c) of processes that submit messages
to channel c– The receiver group RCV(c) of processes that can receive
messages from channel c
• Simple reliability: If process P RCV(c) at the time ∈message m was submitted to c, and P does not leave RCV(c), m should be delivered to P
• Apply to :– To nonfaulty members– No need to be ordered.
About basic schemes• Scalability Issue
– ACK based• Feedback implosion
– NACK based • Sender buffer messages
• Other issues – Detecting missing– Re-transmit to a single or to all?– Membership management
• How does a source know all the receivers?• What is new receiver join during Multcasting?
Basic Reliable-Multicasting –ACK Based
• Reliable multicasting when all receivers are known and are assumed not to fail. -- sender waits for all the ACKs/NACKs.
• (a) Message transmission. (b) Reporting feedback.
• Does the basic scheme scale?
• Issues:– Detecting missing– Piggyback ACK/NACK. – Re-transmit to a single or to all?
– How does a source know all the receivers?– What is new receiver join during Multcasting?
• Scalability:– Receiving N ACKs. Feedback implosion.– NACK based scheme, sender buffer all msg. (delay may be
long)
Basic Reliable-Multicasting –NACK Based,w feedback suppression
• Each node suppress its own NACK, because, retransmission is a multicast• Use a random delay before sending NACK.• Several receivers have scheduled a request for retransmission, but the first retransmission request leads to
the suppression of others.
Some solutions
• Each node suppress its own NACK– random delay before sending NACK, cancel if
another requests.
SRM:• Sender heartbeats• Receiver issued recovery
– Receiver multicasts repair request– Nearest machine multicasts missed message
(recover )
Reliable Group Communication
• Reliable Multicasting– Basic Reliable Multicasting – Scalable Reliable Multicasting
• Atomic multicast– Atomic multicast build on SRM– Virtual synchrony – Message ordering
– Implementing Virtual synchrony
Atomic Multicast
• Formulate reliable multicasting in the presence of process failures in terms of process groups and changes to group membership:– Require:– Deliver to either all process or none at all– All messages are delivered in the same order to
all the processes.
• Guarantee: A message is delivered only to the nonfaulty members of the current group. All members should agree on the current group membership.
• Example: replica updates• Reliable multicast to a group of processes, • Crash and recover to the same state as others
Virtual Synchrony
• Figure 8-12. The logical organization of a distributed system to
• distinguish between message receipt and message delivery.
Virtual Synchrony• Group view G: a list of processes that a message m
should deliver to. – Each process has the same group view. – Processes can join and leave (announce through message vc)
Virtual Synchrony (cont’d)
– Note: here a totally ordered multicast is required.
Virtual Synchrony
Crashes
Observation: Virtually synchronous behavior can be seen independent from the ordering of message delivery. The only issue is that messages are delivered to an agreed upon group of receivers.
Implementing Virtual Synchrony
• Note:• Member failure is assumed to be detected and
subsequently multicast to the current view as a view change. That view change will not be carried out before all messages in the current view have been delivered.
Implementing Virtual Synchrony
• Each process needs to know that a message has been received by all the members in the group view before view change.– Sender crash
• Some nodes may not received m
– Receiver crash• Update after recover
• A general scheme:– Stable message – received by all
Implementing Virtual Synchrony (1)
• Process 4 notices that process 7 has crashed and sends a view change.
Implementing Virtual Synchrony (2)
• (b) Process 6 sends out all its unstable messages, followed by a flush message.
Stable msg: m is received by all the processes
Implementing Virtual Synchrony (3)
• (c) Process 6 installs the new view when it has received a flush
message from everyone else.
