1. Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring 2008 1 Principles of Reliable Distributed Systems Recitation 1: Introduction Spring 2009 Alex Shraer

2. Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring 2008 2 Topics for today Specifications Liveness and Safety Coordinated Attack

3. Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring 2008 3 Safety and Liveness The properties are verifiable in an execution Safety = a property always happens –the program will never produce a wrong result –In all prefixes of a given execution –Even in the empty prefix (doing nothing doesn't violate safety) Liveness = a property eventually happens –the program will eventually produce a result

4. Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring 2008 4 Safety: those properties whose violation always has a finite witness (finite refutation) In other words: if every counter-example for a property p has a finite prefix in which p does not hold, then p is safety. A safety property cannot be “fixed” after it is violated. Liveness: those properties whose violation never has a finite witness (all counter-example traces are infinite) No mater what happens along a finite trace, something good could still happen later - you can always extend a trace to satisfy a livenes property. Safety and Liveness - Cont.

5. Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring 2008 5 Examples If the driver pushes the brakes of the car, it will eventually stop –if this is not true, how can we refute this? –the counter example will have the following form: driver pushes the breakes at some point, but the car never stops afterwards - an infinite execution –this is a liveness property The program terminates within 31 computational steps –a finite execution may violate this; this is a safety property! The program eventually terminates –only an infinite example can possibly refute this claim; liveness! Each process will enter its critical section infinitely often –This means: at any point of the run, each process will eventually enter its critical section (at some future point) (infinitely often = always eventually) –liveness!

6. Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring 2008 6 The meaning of liveness [Lamport 2000] The question of whether a real system satisfies a liveness property is meaningless; it can be answered only by observing the system for an infinite length of time, and real systems don’t run forever. Liveness is always an approximation to the property we really care about. We want a program to terminate within 100 years, but proving that it does would require addition of distracting timing assumptions. So, we prove the weaker condition that the program eventually terminates. This doesn’t prove that the program will terminate within our lifetimes, but it does demonstrate the absence of infinite loops.

7. Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring 2008 7 A non-safety and non-liveness property The machine provides infinitely often beer after initially providing sprite three times in a row This property consists of two parts: 1.it requires beer to be provided infinitely often this is a liveness property 2.the first three drinks it provides should all be sprite example of a bad prefix: one of first three drinks is beer this is a safety property This property is a conjunction of a safety and a liveness property

8. Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring 2008 8 Example - execution of an elevator system states floor: doors: buttons pushed: 1st closed none 1st closed 3rd floor 3rd open none 3rd closed 3rd floor call from 3rd floor moving up 2 floors open the doors make beep sound events: What is the trace of this execution? call from 3rd floor moving up 2 floors open the doors,, (infinite execution), make beep sound

9. Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring 2008 9 Predicates The doors are always open –False! Counter example: the prefix of the execution consisting of its first state If someone summons the elevator to some floor, the doors eventually open – True over our execution After doors open, the next action of the elevator is to make a beep sound –True over our execution The elevator may break after the 1 st year of use –not a property! cannot be evaluated over an execution Suppose that we add time to our model If someone summons the elevator to some floor: –The elevator will eventually stop –The elevator reaches that floor no later than 1 minute later

10. Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring 2008 10 Safety/Liveness/Both/None? הדלתות נפתחות לכל היותר שלוש פעמים מספר המנעולים שאחראי הבניין מתקין הוא לפחות 30. הדלתות נפתחות בדיוק שלוש פעמים היועץ המשפטי יוכל להתמנות לתפקיד שופט. נהג שצבר שלוש עבירות תנועה לא ינהג לפני שיעבור קורס נהיגה מונעת. כל קריאה לפונקציה חוזרת. המשטרה תפנה את הצומת החסום, אבל זה ייקח לה לפחות חצי שעה. המשטרה תפנה את הצומת החסום תוך חצי שעה לכל היותר.

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

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

13. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 13 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 no messages are lost then no general decides “no-attack”.

14. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 14 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. Each general performs the following: –Send(inp) –Upon Deliver(m) Decide(this.inp & m.inp) Or any deterministic rule that matches validity –halt

15. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 15 What happens if? (cont’d) Where’s the difference? Why couldn’t we use the proof from class when only Weak Termination was used? The proof shown in the lecture relies on the fact that all processes terminate (=decide), when we build the runs. Otherwise, the proof doesn’t work

16. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 16 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. –Homework

17. Eran Bergman & Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 17 Stronger Models Bounded loss rate –At most, 10 messages are lost on each channel (from general A to general B and vice versa). Is it enough? Each general performs the following: –Repeat 11 times: Send(my_vote) –Upon Deliver(other_vote) Decide(my_vote & other_vote) Or any deterministic rule that matches validity –halt.

18. Correctness of this Algorithm Agreement: If both generals decide, they decide on the “&” of their votes – the same Validity –if both votes are 0 (not attack), since 0&0 = 0, no general decides “attack” –If both votes are 1 (attack), since 1&1 = 1, no general decides “not attack” Termination –Each vote is sent 11 times. Since at most 10 can be lost, at least one message is delivered (to each general). Therefore, they both decide and halt. Aran Bergman/Eddie Bortnikov, Principles of Reliable Distributed Systems, Technion EE, Spring 2006 18

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