Distributed Computing though Combinatorial Topology
1
Companion slides for Distributed Computing
Through Combinatorial Topology Maurice Herlihy & Dmitry Kozlov & Sergio Rajsbaum
In the Beginning …
2
0 1 1 0 1 0 1
a computer was just a Turing machine …
Distributed Computing though Combinatorial Topology
Presenter
Presentation Notes
In the beginning, a computer was a single processor. A rich theory grew up studying what single processors can and can’t do.
Today ? ?
?
3
Computing is co-ordination and communication
Distributed Computing though Combinatorial Topology
Presenter
Presentation Notes
Today, however, there are many computers. Sometimes these computers are very far apart, as on the Internet. Sometimes they are closer, as in a sensor network. Sometimes they are close, as in a multicore chip. And sometimes they are very close, as in a graphics processor.
No, distributed computations are static mathematical objects!
Distributed computations unfold in time!
Operational versus combinatorial approaches …
4
Background picture: School of Athens, Rafael https://www.flickr.com/photos/stefanorometours/6796909455/in/photolist-6mya9T-bmBWo4-bmC4SR-bmBXrX-5cV https://creativecommons.org/licenses/by/2.0/legalcode
Road Map
5
Distributed Computing
Two Classic Distributed Problems
The Muddy Children
Coordinated Attack
Road Map
6
Distributed Computing
Two Classic Distributed Problems
The Muddy Children
Coordinated Attack
There are Many Models
7 Distributed Computing though Combinatorial Topology
http://sumptuoussynthphonys.blogspot.com
/2013
Presenter
Presentation Notes
In distributed computing, there are many legitimate models of computation. This variety may seem confusing at first, but all these models, different as they are, share common properties.
There are Many Models
8
Communication?
Distributed Computing though Combinatorial Topology
http://sumptuoussynthphonys.blogspot.com
/2013
Presenter
Presentation Notes
In distributed computing, there are many legitimate models of computation. This variety may seem confusing at first, but all these models, different as they are, share common properties.
There are Many Models
9
Communication?
Failures?
Distributed Computing though Combinatorial Topology
http://sumptuoussynthphonys.blogspot.com
/2013
Presenter
Presentation Notes
In distributed computing, there are many legitimate models of computation. This variety may seem confusing at first, but all these models, different as they are, share common properties.
There are Many Models
10
Communication?
Failures?
Distributed Computing though Combinatorial Topology
http://sumptuoussynthphonys.blogspot.com
/2013 Timing?
Presenter
Presentation Notes
In distributed computing, there are many legitimate models of computation. This variety may seem confusing at first, but all these models, different as they are, share common properties.
Communication
11 Distributed Computing though Combinatorial Topology
Distributed Computing though Combinatorial Topology
15
http://ww
w.alpa.ch/en/new
s/2011/dead-sea-scrolls
Read-Write Models
16
write & read individual locations
write & take memory snapshot
Group writes together then takes snapshots together
Layered Read-Write Memory
17
Black Box Memory
Compare-and-swap Fetch-and-add
18
Failures
19
Crash failures: processes halt
How many?
Which ones?
Distributed Computing though Combinatorial Topology
Presenter
Presentation Notes
Failures are halting failures: a process simply stops and takes no more steps. When designing a protocol, it is important to know what kinds of failures your protocol must tolerate.
Wait-Free Failure Model
All but one may crash
20
Presenter
Presentation Notes
In the wait-free model, all but one of the processes can fail. This is the most demanding model.
t-Resilient Failure Model
At most t may crash
Here, t = 1.
21
Presenter
Presentation Notes
In the t-resilient model, at most t process can crash. If t < n-1, this model is less demanding than the wait-free model.
Correlated Failures
Processes on same server may crash
22
Presenter
Presentation Notes
Both the wait-free and t-resilient models assume failures are independent. In real life, failures are often not independent. In this example, the red and greed processes reside at one server, and the purple at another. Protocol designers should expect that red and green fail together, or purple fails by itself.
It is important to understand how time works. Protocol design is easier if processes share a common clock: they take steps at the same rate, and one process can wait for another. Protocol design is harder if processes run at different speeds. In the middle, processes might run at different speeds, but not too different.
Timing Models
27
Processes share a clock
Distributed Computing though Combinatorial Topology
It is important to understand how time works. Protocol design is easier if processes share a common clock: they take steps at the same rate, and one process can wait for another. Protocol design is harder if processes run at different speeds. In the middle, processes might run at different speeds, but not too different.
Timing Models
28
Processes share a clock Synchronous
Distributed Computing though Combinatorial Topology
It is important to understand how time works. Protocol design is easier if processes share a common clock: they take steps at the same rate, and one process can wait for another. Protocol design is harder if processes run at different speeds. In the middle, processes might run at different speeds, but not too different.
Timing Models
29
Processes share a clock Synchronous
Processes do not share a clock
Distributed Computing though Combinatorial Topology
It is important to understand how time works. Protocol design is easier if processes share a common clock: they take steps at the same rate, and one process can wait for another. Protocol design is harder if processes run at different speeds. In the middle, processes might run at different speeds, but not too different.
Timing Models
30
Processes share a clock Synchronous
Processes do not share a clock Asynchronous
Distributed Computing though Combinatorial Topology
It is important to understand how time works. Protocol design is easier if processes share a common clock: they take steps at the same rate, and one process can wait for another. Protocol design is harder if processes run at different speeds. In the middle, processes might run at different speeds, but not too different.
Timing Models
31
Processes share a clock Synchronous
Processes do not share a clock Asynchronous
Processes have approximately-synchronized clocks
Distributed Computing though Combinatorial Topology
It is important to understand how time works. Protocol design is easier if processes share a common clock: they take steps at the same rate, and one process can wait for another. Protocol design is harder if processes run at different speeds. In the middle, processes might run at different speeds, but not too different.
It is important to understand how time works. Protocol design is easier if processes share a common clock: they take steps at the same rate, and one process can wait for another. Protocol design is harder if processes run at different speeds. In the middle, processes might run at different speeds, but not too different.
Synchronous
33
Presenter
Presentation Notes
In synchronous models, processes take steps at the same rate. After the red process takes a step, it knows the blue process has also taken a step. Synchronous comes from Greek: syn = together, chronos = time.
Synchronous Failures !
detection easy 34
Presenter
Presentation Notes
One advantage of the synchronous model is that one process can easily detect when another has failed.
Asynchronous
35
Presenter
Presentation Notes
In asynchronous models, processes take steps at any rate. Asynchronous comes from Greek: a (not) + synchronous (at the same time). Synchronous comes from Greek: syn = together, chronos = time.
Asynchronous Failures
??
detection impossible 36
Presenter
Presentation Notes
The asynchronous model is difficult because it is impossible to tell whether another process has failed or is just slow.
Semi-Synchronous
37
Presenter
Presentation Notes
In the semi-synchronous model, processes may take steps at different speeds, but there is a bound on the difference. Here, for example, each time one process takes two steps, the other must take one. Semi-synchronous is a awkward mixture of semi (Latin for partly) and synchronous (Greek for “at the same time”).
! Semi-Synchronous Failures
detection slow 38
Presenter
Presentation Notes
In semi-synchronous model, it is possible for one process can detect when another has failed, but such detection is usually expensive, since one processor must wait for a long time before it can detect that another has failed. The word
39
Computation Model Space
asynchronous
semi-synchronous
synchronous
messages read-write
black-box
t-resilient wait-free
adversaries
Which combinations make sense? 39
Presenter
Presentation Notes
The space of registers can be divided into three dimensions, where the number of readers and writers is one dimension, the register size is another, and the strength of the correctness condition is a third.
43 Distributed Computing though Combinatorial Topology
110
Each process has a 3-bit local view
Multiple Local Views
44 Distributed Computing though Combinatorial Topology
110
local views differ by 1 bit
111
Multiple Local Views
45 Distributed Computing though Combinatorial Topology
110
local views differ by 1 bit
111
but no process knows which one
Multiple Local Views
46 Distributed Computing though Combinatorial Topology
110
each view is represented by a labeled vertex
111
Global States
47 Distributed Computing though Combinatorial Topology
110
compatible views represented by an
edge
111
000
110 111
001
101 100
011 010
110 111
Distributed Computing though Combinatorial Topology
All possible global states
(where blue has 111)
Presenter
Presentation Notes
This slide shows the possible views of two processes, each with a three-bit local view, with process names indicated by color. A pair of views is joined by an edge if those views can coexist.
Communication
49 Distributed Computing though Combinatorial Topology
110
Each process sends local view
to the other
111 111 110
Presenter
Presentation Notes
Each process then sends its view to the other, but communication is unreliable, and at most one message may be lost.
Communication
50 Distributed Computing though Combinatorial Topology
110
Each process sends local view
to the other
111
but at most one message may be lost!
111
Presenter
Presentation Notes
Each process then sends its view to the other, but communication is unreliable, and at most one message may be lost.
One Communication Round
51 Distributed Computing though Combinatorial Topology
110 ?
111 110
110 111
111 ?
Presenter
Presentation Notes
Here are the set of possible views after a single round of unreliable communication. The first edge is a state where red’s message to blue was lost, but not vice-versa. The middle edge is the state where both messages were delivered. Note that the middle blue vertex is common to both edges because the blue process can’t distinguish between these states..
One Communication Round
52 Distributed Computing though Combinatorial Topology
110 ?
1 Lost
111 110
110 111
111 ?
Presenter
Presentation Notes
Here are the set of possible views after a single round of unreliable communication. The first edge is a state where red’s message to blue was lost, but not vice-versa. The middle edge is the state where both messages were delivered. Note that the middle blue vertex is common to both edges because the blue process can’t distinguish between these states..
One Communication Round
53 Distributed Computing though Combinatorial Topology
110 ?
1 Lost
111 110
110 111
111 ?
none Lost
Presenter
Presentation Notes
Here are the set of possible views after a single round of unreliable communication. The first edge is a state where red’s message to blue was lost, but not vice-versa. The middle edge is the state where both messages were delivered. Note that the middle blue vertex is common to both edges because the blue process can’t distinguish between these states..
One Communication Round
54 Distributed Computing though Combinatorial Topology
110 ?
1 Lost
111 110
110 111
111 ?
1 Lost none Lost
Presenter
Presentation Notes
Here are the set of possible views after a single round of unreliable communication. The first edge is a state where red’s message to blue was lost, but not vice-versa. The middle edge is the state where both messages were delivered. Note that the middle blue vertex is common to both edges because the blue process can’t distinguish between these states..
One Communication Round
55 Distributed Computing though Combinatorial Topology
110 ?
111 110
110 111
111 ?
Presenter
Presentation Notes
Here is the set of states in more compact notation.
110 ?
111 ?
110 111
111 110
Distributed Computing though Combinatorial Topology
All possible global states after one round unreliable communication
Presenter
Presentation Notes
Here is the set of all possible global and local states after one round of unreliable communication. We highlighted the previous slide’s edge at the bottom.
000
110 111
001
101 100
011 010
Presenter
Presentation Notes
An innate property of this model is that, while unreliable communication adds new vertices to the graph, it does not change its overall shape, which is still a cube. Indeed, no matter how many times the processes communicate, the result is still a cube.
000
110 111
001
101 100
011 010
Informally …. Unreliable communication
does not change “topology” of global states
Presenter
Presentation Notes
An innate property of this model is that, while unreliable communication adds new vertices to the graph, it does not change its overall shape, which is still a cube. Indeed, no matter how many times the processes communicate, the result is still a cube.
Reliable Communication?
59 Distributed Computing though Combinatorial Topology
110 ?
111 110
110 111
111 ?
Presenter
Presentation Notes
What if we replace unreliable communication by reliable communication, were messages are guaranteed to be delivered. [animation] Only one edge persists, the one where both messages were delivered.
Reliable Communication?
60 Distributed Computing though Combinatorial Topology
111 110
110 111
Presenter
Presentation Notes
What if we replace unreliable communication by reliable communication, were messages are guaranteed to be delivered. [animation] Only one edge persists, the one where both messages were delivered.
000
110 111
001
101 100
011 010
Distributed Computing though Combinatorial Topology
Presenter
Presentation Notes
This slide shows the same transformation, except that the processes use a reliable communication medium that does not drop messages. At the end of a communication round, each process knows the other's view. Reliable communication changes the overall shape, transforming a cube into a set of disconnected edges.
Tasks
62 Distributed Computing though Combinatorial Topology
Tasks
63
32 19
21
Possible set of input values
Distributed Computing though Combinatorial Topology
Tasks
64
32 19
21
Possible set of input values
Finite computation
Distributed Computing though Combinatorial Topology
Tasks
65
32 19
21
19 19
19
32 32
32
21 21
21
Possible set of input values
Possible set of output values
Finite computation
Distributed Computing though Combinatorial Topology
Task
Inputs Outputs Specification
Protocol
computation decision
Presenter
Presentation Notes
Consider a distributed system trying to solve a task. The initial views of the processes are just the possible inputs to the task, and are described by an input complex (circle on left). The outputs that the processes are allowed to produce, as specified by the task, are described by the output complex, (annulus on left). Distributed computation is just a way to stretch, fold, and possibly tear the input complex, in ways that depend on the specific model, with the goal of transforming it into a form that can be mapped to the output complex.
Road Map
67
Distributed Computing
Two Classic Distributed Problems
The Muddy Children
Coordinated Attack
Muddy Children
68 Distributed Computing though Combinatorial Topology
11:00
Presenter
Presentation Notes
A group of children is playing in the garden …
Muddy Children
69 Distributed Computing though Combinatorial Topology
11:01
Presenter
Presentation Notes
and some of them end up with mud on their foreheads. Each child can see the other children's foreheads, but not its own.
Muddy Children
70 Distributed Computing though Combinatorial Topology
At least one of you is dirty!
12:00
Presenter
Presentation Notes
At noon, their teacher summons the children and says: ``At least one of you has a muddy forehead.
Muddy Children
71 Distributed Computing though Combinatorial Topology
You may not communicate!
12:00
Presenter
Presentation Notes
You are not allowed to communicate with one another about it in any manner.
Muddy Children
72 Distributed Computing though Combinatorial Topology
When you realize you are dirty,
confess on the hour!
12:00
Presenter
Presentation Notes
But whenever you become certain that you are dirty, you must announce it to everybody, exactly on the hour.
Muddy Children
73 Distributed Computing though Combinatorial Topology
1:00
(silence …)
Presenter
Presentation Notes
The children resume playing normally, and nobody mentions the state of anyone's forehead.
Muddy Children
74 Distributed Computing though Combinatorial Topology
2:00
Me! Me!
Presenter
Presentation Notes
There were two muddy children, and at 2:00 they both announce themselves. How does this work?
Operational Explanation
75 Distributed Computing though Combinatorial Topology
1:00
Presenter
Presentation Notes
There were two muddy children, and at 2:00 they both announce themselves. How does this work?
Operational Explanation
76 Distributed Computing though Combinatorial Topology
1:00
Others are clean, so I must be dirty.
Presenter
Presentation Notes
There were two muddy children, and at 2:00 they both announce themselves. How does this work?
Operational Explanation
77 Distributed Computing though Combinatorial Topology
1:00
Me!
Others are clean, so I must be dirty.
Presenter
Presentation Notes
There were two muddy children, and at 2:00 they both announce themselves. How does this work?
Operational Explanation
78 Distributed Computing though Combinatorial Topology
1:01
Presenter
Presentation Notes
There were two muddy children, and at 2:00 they both announce themselves. How does this work?
Operational Explanation
79 Distributed Computing though Combinatorial Topology
1:01 He was quiet, so I must be dirty.
He was quiet, so I must be dirty.
Presenter
Presentation Notes
There were two muddy children, and at 2:00 they both announce themselves. How does this work?
Combinatorial Explanation
80 Distributed Computing though Combinatorial Topology
12:00
Presenter
Presentation Notes
A child's \emph{input} is its initial state of knowledge.
Combinatorial Explanation
81 Distributed Computing though Combinatorial Topology
12:00
Presenter
Presentation Notes
A child's \emph{input} is its initial state of knowledge.
Combinatorial Explanation
82 Distributed Computing though Combinatorial Topology
12:00
Each process has its own input
Presenter
Presentation Notes
A child's \emph{input} is its initial state of knowledge.
Combinatorial Explanation
83 Distributed Computing though Combinatorial Topology
12:00
Each process has its own input
?11 01?
0?1
Presenter
Presentation Notes
A child's \emph{input} is its initial state of knowledge.
Combinatorial Explanation
84 Distributed Computing though Combinatorial Topology
12:00 ?11 01?
0?1 Global State
Presenter
Presentation Notes
A child's \emph{input} is its initial state of knowledge.
all dirty
all clean
?11
00? 0? 0
1?1 11?
0?1 01?
1? 0 10?
?00
?01 ?1 0
11:59
Distributed Computing though Combinatorial Topology
Presenter
Presentation Notes
For three children, here are the possible initial configurations. Each vertex represents a child's possible input. Each vertex is labeled with an input vector, and colored to identify the corresponding child. Each possible configuration is represented as a solid triangle, linking \emph{compatible} states for the three children. The triangle at the very top represents the configurations where all three children are clean, the one at the bottom where they are all dirty, and the triangles in between represent configurations where some are clean and some are dirty.
all dirty
?11
00? 0? 0
1?1 11?
0?1 01?
1? 0 10?
?00
?01 ?1 0
12:01
Distributed Computing though Combinatorial Topology
Presenter
Presentation Notes
For three children, here are the possible initial configurations. Each vertex represents a child's possible input. Each vertex is labeled with an input vector, and colored to identify the corresponding child. Each possible configuration is represented as a solid triangle, linking \emph{compatible} states for the three children. The triangle at the very top represents the configurations where all three children are clean, the one at the bottom where they are all dirty, and the triangles in between represent configurations where some are clean and some are dirty.
all dirty
?11 1?1 11?
0?1 01?
1? 0 10?
?01 ?1 0
1:01
Distributed Computing though Combinatorial Topology
Presenter
Presentation Notes
For three children, here are the possible initial configurations. Each vertex represents a child's possible input. Each vertex is labeled with an input vector, and colored to identify the corresponding child. Each possible configuration is represented as a solid triangle, linking \emph{compatible} states for the three children. The triangle at the very top represents the configurations where all three children are clean, the one at the bottom where they are all dirty, and the triangles in between represent configurations where some are clean and some are dirty.
all dirty
?11 1?1 11?
2:01
Distributed Computing though Combinatorial Topology
Presenter
Presentation Notes
For three children, here are the possible initial configurations. Each vertex represents a child's possible input. Each vertex is labeled with an input vector, and colored to identify the corresponding child. Each possible configuration is represented as a solid triangle, linking \emph{compatible} states for the three children. The triangle at the very top represents the configurations where all three children are clean, the one at the bottom where they are all dirty, and the triangles in between represent configurations where some are clean and some are dirty.
Road Map
89
Distributed Computing
Two Classic Distributed Problems
The Muddy Children
Coordinated Attack
Coordinated Attack
90 Distributed Computing though Combinatorial Topology
Red army wins If both sides
attack together
Alice Bob
The Two Generals
91 Distributed Computing though Combinatorial Topology
Red generals send messengers across the valley
Alice Bob
The Two Generals
92 Distributed Computing though Combinatorial Topology
Messengers don’t always make it
Alice Bob
93
Your Mission
Design a protocol to ensure that Alice and Bob attack
simultaneously
Distributed Computing though Combinatorial Topology
94
Theorem
There is no protocol that ensures that the Red armies
attack simultaneously
Distributed Computing though Combinatorial Topology
95
Operational Proof Suppose Bob receives a message at 1:00 saying
“attack at Dawn”.
Distributed Computing though Combinatorial Topology
96
Operational Proof Suppose Bob receives a message at 1:00 saying
“attack at Dawn”.
Distributed Computing though Combinatorial Topology
Are we done?
97
Operational Proof Suppose Bob receives a message at 1:00 saying
“attack at Dawn”.
Distributed Computing though Combinatorial Topology
Are we done? No, because Alice doesn’t
know if Bob got that message …
98
Operational Proof So Bob sends an
acknowledgment to Alice …
Distributed Computing though Combinatorial Topology
Presenter
Presentation Notes
It is not hard to see that no number of successfully delivered acknowledgments will be enough to ensure that the generals can attack safely. The key insight is that the difficulty is not caused by what actually happens (all messages do arrive) but by the uncertainty regarding what might have happened. In the scenario we just considered, communication is flawless, but coordination is still impossible.
99
Operational Proof So Bob sends an
acknowledgment to Alice …
Distributed Computing though Combinatorial Topology
Are we done?
Presenter
Presentation Notes
It is not hard to see that no number of successfully delivered acknowledgments will be enough to ensure that the generals can attack safely. The key insight is that the difficulty is not caused by what actually happens (all messages do arrive) but by the uncertainty regarding what might have happened. In the scenario we just considered, communication is flawless, but coordination is still impossible.
100
Operational Proof So Bob sends an
acknowledgment to Alice …
Distributed Computing though Combinatorial Topology
Are we done? No, because Bob doesn’t
know if Alice got that message …
Presenter
Presentation Notes
It is not hard to see that no number of successfully delivered acknowledgments will be enough to ensure that the generals can attack safely. The key insight is that the difficulty is not caused by what actually happens (all messages do arrive) but by the uncertainty regarding what might have happened. In the scenario we just considered, communication is flawless, but coordination is still impossible.
101
Operational Proof So Bob sends an
acknowledgment to Alice …
Distributed Computing though Combinatorial Topology
Are we done? No, because Bob doesn’t
know if Alice got that message …
Presenter
Presentation Notes
It is not hard to see that no number of successfully delivered acknowledgments will be enough to ensure that the generals can attack safely. The key insight is that the difficulty is not caused by what actually happens (all messages do arrive) but by the uncertainty regarding what might have happened. In the scenario we just considered, communication is flawless, but coordination is still impossible.
Noon
Attack at dawn! Attack at noon!
Distributed Computing though Combinatorial Topology
Bob is Alice is
Presenter
Presentation Notes
Here is how to consider this problem using the combinatorial approach, encompassing all possible scenarios in a single geometric object, a graph. Alice has two possible initial states: she intends to attack either at dawn, or at noon the next day. Each such state is a black vertex. Bob has only one possible initial state: he await's Alice's order. This state is the white vertex linking the two edges, representing Bob's uncertainty whether he is in a world where Alice intends to attack at dawn, on the left, or in a world where she intends to attack at noon, on the right.
1:00 PM
delivered delivered lost
Distributed Computing though Combinatorial Topology
Presenter
Presentation Notes
At noon, Alice sends a message with her order. Here are the configurations one hour later, at 1:00 PM in each of the possible worlds. Either her message arrives, or it does not. (We can ignore scenarios where the message arrives earlier or later, because if agreement is impossible if messages always arrive on time, then it is impossible even if they do not. The three white vertices represent Bob's possible states. On the left, Bob receives a message to attack at dawn, on the right, to attack at noon, and in the middle, he receives no message. Now Alice is the one who is uncertain whether Bob received her last message.
2:00 PM
delivered lost delivered lost
Distributed Computing though Combinatorial Topology
Presenter
Presentation Notes
This slide shows a subset of the possible configurations an hour later, at 2:00 PM, when Bob's 1:00 PM acknowledgment may or may not have been received. We can continue this process for an arbitrary number of rounds. In each case, it is not hard to see that the graph of possible states forms a line. At time $t$, there will be $2t+2$ edges. At one end, an initial ``attack at dawn'' message is followed by successfully-delivered acknowledgments, and at the other end, an initial ``attack at noon'' message is followed by successfully-delivered acknowledgments. In the states in the middle, however, messages were lost.
output graph
protocol graph
delivered delivered lost
Attack at dawn! Attack at noon! decision
map
Don’t attack!
Presenter
Presentation Notes
If it were possible to reach agreement after some number of message exchanges, we could then label each vertex with an attack order, either ``dawn'' or ``noon''. Because both generals must agree on the attack time, both vertices of each edge must be labeled with the same attack time.
output graph
protocol graph
delivered delivered lost
These edges go here
dawn! noon!
Presenter
Presentation Notes
If it were possible to reach agreement after some number of message exchanges, we could then label each vertex with an attack order, either ``dawn'' or ``noon''. Because both generals must agree on the attack time, both vertices of each edge must be labeled with the same attack time.
This graph is connected
Distributed Computing though Combinatorial Topology
Presenter
Presentation Notes
If it were possible to reach agreement after some number of message exchanges, we could then label each vertex with an attack order, either ``dawn'' or ``noon''. Because both generals must agree on the attack time, both vertices of each edge must be labeled with the same attack time.
This graph is not connected
Distributed Computing though Combinatorial Topology
Presenter
Presentation Notes
If it were possible to reach agreement after some number of message exchanges, we could then label each vertex with an attack order, either ``dawn'' or ``noon''. Because both generals must agree on the attack time, both vertices of each edge must be labeled with the same attack time.
delivered delivered lost
Map not allowed to “tear” protocol complex
Presenter
Presentation Notes
If it were possible to reach agreement after some number of message exchanges, we could then label each vertex with an attack order, either ``dawn'' or ``noon''. Because both generals must agree on the attack time, both vertices of each edge must be labeled with the same attack time.
output graph
protocol graph
decision map
Presenter
Presentation Notes
If it were possible to reach agreement after some number of message exchanges, we could then label each vertex with an attack order, either ``dawn'' or ``noon''. Because both generals must agree on the attack time, both vertices of each edge must be labeled with the same attack time.
Operational Reasoning
111 Distributed Computing though Combinatorial Topology
