Announcements. Midterm Open book, open note, closed neighbor No other external sources No portable electronic devices other than medically necessary medical.

Slides:



Advertisements
Similar presentations
Distributed Computing 8. Impossibility of consensus Shmuel Zaks ©
Advertisements

Impossibility of Distributed Consensus with One Faulty Process
Impossibility of Consensus in Asynchronous Systems (FLP) Ali Ghodsi – UC Berkeley / KTH alig(at)cs.berkeley.edu.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Consensus Steve Ko Computer Sciences and Engineering University at Buffalo.
Distributed Computing 8. Impossibility of consensus Shmuel Zaks ©
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Consensus Steve Ko Computer Sciences and Engineering University at Buffalo.
Sliding window protocol The sender continues the send action without receiving the acknowledgements of at most w messages (w > 0), w is called the window.
Distributed Algorithms – 2g1513 Lecture 10 – by Ali Ghodsi Fault-Tolerance in Asynchronous Networks.
CS 425 / ECE 428 Distributed Systems Fall 2014 Indranil Gupta (Indy) Lecture 13: Impossibility of Consensus All slides © IG.
Computer Science 425 Distributed Systems CS 425 / ECE 428 Consensus
Consensus Hao Li.
Distributed Computing 8. Impossibility of consensus Shmuel Zaks ©
Byzantine Generals Problem: Solution using signed messages.
Sergio Rajsbaum 2006 Lecture 3 Introduction to Principles of Distributed Computing Sergio Rajsbaum Math Institute UNAM, Mexico.
Asynchronous Consensus (Some Slides borrowed from ppt on Web.(by Ken Birman) )
CPSC 668Set 9: Fault Tolerant Consensus1 CPSC 668 Distributed Algorithms and Systems Fall 2006 Prof. Jennifer Welch.
CPSC 668Set 9: Fault Tolerant Consensus1 CPSC 668 Distributed Algorithms and Systems Spring 2008 Prof. Jennifer Welch.
CPSC 668Set 10: Consensus with Byzantine Failures1 CPSC 668 Distributed Algorithms and Systems Fall 2006 Prof. Jennifer Welch.
1 Fault-Tolerant Consensus. 2 Failures in Distributed Systems Link failure: A link fails and remains inactive; the network may get partitioned Crash:
Idit Keidar, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Lecture 5: Synchronous Uniform.
Impossibility of Distributed Consensus with One Faulty Process Michael J. Fischer Nancy A. Lynch Michael S. Paterson Presented by: Oren D. Rubin.
Distributed systems Module 2 -Distributed algorithms Teaching unit 1 – Basic techniques Ernesto Damiani University of Bozen Lesson 4 – Consensus and reliable.
 Idit Keidar, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Lecture 6: Impossibility.
CPSC 668Set 11: Asynchronous Consensus1 CPSC 668 Distributed Algorithms and Systems Fall 2009 Prof. Jennifer Welch.
 Idit Keidar, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Lecture 12: Impossibility.
