[lsd0004] 02/02: Update use of existing pending table concept.

[gnunet]

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

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

commit de76f481524227f6c81af0428d10b6b866085378
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Tue Dec 27 22:25:35 2022 +0900

    Update use of existing pending table concept.
---
 draft-schanzen-r5n.xml | 47 +++++++++++++++++++++++++++--------------------
 1 file changed, 27 insertions(+), 20 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 200f28d..54212c4 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -829,7 +829,7 @@ BEGIN
          the peer has encountered.  To ensure that the peer does
          not run out of memory, information about older requests
          is discarded.  The value of <tt>MAX_RECENT</tt> <bcp14>MAY</bcp14> be
-         configurable and <bcp14>SHOULD</bcp14> be at least 128k.
+         configurable and <bcp14>SHOULD</bcp14> be at least 128 * 
10<sup>3</sup>.
        </t>
        <t>
          For each entry in the pending table, the DHT <bcp14>MUST</bcp14> track
@@ -1703,8 +1703,8 @@ BEGIN
                 (1) If the local peer is the closest peer
                 (cf. <tt>IsClosestPeer (SELF, QueryHash, PeerFilter)</tt>, or 
(2)
                 if the <tt>DemultiplexEverywhere</tt> flag is set, or (3)
-                if the local peer is not the closest and the 
<tt>GetRequest</tt> was answered previously
-              resulting in a cached reply (<xref 
target="p2p_result_processing"/>). 
+                if the local peer is not the closest and a similar 
<tt>GetRequest</tt> was answered previously
+                with a cached result message this request also matches (<xref 
target="p2p_result_processing"/>). 
               </t>
               <t>
                 The reply is produced (if one is available) using the following
@@ -1747,6 +1747,13 @@ BEGIN
               the request to other peers.
               </t>
             </li>
+            <li>
+              <!-- FIXME: For how long? what exactly must be stored? -->
+              The implementation <tt>SHOULD</tt> create (or merge) an entry in 
the pending table
+              <xref target="pending_table"/> for the query represented by this 
<tt>GetMessage</tt>.
+              If the peer is unable to handle an additional entry in the 
table, the message
+              <bcp14>MUST</bcp14> be discarded and processing ends.
+            </li>
             <li>
               Using the value in <tt>REPL_LVL</tt>, the number of peers to 
forward to
               <bcp14>MUST</bcp14> be calculated using
@@ -1762,9 +1769,6 @@ BEGIN
               to, <tt>SEND(P, GetMessageP)</tt> is called.  Here, 
<tt>GetMessageP</tt>
              is the original message with the updated fields for 
<tt>HOPCOUNT</tt> (incremented
               by 1), <tt>PEER_BF</tt> and <tt>RESULT_FILTER</tt>.
-              <!-- FIXME: For how long? what exactly must be stored? -->
-              The implementation <tt>MUST</tt> cache the originator peer 
address and the
-              <tt>GetMessage</tt> in order to correctly process any 
<tt>ResultMessage</tt>s.
             </li>
           </ol>
         </section>
@@ -1971,13 +1975,14 @@ BEGIN
               The implementation <bcp14>MUST</bcp14> instruct the Underlay to 
connect to all provided addresses
               using <tt>TRY_CONNECT</tt> in order to make the underlay aware 
of multiple addresses for this connection.
               When a connection is established, the signal 
<tt>PEER_CONNECTED</tt> will cause
-              the peer to be added to the respective k-bucket of the routing 
table (<xref target="routing"/>).            </li>
+              the peer to be added to the respective k-bucket of the routing 
table (<xref target="routing"/>).
+            </li>
+            <li>
+              If the <tt>QUERY_HASH</tt> of this <tt>ResultMessage</tt> does 
not match an entry in the
+              pending table (<xref target="pending_table"/>), then the message 
is discarded and processing ends.
+              Otherwise, processing continues for each entry in the table as 
follows.
+            </li>
             <li>
-             <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 <tt>FindApproximate</tt> flag was not set in the query 
and the <tt>BTYPE</tt> allowed the
@@ -2011,15 +2016,17 @@ BEGIN
                   the <tt>GETPATH_L</tt> and <tt>PUTPATH_L</tt>
                  <bcp14>MUST</bcp14> be set to zero when forwarding the result.
                 </li>
+                <li>
+                 If the result filter result is either <tt>FILTER_MORE</tt> or 
<tt>FILTER_LAST</tt>,
+                 the message is forwarded to the origin of the query as 
defined in the entry
+                  which may either be the local peer or a remote peer.
+                  In case this is a query of the local peer the result may 
have to be provided to
+                  applications through the overlay API.
+                  Otherwise, the result is forwarded using <tt>SEND(P, 
ResultMessage')</tt> where
+                  <tt>ResultMessage'</tt> is the now modified message.
+                  If the result was <tt>FILTER_LAST</tt>, the query is removed 
from the pending table.
+               </li>
               </ol>
-             <t>
-               If the result is either <tt>FILTER_MORE</tt> or 
<tt>FILTER_LAST</tt>,
-               the message is forwarded to the origin of the query through
-                either the overlay API or using <tt>SEND(P, 
ResultMessage')</tt> where
-                <tt>ResultMessage'</tt> is the now modified message.
-                If the result was <tt>FILTER_LAST</tt>, the query is removed 
from the list of pending
-               queries.
-             </t>
             </li>
            <li>
              Finally, the implementation <bcp14>SHOULD</bcp14> cache

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