[lsd0004] branch master updated: -revise message processing

[gnunet]

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

grothoff pushed a commit to branch master
in repository lsd0004.

The following commit(s) were added to refs/heads/master by this push:
     new 644fc39  -revise message processing
644fc39 is described below

commit 644fc3967068c0ef2c9f23ec8c3e93f73eb618f7
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Fri Mar 11 08:49:39 2022 +0100

    -revise message processing
---
 draft-schanzen-r5n.xml | 95 +++++++++++++++++++++++++-------------------------
 1 file changed, 48 insertions(+), 47 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 5e6dfa8..2215e9a 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -1533,7 +1533,7 @@ bchar = *(ALPHA / DIGIT)
                 <bcp14>MUST</bcp14> be produced (if one is available) using 
the following
                 steps:
               </t>
-              <ol>
+              <ol type="%c)">
                 <li>
                   If <tt>TYPE</tt> indicates a request for a HELLO block,
                   the peer <bcp14>MUST</bcp14> consult the HELLOs it has 
cached for the
@@ -1690,8 +1690,8 @@ bchar = *(ALPHA / DIGIT)
         <section anchor="p2p_result_processing">
           <name>Processing</name>
           <t>
-            Upon receiving a <tt>ResultMessage</tt> from a connected peer.
-            An implementation <bcp14>MUST</bcp14> process it step by step as 
follows:
+            Upon receiving a <tt>ResultMessage</tt> from a connected peer
+            an implementation <bcp14>MUST</bcp14> process it step by step as 
follows:
           </t>
           <ol>
             <li>
@@ -1699,57 +1699,58 @@ bchar = *(ALPHA / DIGIT)
               If the message is expired, it <bcp14>MUST</bcp14> be discarded.
             </li>
             <li>
-              If the MTYPE of the message indicates a HELLO block, it
-              must be validated according to <xref target="hello_block"/>.
-              The payload <bcp14>MUST</bcp14> 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 k-buckets of the routing table.
+              If the BTYPE is supported, then the <tt>BLOCK</tt> 
+              <bcp14>MUST</bcp14> be validated against the 
+             requested BTYPE.  To do this, the peer attempts to compute the
+             key using <tt>DeriveBlockKey</tt>.  If the result is "fail", the 
+             message <bcp14>MUST</bcp14> be discarded.  Note that the result
+             "none" does not count as a failure.  The computed key also
+             does not have to match the <tt>QUERY_HASH</tt> at this time.
             </li>
             <li>
-              If the sender peer of the message is already found in the
+              If the sender of the message is already found in the
               GETPATH, the path <bcp14>MUST</bcp14> be truncated at this 
position.
               The implementation <bcp14>MAY</bcp14> log a warning in such a 
case.
             </li>
             <li>
-              If the <tt>QUERY_HASH</tt> of this <tt>ResultMessage</tt> is 
found in the
-              list of pending local queries and the BTYPE is supported, then
-              the <tt>QUERY_HASH</tt> and <tt>XQUERY</tt>
-              <bcp14>MUST</bcp14> be validated against the requested BTYPE 
using the respective
-              block type implementation of <tt>ValidateBlockReply</tt>.
-              If the approximate flag was not set in the query and the BTYPE 
allows the
-              implementation to compute the key from the block, the computed 
key <bcp14>MUST</bcp14> match
-              the QUERY_HASH. If there is a mismatch, the message 
<bcp14>MUST</bcp14> be discarded.
-            </li>
-            <li>
-              The implementation <bcp14>SHOULD</bcp14> cache RESULT messages
-              if the DemultiplexEverywhere flag was set on the query.
+              If the MTYPE of the message indicates a HELLO block, the
+              peer <bcp14>MUST</bcp14> be considered for the local routing 
+             table if the respective k-bucket is not yet full. In this case,
+             the local peer <bcp14>MUST</bcp14> try to establish a connection 
+             to the peer indicated in the HELLO block using the address 
information
+              from the HELLO block. If a connection is established,
+              the peer is added to the respective k-bucket of the routing 
table.
             </li>
             <li>
-              <t>
-                If requests by other peers for this QUERY_HASH or BTYPE are
-                known,
-                the result block is validated against each request using
-                the respective <tt>ValidateBlockReply</tt> function.  If
-                the BTYPE is not supported, filtering by the result Bloom
-                filter <bcp14>MUST</bcp14> still be performed.
-                <!-- FIXME-CG: check that it can be! Check implementation! -->
-              </t>
-              <t>
-                If the request FLAGS include <tt>FindApproximate</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.
-              </t>
-              <t>
-                If the result message block cannot be verified against the
-                <tt>QUERY_HASH</tt> of the result message or if <tt>BLOCK</tt> 
is
-                malformed, the message <bcp14>MUST</bcp14> be discarded.
-              </t>
-              <t>
-                For each pending request the reply is routed to the requesting
-                peer <tt>P'</tt>. <!--FIXME routed to peer or forwarded to 
peer?-->
+             <t>
+               If the <tt>QUERY_HASH</tt> of this <tt>ResultMessage</tt> is 
found in the
+               list of pending local or remote queries, then
+               for each matching pending query:
               </t>
+             <ol type="%c)">
+               <li>
+                  If the BTYPE is supported, result block <bcp14>MUST</bcp14>
+                 be validated against the specific query using
+                 the respective <tt>ValidateBlockReply</tt> function.  
+                </li>
+               <li>
+                 If the BTYPE is not supported, filtering of exact duplicate 
+                 replies <bcp14>MUST</bcp14> still be performed before 
forwarding
+                 the reply.  Such duplicate filtering <bcp14>MAY</bcp14> be 
implemented
+                 probabilistically, for example using a Bloom filter.
+                </li>
+               <li>
+                 If the approximate flag was not set in the query and the 
BTYPE allowed the
+                 implementation to compute the key from the block, the 
computed key must
+                 exactly match the QUERY_HASH.
+                </li>
+              </ol>
+             <t>
+               If all of the above are satisfied, the result is forwarded to 
the
+                origin of the query. Furthermore, the implementation 
<bcp14>SHOULD</bcp14> 
+               cache RESULT messages if the DemultiplexEverywhere flag was set 
on any
+               of queries that the RESULT provided a new valid answer to.
+               </t>    
             </li>
           </ol>
         </section>
@@ -1839,10 +1840,10 @@ bchar = *(ALPHA / DIGIT)
               The validation <bcp14>MUST</bcp14> include a check of the block 
payload against the
               key under which it is requested to be stored.
             </dd>
-            <dt>DeriveBlockKey(Block) -&gt; Key</dt>
+            <dt>DeriveBlockKey(Block) -&gt; Key | None | Fail</dt>
             <dd>
               is used to synthesize the block key from the block payload
-              and metadata. It is used as part of FIND-peer message processing.
+              and metadata. It is used as part of FIND-peer message 
processing.  
             </dd>
             <dt>FilterResult(Block, XQuery, Key) -&gt; 
ReplyEvaluationResult</dt>
             <dd>

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