diff options
author | Christian Grothoff <grothoff@gnunet.org> | 2022-03-13 02:02:59 +0100 |
---|---|---|
committer | Christian Grothoff <grothoff@gnunet.org> | 2022-03-13 02:02:59 +0100 |
commit | 67574d22540f0e3b2615208ad363851bb67a1e92 (patch) | |
tree | cffb14dd655cb3cb87b8793c997d1ea4b8900f2b | |
parent | 017f167d2e72ead2389e533ec452a395a8185dbf (diff) | |
download | lsd0004-67574d22540f0e3b2615208ad363851bb67a1e92.tar.gz lsd0004-67574d22540f0e3b2615208ad363851bb67a1e92.zip |
add pending table description
-rw-r--r-- | draft-schanzen-r5n.xml | 45 |
1 files changed, 45 insertions, 0 deletions
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) | |||
959 | </dd> | 959 | </dd> |
960 | </dl> | 960 | </dl> |
961 | </section> | 961 | </section> |
962 | <section anchor="pending_table"> | ||
963 | <name>Pending Table</name> | ||
964 | <t> | ||
965 | R<sup>5</sup>N performs stateful routing where the messages | ||
966 | only carry the query hash and do not encode the ultimate | ||
967 | source or destination of the request. Routing a request | ||
968 | towards the key is doing hop-by-hop using the routing table and the | ||
969 | query hash. The pending table is used to route responses | ||
970 | back to the originator. In the pending table each peer | ||
971 | primarily associates a query hash with the associated | ||
972 | originator of the request. The pending table <bcp14>MUST</bcp14> | ||
973 | store entries for the last <tt>MAX_RECENT</tt> requests | ||
974 | the peer has encountered. To ensure that the peer does | ||
975 | not run out of memory, information about older requests | ||
976 | is discarded. The value of <tt>MAX_RECENT</tt> <bcp14>MAY</bcp14> be | ||
977 | configurable and <bcp14>SHOULD</bcp14> be at least 128k. | ||
978 | </t> | ||
979 | <t> | ||
980 | For each entry in the pending table, the DHT <bcp14>MUST</bcp14> track | ||
981 | not only the query key and the origin, but also the | ||
982 | extended query, requested block type and flags, and the | ||
983 | result Bloom filter. If the query did not provide | ||
984 | a result Bloom filter, a fresh result Bloom filter | ||
985 | <bcp14>MUST</bcp14> still be created to filter duplicate replies. | ||
986 | </t> | ||
987 | <t> | ||
988 | When a second query from the same origin for the | ||
989 | same query hash is received, the DHT <bcp14>MUST</bcp14> | ||
990 | attempt to merge the new request with the state for | ||
991 | the old request. In particular, this means that if | ||
992 | the result Bloom filters have the same size and | ||
993 | mutator, they <bcp14>MUST</bcp14> be combined. If | ||
994 | the result Bloom fitlers meta data differs, the | ||
995 | existing result Bloom filter <bcp14>MUST</bcp14> be | ||
996 | discarded and replaced with the incoming result | ||
997 | Bloom filter. | ||
998 | <t> | ||
999 | We note that for local applications, a fixed limit on | ||
1000 | the number of concurrent requests may be problematic. | ||
1001 | Hence, it is <bcp14>RECOMMENDED</bcp14> that implementations | ||
1002 | track requests from local applications separately and | ||
1003 | preserve the information until the application explicitly | ||
1004 | stops the request. | ||
1005 | </t> | ||
1006 | </section> | ||
962 | </section> | 1007 | </section> |
963 | <section anchor="p2p_messages" numbered="true" toc="default"> | 1008 | <section anchor="p2p_messages" numbered="true" toc="default"> |
964 | <name>Message Processing</name> | 1009 | <name>Message Processing</name> |