Update use of existing pending table concept.

1 files changed, 27 insertions, 20 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 200f28d..54212c4 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -829,7 +829,7 @@ BEGIN
           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.
+          configurable and <bcp14>SHOULD</bcp14> be at least 128 * 10<sup>3</sup>.
         </t>
         <t>
           For each entry in the pending table, the DHT <bcp14>MUST</bcp14> track
@@ -1703,8 +1703,8 @@ BEGIN
                 (1) If the local peer is the closest peer
                 (cf. <tt>IsClosestPeer (SELF, QueryHash, PeerFilter)</tt>, or (2)
                 if the <tt>DemultiplexEverywhere</tt> flag is set, or (3)
-                if the local peer is not the closest and the <tt>GetRequest</tt> was answered previously
-              resulting in a cached reply (<xref target="p2p_result_processing"/>). 
+                if the local peer is not the closest and a similar <tt>GetRequest</tt> was answered previously
+                with a cached result message this request also matches (<xref target="p2p_result_processing"/>). 
               </t>
               <t>
                 The reply is produced (if one is available) using the following
@@ -1748,6 +1748,13 @@ BEGIN
               </t>
             </li>
             <li>
+              <!-- FIXME: For how long? what exactly must be stored? -->
+              The implementation <tt>SHOULD</tt> create (or merge) an entry in the pending table
+              <xref target="pending_table"/> for the query represented by this <tt>GetMessage</tt>.
+              If the peer is unable to handle an additional entry in the table, the message
+              <bcp14>MUST</bcp14> be discarded and processing ends.
+            </li>
+            <li>
               Using the value in <tt>REPL_LVL</tt>, the number of peers to forward to
               <bcp14>MUST</bcp14> be calculated using
               <tt>ComputeOutDegree()</tt>.
@@ -1762,9 +1769,6 @@ BEGIN
               to, <tt>SEND(P, GetMessageP)</tt> is called.  Here, <tt>GetMessageP</tt>
               is the original message with the updated fields for <tt>HOPCOUNT</tt> (incremented
               by 1), <tt>PEER_BF</tt> and <tt>RESULT_FILTER</tt>.
-              <!-- FIXME: For how long? what exactly must be stored? -->
-              The implementation <tt>MUST</tt> cache the originator peer address and the
-              <tt>GetMessage</tt> in order to correctly process any <tt>ResultMessage</tt>s.
             </li>
           </ol>
         </section>
@@ -1971,13 +1975,14 @@ BEGIN
               The implementation <bcp14>MUST</bcp14> instruct the Underlay to connect to all provided addresses
               using <tt>TRY_CONNECT</tt> in order to make the underlay aware of multiple addresses for this connection.
               When a connection is established, the signal <tt>PEER_CONNECTED</tt> will cause
-              the peer to be added to the respective k-bucket of the routing table (<xref target="routing"/>).            </li>
+              the peer to be added to the respective k-bucket of the routing table (<xref target="routing"/>).
+            </li>
+            <li>
+              If the <tt>QUERY_HASH</tt> of this <tt>ResultMessage</tt> does not match an entry in the
+              pending table (<xref target="pending_table"/>), then the message is discarded and processing ends.
+              Otherwise, processing continues for each entry in the table as follows.
+            </li>
             <li>
-              <t>
-                If the <tt>QUERY_HASH</tt> of this <tt>ResultMessage</tt> is found in the
-                list of pending local or remote queries, then
-                for each matching pending query:
-              </t>
               <ol type="%c)">
                 <li>
                   If the <tt>FindApproximate</tt> flag was not set in the query and the <tt>BTYPE</tt> allowed the
@@ -2011,15 +2016,17 @@ BEGIN
                   the <tt>GETPATH_L</tt> and <tt>PUTPATH_L</tt>
                   <bcp14>MUST</bcp14> be set to zero when forwarding the result.
                 </li>
+                <li>
+                  If the result filter result is either <tt>FILTER_MORE</tt> or <tt>FILTER_LAST</tt>,
+                  the message is forwarded to the origin of the query as defined in the entry
+                  which may either be the local peer or a remote peer.
+                  In case this is a query of the local peer the result may have to be provided to
+                  applications through the overlay API.
+                  Otherwise, the result is forwarded using <tt>SEND(P, ResultMessage')</tt> where
+                  <tt>ResultMessage'</tt> is the now modified message.
+                  If the result was <tt>FILTER_LAST</tt>, the query is removed from the pending table.
+                </li>
               </ol>
-              <t>
-                If the result is either <tt>FILTER_MORE</tt> or <tt>FILTER_LAST</tt>,
-                the message is forwarded to the origin of the query through
-                either the overlay API or using <tt>SEND(P, ResultMessage')</tt> where
-                <tt>ResultMessage'</tt> is the now modified message.
-                If the result was <tt>FILTER_LAST</tt>, the query is removed from the list of pending
-                queries.
-              </t>
             </li>
             <li>
               Finally, the implementation <bcp14>SHOULD</bcp14> cache