[lsd0004] branch master updated: add pending table description

[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 67574d2  add pending table description
67574d2 is described below

commit 67574d22540f0e3b2615208ad363851bb67a1e92
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Sun Mar 13 02:02:59 2022 +0100

    add pending table description
---
 draft-schanzen-r5n.xml | 45 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 0c11b50..06e3f13 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -959,6 +959,51 @@ bchar = *(ALPHA / DIGIT)
           </dd>
         </dl>
       </section>
+      <section anchor="pending_table">
+        <name>Pending Table</name>
+       <t>
+         R<sup>5</sup>N performs stateful routing where the messages
+         only carry the query hash and do not encode the ultimate
+         source or destination of the request.  Routing a request
+         towards the key is doing hop-by-hop using the routing table and the
+         query hash.  The pending table is used to route responses
+         back to the originator.  In the pending table each peer
+         primarily associates a query hash with the associated
+         originator of the request.  The pending table <bcp14>MUST</bcp14>
+         store entries for the last <tt>MAX_RECENT</tt> requests
+         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.
+       </t>
+       <t>
+         For each entry in the pending table, the DHT <bcp14>MUST</bcp14> track
+         not only the query key and the origin, but also the
+         extended query, requested block type and flags, and the
+         result Bloom filter.  If the query did not provide
+         a result Bloom filter, a fresh result Bloom filter
+         <bcp14>MUST</bcp14> still be created to filter duplicate replies.
+       </t>
+       <t>
+         When a second query from the same origin for the
+         same query hash is received, the DHT <bcp14>MUST</bcp14>
+         attempt to merge the new request with the state for
+         the old request.  In particular, this means that if
+         the result Bloom filters have the same size and
+         mutator, they <bcp14>MUST</bcp14> be combined.  If
+         the result Bloom fitlers meta data differs, the
+         existing result Bloom filter <bcp14>MUST</bcp14> be
+         discarded and replaced with the incoming result
+         Bloom filter.
+       <t>
+         We note that for local applications, a fixed limit on
+         the number of concurrent requests may be problematic.
+         Hence, it is <bcp14>RECOMMENDED</bcp14> that implementations
+         track requests from local applications separately and
+         preserve the information until the application explicitly
+         stops the request.
+       </t>     
+      </section>
     </section>
     <section anchor="p2p_messages" numbered="true" toc="default">
       <name>Message Processing</name>

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