1 / 14

Asynchronous Consensus

Asynchronous Consensus. (Some Slides borrowed from ppt on Web.(by Ken Birman ) ). Consensus problem. In the Consensus problem, all correct processes propose a value and must reach an irrevocable decision on some value that is related to the proposed values [Fisher 1983]

dewitt
Download Presentation

Asynchronous Consensus

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. Asynchronous Consensus (Some Slides borrowed from ppt on Web.(by Ken Birman))

  2. Consensus problem • In the Consensus problem, all correct processes propose a value and must reach an irrevocable decision on some value that is related to the proposed values [Fisher 1983] • The Consensus problem is specified as follows: • Termination: Every correct process eventually decides some value. • Uniform integrity: Every process decides at most once. • Agreement: No two correct processes decide differently. • Uniform validity: If a process decides v, then v was proposed by some process.

  3. FLP(Fischer,Lynch,Paterson) - Main results • Proves the impossibility of fault-tolerant consensus • Every asynchronous fault-tolerant consensus algorithm has an infinite run in which no process decides • It is possible to design asynchronous consensus algorithms that don’t always terminate

  4. The Failure Detectors abstraction (Chandra/Toueg 96) • Showed that FLP applies to many problems, not just consensus • In particular, they show that FLP applies to group membership, reliable multicast • So these practical problems are impossible in asynchronous systems, in formal sense • Chandra/Toueg also look at the weakest condition under which consensus can be solved

  5. Chandra/Toueg Idea • Separate problem into • The consensus algorithm itself • A “failure detector:” a form of oracle that announces suspected failure, but it can change its mind. • Each process has local failure detector oracle typically outputs list of processes suspected to have crashed at any given time

  6. Sample properties • Completeness: detection of every crash • Strong completeness: Eventually, every process that crashes is permanently suspected by every correct process • Weak completeness: Eventually, every process that crashes is permanently suspected by some correct process

  7. Sample properties • Accuracy: does it make mistakes? • Strong accuracy: No process is suspected before it crashes. • Weak accuracy: Some correct process is never suspected • Eventual strong accuracy: there is a time after which correct processes are not suspected by any correct process • Eventual weak accuracy: there is a time after which some correct process is not suspected by any correct process

  8. Example of a failure detector • The detector they call S (“diamond-S”) “eventually strong” • Defined by two properties: • Strong Completeness: Eventually (after some unknown but finite time t), every process that crashes is permanently suspected by every correct process • Eventual weak accuracy: There is a time after which some correct process is not suspected

  9. The Model • Asynchronous distributed system in which there is no bound on message delay, clock drift or the time necessary to execute a step • Every pair of processes is connected by a reliable communication channel • The system consists of a set of n processes 1,…n • t < n/2 of them can crash

  10. Solving Consensus using S failure detector • Algorithm is pretty simple • Rotate a token around a ring of processes • Decision can occur once token makes it around once without a change in failure-suspicion status for any process • Subsequently, as token is passed, each recipient learns the decision outcome

  11. Solving Consensus using S failure detector - cont.

  12. Solving Consensus using S failure detector - cont.

  13. Rotating a token versus 2-phase commit Propose v… ack… Decide v “phase”

  14. Additional notes about S failure detector • If S does not behave as specified, the protocol will never violate safety. The only thing that S is used for is to ensure liveness. • If S does not behave as specified (practically, this means that the network is misbehaving, e.g., overloaded) then the protocol might not terminate

More Related