commit ea6c8d90329ee2cbd609de9f815baabb9f2ea2a5
parent e53fb37978755338e2a79ca7dd69d1cd215481aa
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Wed, 29 Dec 2021 12:19:20 +0100
update processing
Diffstat:
1 file changed, 26 insertions(+), 21 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -653,8 +653,8 @@ END
<section anchor="p2p_put_processing">
<name>Processing</name>
<t>
- Upon receiving a PUT message from a connected peer. An implementation
- MUST process it step by step as follows:
+ Upon receiving a <tt>PutMessage</tt> from a connected peer.
+ An implementation MUST process it step by step as follows:
</t>
<ol>
<li>
@@ -667,23 +667,23 @@ END
Else, the block MUST be validated as defined in (3).
</li>
<li>
- The block key is extracted from BLOCK. If the block key
- does not match KEY or cannot be extracted because the BLOCK
- is malformed, the message MUST be discarded.
- The block is evaluated. TODO FIXME: In the code, we do not really
- do this. We should review.
+ The block payload of the message is evaluated using according
+ to the BTYPE using the respective <tt>ValidateBlockStoreRequest</tt>
+ procedure.
+ If the block payload is invalid or does not match the key,
+ it MUST be discarded.
</li>
<li>
The sender peer ID SHOULD be in the BLOOMFILTER. If not, the
implementation MAY log an error, but MUST continue.
</li>
<li>
- If the "Record Route" flag is set in OPTIONS, add the local peer ID
- to PUTPATH. FIXME: Should should come way later (?)
+ If the <tt>RecordRoute</tt> flag is set in OPTIONS, the local peer ID
+ MUST be appended to the <tt>PUTPATH</tt> of the message.
</li>
<li>
- If the local peer is the closest peer (AM-CLOSEST-PEER) or the
- "Demultiplex Everywhere" options flag ist set, the message MUST
+ If the local peer is the closest peer (<tt>AM-CLOSEST-PEER</tt> is true) or the
+ <tt>DemultiplexEverywhere</tt> options flag ist set, the message MUST
be stored locally in the block storage.
</li>
<li>
@@ -786,14 +786,16 @@ END
<section anchor="p2p_get_processing">
<name>Processing</name>
<t>
- Upon receiving a GET message from a connected peer. An implementation
- MUST process it step by step as follows:
+ Upon receiving a <tt>GetMmessage</tt> from a connected peer an
+ implementation MUST process it step by step as follows:
</t>
<ol>
<li>
- The KEY and XQUERY is validated against the requested BTYPE.
- If the BTYPE is not supported, or if the block key
- does not match the BTYPE or if the XQUERY is malformed,
+ The <tt>KEY</tt> and <tt>XQUERY</tt> is validated against the
+ requested <tt>BTYPE</tt> as defined by its respective
+ <tt>ValidateBlockQuery</tt> procedure.
+ If the <tt>BTYPE</tt> is not supported, or if the block key
+ does not match or if the <tt>XQUERY</tt> is malformed,
the message MUST be discarded.
</li>
<li>
@@ -803,14 +805,14 @@ END
<li>
<t>
If the local peer is the closest peer (AM-CLOSEST-PEER) or the
- "Demultiplex Everywhere" options flag is set, a reply MUST be
- produced:
+ <tt>DemultiplexEverywhere</tt> options flag is set, a reply
+ MUST be produced:
</t>
<ol>
<li>
- If OPTIONS indicate a "Find Peer" request, FIXME the peer selection
+ If OPTIONS indicate a <tt>FindPeer</tt> request, FIXME the peer selection
foo from buckets that probably needs fixing. Take into account
- REPLY_BF
+ <tt>REPLY_BF</tt>
</li>
<li>
Else, if there is a BLOCK in the local Block Storage which is
@@ -820,7 +822,10 @@ END
</ol>
</li>
<li>
- FIXME: We only handle if not GNUNET_BLOCK_EVALUATION_OK_LAST??
+ FIXME: We only handle if not GNUNET_BLOCK_EVALUATION_OK_LAST.
+ This means that we must evaluate the Reply produced in the
+ previous step using <tt>ValidateBlockReply</tt> for this
+ <tt>BTYPE</tt>
</li>
<li>
Given the value in REPL_LVL, the number of peers to forward to
