1 / 73

Distributed Algorithms: Agreement Protocols

Explore distributed algorithms for consensus and agreement problems, including mutual exclusion, election, and transactions. Learn about the challenges of fault tolerance and authenticated vs non-authenticated messages.

peachey
Download Presentation

Distributed Algorithms: Agreement Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Distributed Algorithms:Agreement Protocols

  2. Problems of Agreement • A set of processes need to agree on a value (decision), after one or more processes have proposed what that value (decision) should be • Examples: • mutual exclusion, election, transactions • Processes may be correct, crashed, or they may exhibit arbitrary (Byzantine) failures • Messages are exchanged on an one-to-one basis, and they are not signed

  3. Consensus and related problems • System model • N processes {p1, p2, ..., pN} • Communication is reliable but processes may fail • At most f processes out of N may be faulty. • Crash failure • Byzantine failure (arbitrary) • The system is logically fully connected • A receiver process knows the identity of the sender process • Limiting faults solely to the processes simplifies the solution to the agreement problems • Recently agreement problems have been studied under the failure of communication channels only & under the failure of both process & communication channels

  4. Authenticated & Non-authenticated messages • To reach an agreement, processes have to exchange their values and relay the received values to other procs • Authenticated or signed message system – A (faulty) process cannot forge a message or change the contents of a received message (before it relays the message to other). • A process can verify the authenticity of a received message • Non-authenticated or unsigned or oral message – A (faulty) process can forge a message and claimed to have received it from another process or change the contents of a received message before it relays the message to other. • A process has no way of verifying the authenticity of a received message

  5. Two Agreement Problems • Consensus problem: • N processes agree on a value (e.g. synchronized action – go / abort) • Consensus may have to be reached in the presence of failure • Process failure – crash/fail-stop, arbitrary failure • Communication failure • All process i starts in an “undecided” state • Every process i proposes a value vi , from a set D while in the undecided state. • Process i exchanges messages until it makes decision di and moves to decided state. • A consensus is reached if all correct processes agree on the same value di

  6. Consensus Requirements • Termination: Eventually each correct process sets its decision value • This may not be possible in the presence of process crashes in asynchronous system • Agreement: The decision value is same for all correct processes • Arbitrary (Byzantine) failures may cause inconsistency and prevent agreement • Integrity: if all correct processes propose the same value, any correct process decides that value • Consensus may involve a proposal stage and an agreement stage

  7. Byzantine Generals Problem • Proposed and solved by Lamport • Consider a battle ground. There are a number of generals at different positions and want to reach an agreement in their attack plan, i.e, “attack” or “retreat”. • Generals are separated geographically and communicate through messengers. Some of the generals are “loyal” and some are “traitors”. • Upper bound on number of traitors • Pease et al. showed that it is impossible to reach a consensus if f exceeds (N-1)/3

  8. Byzantine Generals Problem • “Byzantine generals” problem: a “commander” process i orders value v. • The “lieutenant” processes must agree on what the commander ordered. • Processes may be faulty • provide wrong or contradictory messages • Integrity requirement: • A distinguished process decides a value for others to agree upon • Solution only exists if N > 3f, where f : #faulty processes • Differs from consensus in that a distinguished process supplies a value that the others are to agree upon, instead of each of them proposing a value

  9. Byzantine Generals Problem • Requirements • Termination: Eventually each process sets its decision variable • Agreement: The decision value of all correct processes is the same • Integrity: If the commander is correct, then all correct processes agree on the value the commander proposed Note: integrity implies agreement when the commander is correct; but the commander need not be correct

  10. IC: A Variant of Consensus • Interactive Consistency Problem • Every process proposes a single value. • The goal of the algorithm is for the correct processes to agree on a vector of values, one for each process – the “decision vector” • Ex – for each of a set of processes to obtain the same information about their respective states

  11. IC: A Variant of Consensus • Requirements • Termination: Eventually each process sets its decision variable • Agreement: The decision vector of all correct processes is the same • Integrity: If pi is correct, then all correct processes agree on vi as the ith component of its vector

  12. Relationship between C, BG & IC • Although it is common to consider the BG problem with arbitrary process failures, in fact each of the three problems – C, BG, & IC – is meaningful in the context of either arbitrary or crash failures • Each can be framed assuming either a synchronous or an asynchronous system • It is sometimes possible to derive a solution to one problem using a solution to another

  13. Relationship between C, BG & IC • Suppose that there exist solutions to C, BG & IC • Ci(v1, v2, … vN) returns the decision value of pi in a run of the solution to the consensus problem where v1, v2, … are the values that the processes proposed • BGi(j, v) returns the decision value of pi in a run of the solution to the BG problem, where pj, the commander proposed the value v • ICi(v1, v2, … vN)[ j ] returns the jth value in the decision vector of pi in a run of the solution to the IC problem, where v1, v2, … are the values that the processes proposed • It is possible to construct solutions out of the solutions to other problems

  14. Relationship between C, BG & IC • IC can be solved by using BG’s solution by running it N times, once with each process pi (i = 1, 2, … N) acting as the commander: • ICi(v1, v2, … vN)[ j ] = BGi(j, v)(i = 1, 2, … N) • C can be solved by using IC’s solution by running IC to produce a vector of values at each process, then applying an appropriate function on the vector’s values to derive a single value: • Ci(v1, v2, … vN) = majority(ICi(v1, v2, … vN)[1], … ICi(v1, v2, … vN)[N] ) • BG can be solved from C as follows: • The commander pj sends its proposed value v to itself and each of the remaining processes • All processes run C with values v1, v2, … vN that they receive (pj may be faulty) • They derive BGi(j, v) = Ci(v1, v2, … vN) (i = 1, 2, … N)

  15. Consensus • Solving consensus is equivalent to solving reliable and totally ordered multicast • Given a solution to one, we can solve the other • Implementing consensus with RTO-multicast • Collect all processes into a group g • Each process piperforms RTO-multicast(g, vi) • Each process pi chooses di = mi, where mi is the first value that pi RTO-delivers • Termination property follows from the reliability of the multicast • The agreement and integrity properties follow from the reliability and total ordering of multicast delivery • Chandra & Toueg [1996] demonstrates how RTO-multicast can be derived from consensus

  16. Consensus in a synchronous system • We discuss an algorithm that uses only a basic multicast protocol to solve consensus in a synchronous system • The algorithm assumes that up to f of the N processes exhibit crash failures

  17. Communication Model • Complete graph (i.e. logically fully connected) • Synchronous, network

  18. a Multicast a a a Send a message to all processors in one round

  19. a a a a At the end of round: everybody receives a

  20. Multicast a b a b a a b b Two or more processes can multicast at the same round

  21. a,b b a,b a,b a

  22. Crash Failures a Faulty processor a a a

  23. a Faulty processor a Some of the messages are lost, they are never received

  24. a Faulty processor a

  25. Consensus 0 Start 1 4 3 2 Everybody has an initial value

  26. 3 Finish 3 3 3 3 Everybody must decide the same value

  27. 1 1 1 1 1 1 1 1 1 1 Validity condition: If everybody starts with the same value they must decide that value Finish Start

  28. A simple algorithm using B-multicast Each processor: • B-multicast value to all processors • Decide on the minimum (only one round is needed)

  29. Start 0 1 4 3 2

  30. 0,1,2,3,4 0 B-multicast values 0,1,2,3,4 0,1,2,3,4 1 4 0,1,2,3,4 3 2 0,1,2,3,4

  31. Decide on minimum 0,1,2,3,4 0 0,1,2,3,4 0,1,2,3,4 0 0 0,1,2,3,4 0 0 0,1,2,3,4

  32. Finish 0 0 0 0 0

  33. 1 1 1 1 1 1 1 1 1 1 This algorithm satisfies the validity condition Finish Start If everybody starts with the same initial value, everybody decides on that value (minimum)

  34. Consensus with Crash Failures The simple algorithm doesn’t work Each processor: • B-multicast value to all processors • Decide on the minimum

  35. 0 fail Start 0 1 0 4 3 2 The failed processor doesn’t multicast its value to all processors

  36. 0 Multicasted values fail 0,1,2,3,4 1,2,3,4 1 4 0,1,2,3,4 1,2,3,4 3 2

  37. Decide on minimum 0 fail 0,1,2,3,4 1,2,3,4 0 1 0,1,2,3,4 1,2,3,4 0 1

  38. 0 fail Finish 0 1 0 1 No Consensus!!!

  39. If an algorithm solves consensus for f failed process we say it is: an f-resilient consensus algorithm

  40. 0 1 2 Finish Start 1 3 4 1 The input and output of a 3-resilient consensus algorithm Example:

  41. 1 1 1 Finish Start 1 1 1 1 New validity condition: if all non-faulty processes start with the same value then all non-faulty processes decide that value

  42. An f-resilient algorithm Round 1: B-multicast my value Round 2 to round f+1: Multicast any new received values End of round f+1: Decide on the minimum value received

  43. Example: f=1 failures, f+1 = 2 rounds needed 0 Start 1 4 3 2

  44. Example: f=1 failures, f+1 = 2 rounds needed 0 Round 1 fail 0 0,1,2,3,4 1,2,3,4 1 0 4 (new values) 0,1,2,3,4 1,2,3,4 3 2 B-multicast all values to everybody

  45. Example: f=1 failures, f+1 = 2 rounds needed Round 2 0,1,2,3,4 0,1,2,3,4 1 4 0,1,2,3,4 0,1,2,3,4 3 2 B-multicast all new values to everybody

  46. Example: f=1 failures, f+1 = 2 rounds needed Finish 0,1,2,3,4 0,1,2,3,4 0 0 0,1,2,3,4 0,1,2,3,4 0 0 Decide on minimum value

  47. Example: f=2 failures, f+1 = 3 rounds needed 0 Start 1 4 3 2 Another example execution with 3 failures

  48. Example: f=2 failures, f+1 = 3 rounds needed 0 Round 1 Failure 1 1,2,3,4 1,2,3,4 1 0 4 0,1,2,3,4 1,2,3,4 3 2 Multicast all values to everybody

  49. Example: f=2 failures, f+1 = 3 rounds needed 0 Round 2 Failure 1 0,1,2,3,4 1,2,3,4 1 4 0,1,2,3,4 1,2,3,4 3 2 Failure 2 Multicast new values to everybody

  50. Example: f=2 failures, f+1 = 3 rounds needed 0 Failure 1 Round 3 0,1,2,3,4 O, 1,2,3,4 1 4 0,1,2,3,4 0,1,2,3,4 3 2 Failure 2 Multicast new values to everybody

More Related