Communication - University of British Columbia
Download
Report
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