You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Additionally, there is an ettiquette for how gossip should happen.
48
+
Additionally, there is an etiquette for how gossip should happen.
49
+
50
+
The vector clock allows sensible application of version numbers to all updates,
51
+
and ensures that updates received by a node can be at least partially ordered
52
+
by a `precedes` relation, which allows quick exchange about the most recent
53
+
information you have seen. See [the next section](#the-vector-clock) for more
54
+
detail on vector clocks
57
55
58
-
The vector clock ensures that updates received by a node can be at least
59
-
partially ordered by a `precedes` relation, which allows quick exchange about
60
-
the most recent information you have seen. The history structure ensures
61
-
that you can tell your peer the news when you have heard something they have
62
-
not.
56
+
The history data structure keeps track of new updates as they come in, and
57
+
allows them to be replayed on request.
63
58
64
59
Gossip between two peers begins by exchanging vector clocks-- each peer sends
65
60
the other a list of highest version numbered update they've seen from everybody
66
61
in the network (including themselves).
67
62
68
63
Suppose  sends its vector clock to
69
-
. In that list there's the pair
70
-
(, 10).  responds with
71
-
all the updates it has seen locally which are greater than 10, ordering them in
72
-
chronological order. If there are more updates than fit in bandwidth, then are
73
-
simply omitted until the next round of communication, when the two nodes will
74
-
begin where they left off.
64
+
. In that list there's the two-ple
65
+
(, 10), so 
66
+
responds with all the updates it has heard about from itself (e.g. local
67
+
updates) with version numbers greater than 10, ordering them in chronological order.
68
+
 sends them one at a time until it has sent them
69
+
all, or exceeded the its bandwidth. The next time
70
+
 and  gossip, they will
71
+
again exchange vector clocks, which will ensure that they neither repeate
72
+
themselves nor leave anything out. This extends directly to a more complicated
73
+
network, since gossip is always pairwise.
75
74
76
75
Scuttlebutt is cpu and network efficient, and **eventually** consistent.
77
76
78
-
## Versioning [§](#conflicts)##
77
+
## The Vector Clock##
79
78
80
-
How do peers decided when to apply updates? How do they know an update occuring
81
-
elsewhere happened before their own update? Scuttlebutt applies a partial
82
-
ordering on updates by means of a [a vector clock][vector clock], described in
83
-
full in [Lamport 1978][vector clock]. It works, more or less as follows:
79
+
How do we version updates occuring across a distributed network? How does one
80
+
node tell an update coming from a peer occured before a local update?
84
81
85
-
Suppose peers `A`, `B` must exhange updates. They will each maintain a vector
86
-
of logical times for each peer. Logical time refers to the number of events the
87
-
peer has seen. This vector is called the `clock`, and is updated according to
88
-
the following two rules (IR1 and IR2 from [the paper][vector clock]):
82
+
Scuttlebutt [partially orders](partial-ordering) updates by means of a [a vector
83
+
clock][vector clock], described in full in [Lamport 1978][vector clock]. It
84
+
works, more or less as follows:
89
85
90
-
1. Each peer must update it's own entry in the list between any two updates
91
-
2. If A sends an update to B, it must also send along the logical time, `t`, at which the update occured.
92
-
Upon receive the update, B updates A's entry in its own clock to `t`, and then ensures its own
93
-
entry in its clock is greater than `t`.
86
+
Suppose nodes `A`, `B`must exhange updates. Each node maintains a vector,
87
+
called the `clock` of logical times[^logical-time] for each node in the
88
+
network. The `clock` is updated according to the following two rules (IR1 and
89
+
IR2 from [the paper][vector clock]):
94
90
91
+
1. Each peer must update it's own entry in the vector between any two updates
92
+
2. If A sends an update to B, it must also send along the logical time, `t`, at
93
+
which the update occured. Upon receive the update, B updates A's entry in
94
+
its own clock to `t`, and then ensures its own entry in its clock is greater
95
+
than `t`.
95
96
96
97
In the beginning, they each maintain a vector clock that looks like this:
97
98
@@ -107,11 +108,11 @@ A : [1, 0]
107
108
B : [0, 0]
108
109
```
109
110
110
-
When A gossips with B, it sends an update along with the version number at
111
-
which the update occured, in this case `1`. B applies the
112
-
update since it has a version number since `1` is higher than the most recent
113
-
time it has seen. It also increments its own version number to be one higher
114
-
than A's. Note that no event is marked with time 2.
111
+
When `A` gossips with `B`, it sends an update along with the version number at
112
+
which the update occured, in this case `1`. `B` updates the entry in the clock
113
+
corresponding to `A`. It also increments its own entry in its clock to be one
114
+
higher than `A`'s. Note that no individual update is marked with time 2, and
115
+
none will be.
115
116
116
117
```
117
118
A : [1, 0]
@@ -133,7 +134,10 @@ A: [4, 3]
133
134
B: [1, 3]
134
135
```
135
136
136
-
## Conflict ##
137
+
## Conflict
138
+
139
+
How do peers decided when to apply updates? In general, tehre is no simple
140
+
answer here. Different concerns will necessitate different update rules.
137
141
138
142
What happens if B encounters another local update?
139
143
@@ -180,7 +184,7 @@ constructor function called
180
184
Conceivably, you could implement your own clock synchronization algorithm, and
181
185
plug in its results here.
182
186
183
-
## Relation to [npm.im/scuttlebutt][] and _[van Renesse et al.][scuttlebutt]_[§](#relation-to-npm.imscuttlebutt-and-van-renesse-et-al.scuttlebutt) ##
187
+
## Relation to [npm.im/scuttlebutt][] and [*van Renesse et al.*][scuttlebutt]
184
188
185
189
My implementation, and consequently this module, was inspired by [Dominic
186
190
Tarr's scuttlebut module][npm.im/scuttlebutt], which, though totally awesome, I
@@ -197,12 +201,16 @@ course to the restrictions imposed by the format and language (javascript
197
201
rather than maths), although once I had internalized the concepts this ceased
198
202
to be a conscious effort.
199
203
200
-
201
204
[^stream]: [Node Streams][node streams] abstractions built into the node core
202
205
library for handling data over time. They present a unix-like api which allows
203
206
one to write to sinks, read from sources, and pipe sources to sinks. They are
204
207
available in the browser via [browserify][].
205
208
209
+
[^logical-time]: Logical time, as distinct from physical time, is essentially
210
+
the count of events witnessed by the node. Physical time is somewhat
211
+
similar— seconds count the number of times a physical clock's second hand
212
+
ticked, or the number of particles emitted from an atom.
213
+
206
214
[^system-time]: If anyone has contact information for the author, or is able to
207
215
grant legitimate free access to the paper, please [contact
0 commit comments