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

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring Topics for today Specifications Liveness and Safety A flashback from Data Structures: Hash functions if we have time - Skip Lists

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring 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

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring 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.

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring 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!

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring 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.

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring 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

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring 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

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring 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

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

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring Hash Functions – a reminder

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring Hash Functions K – set of keys from a universe U M = {0, …, m-1}, a set of cells h is a mapping from U to M A collision occurs between keys x and y if h(x) = h(y)

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring What is a "good" hash function? Creates a good distribution of hash values so that the keys are distributed evenly among the cells –good distribution = close to uniform –load balance Fast to compute Does not require much storage space For cryptographic hash functions: –one way: hard to invert –weak collision resistance: given x, it is hard to find y  x s.t. h(y)=h(x) –strong collision resistance: it is hard to find x and y s.t. y  x and h(x)=h(y) –and many more No standard set of requirements Many existing implementations, choice depends on –what is being hashed –what properties are needed –etc.

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring Hash Functions – Cont. A hash function h is perfect for a set K  U if h does not cause any collisions among the keys of the set K –If |K|  m for a given set K, constructing such a function is easy – just map each key to a different cell But, what if |U|>m? –some two keys from U will always map to the same cell –h cannot be perfect for a set K containing these two keys  No hash function h can be perfect for all possible K  U Conclusion: when we don’t know K in advance, we can’t construct a perfect h We need “near-perfect” hash functions K  U – set of keys h: U  M

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring Universal Hash Families The idea: construct a family of hash functions: H={h: U → M} While any one function h  H may not be perfect for many choices of K, but a uniformly chosen h will give a mapping with few collisions. H is called universal if for every pair of keys x,y  U (x  y), the number of functions h in H for which h(x)=h(y) is at most |H|/m Equivalent definition: for any x,y  U s.t. x  y and a hash function h chosen uniformly at random from H, it holds that Pr[h(x)=h(y)]  1/m Intuition: A totally random function has a collision probability of exactly 1/m Thus, a function h randomly chosen from a universal H gives a seemingly random function.

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring Load Balance with Universal Hash Families Using a hash function h chosen uniformly at random from a universal hash family H we can achieve good load balance. This means: The expected number of keys from |K| mapped to each cell by h is at most |K|/m Definition: let x, y be any two keys in U, and h  H H is universal

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring Load Balance – Cont. Lemma: for all x  U, K  U, and a function h chosen uniformly at random from a universal family H: Proof:

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring Constructing Universal Hash families Example 1 H = the set of all possible mappings from U to M Choosing h randomly from H is like having a random function h Hence, the probability for collision is 1/m  H is universal |H| = m |U| since each key in U has m mapping options Therefore, picking an h from H requires  (log|H|)=  (|U|·logm) random bits This is also the number of bits of storage required to represent the chosen h –at least need to remember which h we chose

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring Constructing Universal Hash families Example 2 choose a prime p  |U| g(x) = x mod m; f a,b (x) = ax + b (mod p) h a,b (x) = g(f a,b (x)) H = {h a,b | a,b  {0,1,…, p-1} with a  0} H is universal – proof in the books… For any k, there exists a prime p between k and 2k –Bertrand’s postulate (number theory) We can choose p to be O(|U|) (between |U| and 2|U|) To choose h from H we need to choose a and b  2logp = O(log|U|) bits h is efficient to choose, store and evaluate Other examples: in books and Data Structure courses...

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring Some remarks 1/2 There are other families of functions which give stronger guarantees. Strong-universal: Pr[h(x 1 )=y 1 and h(x 2 )=y 2 ] = 1/m 2 Most constructions give strong-universal "universal" is more precisely called "2-universal" –k-universal: (also called k-wise independent) –Example 1 is also an (inefficient) example of this family

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring Some remarks 2/2 The load-balancing property of universal hashing depends on the h being randomly chosen from H; the "adversary" does not know which one we chose But what if we need a single function, known to all? One alternative is Cryptographic hash functions –commonly used in practice –Examples: SHA-1, SHA-256, MD5 –Instead of no-collisions "with high probability", we get no-collisions "based on standard hardness assumptions"

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring Caching with Hash functions Suppose that –K is a set of web-pages –M is a set of servers Our goal: distribute the web-pages uniformly to the servers Use hashing!

Alex Shraer, Principles of Reliable Distributed Systems, Technion EE, Spring Any problems with this idea? In "classical" hash functions, the range of the function was fixed! –all hash functions we discussed so far Problem 1: what if the set of servers M changes ? –e.g., a server crashes or a new server joins the system Example: h(x) = ax+b (mod p) the range is {0,..., p-1}, so if a server joins, almost every web-page would need to be moved to a new location! Problem 2: what if a client computes the hash to find a web-page, but it knows only some subset of servers? Solution: Consistent Hashing ! –next lecture