Distributed Algorithms: Agreement Protocols. Problems of Agreement l A set of processes need to agree on a value (decision), after one or more processes.
CS 425 / ECE 428 Distributed Systems Fall 2014 Indranil Gupta (Indy) Lecture 19: Paxos All slides © IG.
On the Cost of Fault-Tolerant Consensus When There are no Faults Idit Keidar & Sergio Rajsbaum Appears in SIGACT News; MIT Tech. Report.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Consensus Steve Ko Computer Sciences and Engineering University at Buffalo.
Distributed Consensus Reaching agreement is a fundamental problem in distributed computing. Some examples are Leader election / Mutual Exclusion Commit.
Distributed Consensus Reaching agreement is a fundamental problem in distributed computing. Some examples are Leader election / Mutual Exclusion Commit.
Selected topics in distributed computing Shmuel Zaks
Lecture 8-1 Computer Science 425 Distributed Systems CS 425 / CSE 424 / ECE 428 Fall 2010 Indranil Gupta (Indy) September 16, 2010 Lecture 8 The Consensus.
Distributed Algorithms – 2g1513 Lecture 9 – by Ali Ghodsi Fault-Tolerance in Distributed Systems.
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS Fall 2011 Prof. Jennifer Welch CSCE 668 Set 11: Asynchronous Consensus 1.
For Distributed Algorithms 2014 Presentation by Ziv Ronen Based on “Impossibility of Distributed Consensus with One Faulty Process” By: Michael J. Fischer,
Consensus and Its Impossibility in Asynchronous Systems.
Ch11 Distributed Agreement. Outline Distributed Agreement Adversaries Byzantine Agreement Impossibility of Consensus Randomized Distributed Agreement.
Computer Science 425 Distributed Systems (Fall 2009) Lecture 10 The Consensus Problem Part of Section 12.5 and Paper: “Impossibility of Distributed Consensus.
1 Chapter 9 Synchronization Algorithms and Concurrent Programming Gadi Taubenfeld © 2014 Synchronization Algorithms and Concurrent Programming Synchronization.
DISTRIBUTED ALGORITHMS AND SYSTEMS Spring 2014 Prof. Jennifer Welch Set 11: Asynchronous Consensus 1.
1 Consensus Hierarchy Part 1. 2 Consensus in Shared Memory Consider processors in shared memory: which try to solve the consensus problem.
CS294, Yelick Consensus revisited, p1 CS Consensus Revisited
CS 425/ECE 428/CSE424 Distributed Systems (Fall 2009) Lecture 9 Consensus I Section Klara Nahrstedt.
Sliding window protocol The sender continues the send action without receiving the acknowledgements of at most w messages (w > 0), w is called the window.
Hwajung Lee. Reaching agreement is a fundamental problem in distributed computing. Some examples are Leader election / Mutual Exclusion Commit or Abort.
Chap 15. Agreement. Problem Processes need to agree on a single bit No link failures A process can fail by crashing (no malicious behavior) Messages take.
Impossibility of Distributed Consensus with One Faulty Process By, Michael J.Fischer Nancy A. Lynch Michael S.Paterson.
1 CS 525 Advanced Distributed Systems Spring Indranil Gupta (Indy) Lecture 6 Distributed Systems Fundamentals February 4, 2010 All Slides © IG.
Agreement in Distributed Systems n definition of agreement problems n impossibility of consensus with a single crash n solvable problems u consensus with.
Alternating Bit Protocol S R ABP is a link layer protocol. Works on FIFO channels only. Guarantees reliable message delivery with a 1-bit sequence number.
Fault tolerance and related issues in distributed computing Shmuel Zaks GSSI - Feb
DISTRIBUTED ALGORITHMS Spring 2014 Prof. Jennifer Welch Set 9: Fault Tolerant Consensus 1.
CS4231 Parallel and Distributed Algorithms AY 2006/2007 Semester 2 Lecture 9 Instructor: Haifeng YU.
1 Fault-Tolerant Consensus. 2 Communication Model Complete graph Synchronous, network.
CSE 486/586 CSE 486/586 Distributed Systems Consensus Steve Ko Computer Sciences and Engineering University at Buffalo.
1 AGREEMENT PROTOCOLS. 2 Introduction Processes/Sites in distributed systems often compete as well as cooperate to achieve a common goal. Mutual Trust/agreement.
The consensus problem in distributed systems
When Is Agreement Possible
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS
Lecture 16-A: Impossibility of Consensus
Cloud Computing Concepts
Alternating Bit Protocol
Distributed Consensus
Distributed Consensus
FLP Impossibility & Weakest Failure Detector
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS
FLP Impossibility of Consensus
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS
CSE 486/586 Distributed Systems Consensus
Presentation transcript:

Announcements

Midterm Open book, open note, closed neighbor No other external sources No portable electronic devices other than medically necessary medical devices, simple calculators, and watches –Contact me if you have any questions or concerns about this policy

Readings Section 3 of the Byzantine Generals Problem Sections 1–3 of the FLP paper Mutual Exclusion: Sections 11.2, 12.2 Networking: Sections 3.1–3.4 Transactions: Sections 13.4–13.7 Distributed Transactions: Chapter 14

And Now, Our Regularly Scheduled Programming

Signed Messages Basically, an m+1 hop path of unique nodes must contain a good node Thus, every command will get to every loyal general

Food for Thought Suppose you have a Core 2 Quad processor SMP system You run the same program in all four cores for fault-tolerance Which Byzantine General’s algorithm should you use for fault tolerance? Why?

Synchronous vs Asynchronous Byzantine Generals assumed that we knew when a messenger wasn’t sent Is this true in real networks?

Consensus A simple Distributed Systems problem Each process p: –Gets an input xp ← {0,1} –Eventually writes exactly once yp ← {0,1} –Each yp correct processes must be equal –Outputs of both 0 and 1 must be possible How might we solve this?

FLP Slides from Nitin Vaidya Modified by Yih-Chun Hu

Consensus in an Asynchronous System Impossible to achieve! –even a single failed process is enough to avoid the system from reaching agreement Proved in a now-famous result by Fischer, Lynch and Patterson, 1983 (FLP) © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

