[lsd0004] branch master updated: update result processing

[gnunet]

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository lsd0004.

The following commit(s) were added to refs/heads/master by this push:
     new c244759  update result processing
c244759 is described below

commit c244759655e2b9df21f0088852c9bbf02739a798
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Wed Dec 29 16:56:46 2021 +0100

    update result processing
---
 draft-schanzen-r5n.xml | 75 +++++++++++++++++++++++++++++---------------------
 1 file changed, 44 insertions(+), 31 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index f7a953f..822be85 100644
--- 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

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.