Distributed Programming for Dummies A Shifting Transformation Technique Carole Delporte-Hallet, Hugues Fauconnier, Rachid Guerraoui, Bastian Pochon

Agenda Motivation Failure patterns Interactive Consistency problem Transformation algorithm Performance Conclusions

Motivation Distributed programming is not easy

Motivation Provide programming abstractions Hide low level detail Allow working on a strong model Give weaker models automatically

Models Distributed programming semantics and failure patterns

Processes We have n distributed processes All processes are directly linked Synchronized world In each round, each process: 1. Receive an external input value 2. Send a message to all processes 3. Receive all messages sent to it 4. Local computation and state change

PSR Perfectly Synchronized Round-based model Processes can only have atomic failures They are only allowed to crash/stop They can only crash if they are not in the middle of sending out a message

Crash Processes can only have crash failures They are only allowed to crash/stop They can also crash in the middle of sending out a message A message might be sent only to several other processes upon a crash

Omission Processes can have crash failures Processes can have send-omission failures They can send out a message to only a subset of processes in a given round

General Processes can have crash failures Processes can have general-omission failures They can fail to send or receive a message to or from a subset of processes in a given round

Failure models PSR(n,t) Crash(n,t) Omission(n,t) General(n,t) We’d like to write protocols for PSR and run them in weaker failure models

Interactive Consistency An agreement algorithm

Interactive Consistency Synchronous world We have n processors Each has a private value We want all of the “good” processors to know the vector of all values of all the “good” processors Let’s assume that faulty processors can only lie about their own value (or omit messages)

IC Algorithm a d b c A

IC Algorithm: 1 st step a d b c Each client sends “my value is p” message to all clients BCDBCD

IC Algorithm: 2 nd step a d b c Each client sends “x told my that y has the value of z; y told me that …” B, B(c), B(d) C, C(b), C(d) D, D(b), D(c)

IC Algorithm: i th step a d b c B, B(c), B(d), B(c(d)), … C, C(b), C(d), … D, D(b), D(c) Each client sends “x told my that y told me that z has the value of q; y told me that …”

IC Algorithm: and faults? When a processor omits a message, we just assume NIL as his value Example: NIL(b(d)) “d said nothing about b’s value”

IC Algorithm: deciding Looking at all the “rumors” that a knows about the private value of b We choose the rumor value if a single one exists or NIL otherwise If b is non-faulty, then we have B or NIL as its results If b is faulty, then a and c will have the same value for it (single one or NIL result)

IC Algorithm We need k+1 rounds for k faulty processes We’re sending out a lot of messages

PSR Synchronous model We are not going to do anything with this Performance Automatically transforming a protocol from PSR to a weaker model is costly We are going to deal only with time

Why? IC costs t+1 rounds PSR of K rounds costs K(t+1) rounds Optimizations of IC can do 2 rounds for failure-free runs Now we get to K rounds in 2K+f rounds for actual f failures We would like to get K+C rounds

Transformation Algorithm

The algorithm If a process realizes it is faulty in any way – it simulates a crash in PSR We run IC algorithms in parallel, starting one in each round for each PSR round There can be several IC algorithms running in parallel at the same time Each process runs the algorithm of all processes to reconstruct the failure patterns

The algorithm for phase r do input:= receiveInput() start IC instance r with input execute one round for all pending IC instances for each decided IC do update states, decision vector and failures list modify received message by faulty statuses simulate state transition for all processes

Knowledge algorithm Each process sends only its input value The protocol executed on all other processes is known to him He can execute the protocols of other processes by knowing their input values only

Extension No knowledge of other processes’ protocols We now send out both the input and the message we would normally send out This is done before we really know our own state  we are running several rounds in parallel

One small problem… Since we don’t know our state, how can we continue to the next round? We send out extended set of states All of the states we might come across in our next few rounds of computation Compute the future in all of them and optimize as we get more messages

State of the process Until now, the input values did not depend on the state of the process For a finite set of inputs, we can again use the same technique for an extended set of inputs

Performance Not real…

Number of rounds We need K+f phases Result for the first IC round takes f+2 phases All of our rounds are at a 1-phase interval

Size of messages For the simple algorithm suggested: nlog 2 |Input|per process, per round, per IC n  log 2 |Input|per process, per phase  - the number of phases needed to decide an IC

Size of messages For the extended transformation: 2 n  possible states in a phase A coded state takes  =2log 2 |State|+(n+1)log 2 |Message| Message size is  n  2 n  Long…

Conclusions

Summary We showed how to translate PSR into 3 different weaker models We can try doing the same for the Byzantine model