1. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 1 Principles of Reliable Distributed Systems Recitation 1: Introduction Spring 2006 Eddie Bortnikov

2. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 2 Last on 046272 Models –Synchronous and Asynchronous –Failure models (a little…) Specifications –Liveness and Safety The Coordinated Attack Problem Note: The proofs on the board are included in the course’s material –Yes, you should know them for the exam

3. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 3 Safety and Liveness The properties are verifiable on an execution’s trace Safety = a property always happens –Closed under all prefixes Liveness = a property eventually happens

4. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 4 Safety/Liveness/Both/None? ראש השנה חל בדיוק פעם אחת בשנה. היועץ המשפטי יוכל להתמנות לתפקיד שופט. נהג שצבר שלוש עבירות תנועה לא ינהג לפני שיעבור קורס נהיגה מונעת. אף תהליך לא יכול להשתמש ב CPU במשך זמן אינסופי. כל קריאה לפונקציה חוזרת. המשטרה תפנה את הצומת החסום, אבל זה ייקח לה לפחות חצי שעה. המשטרה תפנה את הצומת החסום תוך חצי שעה לכל היותר.

5. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 5 Coordinated Attack Let’s attack at noon tomorrow A B

6. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 6 The Synchronous Model Message loss can be detected –Bounded delay, timeouts Message loss is unbounded –In some runs, all the messages are lost

7. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 7 Coordinated Attack Definition (Reminder) Requirements: –both generals must decide the same: either to attack or not to attack –if both are not ready to attack they must not attack –if both are ready to attack and no messages are lost then they must attack Still cannot be achieved!

8. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 8 Properties of Coordinated Attack Agreement: If both generals decide, they decide the same. Termination: Every general eventually decides. Validity: –If both inputs are “not ready” then no general decides “attack” –if both inputs are “ready” and every message sent is delivered then no general decides “no-attack”.

9. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 9 What happens if? We modify the specification: –Strong Validity: If both inputs are “not ready” then no general decides “attack” if both inputs are “ready” and every message sent is delivered then no general decides “no-attack”. We want an algorithm that solves the problem where Agreement, Termination and Strong Validity are required.

10. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 10 What happens if? (cont’d) Weak Termination: If there are no message losses, then all processes eventually decide. We want an algorithm that solves the problem where Agreement, Weak Termination and Validity are required.

11. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 11 What happens if? (cont’d) Unanimous Termination: If any process decides, then all processes eventually decide. We want an algorithm that solves the problem where Agreement, Weak Termination, Unanimous Termination and Validity are required.

12. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 12 Where’s the difference? Why couldn’t we use the proof from class when only Weak Termination was used?

13. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 13 Stronger Models Bounded loss rate – take 1 –At most, 10 messages are lost on each channel (from general A to general B and vice versa). Is it enough?

14. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 14 Interfaces (Reminder) There are two generals A, B. Each has an input inp A, inp B  {“ready”, “not ready”} Possible actions for Q  {A, B}: –Decide Q (v), v  {“attack”, “no attack”} (Output) –Send Q (m), m  {“yes”, “no”} (Output) –Deliver Q (m) (Input)

15. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 15 Suggested Algorithm Each general performs the following: –Repeat 11 times: Send(inp) –Upon Deliver(m) Decide(this.inp & m.inp) Or any deterministic rule that matches validity –halt.

16. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 16 Stronger Models Bounded loss rate – take 2. –Each message sent is lost with probability p<1 (independently of other system events) Is this enough?

17. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 17 Stronger Models (cont’d) How about if we weaken the specification? –  -Agreement: If both generals decide, Pr( process A decides differently than B )   –We want an algorithm that solves the problem where Termination,  -Agreement, and Validity are required.

18. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 18 Suggested Algorithm Each general performs the following: –In each round do: If inp == “ready” then Send(“yes”), Decide(“attack”) Else, If Deliver(m) and not decided, then Decide(“attack”) –Repeat r rounds such that p r   –If not decided after r rounds, Decide(inp) –halt.

19. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 19 Algorithm Properties Validity and Termination are guaranteed. So is  -Agreement. This algorithm is not early-deciding –When the inputs are both “not-ready”, the decision is never made before r rounds.

20. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 20 To Summarize The exact model assumptions and the exact problem specification are critical –Minor changes in either lead to different results.