Download - Reliable Group Communication
![Page 1: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/1.jpg)
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
![Page 2: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/2.jpg)
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)
![Page 3: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/3.jpg)
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.
![Page 4: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/4.jpg)
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?
![Page 5: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/5.jpg)
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.
![Page 6: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/6.jpg)
• 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)
![Page 7: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/7.jpg)
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.
![Page 8: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/8.jpg)
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 )
![Page 9: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/9.jpg)
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
![Page 10: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/10.jpg)
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.
![Page 11: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/11.jpg)
• Example: replica updates• Reliable multicast to a group of processes, • Crash and recover to the same state as others
![Page 12: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/12.jpg)
Virtual Synchrony
• Figure 8-12. The logical organization of a distributed system to
• distinguish between message receipt and message delivery.
![Page 13: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/13.jpg)
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)
![Page 14: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/14.jpg)
Virtual Synchrony (cont’d)
– Note: here a totally ordered multicast is required.
![Page 15: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/15.jpg)
Virtual Synchrony
![Page 16: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/16.jpg)
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.
![Page 17: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/17.jpg)
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.
![Page 18: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/18.jpg)
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
![Page 19: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/19.jpg)
Implementing Virtual Synchrony (1)
• Process 4 notices that process 7 has crashed and sends a view change.
![Page 20: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/20.jpg)
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
![Page 21: Reliable Group Communication](https://reader033.vdocument.in/reader033/viewer/2022061603/56814944550346895db69025/html5/thumbnails/21.jpg)
Implementing Virtual Synchrony (3)
• (c) Process 6 installs the new view when it has received a flush
message from everyone else.