add pending table description

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)
           </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>