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
<p>In addition to classic replication using <i>createHistoryStream</i>, some Scuttlebutt clients implement a more efficient form of replication known as <i>Epidemic broadcast tree replication</i>. This is often referred to by the abbreviation <i>EBT</i>. The implementation of EBT used in Scuttlebutt is loosely based on the push-lazy-push multicast tree protocol, more commonly known as the <i>Plumtree</i> protocol [1].</p>
<p>An EBT session may be initiated once two peers have completed the secret handshake and have established their respective box streams. The peer who acted as the client during the secret handshake takes on the role of the requester, sending an <i>["ebt", "replicate"]</i> request to the connected peer.</p>
<p>The peer who acted as the server during the secret handshake takes on the role of the responder. After having received the replicate request, the responder must first validate the arguments to ensure that the version is 3 and the format is "classic". If either of those values are incorrect, the responder terminates the stream with an error.</p>
1126
+
<h4id="vector-clocks">Vector Clocks</h4>
1127
+
<p>The responder then sends a vector clock (also known as a "note" or "control message") to the requester. The vector clock takes the form of a JSON object with one or more key-value pairs. The key of each pair specifies a Scuttlebutt feed identified by the @-prefixed public key of the author. The value of each pair is a signed integer encoding a replicate flag, a receive flag and a feed sequence number.
<p>The requester should terminate the stream with an error if any of the received feed identifiers or encoded values are malformed. If the received vector clock is valid, the requester can proceed with decoding the values.</p>
1146
+
<p>The value in each key-value pair of a vector clock encodes a maximum of three data points: a replicate flag, a receive flag and a sequence number. A negative value (usually -1) signals that the responder does not wish to replicate the associated feed, neither sending nor receiving messages. In this scenario, the replicate flag is set to false and both the receive flag and sequence number are irrelevant.</p>
1147
+
<p>A positive value signals that the responder wishes to replicate the associated feed. If the value is positive it should be decoded as follows. First, the JSON number should be parsed and converted to a signed integer. Then, the rightmost (lowest order) bit of the number should be interpreted as a binary flag with 0 equal to true and 1 equal to false. This flag is referred to as the receive flag. Next, a sign-extending right shift (also called arithmetic right shift) by 1 bit should be performed on the binary number, therefore discarding the rightmost (lowest order) bit. The remaining number should then be interpreted as a sequence number for the associated feed.</p>
1148
+
<p>If the receive flag is set to true, the peer who sent the vector clock wishes to receive messages for the associated feed. The decoded sequence number defines the latest message held by the peer for that feed.</p>
1149
+
<p>Encoding of a vector clock value involves reversing the steps outlined above. If the peer does not wish to replicate a feed, the value is simply set to -1. Otherwise, the latest sequence number of the associated feed should be stored as a signed integer and an arithmetic left shift should be performed. The rightmost (lowest order) bit should then be set according to the replicate flag as described previously.</p>
1150
+
<tableclass="clock-values">
1151
+
<thead>
1152
+
<tr>
1153
+
<throwspan="2">Encoded</th>
1154
+
<thcolspan="3">Decoded</th>
1155
+
</tr>
1156
+
<tr>
1157
+
<th>Replicate flag</th>
1158
+
<th>Receive flag</th>
1159
+
<th>Sequence</th>
1160
+
</tr>
1161
+
</thead>
1162
+
<tbody>
1163
+
<tr>
1164
+
<td>-1</td>
1165
+
<td>False</td>
1166
+
<td>Irrelevant</td>
1167
+
<td>Irrelevant</td>
1168
+
</tr>
1169
+
<tr>
1170
+
<td>0</td>
1171
+
<td>True</td>
1172
+
<td>True</td>
1173
+
<td>0</td>
1174
+
</tr>
1175
+
<tr>
1176
+
<td>1</td>
1177
+
<td>True</td>
1178
+
<td>False</td>
1179
+
<td>0</td>
1180
+
</tr>
1181
+
<tr>
1182
+
<td>2</td>
1183
+
<td>True</td>
1184
+
<td>True</td>
1185
+
<td>1</td>
1186
+
</tr>
1187
+
<tr>
1188
+
<td>3</td>
1189
+
<td>True</td>
1190
+
<td>False</td>
1191
+
<td>1</td>
1192
+
</tr>
1193
+
</tbody>
1194
+
</table>
1195
+
<p>The requester then sends their own vector clock to the responder. At this point, the initial exchange of vector clocks is complete and both peers can begin freely sending messages.</p>
<p>[1] Joao Leitao, Jose Pereira and Luis Rodrigues. 2007. Epidemic Broadcast Trees. In <i>2007 26th IEEE International Symposium on Reliable Distributed Systems (SRDS 2007)</i>, 301-310. https://doi.org/10.1109/SRDS.2007.27</p>
0 commit comments