[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0003] branch master updated: more comments
|
From: |
gnunet |
|
Subject: |
[lsd0003] branch master updated: more comments |
|
Date: |
Thu, 14 Jan 2021 14:10:18 +0100 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository lsd0003.
The following commit(s) were added to refs/heads/master by this push:
new d187678 more comments
d187678 is described below
commit d18767809341e4e63fd3f42f6b1d8510e31c6477
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Thu Jan 14 14:09:32 2021 +0100
more comments
---
draft-summermatter-set-union.xml | 236 +++++++++++++++++++++++----------------
1 file changed, 139 insertions(+), 97 deletions(-)
diff --git a/draft-summermatter-set-union.xml b/draft-summermatter-set-union.xml
index b108c79..ca001a2 100644
--- 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>
--
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: more comments,
gnunet <=