[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0004] branch master updated: add pending table description
From: |
gnunet |
Subject: |
[lsd0004] branch master updated: add pending table description |
Date: |
Sun, 13 Mar 2022 02:03:07 +0100 |
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0004] branch master updated: add pending table description,
gnunet <=