[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0003] branch master updated: Refactored 1
|
From: |
gnunet |
|
Subject: |
[lsd0003] branch master updated: Refactored 1 |
|
Date: |
Wed, 13 Jan 2021 19:49:05 +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 cb34904 Refactored 1
cb34904 is described below
commit cb349049b411a5a58635b156a94abab26922eb2f
Author: Elias Summermatter <elias.summermatter@seccom.ch>
AuthorDate: Wed Jan 13 19:48:19 2021 +0100
Refactored 1
---
draft-summermatter-set-union.xml | 327 +++++++++++++++++++++------------------
1 file changed, 174 insertions(+), 153 deletions(-)
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index 9e07080..a12fee4 100644
--- a/draft-summermatter-set-union.xml
+++ b/draft-summermatter-set-union.xml
@@ -79,18 +79,21 @@
<t>
The Protocol should prevent bad acting peers from waisting
resources by sending wrong formed elements, pretending to have a multiple
of elements or request more elements than the size of the full
set. This is achieved by
- remembering how much elements already have been sent and how
many elements are possible by some real world
- limiting factor in E-Voting this for example is the people who
are permitted to vote.
+ saving the count of already sent elements and plausibility
checks on how many elements are possible by some real world
+ limiting factor. In E-Voting this is for example the count of
people who are permitted to vote.
</t>
<t>
- Another probabilistic approach to discover bad behaving peers
is sampling, in this case the proving peer need
- to prove to the verifying peer that he really has the amount
of elements he claims to have. To prove this the verifying peer chooses some
+ Another probabilistic approach to discover bad behaving peers
is sampling, in this approach the proving peer needs
+ to prove that he is in possession of the elements he claimed
to be. This is achieved by the following procedure:
+ </t>
+ <t>
+ The verifying peer chooses some
random salt and sends the salt to the proving peer. The
proving peer salts the hash of elements with the given
salt from the verifying peer. Then the proving peer calculates
the new hashes modulo a number depending on the set sized difference and
- sends all the elements where the modulo calculation equals
0(?) to the verifying peer.
+ sends all the elements where the modulo calculation equals 0
to the verifying peer.
As soon as the verifying peer receives the elements the
verifying peer can verify that all the elements
are valid and the modulo calculation equals 0 then the
verifying peer can be assured with a high probability
- that the peer is honest about his set size.
+ that the peer is honest about his remaining set size and
difference.
</t>
<t>
The Byzantine Fault Tolerant Set Reconciliation can be used in
a variety of different fields of application,
@@ -105,7 +108,9 @@
</t>
<t>
The protocol should minimize network round-trips and bytes
send over the network at the
- expense of CPU operations.
+ expense of CPU operations. The tradeoff between round-trips
and network bytes is specified by
+ the application and depends on field of application and the
environment.
+
The protocol uses some heuristics to determinate if sending
the full set of elements or just sending the elements
that differ in the set is cheaper.
</t>
@@ -123,112 +128,119 @@
</t>
</section>
- <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">
+ <section anchor="background" numbered="true" toc="default">
+ <name>Background</name>
+ <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 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 an 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[
- bucket-0 bucket-1 bucket-2 bucket-3
- +-------------+-------------+-------------+-------------+
- | 0 | 1 | 0 | 1 |
- +-------------+-------------+-------------+-------------+
- ]]></artwork>
+ --------------------------------
+ # M: E->B^k (B=Z/l)
+ --------------------------------
+ # l = Number of bits per element
+ # B = 0,1,2,3,4,...l
+ # k = Number of buckets
+ # E = Element from the set
+ # Z = Natural Numbers Mod l
+ --------------------------------
+ Example: l=256, k=3
+ M(E) = {4,6,255}
+
+ ]]></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>
+ <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>
+ <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 anchor="cbf" numbered="true" toc="default">
+ <name>Counting Bloom Filter</name>
+ <t>
+ A Counting Bloom Filter (CBF) is an extension of the <xref
target="bf" format="title" />. In the CBF the binary filed of the bucket is
replaced by
+ 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>
<section anchor="ibv" numbered="true" toc="default">
<name>Invertible Bloom Filter</name>
<t>
- A Invertible Bloom Filter (IBF) is a further extension of the
CBF. The IBF extends the CBF with two more operations,
+ A Invertible Bloom Filter (IBF) is a further extension of the
<xref target="cbf" format="title" />. The IBF extends the <xref target="cbf"
format="title" /> 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.
@@ -241,10 +253,17 @@
<t>
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.
+ is a tradeoff and has to be adjusted to the CPU
architecture and setsize for optimal performance.
+ </t>
+ <t>
+ If the IBF size is to small or the mapping function does
not spread out the elements uniformly a counter can overflow,
+ in this case the highest and the lowest number the signed
counter can accept means infinite.
+ If a counter of one bucket is set to infinite the IBF can
not be decoded anymore and size of the IBF
+ or the size of the counter has to be adjusted.
+ For a IBF with 4-bit counters this means if the counter of
one bucket is set to 7 or -8 the IBF is invalid.
+ The implementation described in this document the size of
the counter and the HASH Value is 32-bit. This means
+ the counter of this implementation can reach a minimum of
-2147483647 and a maximum of 2147483646, before the
+ counter overflows and the IBF cant be decoded anymore.
</t>
<figure anchor="figure_ibf_format">
<artwork name="" type="" align="left" alt=""><![CDATA[
@@ -263,9 +282,8 @@
<section anchor="ibv_operations_insert" numbered="true"
toc="default">
<name>Insert Element</name>
<t>
- To add an element to a IBF the element is hashed with
different hash functions the output of
- the hash functions is mapped on the two-component data
structure. At the
- bit positions with a one of the hash output the
counter is increased by one and the value
+ To add an element to a IBF the element is mapped as
described in the <xref target="cbf" format="title" /> section on
+ the IBF. Where the map function hits the counter is
increased by one and the value
field is updated with the XOR product of the new hash
and the previously stored value.
</t>
<t>
@@ -309,13 +327,12 @@
<section anchor="ibf_operations_remove" numbered="true"
toc="default">
<name>Remove Element</name>
<t>
- To remove an element from the IBF the element is
hashed with the same hash functions that it was
- hashed to insert and at the bit positions where the
hashes result in a one the counter in the
- two-component data structure is reduced by one and the
resulting hash is XORed with the value field
- and is written to the value field again.
+ To remove an element from the IBF the element is
mapped with the same map functions that was used to previously insert
+ the Element. Then all the bucket that got hit by the
map function are reduced by one and the value field of the buckets is
+ replaced by a new value containing the old value xored
with the hash of the removed Element.
</t>
<t>
- In the following example the insert operation for the
element [1100] with the hash 0101 is demonstrated.
+ In the following example the remove operation for the
element [1100] with the hash 0101 is demonstrated.
</t>
<t>IBF with encoded elements:</t>
<figure anchor="figure_ibf_remove_0">
@@ -343,12 +360,14 @@
<section anchor="ibf_operations_decode" numbered="true"
toc="default">
<name>Decode IBF</name>
<t>
- To decode a IBF there are pure buckets needed, pure
buckets are buckets where which contain only
- one element (counter = 1). If there is no pure element
in the IBF does not decode and there is the
- need to choose a bigger IBF or different hash function
to create the IBF.
+ To decode an IBF there are pure buckets needed, pure
buckets are buckets which contain only
+ one element - the counter is set to 1 or -1. If there
is no pure bucket in the IBF, its not possible
+ to decode the IBF. In this case a new IBF has to be
created, the new IBF needs to be bigger or a different mapping function
+ should be used.
If there are pure buckets its possible to decode the
IBF by removing elements as described
- in the section "Remove Element" from the pure buckets
from the filter creating new pure buckets
- until the IBF is completely empty and all elements
have been decoded.
+ in the section <xref target="ibf_operations_remove"
format="title" /> from the pure buckets from the filter creating new pure
buckets
+ until the IBF is empty and all elements have been
decoded. Its possible the an IBF only partly decodes, in this case a new IBF
has to be
+ created.
</t>
<t>
In the following example the successful decoding of an
IBF containing the two elements previously
@@ -400,9 +419,9 @@
<section anchor="ibv_operations_setdiff" numbered="true"
toc="default">
<name>Set Difference</name>
<t>
- One of the most interesting capability of IBF's is the
possibility to easily calculate the difference
- between two IBF's.
- To calculate the difference between two IBF's its only
necessary to XOR the value of both IBF's bucket by bucket and
+ One of the most interesting capability of IBFs is the
possibility to easily calculate the difference
+ between two IBFs.
+ To calculate the difference between two IBFs its only
necessary to XOR the value of both IBFs bucket by bucket and
subtracting the counts which results in a new IBF with
the same amount of buckets.
This new IBF can be decoded as described in section
<xref target="ibf_operations_decode" format="counter" />.
The new IBF can have two types of pure buckets with
counter set to 1 or -1. If the counter is set to 1
@@ -482,7 +501,7 @@
this until the decoding of the SE fails or Stratum 0 is
reached. Then its possible to estimate
how big the difference between two sets is by adding the
number of extracted hashes up (C) and scale it
by the expected number of elements (E) in the remaining
unencoded IBF's (C*E=[estimated count of objects]).
- If no of the SE decoded choose a smaller stratum or try a
other hash function.
+ If non of the SE decoded choose a smaller stratum or try a
other mapping function.
</t>
</section>
</section>
@@ -503,20 +522,24 @@
############# IMAGE ##################
</t>
- <t>.
+ <t>
+ In the following section the operation mode independent flow
in the beginning is described in detail:
+ </t>
+
+ <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
+ state. The first step for the initiating peer in the protocol
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
- 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 <xref target="modeofoperation_individual-elements" format="title" />
+ <em><xref target="messages_se" format="title" /></em> message.
When the initiating peer receives the Strata Estimator the initiating peer
decides
+ with some heuristics which operation mode is best fitted for
the the estimated set difference and the environment.
+ The detailed tradeoff between the <xref
target="modeofoperation_full-sync" format="title" /> 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" numbered="true"
toc="default">
<name>Full Synchronisation Mode</name>
<t>
- In full synchronisation mode, if the set of the initiating
peer is bigger than the set of the receiving peer, the initiating
+ When the initiating peer decide to use the Full
Synchronisation Mode and the set of the initiating peer is bigger than the set
of the receiving peer, the initiating
peer sends a <em><xref target="messages_request_full"
format="title" /></em> message and change from <strong>Expecting SE</strong> to
the <strong>Full Receiving</strong> State.
In all other cases the initiating peer sends all set
elements to the other peer followed by the <em><xref
target="messages_full_done" format="title" /></em> message and
changes into <strong>Full Sending</strong> state.
@@ -528,9 +551,9 @@
<dl>
<dt><strong>Expecting IBF:</strong></dt>
<dd>
- If a peer in the in state <strong>Expecting
IBF</strong> receives a <em><xref target="messages_request_full" format="title"
/></em> message from the other peer, the
- peer starts sending all the elements of the set
followed by a <em><xref target="messages_full_done" format="title" /></em>
message and change to the
- <strong>Full Sending</strong> State. If the peer
receives an <em><xref target="messages_full_element" format="title" /></em> the
peer changes to the state <strong>Full Receiving</strong>.
+ If a peer in the <strong>Expecting IBF</strong> state
receives a <em><xref target="messages_request_full" format="title" /></em>
message from the other peer, the
+ peer starts sending all the elements of the set
followed by a <em><xref target="messages_full_done" format="title" /></em>
message to the other peer and change to the
+ <strong>Full Sending</strong> State. If the peer
receives an <em><xref target="messages_full_element" format="title" /></em>
message the peer changes to the <strong>Full Receiving</strong> state.
</dd>
<dt><strong>Full Sending:</strong></dt>
<dd>
@@ -540,7 +563,7 @@
<dt><strong>Full Receiving (In code: Expecting IBF):
</strong></dt>
<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. As soon as a the <em><xref
target="messages_full_done" format="title" /></em> message is received the peer
sends the remaining elements from his set to the other
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>
@@ -548,15 +571,13 @@
<section anchor="modeofoperation_individual-elements"
numbered="true" toc="default">
<name>Individual Element Synchronisation Mode</name>
<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.
+ When the initiating peer in <strong>Expected SE</strong>
state decide to use the Individual Element Synchronisation Mode, the peer
+ sends a <em><xref target="messages_ibf" format="title"
/></em> 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
+ The receiving peer in the <strong>Expecting IBF</strong>
state then receives the
+ <em><xref target="messages_ibf" format="title" /></em>
message from the initiating peer and changes into <strong>Expecting IBF
Last</strong> state when there
+ are multiple <em><xref target="messages_ibf"
format="title" /></em> messages to sent, when there is just a single <em><xref
target="messages_ibf" format="title" /></em> message the reviving peer
switches directly to the <strong>Active Decoding</strong>
state.
</t>
<t>
@@ -593,8 +614,8 @@
<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
+ is received if the active peer has decoded 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 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>
@@ -621,7 +642,7 @@
<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.
+ inquiries to the passive peer 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
@@ -670,7 +691,7 @@
<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>
+ In the <strong>Expecing IBF Last</strong> state
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>
@@ -941,9 +962,9 @@
<section anchor="messages_offer_description" numbered="true"
toc="default">
<name>Description</name>
<t>
- The offer message answers an <em><xref
target="messages_inquiry" format="title" /></em> message
+ The offer message is an answer to an <em><xref
target="messages_inquiry" format="title" /></em> message
and transmits the full hash of an element that has
been requested by the other peer.
- This full hash enables the other peer to check if the
element is not in his set and
+ This full hash enables the other peer to check if the
element is really missing in his set and
eventually send a <em><xref target="messages_demand"
format="title" /></em> message for that a element.
</t>
<t>
@@ -1125,11 +1146,11 @@
<section anchor="messages_full_done_description"
numbered="true" toc="default">
<name>Description</name>
<t>
- The full done message sent in the <xref
target="modeofoperation_full-sync" format="title" /> sent
+ The full done message is sent in the <xref
target="modeofoperation_full-sync" format="title" />
to signal that all remaining elements of the set have
been sent. The message is received and sent in in the
<strong>Full Sending</strong> and in the <strong>Full
Receiving</strong> state. When the full done message is received
in <strong>Full Sending</strong> state the peer
changes directly into <strong>Finished</strong> state. In
- <strong>Full Receiving</strong> state receiving a full
done message initiates sending of
+ <strong>Full Receiving</strong> state receiving a full
done message initiates the sending of
the remaining elements that are missing in the set of
the other peer.
</t>
</section>
@@ -1171,7 +1192,7 @@
<strong>Full Receiving</strong> state.
</t>
<t>
- The receiving peer can receive the request full
message in the <strong>Expecting IBF</strong>, afterwards the receiving peer
+ The receiving peer receives the Request Full message
in the <strong>Expecting IBF</strong>, afterwards the receiving peer
starts sending his complete set in <xref
target="messages_full_element" format="title" /> messages to the initiating
peer.
</t>
</section>
@@ -1214,7 +1235,7 @@
</t>
<t>
When the initiating peer receives the strata estimator
the peer decides which <xref target="modeofoperation" format="title" /> to use
- for the synchronization. Depending on the size of set
difference and the <xref target="modeofoperation" format="title" /> the
initiating peer
+ for the synchronization. Depending on the size of the
set difference and the <xref target="modeofoperation" format="title" /> the
initiating peer
changes into <strong>Full Sending</strong>,
<strong>Full Receiving</strong> or <strong>Passive Decoding</strong> state.
</t>
</section>
@@ -1266,7 +1287,7 @@
</t>
<t>
Since the content of the message is the same as the
uncompressed Strata Estimator, the details
- aren't repeated here for more information see section
<xref target="messages_se" format="counter" />.
+ aren't repeated here for details see section <xref
target="messages_se" format="counter" />.
</t>
</section>
</section>
--
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: Refactored 1,
gnunet <=