Lecture 13 Synchronization (cont)

EECE 411: Design of Distributed Software Applications Logistics Last quiz Max: 69 / Median: 52 / Min: 24 In a box outside my office Project P01 deadline in a week Coding session / office hours: Wednesday? Non-blocking IO lecture: Nov 4 th. Next quiz Tuesday 16 th. Remembrance day: Nov 11 th. No class on Nov 18 th

EECE 411: Design of Distributed Software Applications Today Clocks can not be perfectly synchronized. What can I do in these conditions? Figure out how large is the drift Example: GPS systems Design the system to take drift into account Example: server design to provide at-most-once semantics Do not use physical clocks! Consider only event order - Logical clocks

EECE 411: Design of Distributed Software Applications Logical clocks -- Time Revisited What’s important? The precise time an event occurred? The order in which events occur? Our examples: Two shooters in a multiplayer online game shoot (and kill) the same target. Need to decide who gets the point? Object A is observed from two vantage points S 1 and S 2 at local times t 1 and t 2. Need to aggregate everything into one consistent view. Which way is A moving? How fast? Fairness vs. correctness tradeoffs?

EECE 411: Design of Distributed Software Applications “Happens-before” relation Problem: We need to introduce a notion of ordering before we can order anything. The happened-before relation on the set of events in a distributed system: if a and b in the same process, and a occurs before b, then a → b if a is an event of sending a message by a process, and b receiving same message by another process then a → b Notation: a → b, when all participants agree that b occurs after a. Property: transitive Two events are concurrent if nothing can be said about the order in which they happened (partial order)

EECE 411: Design of Distributed Software Applications Logical clocks Problem: How do we maintain a global view on the system’s behavior that is consistent with the ‘happened-before’ relation? Solution: attach a timestamp C(e) to each event e, satisfying the following properties: P1: If a and b are two events in the same process, and a → b, then we demand that C(a) < C(b). P2: If a corresponds to sending a message m, and b to the receipt of that message, then also C(a) < C(b). Note: C must only increase Problem: Need to attach timestamps to all events in the system (consistent with the rules above) when there’s no global clock Idea: maintain a consistent set of logical clocks, one per process.

EECE 411: Design of Distributed Software Applications Logical clocks (cont) -- Lamport’s Approach Solution: Each process P i maintains a local counter C i and adjusts this counter according to the following rules: (1) For any two successive events that take place within process P i the counter C i is incremented by 1. (2) Each time a message m is sent by process P i the message receives a timestamp ts(m) = C i (3) Whenever a message m is received by a process P j, P j adjusts its local counter C j to max{C j, ts(m)} + 1; then passes m to the application. Property P1 is satisfied by (1); Property P2 by (2) and (3). Note: it can still occur that two events happen at the same time. Avoid this by breaking ties through process IDs.

EECE 411: Design of Distributed Software Applications Updating Lamport’s logical timestamps p 1 p 2 p 3 p n Clock Value Message timestamp Physical Time

EECE 411: Design of Distributed Software Applications Architectural view Middleware layer in charge of: Stamping messages with clock times, reading timestamps Local management of logical clocks (i.e., updating clocks) Message ordering (if necessary)

EECE 411: Design of Distributed Software Applications Example use: Totally ordered group communication Two accounts: Initial state: $100 account balance Update 1: add $100 Update 2: add 1% monthly interest Updates need to be performed in the same order at the two replicas? Middleware layer that provides total ordering

EECE 411: Design of Distributed Software Applications Totally ordered group communication (cont) Solution: Each message is timestamped with local logical time then multicasted When multicasted, also message logically sent to the sender itself When receiving, the middleware layer Adds message to a queue Acknowledges (using multicast) the message Delivers from queue to application only when all acks are received

EECE 411: Design of Distributed Software Applications Totally Ordered Multicast – Algorithm Process P i sends timestamped message msg i to all others. The message itself is put in a local queue queue i. Any incoming message at P k is queued in queue k, according to its timestamp, and acknowledged to every other process. P k delivers a message msg i to its application if: msg i is at the head of queue k for each process P x, there is a message msg x in queue k with a larger timestamp. Guarantee: all the multicasted messages are delivered in the same order at all destinations. Nothing is guaranteed about the actual order! Note: We assume that communication is reliable and FIFO ordered. Quiz-like questions: What happens if we drop channel reliability assumption? What happens if we drop channel FIFO assumption? Sending / Receiving Deliver to application

EECE 411: Design of Distributed Software Applications More quiz-like questions What happens if we drop channel reliability assumption? How would you change the previous protocol to still work correctly without this assumption? What happens if we drop channel FIFO assumption? How would you change the previous protocol to still work correctly without this assumption? What’s the complexity of the protocol in terms of number of messages Can the number of messages be reduced? Assume you have a bound on message propagation time in the network. Design a protocol that provides total ordering (and generates less traffic)

EECE 411: Design of Distributed Software Applications So far … Physical clocks Two applications Provide at-most-once semantics Global Positioning Systems ‘Logical clocks’ Where only ordering of events matters