commit 036b23cf20287d2f41856d594617b68efb3af9b8
parent 8117a472e3122e371b595ef68d6c89170a36070a
Author: Elias Summermatter <elias.summermatter@seccom.ch>
Date: Wed, 6 Jan 2021 10:52:58 +0100
Initial commit after holidays many changes and rewrites
Diffstat:
1 file changed, 300 insertions(+), 39 deletions(-)
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
@@ -123,34 +123,132 @@
</t>
</section>
- <section anchor="contributors" numbered="true" toc="default">
- <name>Contributors</name>
- <t>
- The original GNU NET implementation of the Byzantine Fault Tolerant Set Reconciliation has mainly been
- written by Florian Dold and Christian Grothoff.
- </t>
+ <section anchor="bf" numbered="true" toc="default">
+ <name>Bloom Filter</name>
+ <t>
+ A Bloom Filter (BF) is a space-efficient datastructure to test if am element is part of a set of elements.
+ Since a Bloom filter is a probabilistic datastructure its possible to have false positives but false negatives
+ are not possible.
+ </t>
+ <t>
+ A BF consists out of multiple buckets, every bucket can be set to 0 or 1. In the beginning all buckets are set
+ to 0. To add an element to the BF the corresponding buckets are set to 1. To map an element on the array of buckets
+ a mapping function M is required. The mapping function is non-injective a takes an element as input and outputs a
+ deterministic bit stream of the length of the BF. The Mapping function is described by the following mathematical equation:
+ </t>
+ <figure anchor="bf_mapping_function_math">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ --------------------------------
+ # E->B^k (B=Z/l)
+ --------------------------------
+ # l = number buckets
+ # B = 0...1,
+ # k = number of bits per element
+ # E = Element from the set
+ --------------------------------
+ ]]></artwork>
+ </figure>
+ <t>
+ Further in this document a bitstream outputted by the mapping function is represented by
+ a set of numeric values for example (0101) = (2,4).
+ In the BF the buckets are set to 1 if the corresponding bit in the bitstream is 1.
+ If there is a collision and a bucket is already set to 1, the bucket stays 1.
+ </t>
+ <t>
+ In the following example the element M(element) = (1,3) has been added:
+ </t>
+ <figure anchor="figure_bf_insert_0">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ bucket-0 bucket-1 bucket-2 bucket-3
+ +-------------+-------------+-------------+-------------+
+ | 0 | 1 | 0 | 1 |
+ +-------------+-------------+-------------+-------------+
+ ]]></artwork>
+ </figure>
+ <t>
+ Is easy to see that the M(element) = (0,3) could be in the BF bellow and M(element) = (0,2) can't be
+ in the BF bellow:
+ </t>
+
+ <figure anchor="figure_bf_contains">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ bucket-0 bucket-1 bucket-2 bucket-3
+ +-------------+-------------+-------------+-------------+
+ | 1 | 0 | 0 | 1 |
+ +-------------+-------------+-------------+-------------+
+ ]]></artwork>
+ </figure>
+ <t>
+ Its not possible to remove an element from the BF because buckets can only be set to 1 or 0 so its not possible to
+ differentiate between buckets containing one or multiple elements. To remove elements from the BF a <xref target="cbf" format="title" />
+ is required.
+ </t>
+ </section>
+
+ <section anchor="cbf" numbered="true" toc="default">
+ <name>Counting Bloom Filter</name>
+ <t>
+ A Counting Bloom Filter (CBF) is an extension of the Bloom Filer datastructure it replaces the filed of
+ the bucket with an unsigned counter. This allows the removal of an elements from the CBF.
+ </t>
+ <t>
+ Adding an element to the CBF is similar to the adding operation of the BF but instead of setting the bucket on hit to 1 the bucket
+ is increased by 1. For example if two colliding elements M(element1) = (1,3) and
+ M(element2) = (0,3) are added to the CBF bucket 0 and 1 are set to 1 and bucket 3 (the colliding bucket) is set
+ to 2:
+ </t>
+ <figure anchor="figure_cbf_insert_0">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ bucket-0 bucket-1 bucket-2 bucket-3
+ +-------------+-------------+-------------+-------------+
+ | 1 | 1 | 0 | 2 |
+ +-------------+-------------+-------------+-------------+
+ ]]></artwork>
+ </figure>
+ <t>
+ The order of a bucket is defined by the counter, if a bucket contains two elements the counter is set to 2 so the order of
+ the bucket is two.
+ </t>
+ <t>
+ To remove an element form the CBF the counter is decreased by 1.
+ </t>
+ <t>
+ Removing M(element2) = (1,3) from the CBF above:
+ </t>
+ <figure anchor="figure_cbf_remove_0">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ bucket-0 bucket-1 bucket-2 bucket-3
+ +-------------+-------------+-------------+-------------+
+ | 1 | 0 | 0 | 1 |
+ +-------------+-------------+-------------+-------------+
+ ]]></artwork>
+ </figure>
</section>
<section anchor="ibv" numbered="true" toc="default">
<name>Invertible Bloom Filter</name>
<t>
- A Invertible Bloom Filter (IBF) is a probabilistic data structure that allows to determinate efficiently
- but not with absolut certainty that a given element is presence or absence in a set.
- The IBF knows three basic operations add element, remove element and decode.
+ A Invertible Bloom Filter (IBF) is a further extension of the CBF. The IBF extends the CBF with two more operations,
+ beside insert and remove the IBF supports a decode and set difference operation. This two extra operations allows the
+ IBF to calculate small differences in big sets very efficiently.
IBF are useful when there is the need to check a set of elements for the presence or absence of some
elements in a big set efficiently.
+
</t>
<section anchor="ibf_format" numbered="true" toc="default">
<name>Format</name>
<t>
- The storage format of an IBF is a "two-component data structure" that stores a hash value
- and a signed counter in a bucket. For every bit of the defined output length of the used hash functions
- there is a value and a count stored.
+ The storage format of an IBF consists of n buckets that store a hash value
+ and a signed counter. The decision how many bits are used for the counter and for the map filed
+ is a tradeoff and has to be adjusted to the cup architecture and setsize for optimal performance.
+ If a 4-bit counter reaches 7 or -8 this means the counter is overflown and the IBF does not decode
+ anymore in this case the size of the IBF or the size of the counter has to be adjusted. In
+ the described implementation the size of the counter and the HASH Value is 32-bit.
</t>
<figure anchor="figure_ibf_format">
<artwork name="" type="" align="left" alt=""><![CDATA[
- bit-1 bit-2 bit-3 bit-4
+ bucket-0 bucket-1 bucket-2 bucket-3
+-------------+-------------+-------------+-------------+-------
count | COUNTER | COUNTER | COUNTER | COUNTER | C...
+-------------+-------------+-------------+-------------+------
@@ -177,7 +275,7 @@
<t>Empty IBF:</t>
<figure anchor="figure_ibf_insert_0">
<artwork name="" type="" align="left" alt=""><![CDATA[
- bit-1 bit-2 bit-3 bit-4
+ bucket-0 bucket-1 bucket-2 bucket-3
+-------------+-------------+-------------+-------------+
count | 0 | 0 | 0 | 0 |
+-------------+-------------+-------------+-------------+
@@ -188,7 +286,7 @@
<t>Insert first element: [0101] with hash 4242:</t>
<figure anchor="figure_ibf_insert_1">
<artwork name="" type="" align="left" alt=""><![CDATA[
- bit-1 bit-2 bit-3 bit-4
+ bucket-0 bucket-1 bucket-2 bucket-3
+-------------+-------------+-------------+-------------+
count | 0 | 1 | 0 | 1 |
+-------------+-------------+-------------+-------------+
@@ -199,7 +297,7 @@
<t>Insert second element: [1100] with hash 0101:</t>
<figure anchor="figure_ibf_insert_2">
<artwork name="" type="" align="left" alt=""><![CDATA[
- bit-1 bit-2 bit-3 bit-4
+ bucket-0 bucket-1 bucket-2 bucket-3
+-------------+-------------+-------------+-------------+
count | 1 | 2 | 0 | 1 |
+-------------+-------------+-------------+-------------+
@@ -222,7 +320,7 @@
<t>IBF with encoded elements:</t>
<figure anchor="figure_ibf_remove_0">
<artwork name="" type="" align="left" alt=""><![CDATA[
- bit-1 bit-2 bit-3 bit-4
+ bucket-0 bucket-1 bucket-2 bucket-3
+-------------+-------------+-------------+-------------+
count | 1 | 2 | 0 | 1 |
+-------------+-------------+-------------+-------------+
@@ -233,7 +331,7 @@
<t>Remove element [1100] with hash 0101 from the IBF:</t>
<figure anchor="figure_ibf_remove_1">
<artwork name="" type="" align="left" alt=""><![CDATA[
- bit-1 bit-2 bit-3 bit-4
+ bucket-0 bucket-1 bucket-2 bucket-3
+-------------+-------------+-------------+-------------+
count | 0 | 1 | 0 | 1 |
+-------------+-------------+-------------+-------------+
@@ -261,7 +359,7 @@
</t>
<figure anchor="figure_ibf_decode_0">
<artwork name="" type="" align="left" alt=""><![CDATA[
- bit-1 bit-2 bit-3 bit-4
+ bucket-0 bucket-1 bucket-2 bucket-3
+-------------+-------------+-------------+-------------+
count | 1 | 2 | 0 | 1 |
+-------------+-------------+-------------+-------------+
@@ -275,7 +373,7 @@
</t>
<figure anchor="figure_ibf_decode_1">
<artwork name="" type="" align="left" alt=""><![CDATA[
- bit-1 bit-2 bit-3 bit-4
+ bucket-0 bucket-1 bucket-2 bucket-3
+-------------+-------------+-------------+-------------+
count | 0 | 1 | 0 | 1 |
+-------------+-------------+-------------+-------------+
@@ -290,7 +388,7 @@
</t>
<figure anchor="figure_ibf_decode_2">
<artwork name="" type="" align="left" alt=""><![CDATA[
- bit-1 bit-2 bit-3 bit-4
+ bucket-0 bucket-1 bucket-2 bucket-3
+-------------+-------------+-------------+-------------+
count | 0 | 0 | 0 | 0 |
+-------------+-------------+-------------+-------------+
@@ -325,7 +423,7 @@
<t>IBF-A containing elements with hash 0101 and 4242:</t>
<figure anchor="figure_ibf_setdiff_A">
<artwork name="" type="" align="left" alt=""><![CDATA[
- bit-1 bit-2 bit-3 bit-4
+ bucket-0 bucket-1 bucket-2 bucket-3
+-------------+-------------+-------------+-------------+
count | 1 | 2 | 0 | 1 |
+-------------+-------------+-------------+-------------+
@@ -336,7 +434,7 @@
<t>IBF-B containing elements with hash 4242 and 5050</t>
<figure anchor="figure_ibf_setdiff_B">
<artwork name="" type="" align="left" alt=""><![CDATA[
- bit-1 bit-2 bit-3 bit-4
+ bucket-0 bucket-1 bucket-2 bucket-3
+-------------+-------------+-------------+-------------+
count | 0 | 1 | 1 | 1 |
+-------------+-------------+-------------+-------------+
@@ -347,7 +445,7 @@
<t>IBF-AB XOR value and subtract count:</t>
<figure anchor="figure_ibf_setdiff_AB">
<artwork name="" type="" align="left" alt=""><![CDATA[
- bit-1 bit-2 bit-3 bit-4
+ bucket-0 bucket-1 bucket-2 bucket-3
+-------------+-------------+-------------+-------------+
count | 1 | 1 | -1 | 0 |
+-------------+-------------+-------------+-------------+
@@ -408,13 +506,13 @@
<t>.
The initiating peer is initially in the <strong>Initiating Connection</strong> state and the receiving peer in the <strong>Expecting Connection</strong>
state. The first step of the protocol for the initiating peer is to send an <em><xref target="messages_operation_request" format="title" /></em> to the receiving peer and
- change into <strong>Expect SE</strong> state. After receiving the <em><xref target="messages_operation_request" format="title" /></em> the receiving peer changes in <strong>Expecting IBF"</strong> state and answers with the
- Strata Estimator (<em><xref target="messages_se" format="title" /></em>) . After the initiating peer has received the Strata Estimator the initiating peer decides
+ change into <strong>Expect SE</strong> state. After receiving the <em><xref target="messages_operation_request" format="title" /></em> the receiving peer changes in <strong>Expecting IBF</strong> state and answers with the
+ Strata Estimator (<em><xref target="messages_se" format="title" /></em>). After the initiating peer has received the Strata Estimator the initiating peer decides
with heuristics which operation mode is best fitted for the the estimated set difference and the environment.
- The detailed tradeoff between the "Full Synchronisation Mode" and the "Individual Element Synchronisation Mode"
- is explained in the section "Combined Mode".
+ The detailed tradeoff between the "Full Synchronisation Mode" and the <xref target="modeofoperation_individual-elements" format="title" />
+ is explained in the section <xref target="modeofoperation_combined-mode" format="title" />.
</t>
- <section anchor="modeofoperation_full-sync-client-with-bigger-set" numbered="true" toc="default">
+ <section anchor="modeofoperation_full-sync" numbered="true" toc="default">
<name>Full Synchronisation Mode</name>
<t>
@@ -426,7 +524,7 @@
<t>
############# Statemaschine diagram full mode ##################
</t>
- <t><strong>STATES:</strong></t>
+ <t><strong>The behavior of the participants the different state is described below:</strong></t>
<dl>
<dt><strong>Expecting IBF:</strong></dt>
<dd>
@@ -443,20 +541,174 @@
<dd>
While a peer is in <strong>Full Receiving</strong> state the peer expects to continuously receiving elements from the other
peer. As soon as a the <em><xref target="messages_full_done" format="title" /></em> message is received the peer sends the remaining elements set to the other
- peer followed by a <em>Full Done</em>. After sending the last message the peer changes into <strong>Finished</strong> state.
+ peer followed by a <em><xref target="messages_full_done" format="title" /></em>. After sending the last message the peer changes into <strong>Finished</strong> state.
</dd>
</dl>
</section>
<section anchor="modeofoperation_individual-elements" numbered="true" toc="default">
<name>Individual Element Synchronisation Mode</name>
- <t>--- TEXT HERE ---</t>
+ <t>
+ In Individual Element Synchronisation Mode and the initiating peer is in <strong>Expected SE</strong> state and receives a
+ <em><xref target="messages_se" format="title" /></em> message or a <em><xref target="messages_sec" format="title" /></em> message. The initiating
+ peer decodes the Strata Estimator and sends the complete <em><xref target="messages_ibf" format="title" /></em> back to the receiving peer
+ and changes into the <strong>Passive Decoding</strong> state.
+ </t>
+ <t>
+ The receiving peer in the <strong>Expecting IBF</strong> state receives a
+ <em><xref target="messages_ibf" format="title" /></em> message from the initiating peer and changes into <strong>Expecting IBF Last</strong> if there
+ are multiple IBFs sent otherwise and there is one <em><xref target="messages_ibf" format="title" /></em> message the reviving peer
+ switches directly to the <strong>Active Decoding</strong> state.
+ </t>
+ <t>
+ The peer that is in the <strong>Active Decoding</strong>, <strong>Finish closing</strong> or in the <strong>Expecting IBF Last</strong> state is called active
+ peer and the peer that is in <strong>Passive Decoding</strong> and <strong>Finish Waiting</strong> state is called the passive peer.
+ </t>
+ <t>
+ ############# Statemaschine Individual Element Synchronisation Mode ##################
+ </t>
+ <t><strong>The behavior of the participants the different state is described below:</strong></t>
+ <dl>
+ <dt><strong>Passive Decoding:</strong></dt>
+ <dd>
+ <t>
+ In the <strong>Passive Decoding</strong> state the passive peer reacts to request from the active peer.
+ The action the passive peer executes depend on the message the passive peer receives in the <strong>Passive Decoding</strong> state from the active peer
+ and is described bellow on message basis.
+ </t>
+
+ <dl>
+ <dt><em><xref target="messages_inquiry" format="title" /></em> Message:</dt>
+ <dd>
+ The <em><xref target="messages_inquiry" format="title" /></em> message
+ is received if the active peer requests the hash of an element that is missing in the active peers set.
+ In this case the passive peer answers with an <em><xref target="messages_offer" format="title" /></em> message
+ which contains a hash of the requested element.
+ </dd>
+ <dt><em><xref target="messages_demand" format="title" /></em> Message:</dt>
+ <dd>
+ The <em><xref target="messages_demand" format="title" /></em> message
+ is received if the active peer requests a complete element that is missing in the active peers set. If the requested element is valid
+ the passive peer answers with the <em><xref target="messages_elements" format="title" /></em> message which contains the requested element.
+ </dd>
+ <dt><em><xref target="messages_offer" format="title" /></em> Message:</dt>
+ <dd>
+ The <em><xref target="messages_offer" format="title" /></em> message
+ is received if the active peer decodes an element that is present in the active peers set and is missing in the
+ set of the passive peer. If the offered element is truly missing in the set of the passive peer, the passive peer answers
+ with a <em><xref target="messages_demand" format="title" /></em> message.
+ </dd>
+ <dt><em><xref target="messages_elements" format="title" /></em> Message:</dt>
+ <dd>
+ A element that is received is saved and validated and not further action is taken.
+ </dd>
+ <dt><em><xref target="messages_ibf" format="title" /></em> Message:</dt>
+ <dd>
+ If an <em><xref target="messages_ibf" format="title" /></em> message is received the passive client assumes that the decoding of the IBF
+ on the active site has failed and role change is initiated. The peer changes directly
+ into the <strong>Active Decoding</strong> state or in <strong>Expecting IBF Last</strong> state
+ depending on how many IBFs are sent.
+ </dd>
+ <dt><em><xref target="messages_done" format="title" /></em> Message:</dt>
+ <dd>
+ Receiving the <em><xref target="messages_done" format="title" /></em> message signals
+ the passive peer that all demand of the active peer have been satisfied. In this case the passive peer changes into
+ <strong>Finish Waiting</strong> state.
+ </dd>
+ </dl>
+ </dd>
+ <dt><strong>Active Decoding:</strong></dt>
+ <dd>
+ <t>
+ In <strong>Active Decoding</strong> state the active peer decodes the IBFs and evaluate the set difference
+ between the active and passive peer. In case the IBF decodes successfully the active peer sends offers and
+ inquiries to the passive client depending on which site the element is missing.
+ </t>
+ <t>
+ If the IBF decodes a positive (1) pure bucket the element is missing on the passive peers site
+ so the active peer sends an <em><xref target="messages_offer" format="title" /></em> to the active peer.
+ A negative (-1) pure bucket indicates that a element is missing in the active peers set so the active peers
+ sends <em><xref target="messages_inquiry" format="title" /></em> to the passive client.
+ </t>
+ <t>
+ In case the IBF does not successfully decode the active peer sends an IBF to the passive client
+ and changes into <strong>Passive Decoding</strong> state. This initiates a role change
+ active->passive.
+ </t>
+ <t>
+ All other actions the active peer executes depend on the message the active peer receives from
+ the passive peer. The actions are described below on message basis:
+ </t>
+ <dl>
+ <dt><em><xref target="messages_offer" format="title" /></em> Message:</dt>
+ <dd>
+ The <em><xref target="messages_offer" format="title" /></em> message indicates that the
+ passive peer received a <em><xref target="messages_inquiry" format="title" /></em> message from
+ the active peer. If a Inquiry has been sent and the offered element is missing in the active peers set,
+ the active peer sends a <em><xref target="messages_demand" format="title" /></em> message to the
+ passive peer.
+ </dd>
+ <dt><em><xref target="messages_demand" format="title" /></em> Message:</dt>
+ <dd>
+ The <em><xref target="messages_demand" format="title" /></em> message indicates that the
+ passive peer received a <em><xref target="messages_offer" format="title" /></em> from
+ the active peer. The active peer satisfies the demand of the passive peer by sending
+ <em><xref target="messages_elements" format="title" /></em> message if a offer request
+ for the element has been sent.
+ </dd>
+ <dt><em><xref target="messages_elements" format="title" /></em> Message:</dt>
+ <dd>
+ A element that is received is saved and validated and not further action is taken.
+ </dd>
+ <dt><em><xref target="messages_done" format="title" /></em> Message:</dt>
+ <dd>
+ Receiving the message <em><xref target="messages_done" format="title" /></em> indicates
+ that all demands of the passive peer have been satisfied. The active peer then changes into the
+ state <strong>Finish Closing</strong> state.
+ </dd>
+ </dl>
+ </dd>
+ <dt><strong>Expecing IBF Last</strong></dt>
+ <dd>
+ <t>
+ In the <strong>Expecing IBF Last</strong> the active peer continuously receives <em><xref target="messages_ibf" format="title" /></em>
+ messages from the passive peer. When the last <em><xref target="messages_ibf" format="title" /></em> message is resived
+ the active peer changes into <strong>Active Decoding</strong> state.
+ </t>
+ </dd>
+ <dt><strong>Finish Closing</strong> / <strong>Finish Waiting</strong></dt>
+ <dd>
+ <t>
+ In this states the peers are waiting for all demands to be satisfied and for the synchronisation
+ to be completed. When all demands are satisfied the peer changes into state <strong>done</strong>.
+ </t>
+ </dd>
+ </dl>
</section>
<section anchor="modeofoperation_combined-mode" numbered="true" toc="default">
<name>Combined Mode</name>
<t>
+ In the Combined Mode the <xref target="modeofoperation_full-sync" format="title" /> and the <xref target="modeofoperation_individual-elements" format="title" />
+ are combined to reach the optimal result.
+ </t>
+ <t>
+ The <xref target="modeofoperation_individual-elements" format="title" /> is only efficient on small set
+ differences or if the byte-size of the elements is large. Is the set difference big for example
+ in the initial synchronisation a <xref target="modeofoperation_full-sync" format="title" /> is
+ more efficient. The exact heuristics and parameter on the basis the protocol evaluates which mode
+ is the optimal is described in the <xref target="performance" format="title" /> section of this document.
+ </t>
+ <t>
+ There are two main conditions when a <xref target="modeofoperation_full-sync" format="title" />
+ is enforced. The first condition is if the flag "FULL_SYNC" is set, this is used for testing purposes only and
+ should not be used in production environment. The second condition applies if one of the peers has an empty
+ set and the set is initially synchronized.
+ </t>
+ <t>
+ ############# NOTE ############
To ensure that ...... the difference is multiplied by 1.5 if there are more than 200 elements differences between the sets (WHY? line 1398).
The Full Synchronisation Mode is used if the flag to force full sync is set, the estimated difference between the two sets is bigger
than 25% or the set size of the receiving peer is zero. Otherwise the Individual Element Synchronisation Mode is used.
+ ############# NOTE END############
</t>
</section>
</section>
@@ -577,7 +829,7 @@
is a 8-bit unsigned integer which signals the order of the IBF. The order of the IBF
is defined as the logarithm of the number of buckets of the IBF.
</dd>
- <dt>PAD1</dt>
+ <dt>PAD1 ### PAD1 und 2 zusammen nehmen</dt>
<dd>
is 8-bit always set to zero
</dd>
@@ -587,7 +839,7 @@
</dd>
<dt>OFFSET</dt>
<dd>
- is a 32-bit unsigned integer which signals the offset of the strata estimator.
+ is a 32-bit unsigned integer which signals the offset of the strata estimator. ### Beser erklähren postion der nachfolgenden ibf slices im orignial
</dd>
<dt>SALT</dt>
<dd>
@@ -622,12 +874,12 @@
<section anchor="messages_elements_description" numbered="true" toc="default">
<name>Description</name>
<t>
- The Element message contains a element that is synced in the <xref target="modeofoperation_individual-elements" format="title" />
+ The Element message contains an element that is synchronized in the <xref target="modeofoperation_individual-elements" format="title" />
and transmits a full element between the peers.
</t>
<t>
This message is sent in the state <strong>Active Decoding</strong> and <strong>Passive Decoding</strong>
- as answer to an <em><xref target="messages_demand" format="title" /></em> message from the remote peer.
+ as answer to a <em><xref target="messages_demand" format="title" /></em> message from the remote peer.
The Element message can also be received in the <strong>Finish Closing</strong> or <strong>Finish Waiting</strong>
state after receiving a <em><xref target="messages_done" format="title" /></em> message from the remote peer, in this
case the client changes to the <strong>Finished</strong> state as soon as all demands for elements have been satisfied.
@@ -652,11 +904,13 @@
<dl>
<dt>MSG SIZE</dt>
<dd>
+ # is 16-bit unsigned integer in network byte order witch describes the message size in bytes and the header is mitgezählt.
is a 16-bit unsigned integer in network byte order (BIG ENDIAN) which describes the the message size.
</dd>
<dt>MSG TYPE</dt>
<dd>
- is a 16-bit unsigned integer in network byte order (BIG ENDIAN) with the value as registered in GANA
+ the value of .... as registerd in [GANA] in network byt order
+ is a 16-bit unsigned integer in network byte order (BIG ENDIAN) with the value as registered in GANA # Symbolischer name von gana hinzufügen
</dd>
<dt>E TYPE</dt>
<dd>
@@ -719,7 +973,7 @@
<dd>
is a 16-bit unsigned integer in network byte order (BIG ENDIAN) with the value as registered in GANA
</dd>
- <dt>GNUNET HASH</dt>
+ <dt>HASH ### Replace GNUENT HASH durch HASH</dt>
<dd>
is a SHA 512-bit hash of the element that is requested with a inquiry message.
</dd>
@@ -947,7 +1201,7 @@
</dd>
<dt>SETSIZE</dt>
<dd>
- is a 64-bit unsigned integer that is defined by the size of the set the SE is
+ is a 64-bit unsigned integer that is defined by the size of the set the SE is #### Mögliche optimierung wäre wäre hier eine 32bit padding einzuführen damit es aligned
</dd>
<dt>SE-SLICES</dt>
<dd>
@@ -1081,6 +1335,13 @@ Type | Name | References | Description
</figure>
</section>
<!-- gana -->
+ <section anchor="contributors" numbered="true" toc="default">
+ <name>Contributors</name>
+ <t>
+ The original GNU NET implementation of the Byzantine Fault Tolerant Set Reconciliation has mainly been
+ written by Florian Dold and Christian Grothoff.
+ </t>
+ </section>
</middle>
<back>
<references>
