1 / 21

Reliable Group Communication

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).

denzel
Download Presentation

Reliable Group Communication

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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. S: source • E.g, routers build shortest path spanning tree from a source network to all networks containing members of group (Dijkstra) R1 R4 R2 R5 R3 R7 R6

  3. 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.

  4. 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?

  5. 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.

  6. 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)

  7. 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.

  8. 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 )

  9. 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

  10. Atomic Multicast • Formulate reliable multicasting in the presence ofprocess 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.

  11. Example: replica updates • Reliable multicast to a group of processes, • Crash and recover to the same state as others

  12. Virtual Synchrony • Figure 8-12. The logical organization of a distributed system to • distinguish between message receipt and message delivery.

  13. 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)

  14. Virtual Synchrony (cont’d) • Note: here a totally ordered multicast is required.

  15. Virtual Synchrony

  16. 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.

  17. 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.

  18. 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

  19. Implementing Virtual Synchrony (1) • Process 4 notices that process 7 has crashed and sends a view change.

  20. Implementing Virtual Synchrony (2) Stable msg: m is received by all the processes • (b) Process 6 sends out all its unstable messages, followed by a flush message.

  21. Implementing Virtual Synchrony (3) • (c) Process 6 installs the new view when it has received a flush message from everyone else.

More Related