commit de76f481524227f6c81af0428d10b6b866085378
parent d42a8a5f8cb64ec103598b981eeafd0533662ff9
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Tue, 27 Dec 2022 22:25:35 +0900
Update use of existing pending table concept.
Diffstat:
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git 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
