1. Distributed systems Causal Broadcast
Prof R. Guerraoui
Distributed Programming Laboratory

2. Overview Intuitions: why causal broadcast?
Specifications of causal broadcast
Algorithms:
A non-blocking algorithm using the past and
A blocking algorithm using vector clocks

3. Broadcast A
deliver m B m
broadcast
deliver C

4. Intuitions (1)
So far, we did not consider ordering among messages; In particular, we considered messages to be independent
Two messages from the same process might not be delivered in the order they were broadcast
A message m1 that causes a message m2 might be delivered by some process after m2

5. Intuitions (2)
Consider a system of news where every new event that is displayed in the screen contains a reference to the event that caused it, e.g., a comment on some information includes a reference to the actual information
Even uniform reliable broadcast does not guarantee such a dependency of delivery
Causal broadcast alleviates the need for the application to deal with such dependencies

6. Modules of a process Applications (R-U) Causal broadcast
indication
Applications
request
(R-U) Causal broadcast
indication
request
indication
(R-U)Reliable broadcast
Failure detector
Channels

7. Overview Intuitions: why causal broadcast?
Specifications of causal broadcast
Algorithms:
A non-blocking algorithm using the past and
A blocking algorithm using vector clocks

8. Causal broadcast Events Request: <coBroadcast, m>
Indication: <coDeliver, src, m>
Property:
Causal Order (CO)

9. Causality
Let m1 and m2 be any two messages: m1 -> m2 (m1 causally precedes m2) iff
C1 (FIFO order). Some process pi broadcasts m1 before broadcasting m2
C2 (Local order). Some process pi delivers m1 and then broadcasts m2
C3 (Transitivity). There is a message m3 such that m1 -> m3 and m3 - > m2

10. Causal broadcast Events Request: <coBroadcast, m>
Indication: <coDeliver, src, m>
Property:
CO: If any process pi delivers a message m2, then pi must have delivered every message m1 such that m1 -> m2

11. Causality ? p1 p2 p3 delivery delivery m2 m1 delivery delivery m1 m2

12. Causality ? p1 p2 p3 delivery delivery m2 m1 delivery delivery m1 m2

13. Causality ? p1 p2 p3 delivery delivery m2 m1 delivery delivery m1 m2

14. Reliable causal broadcast (rcb)
Events
Request: <rcoBroadcast, m>
Indication: <rcoDeliver, src, m>
Properties:
RB1, RB2, RB3, RB4 + CO

15. Uniform causal broadcast (ucb)
Events
Request: <ucoBroadcast, m>
Indication: <ucoDeliver, src, m>
Properties:
URB1, URB2, URB3, URB4 + CO

16. Overview Intuitions: why causal broadcast?
Specifications of causal broadcast
Algorithms:
A non-blocking algorithm using the past and
A blocking algorithm using vector clocks

17. Algorithms
We present reliable causal broadcast algorithms using reliable broadcast
We obtain uniform causal broadcast algorithms by using instead an underlying uniform reliable broadcast

18. Algorithm 1 Implements: ReliableCausalOrderBroadcast (rco).
Uses: ReliableBroadcast (rb).
upon event < Init > do
delivered := past := ;
upon event < rcoBroadcast, m> do
trigger < rbBroadcast, [Data,past,m]>;
past := past U {[self,m]};

19. Algorithm 1 (cont’d) if m  delivered then
upon event <rbDeliver,pi,[Data,pastm,m]> do
if m  delivered then
(*) forall [sn, n] in pastm do
if n  delivered then
trigger < rcoDeliver,sn,n>;
delivered := delivered U {n};
past := past U {[sn, n]};

20. Algorithm 1 (cont’d) (*) … trigger <rcoDeliver,pi,m>;
delivered := delivered U {m};
past := past U {[pi,m]};

21. Algorithm 1 m1 m2 p1
m2(m1) m1 m2 p2 m1 m1
m2(m1) m1 p3 m2

22. Algorithm 1 m1 m2 p1
m2(m1) m1 m1 m2 p2 m1
m2(m1) m1 p3 m2

23. Uniformity Algorithm 1 ensures causal reliable broadcast
If we replace reliable broadcast with uniform reliable broadcast, Algorithm 1 would ensure uniform causal broadcast
What if we have best-effort with causality? Claim is that we would have anyway reliable bcast; assume the sender fails; some correct process p delivers m and some other q does not deliver m; Assume p bcasts another message message m’; then q needs to deliver m’ and then m also

24. Algorithm 1’ (gc) Implements: GarbageCollection (+ Algo 1). Uses:
ReliableBroadcast (rb).
PerfectFailureDetector(P).
upon event < Init > do
delivered := past := ;
correct := S;
ackm :=  (for all m);

25. Algorithm 1’ (gc – cont’d)
upon event < crash, pi > do
correct := correct \ {pi}
upon for some m  delivered: self  ackm do
ackm := ackm U {self};
trigger < rbBroadcast, [ACK,m]>;

26. Algorithm 1’ (gc – cont’d)
upon event <rbDeliver,pi,[ACK,m]> do
ackm := ackm U {pi};
if forall pj  correct: pj  ackm do
past := past \ {[sm, m]};
Assume pj gets acks from all but pi; and pi fails…
We would need to keep messages for pi…
Nobody will clean m
We should add the same after correct
What if the fd is not accurate? We violate causality
What if the fd is not complete? We do not clean certain messages

27. Algorithm 2 Implements: ReliableCausalOrderBroadcast (rco).
Uses: ReliableBroadcast (rb).
upon event < Init > do
for all pi  S: VC[pi] := 0;
pending := 
On se rappelle combien de messages on a vu de chaque processus
Et chaque message se rappelle du nombre de messages dans son passé

28. Algorithm 2 (cont’d) upon event < rcoBroadcast, m> do
trigger < rcoDeliver, self, m>;
trigger < rbBroadcast, [Data,VC,m]>;
VC[self] := VC[self] + 1;

29. Algorithm 2 (cont’d) upon event <rbDeliver, pj, [Data,VCm,m]> do
if pj ≠ self then
pending := pending  (pj, [Data,VCm,m]);
deliver-pending.

30. Algorithm 2 (cont’d) procedure deliver-pending is
While (s, [Data,VCm,m])  pending s.t.
for all pk: (VC[pk]  VCm[pk]) do
pending := pending  (s, [Data,VCm,m]);
trigger < rcoDeliver, self, m>;
VC[s] := VC[s] + 1.
On vérifie qu’il ne nous manque pas de messages

31. Algorithm 2 m1 m2 p1 m2 m1 m1 m2 p2 m1 m2
[0,0,0] m2
[1,0,0] p3 m1

32. Algorithm 2 p1 p2 p3 m1 m2 m1 [1,0,0] m2 m2 m1 m1 m2 [0,0,0] [1,0,0]