Message Ordering and Group Communications Course: Distributed Computing Faculty: Dr. Rajendra Prasath Spring 2019
About this topic This course covers various concepts in Message Ordering and Group communication in Distributed Systems. We will also focus on different models of communications and their pros and cons 2 Rajendra, IIIT Sri City
RECAP What did you learn so far? What did you learn so far? è Challenges in Message Passing systems è Distributed Sorting è Space-Time Diagram è Partial Ordering / Total Ordering è Causal Ordering - Precedence Relations è Concurrent Events è Local Clocks and Vector Clocks è Distributed Snapshots è Termination Detection using Dist. Snapshots è Leader Election Problem in Rings 3 Rajendra, IIIT Sri City
opic … Recent Recent Topic è Topology Abstraction and Overlays è Various Interconnection Topologies è Abstraction - Basic Concepts è Interconnection Patterns suitable for message propagation è Types of Algorithms and their executions è Measures and Metrics è Many more to come up … stay tuned in !! 4 Rajendra, IIIT Sri City
Topics to focus on opics to focus on … For Mid Semester 2 è Leader Election in Distributed Systems è Topology Abstraction and Overlays è Message Ordering è Group Communication è Distributed Mutual Exclusion è Deadlock Detection è Check pointing and rollback recovery 5 Rajendra, IIIT Sri City
Message Ordering / Group Communication 6 Rajendra, IIIT Sri City
Models of Models of Communication Communication è One – to – One Unicast è 1 – 1 è Point – to – point è Anycast è 1 – nearest 1 of several identical nodes è è One – to – Many Multicast è 1 – many è Group Communication è Broadcast è 1 – All è 7 Rajendra, IIIT Sri City
Gr Groups oups è Why groups? Groups allow us to deal with a collection of processes è as one abstraction è Send message to one entity Deliver to entire group è è Groups are dynamic Created and destroyed è Processes can join or leave è May belong to 0 or more groups è è Primitives join_group, leave_group, send_to_group, è query_membership 8 Rajendra, IIIT Sri City
Design Issues Design Issues Closed vs. Open Closed: only group members can sent messages è Peer vs. Hierarchical Peer: each member communicates with group è Hierarchical: go through dedicated coordinator(s) è Diffusion: send to other servers & clients è Managing membership & group creation/deletion Distributed vs. centralized è Leaving & joining must be synchronous Fault tolerance Reliable message delivery? What about missing è members? 9 Rajendra, IIIT Sri City
Failur ailures es è Crash failure Process stops communicating è è Omission failure (typically due to network) Send omission: A process fails to send messages è Receive omission: A process fails to receive messages è è Byzantine Failure Some messages are faulty, including sending fake è messages è Partition Failure The network may get segmented, dividing the group è into two or more unreachable sub-groups 10 Rajendra, IIIT Sri City
Multiple Unicasts Multiple Unicasts è Sender knows Group members 11 Rajendra, IIIT Sri City
Hier Hierar archical chical è Multiple unicasts via group coordinator è coordinator knows group members 12 Rajendra, IIIT Sri City
Atomic Multicast Atomic Multicast è Atomicity è Message sent to a group arrives at all group members If it fails to arrive at any member, no member will è process it è Problems è Unreliable network Each message should be acknowledged è Acknowledgements can be lost è Message sender might die è 13 Rajendra, IIIT Sri City
How to achieve How to achieve Atomicity? Atomicity? è General Idea Ensure that every recipient acknowledges receipt of è the message Only then allow the application to process the è message If we give up on a recipient then no recipient can è process the received message è Easier said than done! What if a recipient dies after acknowledging the è message? Is it obligated to restart? è If it restarts, will it know to process the message? è What if the sender (or coordinator) dies partway è through the protocol? 14 Rajendra, IIIT Sri City
Achieving Achieving Atomicity Atomicity – An Example An Example Retry through network failures & system downtime Sender & receivers maintain a persistent log è Each message has a unique ID so we can discard duplicates è Sender è – sends the message to all group members – Writes the message to log – Waits for acknowledgement from each group member – Writes the acknowledgement to log – If timeout on waiting for an acknowledgement, retransmit to group member Receiver logs received non-duplicate message to persistent è log and sends an acknowledgement NEVER GIVE UP! – Assume that dead senders or receivers will be rebooted and will restart where they left off 15 Rajendra, IIIT Sri City
Reliable multicast Reliable multicast All non-faulty group members will receive the message Ø Assume sender & recipients will remain alive Ø Network may have glitches - Retransmit undelivered messages Acknowledgements Ø Send message to each group member Ø Wait for acknowledgement from each group member Ø Retransmit to non-responding members Ø Subject to feedback implosion Negative acknowledgements Ø Use a sequence number on each message Ø Receiver requests retransmission of a missed message Ø More efficient but requires sender to buffer messages indefinitely 16 Rajendra, IIIT Sri City
Acknowledgements Acknowledgements Easiest thing is to wait for an ACK before sending the next message – But that incurs a round-trip delay Optimizing – Pipelining § Send multiple messages – receive ACKs asynchronously § Set timeout – retransmit message for missing ACKs – Cumulative ACKs § Wait a little while before sending an ACK § If you receive others, then send one ACK for everything – Piggybacked ACKs § Send an ACK along with a return message TCP does all of these … but now we have to do this on each recipient 17 Rajendra, IIIT Sri City
Message Or Message Ordering dering How to order messages? Send vs Delivery Global Time Ordering Total Ordering Causal Ordering Sync Ordering FIFO Ordering Unordered multicast Good / Bad Ordering 18 Rajendra, IIIT Sri City
Good Or Good Ordering dering An Example 19 Rajendra, IIIT Sri City
Bad Or Bad Ordering dering An Example 20 Rajendra, IIIT Sri City
Good Or Good Ordering dering Another Example 21 Rajendra, IIIT Sri City
Bad Or Bad Ordering dering An Example 22 Rajendra, IIIT Sri City
Send vs. Send vs. Delivery of Delivery of Messages Messages Multicast receiver algorithm decides when to deliver a message to a process A received message may be: delivered immediately (put on a delivery queue that the process reads) placed on a hold-back queue (because we need to wait for an earlier message) rejected/discarded (duplicate or earlier message that we no longer want) 23 Rajendra, IIIT Sri City
An Illustr An Illustration ation Sending, delivering and holding back 24 Rajendra, IIIT Sri City
Global Global Time Or Time Ordering dering All messages arrive in exact order sent Assumes that two events never happen at exactly the same time! Why Not? No global clocks … right? Difficult (impossible) to achieve 25 Rajendra, IIIT Sri City
Total Or otal Ordering dering Consistent ordering everywhere All messages arrive at all group members in the same order They are sorted in the same order in the delivery queue Two Conditions: If a process sends m before m’ then any other process that delivers m’ will have delivered m If a process delivers m’ before m” then every other process will have delivered m’ before m” 26 Rajendra, IIIT Sri City
Total Or otal Ordering - Implementation dering - Implementation How to implement this? Attach unique totally sequenced message ID Receiver delivers a message to the application only if it has received all messages with a smaller ID 27 Rajendra, IIIT Sri City
Causal Or ausal Ordering dering Partial ordering Messages sequenced by Lamport or Vector timestamps Condition: If multicast(G, m) → multicast(G, m’) then every process that delivers m’ will have m delivered already If message m’ is causally dependent on the message m, then all processes must deliver m before m’ 28 Rajendra, IIIT Sri City
Causal ausal vs vs Concurr Concurrent ent An illustrative example 29 Rajendra, IIIT Sri City
Causal Or ausal Ordering - Implementation dering - Implementation How to implement CO? P i receives a message from P j Each process keeps a precedence vector (similar to vector timestamp) Vector is updated on multicast send and receive events Each entry = number of the latest message from the corresponding group member that causally precedes the event 30 Rajendra, IIIT Sri City
Recommend
More recommend
