220 likes | 495 Views
Coordination in Distributed Systems. Coordination Anecdotes. Decentralized, no coordination Aloha ~ 18% Some coordinating Master Slotted Aloha ~ 36% Impossibility of Concensus If the ether dropped your packets, we will never have concensus (lynch). Why is coordination important.
E N D
Coordination Anecdotes • Decentralized, no coordination • Aloha ~ 18% • Some coordinating Master • Slotted Aloha ~ 36% • Impossibility of Concensus • If the ether dropped your packets, we will never have concensus (lynch)
Why is coordination important • Resource Sharing • Database • Files • Agreement • Agree on an award for faculty • Agree on whether to take a quiz • Leader Election • Choose Time server • Choose Bus Master
Challenges • Host Failures • Link Failures • Time and Causual Ordering
Distributed Mutual Exclusion • Mutual Exclusion • Atmost one process in the critical section • What happens when processes are distributed • Let’s assume reliability first • Three messages • Enter(): I want to enter • ResourceAccess(): OK Go ahead access the critical section • Exit(): I am done
Requirements for Mutex • At most one process in the critical section • Everyone gets to access the critical section: Eventual grant • Global ordering: Difficult
Distributed Mutual Exclusion P1 P4 P3 P2
Centralized Algorithm • Single Coordinating Server • P can enter Critical Section (CS) if it has a grant TOKEN • Server Grants TOKEN • Processes Request TOKEN • GRANT if CS is free • Else queue • Grant to the oldest in the queue • Problems • Performance Bottleneck • Server Crash • Ordering?
Ring Based Coordination • Logical Ring • Typically based on network address • Pass token clockwise (other otherwise)
Ring based Coordination • No Master, no Centralized Server • Wait for TOKEN • If you want to enter CS • Grab Token • Access CS • Release and Pass along the TOKEN • Else • Pass along the Token • Problems: • Continuous Overhead • Must wait for N (worst case) before enter is granted • Ordering?
Ricarta&Agarwal Algo • Based on Reliable Multicast • Multicast to All Processes when you want to enter CS • If you hear an Ack from everyone • Enter CS • Else • Repeat • Ordering? • Timestamp multicast with Lamport Clocks • Use vector clocks for total ordering
Leader Election • Elect Unique Master • Typically after failure • Simulataneous Requests Allowed • Permissible States • Either No Leader • Or Well-known leader • Everyone must know about leader • All processes must participate in election and can discover leader
Ring coordination • Find the Master with the maximum UID • Receive UID • Pass max(Own UID, Nieghbor UID) • If you hear your UID again • You are the leader • Annouce yourself as the leader • Problems: • Two Iterations • Unique IDs assumed • Failure?
Itai&Rodeh Algo • Relaxes UID Requirement • Again Ring Based (unidirectional) • Election • Assign you’re an ID (from 1 … k) • Do the Chang algo • If no leader • Choose ID again • Termination? • Probablistic
Termination • Larger the K, larger your probability of assigning yourself a unique ID • N = 4, K=16 • Time to terminate: 1.01 rounds • Welcome to the power of randomization • Used in everyday things to make problems tractable • Think Ethernet
IEEE 1394: Firewire • High-speed synchronous Bus • Used on Sony Handycams • Bus Master Election Algorithm • Not a ring (actually a tree) • Hot Plug-n-Play: NO UIDs • Must elect master after a device is attached or removed
Algo • Start with Leaves • Send “adopt me” • Leave has only one egress link • If you hear n-1 “adopt me” messages • Forward the message to the Nth link • Why is probability used again for root detection?