commit cb349049b411a5a58635b156a94abab26922eb2f
parent b4ddc907cae414fae25b58a2691eca020942785b
Author: Elias Summermatter <elias.summermatter@seccom.ch>
Date: Wed, 13 Jan 2021 19:48:19 +0100
Refactored 1
Diffstat:
1 file changed, 174 insertions(+), 153 deletions(-)
diff --git 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>
