commit 67574d22540f0e3b2615208ad363851bb67a1e92
parent 017f167d2e72ead2389e533ec452a395a8185dbf
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Sun, 13 Mar 2022 02:02:59 +0100
add pending table description
Diffstat:
1 file changed, 45 insertions(+), 0 deletions(-)
diff --git 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>
