Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors. Michel Raynal, Julien Stainer
|
|
|
- Vernon Chase
- 6 years ago
- Views:
Transcription
1 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors Michel Raynal, Julien Stainer
2 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 2 / 22 Outline Classic Models and Problems Classic Problems Difficulties and Impossibilities Failure Detectors: Enriching Asynchronous Models Preventing Partitioning: Σ Breaking Symmetry: Ω Message Adversaries: Weakening Synchronous Crash-free Models Shared Memory from Synchrony: the Adversary TOUR Ω from Synchrony: the Adversary SOURCE Σ from Synchrony: the Adversary QUORUM Equivalence Results Elements of Proof
3 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 3 / 22 The Synchronous Message-passing Model: SMP[ ] execution stripped in a sequence of rounds
4 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 3 / 22 The Synchronous Message-passing Model: SMP[ ] execution stripped in a sequence of rounds each round is made of three phasis: processes send messages to each other
5 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 3 / 22 The Synchronous Message-passing Model: SMP[ ] execution stripped in a sequence of rounds each round is made of three phasis: processes send messages to each other they receive the round messages addressed to them
6 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 3 / 22 The Synchronous Message-passing Model: SMP[ ] execution stripped in a sequence of rounds each round is made of three phasis: processes send messages to each other they receive the round messages addressed to them they compute locally their new states
7 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 3 / 22 The Synchronous Message-passing Model: SMP[ ] execution stripped in a sequence of rounds each round is made of three phasis: processes send messages to each other they receive the round messages addressed to them they compute locally their new states The messages are all received during the round they are sent It models the use of timeouts. Relative speeds of processes are bounded. They synchronize on the slowest in heterogeneous environments.
8 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 3 / 22 The Synchronous Message-passing Model: SMP[ ] execution stripped in a sequence of rounds each round is made of three phasis: processes send messages to each other they receive the round messages addressed to them they compute locally their new states without message losses, failures are easy to detect The messages are all received during the round they are sent It models the use of timeouts. Relative speeds of processes are bounded. They synchronize on the slowest in heterogeneous environments.
9 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 4 / 22 The Asynchronous Message-passing Model: AMP[ ] processes are prone to failures
10 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 4 / 22 The Asynchronous Message-passing Model: AMP[ ] processes are prone to failures relative speeds of processes are (finite but) unbounded
11 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 4 / 22 The Asynchronous Message-passing Model: AMP[ ] processes are prone to failures relative speeds of processes are (finite but) unbounded message delivery durations are (finite but) unbounded
12 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 4 / 22 The Asynchronous Message-passing Model: AMP[ ] processes are prone to failures relative speeds of processes are (finite but) unbounded message delivery durations are (finite but) unbounded Crashed and slow processes are undistinguishable.
13 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 5 / 22 The Asynchronous Shared Memory Model: ASM[ ] processes are prone to failures
14 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 5 / 22 The Asynchronous Shared Memory Model: ASM[ ] processes are prone to failures relative speeds of processes are (finite but) unbounded
15 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 5 / 22 The Asynchronous Shared Memory Model: ASM[ ] processes are prone to failures relative speeds of processes are (finite but) unbounded processes share an array of single-writer multi-readers atomic registers
16 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 5 / 22 The Asynchronous Shared Memory Model: ASM[ ] processes are prone to failures relative speeds of processes are (finite but) unbounded processes share an array of single-writer multi-readers atomic registers Crashed and slow processes are undistinguishable.
17 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 5 / 22 The Asynchronous Shared Memory Model: ASM[ ] processes are prone to failures relative speeds of processes are (finite but) unbounded processes share an array of single-writer multi-readers atomic registers Crashed and slow processes are undistinguishable. But... The memory offers a more powerful communication medium than asynchronous messages.
18 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 6 / 22 Simulating a Shared Memory simulating read and write operations in a linearizable manner: each operation executes with the same consequences as if it happens instantaneously between its invocation and its end.
19 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 6 / 22 Simulating a Shared Memory simulating read and write operations in a linearizable manner: each operation executes with the same consequences as if it happens instantaneously between its invocation and its end.
20 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 6 / 22 Simulating a Shared Memory simulating read and write operations in a linearizable manner: each operation executes with the same consequences as if it happens instantaneously between its invocation and its end.
21 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 6 / 22 Simulating a Shared Memory simulating read and write operations in a linearizable manner: each operation executes with the same consequences as if it happens instantaneously between its invocation and its end.
22 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 6 / 22 Simulating a Shared Memory simulating read and write operations in a linearizable manner: each operation executes with the same consequences as if it happens instantaneously between its invocation and its end.
23 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 6 / 22 Simulating a Shared Memory simulating read and write operations in a linearizable manner: each operation executes with the same consequences as if it happens instantaneously between its invocation and its end.
24 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 6 / 22 Simulating a Shared Memory simulating read and write operations in a linearizable manner: each operation executes with the same consequences as if it happens instantaneously between its invocation and its end.
25 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 6 / 22 Simulating a Shared Memory simulating read and write operations in a linearizable manner: each operation executes with the same consequences as if it happens instantaneously between its invocation and its end.
26 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 6 / 22 Simulating a Shared Memory simulating read and write operations in a linearizable manner: each operation executes with the same consequences as if it happens instantaneously between its invocation and its end.
27 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 6 / 22 Simulating a Shared Memory simulating read and write operations in a linearizable manner: each operation executes with the same consequences as if it happens instantaneously between its invocation and its end.
28 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 6 / 22 Simulating a Shared Memory simulating read and write operations in a linearizable manner: each operation executes with the same consequences as if it happens instantaneously between its invocation and its end.
29 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 7 / 22 Consensus: Reaching Agreement each participating process proposes a value a process that doesn t crash eventually decides a value all decided values are proposed values the decided values are all the same Solving Consensus Allows to Solve State Machine Replication allows to solve any task with a sequential specification can be used to replicate services in a resilient manner
30 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 8 / 22 Simulating a Memory is Impossible in AMP[ ] as soon as a majority of processes can crash
31 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 8 / 22 Simulating a Memory is Impossible in AMP[ ] as soon as a majority of processes can crash since messages can be arbitrarily delayed, two parts of the system can execute as if the processes of the other part were crashed
![Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 8 / 22 Simulating a Memory is Impossible in AMP[ ] as soon as a](/docs-images/71/66041900/images/32-0.jpg "majority of processes can crash since messages can be arbitrarily delayed, two parts of the system can execute as if the processes of the other part were")
32 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 8 / 22 Simulating a Memory is Impossible in AMP[ ] as soon as a majority of processes can crash since messages can be arbitrarily delayed, two parts of the system can execute as if the processes of the other part were crashed
![Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 8 / 22 Simulating a Memory is Impossible in AMP[ ] as soon as a](/docs-images/71/66041900/images/33-1.jpg "majority of processes can crash since messages can be arbitrarily delayed, two parts of the system can execute as if the processes of the other part were")
33 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 8 / 22 Simulating a Memory is Impossible in AMP[ ] as soon as a majority of processes can crash since messages can be arbitrarily delayed, two parts of the system can execute as if the processes of the other part were crashed
34 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 8 / 22 Simulating a Memory is Impossible in AMP[ ] as soon as a majority of processes can crash since messages can be arbitrarily delayed, two parts of the system can execute as if the processes of the other part were crashed if messages are delayed for too long, the situation is undistinguishable from the previous one: processes behave as before
![Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 8 / 22 Simulating a Memory is Impossible in AMP[ ] as soon as a majority of processes can crash since messages](/docs-images/71/66041900/images/35-0.jpg "can be arbitrarily delayed, two parts of the system can execute as if the processes of the other part were crashed if messages are delayed for too long, the situation is undistinguishable from the")
35 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 8 / 22 Simulating a Memory is Impossible in AMP[ ] as soon as a majority of processes can crash since messages can be arbitrarily delayed, two parts of the system can execute as if the processes of the other part were crashed if messages are delayed for too long, the situation is undistinguishable from the previous one: processes behave as before
36 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 8 / 22 Simulating a Memory is Impossible in AMP[ ] as soon as a majority of processes can crash if the system splits for too long, it is impossible to maintain read and write linearizable semantic
37 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 9 / 22 Solving Consensus is impossible in both AMP[ ] and ASM[ ] the possible executions of an algorithm in ASM can be represented by a subdivided complex
38 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 9 / 22 Solving Consensus is impossible in both AMP[ ] and ASM[ ] the possible executions of an algorithm in ASM can be represented by a subdivided complex
39 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 9 / 22 Solving Consensus is impossible in both AMP[ ] and ASM[ ] the possible executions of an algorithm in ASM can be represented by a subdivided complex
40 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 9 / 22 Solving Consensus is impossible in both AMP[ ] and ASM[ ] the possible executions of an algorithm in ASM can be represented by a subdivided complex
41 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 9 / 22 Solving Consensus is impossible in both AMP[ ] and ASM[ ] the possible executions of an algorithm in ASM can be represented by a subdivided complex
42 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 9 / 22 Solving Consensus is impossible in both AMP[ ] and ASM[ ] the possible executions of an algorithm in ASM can be represented by a subdivided complex the processes have to decide in a finite number of steps, the complex subdivision is consequently finite
43 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 9 / 22 Solving Consensus is impossible in both AMP[ ] and ASM[ ] the possible executions of an algorithm in ASM can be represented by a subdivided complex the processes have to decide in a finite number of steps, the complex subdivision is consequently finite the states can be tagged with the corresponding decided values
44 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 9 / 22 Solving Consensus is impossible in both AMP[ ] and ASM[ ] the possible executions of an algorithm in ASM can be represented by a subdivided complex the processes have to decide in a finite number of steps, the complex subdivision is consequently finite the states can be tagged with the corresponding decided values impossibility result comes from combinatorial topology
![Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 9 / 22 Solving Consensus is impossible in both AMP[ ] and ASM[](/docs-images/71/66041900/images/45-1.jpg "] the possible executions of an algorithm in ASM can be represented by a subdivided complex the representation can be used with more than two")
45 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 9 / 22 Solving Consensus is impossible in both AMP[ ] and ASM[ ] the possible executions of an algorithm in ASM can be represented by a subdivided complex the representation can be used with more than two processes
46 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 10 / 22 Failure Detectors failure detectors provide each process with an externally controlled variable the value of this variable depends on the system global state it informs processes about crashes Failure Detectors reinforce Asynchronous Models AMP[ ] and ASM[ ]
47 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 11 / 22 Preventing Partitioning: Σ Σ provides each process with a set of process identities called quorum any two quorum taken at any time on any processes intersect eventually quorums only contain correct processes Σ is Minimal to Simulate a Memory in AMP[ ]
48 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 12 / 22 Breaking Symmetry: Ω Ω provides each process with the identity of a process considered as the leader the leader is eventually the same for each process correct Ω is Minimal to Solve the Consensus in ASM[ ] Σ, Ω is Minimal to Solve the Consensus in AMP[ ]
49 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 13 / 22 Message Adversaries the adversary removes messages in SMP[ ] properties define the patterns of messages that can be removed during a round across the execution Message Adversaries weaken the Synchronous Crash-free Model SMP[ ]
50 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 14 / 22 Shared Memory from Synchrony: the Adversary TOUR TOUR can remove any message but it preserves a tournament in any round in any round and between any pair of processes, it has to let one of the two messages exchanged untouched
51 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 14 / 22 Shared Memory from Synchrony: the Adversary TOUR TOUR can remove any message but it preserves a tournament in any round in any round and between any pair of processes, it has to let one of the two messages exchanged untouched
52 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 15 / 22 Ω from Synchrony: the Adversary SOURCE SOURCE can remove any message but it eventually preserves all messages sent by a given source
53 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 15 / 22 Ω from Synchrony: the Adversary SOURCE SOURCE can remove any message but it eventually preserves all messages sent by a given source
54 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 15 / 22 Ω from Synchrony: the Adversary SOURCE SOURCE can remove any message but it eventually preserves all messages sent by a given source
55 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 15 / 22 Ω from Synchrony: the Adversary SOURCE SOURCE can remove any message but it eventually preserves all messages sent by a given source
56 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 15 / 22 Ω from Synchrony: the Adversary SOURCE SOURCE can remove any message but it eventually preserves all messages sent by a given source
57 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 15 / 22 Ω from Synchrony: the Adversary SOURCE SOURCE can remove any message but it eventually preserves all messages sent by a given source
58 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 15 / 22 Ω from Synchrony: the Adversary SOURCE SOURCE can remove any message but it eventually preserves all messages sent by a given source
59 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 15 / 22 Ω from Synchrony: the Adversary SOURCE SOURCE can remove any message but it eventually preserves all messages sent by a given source
60 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 16 / 22 Σ from Synchrony: the Adversary QUORUM QUORUM can remove any message but in each round each process receives messages from an entire quorum in any two rounds r 1 and r 2, for any two processes p 1 and p 2, there is a process p 3 such that: p1 receives the message of p 3 during r 1 and p2 receives the message of p 3 during r 2 and p 3 is infinitely often able to send messages (directly or not) to any other process
61
62 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 18 / 22 Simulating SMP[SOURCE, TOUR] in ASM[Ω] Each process waits to be the leader or to receive a message from the leader. It writes its round messages to the other processes. It scans the memory and delivers the round messages.
63 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 18 / 22 Simulating SMP[SOURCE, TOUR] in ASM[Ω] Each process waits to be the leader or to receive a message from the leader. It writes its round messages to the other processes. It scans the memory and delivers the round messages. Everything happens as if all the other messages were removed by the adversary. The eventual leader s messages are eventually all received The atomic registers entail the TOUR property
64 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 19 / 22 Simulating ASM[Ω] in SMP[SOURCE, TOUR] Full information protocol. To complete an operation (read or write), a process inject it with a sequence number and its name and count as informed: the processes from which it didn t received any messages during the round; those from which it received its own message. It continues its execution when each other process is informed. The eventual leader is elected by counting the number of rounds missed by each process.
65 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 19 / 22 Simulating ASM[Ω] in SMP[SOURCE, TOUR] Full information protocol. To complete an operation (read or write), a process inject it with a sequence number and its name and count as informed: the processes from which it didn t received any messages during the round; those from which it received its own message. It continues its execution when each other process is informed. The eventual leader is elected by counting the number of rounds missed by each process. In two tournaments, at least one process reaches every other, it learns it in the next round. Some processes stay stuck on a communication operation, analog to crashed ones for the other. (The simulation is only non blocking)
66 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 20 / 22 Wrap Up Message adversaries offer a way to model asynchrony, crashes and shared memory in the simple synchronous crash-free system. Some important failure detectors have corresponding message adversaries. Representing these model properties through a single abstraction allows to compare them.
67 Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 21 / 22 Perspectives Do all failure detectors have their message adversary counterpart? Can we easily obtain the message adversaries matching t-resilient asynchronous models? What is the strongest message adversary allowing consensus to be solved? How could be the notion of Byzantine failure be ported to this model? Some messages adversaries have a natural topological representation, how does it compare to the usual barycentric one? Is the notion of message adversary the key to reveal the Grand Unified Model of distributed computability?
68 Thank you for your attention! Synchrony Weakened by Message Adversaries vs Asynchrony Enriched with Failure Detectors 22 / 22
Replication in Distributed Systems
Replication in Distributed Systems Replication Basics Multiple copies of data kept in different nodes A set of replicas holding copies of a data Nodes can be physically very close or distributed all over
Point-Set Topology for Impossibility Results in Distributed Computing. Thomas Nowak
Point-Set Topology for Impossibility Results in Distributed Computing Thomas Nowak Overview Introduction Safety vs. Liveness First Example: Wait-Free Shared Memory Message Omission Model Execution Trees
The Wait-Free Hierarchy
Jennifer L. Welch References 1 M. Herlihy, Wait-Free Synchronization, ACM TOPLAS, 13(1):124-149 (1991) M. Fischer, N. Lynch, and M. Paterson, Impossibility of Distributed Consensus with One Faulty Process,
A Timing Assumption and a t-resilient Protocol for Implementing an Eventual Leader Service in Asynchronous Shared Memory Systems
A Timing Assumption and a t-resilient Protocol for Implementing an Eventual Leader Service in Asynchronous Shared Memory Systems Antonio FERNÁNDEZ y Ernesto JIMÉNEZ z Michel RAYNAL? Gilles TRÉDAN? y LADyR,
Distributed systems. Lecture 6: distributed transactions, elections, consensus and replication. Malte Schwarzkopf
Distributed systems Lecture 6: distributed transactions, elections, consensus and replication Malte Schwarzkopf Last time Saw how we can build ordered multicast Messages between processes in a group Need
Consensus Problem. Pradipta De
Consensus Problem Slides are based on the book chapter from Distributed Computing: Principles, Paradigms and Algorithms (Chapter 14) by Kshemkalyani and Singhal Pradipta De pradipta.de@sunykorea.ac.kr
Implementing Shared Registers in Asynchronous Message-Passing Systems, 1995; Attiya, Bar-Noy, Dolev
Implementing Shared Registers in Asynchronous Message-Passing Systems, 1995; Attiya, Bar-Noy, Dolev Eric Ruppert, York University, www.cse.yorku.ca/ ruppert INDEX TERMS: distributed computing, shared memory,
The Alpha of Indulgent Consensus
The Computer Journal Advance Access published August 3, 2006 Ó The Author 2006. Published by Oxford University Press on behalf of The British Computer Society. All rights reserved. For Permissions, please
Practical Byzantine Fault Tolerance. Miguel Castro and Barbara Liskov
Practical Byzantine Fault Tolerance Miguel Castro and Barbara Liskov Outline 1. Introduction to Byzantine Fault Tolerance Problem 2. PBFT Algorithm a. Models and overview b. Three-phase protocol c. View-change
What Can be Computed in a Distributed System?
What Can be Computed in a Distributed System? Michel Raynal Institut Universitaire de France &IRISA,Université de Rennes, France & Department of Computing, Polytechnic University, Hong Kong raynal@irisa.fr
Distributed Systems. 09. State Machine Replication & Virtual Synchrony. Paul Krzyzanowski. Rutgers University. Fall Paul Krzyzanowski
Distributed Systems 09. State Machine Replication & Virtual Synchrony Paul Krzyzanowski Rutgers University Fall 2016 1 State machine replication 2 State machine replication We want high scalability and
Data Consistency and Blockchain. Bei Chun Zhou (BlockChainZ)
Data Consistency and Blockchain Bei Chun Zhou (BlockChainZ) beichunz@cn.ibm.com 1 Data Consistency Point-in-time consistency Transaction consistency Application consistency 2 Strong Consistency ACID Atomicity.
Consensus, impossibility results and Paxos. Ken Birman
Consensus, impossibility results and Paxos Ken Birman Consensus a classic problem Consensus abstraction underlies many distributed systems and protocols N processes They start execution with inputs {0,1}
Distributed Systems. replication Johan Montelius ID2201. Distributed Systems ID2201
Distributed Systems ID2201 replication Johan Montelius 1 The problem The problem we have: servers might be unavailable The solution: keep duplicates at different servers 2 Building a fault-tolerant service
Failures, Elections, and Raft
Failures, Elections, and Raft CS 8 XI Copyright 06 Thomas W. Doeppner, Rodrigo Fonseca. All rights reserved. Distributed Banking SFO add interest based on current balance PVD deposit $000 CS 8 XI Copyright
Last time. Distributed systems Lecture 6: Elections, distributed transactions, and replication. DrRobert N. M. Watson
Distributed systems Lecture 6: Elections, distributed transactions, and replication DrRobert N. M. Watson 1 Last time Saw how we can build ordered multicast Messages between processes in a group Need to
Asynchronous Reconfiguration for Paxos State Machines
Asynchronous Reconfiguration for Paxos State Machines Leander Jehl and Hein Meling Department of Electrical Engineering and Computer Science University of Stavanger, Norway Abstract. This paper addresses
Semi-Passive Replication in the Presence of Byzantine Faults
Semi-Passive Replication in the Presence of Byzantine Faults HariGovind V. Ramasamy Adnan Agbaria William H. Sanders University of Illinois at Urbana-Champaign 1308 W. Main Street, Urbana IL 61801, USA
From a Store-collect Object and Ω to Efficient Asynchronous Consensus
From a Store-collect Object and Ω to Efficient Asynchronous Consensus Michel Raynal, Julien Stainer To cite this version: Michel Raynal, Julien Stainer. From a Store-collect Object and Ω to Efficient Asynchronous
Initial Assumptions. Modern Distributed Computing. Network Topology. Initial Input
Initial Assumptions Modern Distributed Computing Theory and Applications Ioannis Chatzigiannakis Sapienza University of Rome Lecture 4 Tuesday, March 6, 03 Exercises correspond to problems studied during
Anonymous and Fault-Tolerant Shared-Memory Computing
Distributed Computing manuscript No. (will be inserted by the editor) Rachid Guerraoui Eric Ruppert Anonymous and Fault-Tolerant Shared-Memory Computing the date of receipt and acceptance should be inserted
Consensus a classic problem. Consensus, impossibility results and Paxos. Distributed Consensus. Asynchronous networks.
Consensus, impossibility results and Paxos Ken Birman Consensus a classic problem Consensus abstraction underlies many distributed systems and protocols N processes They start execution with inputs {0,1}
Distributed Algorithms. Partha Sarathi Mandal Department of Mathematics IIT Guwahati
Distributed Algorithms Partha Sarathi Mandal Department of Mathematics IIT Guwahati Thanks to Dr. Sukumar Ghosh for the slides Distributed Algorithms Distributed algorithms for various graph theoretic
Distributed Systems 8L for Part IB
Distributed Systems 8L for Part IB Handout 3 Dr. Steven Hand 1 Distributed Mutual Exclusion In first part of course, saw need to coordinate concurrent processes / threads In particular considered how to
Consensus in Distributed Systems. Jeff Chase Duke University
Consensus in Distributed Systems Jeff Chase Duke University Consensus P 1 P 1 v 1 d 1 Unreliable multicast P 2 P 3 Consensus algorithm P 2 P 3 v 2 Step 1 Propose. v 3 d 2 Step 2 Decide. d 3 Generalizes
A General Characterization of Indulgence
A General Characterization of Indulgence R. Guerraoui 1,2 N. Lynch 2 (1) School of Computer and Communication Sciences, EPFL (2) Computer Science and Artificial Intelligence Laboratory, MIT Abstract. An
Silvia Bonomi. Implementing Distributed Computing Abstractions in the presence of Churn
N o d ordre : 4041 ANNÉE 2010 THÈSE / UNIVERSITÉ DE RENNES 1 sous le sceau de l Université Européenne de Bretagne pour le grade de DOCTEUR DE L UNIVERSITÉ DE RENNES 1 Mention : Informatique Ecole doctorale
Introduction to Distributed Systems Seif Haridi
Introduction to Distributed Systems Seif Haridi haridi@kth.se What is a distributed system? A set of nodes, connected by a network, which appear to its users as a single coherent system p1 p2. pn send
CS5412: CONSENSUS AND THE FLP IMPOSSIBILITY RESULT
1 CS5412: CONSENSUS AND THE FLP IMPOSSIBILITY RESULT Lecture XII Ken Birman Generalizing Ron and Hermione s challenge 2 Recall from last time: Ron and Hermione had difficulty agreeing where to meet for
Relationships Between Broadcast and Shared Memory in Reliable Anonymous Distributed Systems
Relationships Between Broadcast and Shared Memory in Reliable Anonymous Distributed Systems James Aspnes, Yale University Faith Ellen Fich, University of Toronto Eric Ruppert, York University Anonymity
arxiv: v2 [cs.dc] 12 Sep 2017
![arxiv: v2 [cs.dc] 12 Sep 2017](/thumbs/74/69997265.jpg "arxiv: v2 [cs.dc] 12 Sep 2017")
Efficient Synchronous Byzantine Consensus Ittai Abraham 1, Srinivas Devadas 2, Danny Dolev 3, Kartik Nayak 4, and Ling Ren 2 arxiv:1704.02397v2 [cs.dc] 12 Sep 2017 1 VMware Research iabraham@vmware.com
Optimal Resilience for Erasure-Coded Byzantine Distributed Storage
Optimal Resilience for Erasure-Coded Byzantine Distributed Storage Christian Cachin IBM Research Zurich Research Laboratory CH-8803 Rüschlikon, Switzerland cca@zurich.ibm.com Stefano Tessaro ETH Zurich
Today: Fault Tolerance
Today: Fault Tolerance Agreement in presence of faults Two army problem Byzantine generals problem Reliable communication Distributed commit Two phase commit Three phase commit Paxos Failure recovery Checkpointing
Parsimonious Asynchronous Byzantine-Fault-Tolerant Atomic Broadcast
Parsimonious Asynchronous Byzantine-Fault-Tolerant Atomic Broadcast HariGovind V. Ramasamy Christian Cachin August 19, 2005 Abstract Atomic broadcast is a communication primitive that allows a group of
Concurrent Programming: Algorithms, Principles, and Foundations
Concurrent Programming: Algorithms, Principles, and Foundations Algorithms, Principles, and Foundations Bearbeitet von Michel Raynal 1. Auflage 2012. Buch. xxxii, 516 S. Hardcover ISBN 978 3 642 32026
arxiv: v1 [cs.dc] 13 May 2017
![arxiv: v1 [cs.dc] 13 May 2017](/thumbs/93/114013481.jpg "arxiv: v1 [cs.dc] 13 May 2017")
Which Broadcast Abstraction Captures k-set Agreement? Damien Imbs, Achour Mostéfaoui, Matthieu Perrin, Michel Raynal, LIF, Université Aix-Marseille, 13288 Marseille, France LINA, Université de Nantes,
Agreement in Distributed Systems CS 188 Distributed Systems February 19, 2015
Agreement in Distributed Systems CS 188 Distributed Systems February 19, 2015 Page 1 Introduction We frequently want to get a set of nodes in a distributed system to agree Commitment protocols and mutual
Intuitive distributed algorithms. with F#
Intuitive distributed algorithms with F# Natallia Dzenisenka Alena Hall @nata_dzen @lenadroid A tour of a variety of intuitivedistributed algorithms used in practical distributed systems. and how to prototype
Multi-writer Regular Registers in Dynamic Distributed Systems with Byzantine Failures
Multi-writer Regular Registers in Dynamic Distributed Systems with Byzantine Failures Silvia Bonomi, Amir Soltani Nezhad Università degli Studi di Roma La Sapienza, Via Ariosto 25, 00185 Roma, Italy bonomi@dis.uniroma1.it
Distributed Algorithms Models
Distributed Algorithms Models Alberto Montresor University of Trento, Italy 2016/04/26 This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Contents 1 Taxonomy
Introduction to Distributed Systems
Introduction to Distributed Systems Minsoo Ryu Department of Computer Science and Engineering 2 Definition A distributed system is a collection of independent computers that appears to its users as a single
Important Lessons. A Distributed Algorithm (2) Today's Lecture - Replication
Important Lessons Lamport & vector clocks both give a logical timestamps Total ordering vs. causal ordering Other issues in coordinating node activities Exclusive access to resources/data Choosing a single
CSE 5306 Distributed Systems. Fault Tolerance
CSE 5306 Distributed Systems Fault Tolerance 1 Failure in Distributed Systems Partial failure happens when one component of a distributed system fails often leaves other components unaffected A failure
Reliable Distributed System Approaches
Reliable Distributed System Approaches Manuel Graber Seminar of Distributed Computing WS 03/04 The Papers The Process Group Approach to Reliable Distributed Computing K. Birman; Communications of the ACM,
Distributed algorithms
Distributed algorithms Prof R. Guerraoui lpdwww.epfl.ch Exam: Written Reference: Book - Springer Verlag http://lpd.epfl.ch/site/education/da - Introduction to Reliable (and Secure) Distributed Programming
What is a distributed system?
CS 378 Intro to Distributed Computing Lorenzo Alvisi Harish Rajamani What is a distributed system? A distributed system is one in which the failure of a computer you didn t even know existed can render
Transactions. CS 475, Spring 2018 Concurrent & Distributed Systems
Transactions CS 475, Spring 2018 Concurrent & Distributed Systems Review: Transactions boolean transfermoney(person from, Person to, float amount){ if(from.balance >= amount) { from.balance = from.balance
Recall our 2PC commit problem. Recall our 2PC commit problem. Doing failover correctly isn t easy. Consensus I. FLP Impossibility, Paxos
Consensus I Recall our 2PC commit problem FLP Impossibility, Paxos Client C 1 C à TC: go! COS 418: Distributed Systems Lecture 7 Michael Freedman Bank A B 2 TC à A, B: prepare! 3 A, B à P: yes or no 4
Fault-Tolerant Distributed Consensus
Fault-Tolerant Distributed Consensus Lawrence Kesteloot January 20, 1995 1 Introduction A fault-tolerant system is one that can sustain a reasonable number of process or communication failures, both intermittent
Self-stabilizing Byzantine Digital Clock Synchronization
Self-stabilizing Byzantine Digital Clock Synchronization Ezra N. Hoch, Danny Dolev and Ariel Daliot The Hebrew University of Jerusalem We present a scheme that achieves self-stabilizing Byzantine digital
Distributed Recursion
Distributed Recursion March 2011 Sergio Rajsbaum Instituto de Matemáticas, UNAM joint work with Eli Gafni, UCLA Introduction Though it is a new field, computer science already touches virtually every aspect
k-abortable Objects: Progress under High Contention
k-abortable Objects: Progress under High Contention Naama Ben-David 1, David Yu Cheng Chan 2, Vassos Hadzilacos 2, and Sam Toueg 2 Carnegie Mellon University 1 University of Toronto 2 Outline Background
Today: Fault Tolerance. Fault Tolerance
Today: Fault Tolerance Agreement in presence of faults Two army problem Byzantine generals problem Reliable communication Distributed commit Two phase commit Three phase commit Paxos Failure recovery Checkpointing
Large-Scale Key-Value Stores Eventual Consistency Marco Serafini
Large-Scale Key-Value Stores Eventual Consistency Marco Serafini COMPSCI 590S Lecture 13 Goals of Key-Value Stores Export simple API put(key, value) get(key) Simpler and faster than a DBMS Less complexity,
Distributed systems. Consensus
Distributed systems Consensus Prof R. Guerraoui Distributed Programming Laboratory Consensus B A C 2 Consensus In the consensus problem, the processes propose values and have to agree on one among these
HP: Hybrid Paxos for WANs
HP: Hybrid Paxos for WANs Dan Dobre, Matthias Majuntke, Marco Serafini and Neeraj Suri {dan,majuntke,marco,suri}@cs.tu-darmstadt.de TU Darmstadt, Germany Neeraj Suri EU-NSF ICT March 2006 Dependable Embedded
Distributed Systems. Characteristics of Distributed Systems. Lecture Notes 1 Basic Concepts. Operating Systems. Anand Tripathi
1 Lecture Notes 1 Basic Concepts Anand Tripathi CSci 8980 Operating Systems Anand Tripathi CSci 8980 1 Distributed Systems A set of computers (hosts or nodes) connected through a communication network.
Distributed Systems. Characteristics of Distributed Systems. Characteristics of Distributed Systems. Goals in Distributed System Designs
1 Anand Tripathi CSci 8980 Operating Systems Lecture Notes 1 Basic Concepts Distributed Systems A set of computers (hosts or nodes) connected through a communication network. Nodes may have different speeds
Fault-Tolerant Distributed Services and Paxos"
Fault-Tolerant Distributed Services and Paxos" INF346, 2015 2015 P. Kuznetsov and M. Vukolic So far " " Shared memory synchronization:" Wait-freedom and linearizability" Consensus and universality " Fine-grained
Agreement and Consensus. SWE 622, Spring 2017 Distributed Software Engineering
Agreement and Consensus SWE 622, Spring 2017 Distributed Software Engineering Today General agreement problems Fault tolerance limitations of 2PC 3PC Paxos + ZooKeeper 2 Midterm Recap 200 GMU SWE 622 Midterm
CSE 5306 Distributed Systems
CSE 5306 Distributed Systems Fault Tolerance Jia Rao http://ranger.uta.edu/~jrao/ 1 Failure in Distributed Systems Partial failure Happens when one component of a distributed system fails Often leaves
There Is More Consensus in Egalitarian Parliaments
There Is More Consensus in Egalitarian Parliaments Iulian Moraru, David Andersen, Michael Kaminsky Carnegie Mellon University Intel Labs Fault tolerance Redundancy State Machine Replication 3 State Machine
A Case Study of Agreement Problems in Distributed Systems : Non-Blocking Atomic Commitment
A Case Study of Agreement Problems in Distributed Systems : Non-Blocking Atomic Commitment Michel RAYNAL IRISA, Campus de Beaulieu 35042 Rennes Cedex (France) raynal @irisa.fr Abstract This paper considers
Anonymous Agreement: The Janus Algorithm
Anonymous Agreement: The Janus Algorithm Zohir Bouzid 1, Pierre Sutra 1, and Corentin Travers 2 1 University Pierre et Marie Curie - Paris 6, LIP6-CNRS 7606, France. name.surname@lip6.fr 2 LaBRI University
Erasure Coding in Object Stores: Challenges and Opportunities
Erasure Coding in Object Stores: Challenges and Opportunities Lewis Tseng Boston College July 2018, PODC Acknowledgements Nancy Lynch Muriel Medard Kishori Konwar Prakash Narayana Moorthy Viveck R. Cadambe
Generating Fast Indulgent Algorithms
Generating Fast Indulgent Algorithms Dan Alistarh 1, Seth Gilbert 2, Rachid Guerraoui 1, and Corentin Travers 3 1 EPFL, Switzerland 2 National University of Singapore 3 Université de Bordeaux 1, France
Fault Tolerance. Distributed Software Systems. Definitions
Fault Tolerance Distributed Software Systems Definitions Availability: probability the system operates correctly at any given moment Reliability: ability to run correctly for a long interval of time Safety:
Distributed Systems. coordination Johan Montelius ID2201. Distributed Systems ID2201
Distributed Systems ID2201 coordination Johan Montelius 1 Coordination Coordinating several threads in one node is a problem, coordination in a network is of course worse: failure of nodes and networks
Basic vs. Reliable Multicast
Basic vs. Reliable Multicast Basic multicast does not consider process crashes. Reliable multicast does. So far, we considered the basic versions of ordered multicasts. What about the reliable versions?
Applications of Paxos Algorithm
Applications of Paxos Algorithm Gurkan Solmaz COP 6938 - Cloud Computing - Fall 2012 Department of Electrical Engineering and Computer Science University of Central Florida - Orlando, FL Oct 15, 2012 1
Anonymity-Preserving Failure Detectors
Anonymity-Preserving Failure Detectors Zohir Bouzid and Corentin Travers LaBRI, U. Bordeaux, France name.surname@labri.fr Abstract. The paper investigates the consensus problem in anonymous, failures prone
Fork Sequential Consistency is Blocking
Fork Sequential Consistency is Blocking Christian Cachin Idit Keidar Alexander Shraer May 14, 2008 Abstract We consider an untrusted server storing shared data on behalf of clients. We show that no storage
Replicated State Machine in Wide-area Networks
Replicated State Machine in Wide-area Networks Yanhua Mao CSE223A WI09 1 Building replicated state machine with consensus General approach to replicate stateful deterministic services Provide strong consistency
Consensus and related problems
Consensus and related problems Today l Consensus l Google s Chubby l Paxos for Chubby Consensus and failures How to make process agree on a value after one or more have proposed what the value should be?
6.852: Distributed Algorithms Fall, Instructor: Nancy Lynch TAs: Cameron Musco, Katerina Sotiraki Course Secretary: Joanne Hanley
6.852: Distributed Algorithms Fall, 2015 Instructor: Nancy Lynch TAs: Cameron Musco, Katerina Sotiraki Course Secretary: Joanne Hanley What are Distributed Algorithms? Algorithms that run on networked
Distributed Consensus Protocols
Distributed Consensus Protocols ABSTRACT In this paper, I compare Paxos, the most popular and influential of distributed consensus protocols, and Raft, a fairly new protocol that is considered to be a
Asynchronous Models. Chapter Asynchronous Processes States, Inputs, and Outputs
Chapter 3 Asynchronous Models 3.1 Asynchronous Processes Like a synchronous reactive component, an asynchronous process interacts with other processes via inputs and outputs, and maintains an internal
Fork Sequential Consistency is Blocking
Fork Sequential Consistency is Blocking Christian Cachin Idit Keidar Alexander Shraer Novembe4, 008 Abstract We consider an untrusted server storing shared data on behalf of clients. We show that no storage
Distributed Commit in Asynchronous Systems
Distributed Commit in Asynchronous Systems Minsoo Ryu Department of Computer Science and Engineering 2 Distributed Commit Problem - Either everybody commits a transaction, or nobody - This means consensus!
Middleware and Distributed Systems. System Models. Dr. Martin v. Löwis
Middleware and Distributed Systems System Models Dr. Martin v. Löwis System Models (Coulouris et al.) Architectural models of distributed systems placement of parts and relationships between them e.g.
EECS 498 Introduction to Distributed Systems
EECS 498 Introduction to Distributed Systems Fall 2017 Harsha V. Madhyastha Replicated State Machines Logical clocks Primary/ Backup Paxos? 0 1 (N-1)/2 No. of tolerable failures October 11, 2017 EECS 498
Parallélisme. Aim of the talk. Decision tasks. Example: consensus
Parallélisme Aim of the talk Geometry and Distributed Systems Can we implement some functions on some distributed architecture, even if there are some crashes? Eric Goubault Commissariat à l Energie Atomique
The Topological Structure of Asynchronous Computability
The Topological Structure of Asynchronous Computability MAURICE HERLIHY Brown University, Providence, Rhode Island AND NIR SHAVIT Tel-Aviv University, Tel-Aviv Israel Abstract. We give necessary and sufficient
Implementing a Register in a Dynamic Distributed System
Implementing a Register in a Dynamic Distributed System Roberto Baldoni, Silvia Bonomi, Anne-Marie Kermarrec, Michel Raynal Sapienza Università di Roma, Via Ariosto 25, 85 Roma, Italy INRIA, Univeristé
Secure Multiparty Computation: Introduction. Ran Cohen (Tel Aviv University)
Secure Multiparty Computation: Introduction Ran Cohen (Tel Aviv University) Scenario 1: Private Dating Alice and Bob meet at a pub If both of them want to date together they will find out If Alice doesn
Dynamic Atomic Storage without Consensus
Dynamic Atomic Storage without Consensus MARCOS K. AGUILERA, Microsoft Research IDIT KEIDAR, Technion DAHLIA MALKHI, Microsoft Research ALEXANDER SHRAER, Yahoo! Research This article deals with the emulation
C 1. Today s Question. CSE 486/586 Distributed Systems Failure Detectors. Two Different System Models. Failure Model. Why, What, and How
CSE 486/586 Distributed Systems Failure Detectors Today s Question I have a feeling that something went wrong Steve Ko Computer Sciences and Engineering University at Buffalo zzz You ll learn new terminologies,
Reaching Consensus. Lecture The Problem
Lecture 4 Reaching Consensus 4.1 The Problem In the previous lecture, we ve seen that consensus can t be solved in asynchronous systems. That means asking how can we solve consensus? is pointless. But
Distributed Systems (5DV147)
Distributed Systems (5DV147) Fundamentals Fall 2013 1 basics 2 basics Single process int i; i=i+1; 1 CPU - Steps are strictly sequential - Program behavior & variables state determined by sequence of operations
Distributed Systems 11. Consensus. Paul Krzyzanowski
Distributed Systems 11. Consensus Paul Krzyzanowski pxk@cs.rutgers.edu 1 Consensus Goal Allow a group of processes to agree on a result All processes must agree on the same value The value must be one
arxiv: v3 [cs.dc] 4 Dec 2018
![arxiv: v3 [cs.dc] 4 Dec 2018](/thumbs/94/119445259.jpg "arxiv: v3 [cs.dc] 4 Dec 2018")
RCanopus: Making Canopus Resilient to Failures and Byzantine Faults arxiv:1810.09300v3 [cs.dc] 4 Dec 2018 1 Introduction S. Keshav, W. Golab, B. Wong, S. Rizvi, and S. Gorbunov School of Computer Science,
Shared Memory Seif Haridi
Shared Memory Seif Haridi haridi@kth.se Real Shared Memory Formal model of shared memory No message passing (No channels, no sends, no delivers of messages) Instead processes access a shared memory Models
Michel Raynal. Distributed Algorithms for Message-Passing Systems
Michel Raynal Distributed Algorithms for Message-Passing Systems Contents Part I Distributed Graph Algorithms 1 Basic Definitions and Network Traversal Algorithms... 3 1.1 DistributedAlgorithms... 3 1.1.1
Practical Byzantine Fault Tolerance (The Byzantine Generals Problem)
Practical Byzantine Fault Tolerance (The Byzantine Generals Problem) Introduction Malicious attacks and software errors that can cause arbitrary behaviors of faulty nodes are increasingly common Previous
Distributed Systems (5DV147)
Distributed Systems (5DV147) Replication and consistency Fall 2013 1 Replication 2 What is replication? Introduction Make different copies of data ensuring that all copies are identical Immutable data
SCALABLE MPC WITH STATIC ADVERSARY. Mahnush Movahedi, Jared Saia, Valerie King, Varsha Dani University of New Mexico University of Victoria
SCALABLE MPC WITH STATIC ADVERSARY Mahnush Movahedi, Jared Saia, Valerie King, Varsha Dani University of New Mexico University of Victoria November 2013 Multiparty Computation (MPC) 2 n players participate
Exam Distributed Systems
Exam Distributed Systems 5 February 2010, 9:00am 12:00pm Part 2 Prof. R. Wattenhofer Family Name, First Name:..................................................... ETH Student ID Number:.....................................................
Simulating Few by Many: k-concurrency via k-set Consensus
Simulating Few by Many: k-concurrency via k-set Consensus Eli Gafni May 29, 2007 Abstract We introduce a new novel emulation by which we show an equivalence between k-set Consensus and k-concurrency: Any
Practical Byzantine Fault Tolerance
Practical Byzantine Fault Tolerance Robert Grimm New York University (Partially based on notes by Eric Brewer and David Mazières) The Three Questions What is the problem? What is new or different? What
Coordination 1. To do. Mutual exclusion Election algorithms Next time: Global state. q q q
Coordination 1 To do q q q Mutual exclusion Election algorithms Next time: Global state Coordination and agreement in US Congress 1798-2015 Process coordination How can processes coordinate their action?