commit d18767809341e4e63fd3f42f6b1d8510e31c6477
parent cab45ba74dc984053f893d8caf5e406f643bed93
Author: Christian Grothoff <christian@grothoff.org>
Date: Thu, 14 Jan 2021 14:09:32 +0100
more comments
Diffstat:
1 file changed, 139 insertions(+), 97 deletions(-)
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
@@ -746,9 +746,9 @@ hashSum | 0000 | 0000 | 0000 | 0000 |
<t>
When the initiating peer decides 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.
+ peer sends a <em><xref target="messages_request_full" format="title" /></em> message, and transitions from <strong>Expecting SE</strong> to the <strong>Full Receiving</strong> state.
+ If the set of the initiating peer is smaller, it sends all set elements to the other peer followed by the <em><xref target="messages_full_done" format="title" /></em> message, and
+ transitions into the <strong>Full Sending</strong> state.
</t>
<t>
############# Statemaschine diagram full mode ##################
@@ -758,87 +758,105 @@ hashSum | 0000 | 0000 | 0000 | 0000 |
<dt><strong>Expecting IBF:</strong></dt>
<dd>
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.
+ peer sends all the elements of its set followed by a <em><xref target="messages_full_done" format="title" /></em> message to the other peer, and transitions to the
+ <strong>Full Sending</strong> state. If the peer receives an <em><xref target="messages_full_element" format="title" /></em> message, it processes the element and transitions to the <strong>Full Receiving</strong> state.
</dd>
<dt><strong>Full Sending:</strong></dt>
<dd>
- While a peer is in <strong>Full Sending</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 changes into <strong>Finished</strong> state.
+ While a peer is in <strong>Full Sending</strong> state the peer expects to continuously receive elements from the other
+ peer. As soon as a the <em><xref target="messages_full_done" format="title" /></em> message is received, the peer transitions into
+ the <strong>Finished</strong> state.
</dd>
<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 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.
+ While a peer is in the <strong>Full Receiving</strong> state, it expects to continuously receive elements from the other
+ peer. As soon as a the <em><xref target="messages_full_done" format="title" /></em> message is received, it sends
+ the remaining elements (those it did not receive) from its set to the other
+ peer, followed by a <em><xref target="messages_full_done" format="title" /></em>.
+ After sending the last message, the peer transitions into the <strong>Finished</strong> state.
</dd>
</dl>
</section>
<section anchor="modeofoperation_individual-elements" numbered="true" toc="default">
<name>Delta Synchronisation Mode</name>
<t>
- When the initiating peer in <strong>Expected SE</strong> state decide to use the delta 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.
+ When the initiating peer in the <strong>Expected SE</strong> state decides to use the delta synchronisation mode, it
+ sends a <em><xref target="messages_ibf" format="title" /></em> to the receiving peer and transitions into the <strong>Passive Decoding</strong> state.
</t>
<t>
- 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.
+ The receiving peer in the <strong>Expecting IBF</strong> state receives the
+ <em><xref target="messages_ibf" format="title" /></em> message from
+ the initiating peer and transitions into the <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
+ transitions 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.
+ 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 the active peer and the peer that is in either the <strong>Passive Decoding</strong> or the <strong>Finish Waiting</strong> state
+ is called the passive peer.
</t>
<t>
############# Statemaschine Delta Synchronisation Mode ##################
</t>
- <t><strong>The behavior of the participants the different state is described below:</strong></t>
+ <t><strong>The behavior of the participants the different states 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.
+ In the <strong>Passive Decoding</strong> state the passive peer reacts to requests from the active peer.
+ The action the passive peer executes depends on the message the passive peer receives in the <strong>Passive Decoding</strong> state from the active peer
+ and is described below on a per message basis.
</t>
<dl>
- <dt><em><xref target="messages_inquiry" format="title" /></em> Message:</dt>
+ <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.
+ is received if the active peer requests the SHA-512 hash of one or more elements (by sending the 64 bit element ID)
+ that are missing from the active peer's set.
+ In this case the passive peer answers with <em><xref target="messages_offer" format="title" /></em> messages
+ which contain the SHA-512 hash of the requested element. If the passive peer does not have an element with
+ a matching element ID, it MUST ignore the inquiry. If multiple elements match the 64 bit element ID, the passive
+ peer MUST send offers for all of the matching elements.
</dd>
- <dt><em><xref target="messages_demand" format="title" /></em> Message:</dt>
+ <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.
+ the passive peer answers with an <em><xref target="messages_elements" format="title" /></em> message which contains the full,
+ application-dependent data of the requested element. If the passive peer receives a demand for a SHA-512 hash for which
+ it has no element, a protocol violation is detected and the protocol MUST be aborted.
+ Implementations MAY strengthen this and forbid demands without previous matching offers.
</dd>
- <dt><em><xref target="messages_offer" format="title" /></em> Message:</dt>
+ <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 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.
+ is received if the active peer has decoded an element that is present in the active peers set and may be missing in the
+ set of the passive peer. If the SHA-512 hash of the offer is indeed not a hash of any of the elements from the set of
+ the passive peer, the passive peer MUST answer with a <em><xref target="messages_demand" format="title" /></em> message
+ for that SHA-512 hash and remember that it issued this demand.
</dd>
- <dt><em><xref target="messages_elements" format="title" /></em> Message:</dt>
+ <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.
+ A element that is received is validated and safed and not further action is taken.
+ FIXME: Eh, don't we need to (1) check that we did in fact DEMAND this element, and (2) strike it
+ from the list of pending demands?
</dd>
- <dt><em><xref target="messages_ibf" format="title" /></em> Message:</dt>
+ <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.
+ If an <em><xref target="messages_ibf" format="title" /></em> message is received, this
+ indicates that decoding of the IBF on the active site has failed and roles should be swapped.
+ The receiving passive peer transitions into the <strong>Active Decoding</strong> state
+ or into the <strong>Expecting IBF Last</strong> state depending on how many IBFs are sent.
+ FIXME: really should use two IBF message types (IBF_DATA, IBF_LAST).
</dd>
- <dt><em><xref target="messages_done" format="title" /></em> Message:</dt>
+ <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
+ the passive peer that all demands of the active peer have been satisfied. Alas, the
+ active peer will continue to process demands from the passive peer.
+ Upon receiving this message, the passive peer transitions into the
<strong>Finish Waiting</strong> state.
</dd>
</dl>
@@ -846,51 +864,63 @@ hashSum | 0000 | 0000 | 0000 | 0000 |
<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 peer depending on which site the element is missing.
+ In the <strong>Active Decoding</strong> state the active peer decodes the IBFs and evaluates the set difference
+ between the active and passive peer. Whenever an element ID is obtained by decoding the IBF, the active peer
+ sends either an offer or an inquiry to the passive peer, depending on which site the decoded 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.
+ If the IBF decodes a positive (1) pure bucket, the element is missing on the passive peers site.
+ Thus the active peer sends an <em><xref target="messages_offer" format="title" /></em> to the passive peer.
+ A negative (-1) pure bucket indicates that a element is missing in the active peers set, so the active peer
+ sends a <em><xref target="messages_inquiry" format="title" /></em> to the passive peer.
</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.
+ In case the IBF does not successfully decode anymore, the active peer sends a new IBF to the passive client
+ and changes into <strong>Passive Decoding</strong> state. This initiates a role swap.
+ FIXME: On what basis is the new IBF constructed? Specifically, which set is used? Do we
+ wait for the completion of pending demands first? How do L/k/M change? Some of this should
+ be detailed here, but the full details likely need a separate section on the algorithms.
</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:
+ All other actions taken by the active peer depend on the message the active peer receives from
+ the passive peer. The actions are described below on a per message basis:
</t>
+ <!-- FIXME: Done message generation not described anywhere! -->
<dl>
- <dt><em><xref target="messages_offer" format="title" /></em> Message:</dt>
+ <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. If a Inquiry has been sent and <!-- FIXME: is this indeed a condition that is checked? -->
+ 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.
+ <!-- FIXME: what happens if the offer is for an element that is not missing? I think then we just ignore it, right? -->
</dd>
- <dt><em><xref target="messages_demand" format="title" /></em> Message:</dt>
+ <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
+ 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.
+ FIXME: Do we really check that we first made an offer? FIXME: what happens if
+ we do not have an element with the respective SHA-512 hash?
+ FIXME: should we check that a demand cannot be sent repeatedly for the same element?
</dd>
- <dt><em><xref target="messages_elements" format="title" /></em> Message:</dt>
+ <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.
+ A element that is received is validated and saved and not further action is taken.
+ FIXME: what if we receive elements we already know? Is that cause for failure?
+ FIXME: Do we not need to remember that our demands were satisfied?
</dd>
- <dt><em><xref target="messages_done" format="title" /></em> Message:</dt>
+ <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.
+ FIXME: We cannot really receive this message before we completed decoding the IBF and send DONE to the passive peer.
+ So that might be an additional constraint to check here!
</dd>
</dl>
</dd>
@@ -898,7 +928,7 @@ hashSum | 0000 | 0000 | 0000 | 0000 |
<dd>
<t>
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
+ messages from the passive peer. When the last <em><xref target="messages_ibf" format="title" /></em> message is received
the active peer changes into <strong>Active Decoding</strong> state.
</t>
</dd>
@@ -907,6 +937,7 @@ hashSum | 0000 | 0000 | 0000 | 0000 |
<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>.
+ FIXME: I thought "done" was a message, and the final state was called "Finished"!??!?
</t>
</dd>
</dl>
@@ -914,21 +945,23 @@ hashSum | 0000 | 0000 | 0000 | 0000 |
<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.
+ In the combined mode the <xref target="modeofoperation_full-sync" format="title" /> and
+ the <xref target="modeofoperation_individual-elements" format="title" />
+ are combined to minimize resource consumption.
</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.
+ differences or if the byte-size of the elements is large. Is the set difference is estimated to be large
+ the <xref target="modeofoperation_full-sync" format="title" /> is
+ more efficient. The exact heuristics and parameters on which the protocol decides which mode
+ should be used are 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.
+ There are two main cases when a <xref target="modeofoperation_full-sync" format="title" />
+ is always used.
+ The first case is when one of the peers announces having an empty set. FIXME: HOW is this announced?
+ The second case is if the application requested full synchronization explicitly.
+ This is useful for testing and should not be used in production.
</t>
<t>
############# NOTE ############
@@ -950,14 +983,16 @@ hashSum | 0000 | 0000 | 0000 | 0000 |
<section anchor="messages_operation_request_description" numbered="true" toc="default">
<name>Description</name>
<t>
- This message is the first message of the protocol and it is sent to signal the receiving peer
+ This message is the first message of the protocol and it is sent to signal to the receiving peer
that the initiating peer wants to initialize a new connection.
</t>
<t>
- This Message is sent in the transition between the <strong>Initiating connection</strong> state and the <strong>Expect SE</strong> state.
+ This message is sent in the transition between the <strong>Initiating Connection</strong> state and the <strong>Expect SE</strong> state.
</t>
<t>
- If a peer receives this message the peer answers with sending a Strata estimator back.
+ If a peer receives this message and is willing to run the protocol, it answers by sending back a Strata estimator message.
+ FIXME: turn 'strata estimator' into a link!
+ Otherwise it simply closes the connection.
</t>
</section>
<section anchor="messages_operation_request_structure" numbered="true" toc="default">
@@ -984,19 +1019,20 @@ hashSum | 0000 | 0000 | 0000 | 0000 |
</dd>
<dt>MSG TYPE</dt>
<dd>
- the type of SETU_P2P_OPERATION_REQUEST as registered in <xref target="gana" format="title" /> in network byte order.
+ the type of SETU_P2P_OPERATION_REQUEST as registered in <xref target="gana" format="title" />, in network byte order.
</dd>
<dt>OPERATION TYPE</dt>
<dd>
- is a 32-bit unsigned integer which describes the type of operation that should be initiated.
+ is a 32-bit unsigned integer which describes the type of operation that should be initiated.
+ FIXME: unclear what this is. What operation types are there? What are the numeric values?
</dd>
<dt>ELEMENT COUNT</dt>
<dd>
- is the count of the elements the requesting party has stored in a 32-bit unsigned integer.
+ is the number of the elements the requesting party has in its set, as a 32-bit unsigned integer in network byte order.
</dd>
<dt>APX</dt>
<dd>
- is SHA 512-bit hash that identifies the application.
+ is a SHA-512 hash that identifies the application.
</dd>
</dl>
</section>
@@ -1072,7 +1108,11 @@ hashSum | 0000 | 0000 | 0000 | 0000 |
<dt>IBF-SLICES</dt>
<dd>
are variable count of slices in an array. A single slice contains out of a 64-bit Key, a
- 32-bit Key Hash and a 32 bit count.
+ 32-bit Key Hash and an 8-bit count.
+ FIXME: this is not sufficiently precise! How are the element IDs (and IDSUMS) computed?
+ How are the HASHes (and HASHSUMS) computed? Which byte order is used? What role does
+ the SALT have in these computations? Definitively needs DETAILED algorithm(s) and
+ test vectors.
</dd>
</dl>
<figure anchor="figure_ibf_slice">
@@ -1108,7 +1148,7 @@ hashSum | 0000 | 0000 | 0000 | 0000 |
case the client changes to the <strong>Finished</strong> state as soon as all demands for elements have been satisfied.
</t>
<t>
- This message is exclusively send in the <xref target="modeofoperation_individual-elements" format="title" />.
+ This message is exclusively sent in the <xref target="modeofoperation_individual-elements" format="title" />.
</t>
</section>
<section anchor="messages_elements_structure" numbered="true" toc="default">
@@ -1170,15 +1210,15 @@ hashSum | 0000 | 0000 | 0000 | 0000 |
<t>
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 really missing in his set and
- eventually send a <em><xref target="messages_demand" format="title" /></em> message for that a element.
+ This full hash enables the other peer to check if the element is really missing in its set and
+ eventually sends a <em><xref target="messages_demand" format="title" /></em> message for that a element.
</t>
<t>
The offer is sent and received only in the <strong>Active Decoding</strong> and in the <strong>Passive Decoding</strong>
state.
</t>
<t>
- This message is exclusively send in the <xref target="modeofoperation_individual-elements" format="title" />.
+ This message is exclusively sent in the <xref target="modeofoperation_individual-elements" format="title" />.
</t>
</section>
<section anchor="messages_offer_structure" numbered="true" toc="default">
@@ -1219,12 +1259,12 @@ hashSum | 0000 | 0000 | 0000 | 0000 |
<section anchor="messages_inquiry_description" numbered="true" toc="default">
<name>Description</name>
<t>
- The Inquiry message is exclusively send by the active peer in <strong>Active Decoding</strong> state
+ The Inquiry message is exclusively sent by the active peer in <strong>Active Decoding</strong> state
to request the full hash of an element that is missing in the active peers set. This is normally answered
by the passive peer with <em><xref target="messages_offer" format="title" /></em> message.
</t>
<t>
- This message is exclusively send in the <xref target="modeofoperation_individual-elements" format="title" />.
+ This message is exclusively sent in the <xref target="modeofoperation_individual-elements" format="title" />.
</t>
<t>
NOTE: HERE IS AN IMPLEMENTATION BUG UNNECESSARY 32-BIT PADDING!
@@ -1269,12 +1309,12 @@ hashSum | 0000 | 0000 | 0000 | 0000 |
<t>
The demand message is sent in the <strong>Active Decoding</strong> and in the <strong>Passive Decoding</strong>
state. It is a answer to a received <em><xref target="messages_offer" format="title" /></em> message
- and its send if the element described in the <em><xref target="messages_offer" format="title" /></em> message
+ and is sent if the element described in the <em><xref target="messages_offer" format="title" /></em> message
is missing in the peers set. In the normal workflow the answer to the demand message is an
<em><xref target="messages_elements" format="title" /></em> message.
</t>
<t>
- This message is exclusively send in the <xref target="modeofoperation_individual-elements" format="title" />.
+ This message is exclusively sent in the <xref target="modeofoperation_individual-elements" format="title" />.
</t>
</section>
<section anchor="messages_demand_structure" numbered="true" toc="default">
@@ -1314,11 +1354,13 @@ hashSum | 0000 | 0000 | 0000 | 0000 |
<section anchor="messages_done_description" numbered="true" toc="default">
<name>Description</name>
<t>
- The done message is send when all <em><xref target="messages_demand" format="title" /></em> messages
+ The done message is sent when all <em><xref target="messages_demand" format="title" /></em> messages
have been successfully satisfied and the set is complete synchronized.
+ FIXME: we might want to consider adding an additional final checksum (XOR SHA-512 hash) over
+ all elements to this message, to ensure that really both sides ended up with the same set?
</t>
<t>
- This message is exclusively send in the <xref target="modeofoperation_individual-elements" format="title" />.
+ This message is exclusively sent in the <xref target="modeofoperation_individual-elements" format="title" />.
</t>
</section>
<section anchor="messages_done_structure" numbered="true" toc="default">
@@ -1399,7 +1441,7 @@ hashSum | 0000 | 0000 | 0000 | 0000 |
</t>
<t>
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.
+ starts sending its complete set in <xref target="messages_full_element" format="title" /> messages to the initiating peer.
</t>
</section>
<section anchor="messages_request_full_structure" numbered="true" toc="default">
@@ -1572,6 +1614,13 @@ hashSum | 0000 | 0000 | 0000 | 0000 |
</section>
+ <section anchor="performance" numbered="true" toc="default">
+ <name>Performance Considerations</name>
+ <t>
+ --- TEXT HERE ---
+ </t>
+ </section>
+
<section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
<section anchor="security_crypto" numbered="true" toc="default">
@@ -1595,13 +1644,6 @@ hashSum | 0000 | 0000 | 0000 | 0000 |
</section>
</section>
- <section anchor="performance" numbered="true" toc="default">
- <name>Performance</name>
- <t>
- --- TEXT HERE ---
- </t>
- </section>
-
<section anchor="gana" numbered="true" toc="default">
<name>GANA Considerations</name>
<t>
