Transcript Communication - University of British Columbia

Lecture 13
Synchronization (cont)
Logistics

Last quiz



Project




Max: 69 / Median: 52 / Min: 24
In a box outside my office
P01 deadline in a week
Coding session / office hours: Wednesday?
Non-blocking IO lecture: Nov 4th.
Next quiz

Tuesday 16th.


Remembrance day: Nov 11th.
No class on Nov 18th
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


Design the system to take drift into account


Example: GPS systems
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 S1 and S2 at local
times t1 and t2.

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 Pi maintains a local counter Ci and
adjusts this counter according to the following rules:






(1) For any two successive events that take place within process Pi
the counter Ci is incremented by 1.
(2) Each time a message m is sent by process Pi the message
receives a timestamp ts(m) = Ci
(3) Whenever a message m is received by a process Pj, Pj adjusts its
local counter Cj to max{Cj, 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
Physical Time
p 1
0
1
2
8
7
1
p 2
p 3
0
2
0
8
3
3
2
3
6
4
9 10
7
5
4
p 4
n
0
5
6
Clock Value
timestamp
Message
EECE 411: Design of Distributed Software Applications
7
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


Process Pi sends timestamped message msgi to all others. The message
itself is put in a local queue queuei.
Any incoming message at Pk is queued in queuek, according to its
timestamp, and acknowledged to every other process.
Pk delivers a message msgi to its application if:


msgi is at the head of queuek
for each process Px, there is a message msgx in queuek with a larger timestamp.
Guarantee: all the multicasted messages are delivered in the same
order at all destinations.

Deliver to
application

Sending /
Receiving
Totally Ordered Multicast – Algorithm
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 weEECE
drop
FIFO Software
assumption?
411:channel
Design of Distributed
Applications
More quiz-like questions

What happens if we drop channel reliability 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


How would you change the previous protocol to still work
correctly without this assumption?
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
EECE 411: Design of Distributed Software Applications