Recall Each process p has a state –program counter, registers, stack, local variables –input register xp : initially either 0 or 1 –output register yp : initially b Consensus Problem: design a protocol so that either –all processes set their output variables to 0 –or all processes set their output variables to 1 © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

pp’ Global Message Buffer send(p’,m) receive(p’) may return null “Network” Network Model © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

Terminology State of a process Configuration: collection of states, one for each process; and state of the global buffer Each Event –receipt of a message by a process (say p) –processing of message –sending out of all necessary messages by p Schedule: sequence of events © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

C C’ C’’ Event e’=(p’,m’) Event e’’=(p’’,m’’) Configuration C Schedule s=(e’,e’’) C C’’ Equivalent © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

Lemma 1 C C’ C’’ Schedule s1 Schedule s2 s2 s1 s1 and s2 involve disjoint sets of receiving processes Schedules are commutative © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

Easier Consensus Problem Easier Consensus Problem: some process eventually sets yp to be 0 or 1 Only one process crashes – we’re free to choose which one Consensus Protocol correct if 1.Any accessible config. (config. reachable from an initial config.) does not have > 1 decision value 2.For v in {0,1}, some accessible config. has value v –avoids trivial solution to the consensus problem © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

*valance Let config. C have a set of decision values V reachable from it –If |V| = 2, config. C is bivalent –If |V| = 1, config. C is 0-valent or 1-valent, as is the case Bivalent means outcome is unpredictable © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

What we’ll Show 1.There exists an initial configuration that is bivalent 2.Starting from a bivalent config., there is always another bivalent config. that is reachable © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

Lemma 2 Some initial configuration is bivalent Suppose all initial configurations were either 0-valent or 1-valent. Place all configurations side-by-side, where adjacent configurations differ in initial xp value for exactly one process There is some adjacent pair of 1-valent and 0-valent configs. © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

Lemma 2 Some initial configuration is bivalent There is some adjacent pair of 1-valent and 0-valent configs. Let the process p that has a different state across these two configs. be the process that has crashed (silent throughout) Both initial configs. will lead to the same config. for the same sequence of events One of these initial configs. must be bivalent to allow for a failure © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

What we’ll Show 1.There exists an initial configuration that is bivalent 2.Starting from a bivalent config., there is always another bivalent config. that is reachable © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

Lemma 3 Starting from a bivalent config., there is always another bivalent config. that is reachable © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

Lemma 3 A bivalent initial config. let e=(p,m) be an applicable event to the initial config. Let C be the set of configs. reachable without applying e © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

Lemma 3 A bivalent initial config. let e=(p,m) be an applicable event to the initial config. Let C be the set of configs. reachable without applying e e e e e e Let D be the set of configs. obtained by applying e to a config. in C © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

Lemma 3 D C e e e e e bivalent [don’t apply event e=(p,m)] © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

There are adjacent configs. C0 and C1 in C such that C1 = C0 followed by e’ and e’=(p’,m’) D0=C0 and then e=(p,m) D1=C1 and then e=(p,m) D0 is 0-valent, D1 is 1-valent (why?) Claim. D contains a bivalent config. Proof. By contradiction. => assume there is no bivalent config in D D C e e e e e bivalent [don’t apply event e=(p,m)] i-valent config Ei reachable from C exists (because C is bivalent) If Ei in C, then Fi = e(Ei) Else e was applied reaching Ei Either way there exists Fi in D for both i=0 and 1 © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu Warning: Definition change Before:adjacent states differed in only one input (xi) bit Now:adjacent states differ by only one event

Proof. (contd.) Case I: p’ is not p Case II: p’ same as p D C e e e e e bivalent [don’t apply event e=(p,m)] C0 D1 D0C1 e e e’ Why? (Lemma 1) But D0 is then bivalent! © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

Proof. (contd.) Case I: p’ is not p Case II: p’ same as p D C e e e e e bivalent [don’t apply event e=(p,m)] C0 D1 D0 C1 e e’ A E0 e sch. s E1 sch. s (e’,e) e sch. s finite deciding run from C0 p takes no steps But A is then bivalent! © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

Lemma 3 Starting from a bivalent config., there is always another bivalent config. that is reachable © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu

Putting it all Together Lemma 2: There exists an initial configuration that is bivalent Lemma 3: Starting from a bivalent config., there is always another bivalent config. that is reachable Theorem (Impossibility of Consensus): There is always a run of events in an asynchronous distributed system such that the group of processes never reach consensus © 2005, 2006 by Nitin Vaidya and Yih-Chun Hu