commit c244759655e2b9df21f0088852c9bbf02739a798
parent 52754000569383b24e2e7b4644cbaaf2d24b35d9
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Wed, 29 Dec 2021 16:56:46 +0100
update result processing
Diffstat:
1 file changed, 44 insertions(+), 31 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -595,10 +595,10 @@ END
</section>
<section anchor="p2p_xq" numbered="true" toc="default">
<name>Extended query</name>
- <t>TODO: What is this for? Not documented anywhere</t>
+ <t>TODO: Talk about XQuery in the context of messages.</t>
</section>
<section anchor="p2p_put" numbered="true" toc="default">
- <name>PUT message</name>
+ <name>PutMessage</name>
<section anchor="p2p_put_wire">
<name>Wire Format</name>
<figure anchor="figure_putmsg">
@@ -736,7 +736,7 @@ END
</section>
</section>
<section anchor="p2p_get" numbered="true" toc="default">
- <name>GET Message</name>
+ <name>GetMessage</name>
<section anchor="p2p_get_wire">
<name>Wire Format</name>
<figure anchor="figure_getmsg">
@@ -877,7 +877,7 @@ END
</section>
</section>
<section anchor="p2p_result" numbered="true" toc="default">
- <name>RESULT message</name>
+ <name>ResultMessage</name>
<section anchor="p2p_result_wire">
<name>Wire Format</name>
<figure anchor="figure_resmsg">
@@ -968,48 +968,61 @@ END
<section anchor="p2p_result_processing">
<name>Processing</name>
<t>
- Upon receiving a RESULT message from a connected peer. An implementation
- MUST process it step by step as follows:
+ Upon receiving a <tt>ResultMessage</tt> from a connected peer.
+ An implementation MUST process it step by step as follows:
</t>
<ol>
<li>
- The EXPIRATION field is evaluated. If the message is expired,
- it MUST be discarded.
+ The <tt>EXPIRATION</tt> field is evaluated.
+ If the message is expired, it MUST be discarded.
</li>
<li>
- If the MTYPE of the message indicates a HELLO block, the
- payload MUST be considered for the local routing table.
- FIXME: Considered how?
+ If the MTYPE of the message indicates a HELLO block, it
+ must be validated according to <xref target="hello_block"/>.
+ The payload MUST be considered for the local routing table by
+ trying to establish a connection to the peer using the information
+ from the HELLO block. If a connection can be established,
+ the peer is added to the <tt>KBuckets</tt> routing table.
</li>
<li>
- If the sender peer (FIXME which peer?) is already found in the
- GETPATH, the path MUST be truncated.
+ If the sender peer of the message is already found in the
+ GETPATH, the path MUST be truncated at this position.
+ The implementation MAY log a warning in such a case.
</li>
<li>
- If the KEY of this PUT message is found in the list of pending
- queries, the the KEY and XQUERY is validated against the requested
- BTYPE.
+ If the <tt>KEY</tt> of this <tt>ResultMessage</tt> is found in the
+ list of pending local queries, the <tt>KEY</tt> and <tt>XQUERY</tt>
+ are validated against the requested BTYPE using the respective
+ block type implementation of <tt>ValidateBlockReply</tt>.
If the BTYPE is not supported, or if the block key
does not match the BTYPE or if the XQUERY is malformed,
- the message MUST be discarded. (FIXME: It is not clear the key
- validation is happening. However, block validation is.)
+ the message MUST be discarded.
</li>
<li>
The implementation MAY cache RESULT messages.
</li>
<li>
- If no requests for this KEY or BTYPE are known, result processing
- is completed.
- </li>
- <li>
- If the request is of type "Find Peer" and the message BTYPE is
- of type HELLO the block key is extracted from BLOCK, and if the
- block key does not match KEY or cannot be extracted because
- the BLOCK is malformed, the message MUST be discarded.
- Otherwise, the block is evaluated against the message KEY.
- FIXME: If OK_MORE or OK_LAST the RESULT is routed. One (!) peer is
- selected from the connected peers (!). If none is found the message
- is discarded.
+ <t>
+ If requests by other peers for this KEY or BTYPE are known,
+ the result block is validated against each request using
+ the respective <tt>ValidateBlockReply</tt> function.
+ </t>
+ <t>
+ If the request options include <tt>FindPeer</tt> and the result
+ message block type is HELLO the block validation must use the
+ key derived using <tt>DeriveBlockKey</tt> as the key included in
+ the request is only approximate. (FIXME: So we extract the key
+ to then check it again against the block? This does not make sense...)
+ </t>
+ <t>
+ If the result message block cannot be verified against the
+ <tt>KEY</tt> of the result message or if <tt>BLOCK</tt> is
+ malformed, the message MUST be discarded.
+ </t>
+ <t>
+ For each pending request the reply is sent to the requesting
+ peer.
+ </t>
</li>
</ol>
</section>
@@ -1102,7 +1115,7 @@ END
its own block type called "HELLO". A block with this block type
contains the peer ID of the peer initiating the GET request.
</t>
- <section>
+ <section anchor="hello_block">
<name>HELLO</name>
<t>
The HELLO block type wire format is illustrated in
