[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0003] branch master updated: Initial commit after holidays many chan
|
From: |
gnunet |
|
Subject: |
[lsd0003] branch master updated: Initial commit after holidays many changes and rewrites |
|
Date: |
Wed, 06 Jan 2021 10:53:47 +0100 |
This is an automated email from the git hooks/post-receive script.
elias-summermatter pushed a commit to branch master
in repository lsd0003.
The following commit(s) were added to refs/heads/master by this push:
new 036b23c Initial commit after holidays many changes and rewrites
036b23c is described below
commit 036b23cf20287d2f41856d594617b68efb3af9b8
Author: Elias Summermatter <elias.summermatter@seccom.ch>
AuthorDate: Wed Jan 6 10:52:58 2021 +0100
Initial commit after holidays many changes and rewrites
---
draft-summermatter-set-union.xml | 339 ++++++++++++++++++++++++++++++++++-----
1 file changed, 300 insertions(+), 39 deletions(-)
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index 4ff8855..416308d 100644
--- 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>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0003] branch master updated: Initial commit after holidays many changes and rewrites,
gnunet <=