commit 644fc3967068c0ef2c9f23ec8c3e93f73eb618f7
parent eceaa0466a9fcfe901aecae558562d5fa4a8bc68
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Fri, 11 Mar 2022 08:49:39 +0100
-revise message processing
Diffstat:
1 file changed, 48 insertions(+), 47 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -1533,7 +1533,7 @@ bchar = *(ALPHA / DIGIT)
<bcp14>MUST</bcp14> be produced (if one is available) using the following
steps:
</t>
- <ol>
+ <ol type="%c)">
<li>
If <tt>TYPE</tt> indicates a request for a HELLO block,
the peer <bcp14>MUST</bcp14> consult the HELLOs it has cached for the
@@ -1690,8 +1690,8 @@ bchar = *(ALPHA / DIGIT)
<section anchor="p2p_result_processing">
<name>Processing</name>
<t>
- Upon receiving a <tt>ResultMessage</tt> from a connected peer.
- An implementation <bcp14>MUST</bcp14> process it step by step as follows:
+ Upon receiving a <tt>ResultMessage</tt> from a connected peer
+ an implementation <bcp14>MUST</bcp14> process it step by step as follows:
</t>
<ol>
<li>
@@ -1699,57 +1699,58 @@ bchar = *(ALPHA / DIGIT)
If the message is expired, it <bcp14>MUST</bcp14> be discarded.
</li>
<li>
- If the MTYPE of the message indicates a HELLO block, it
- must be validated according to <xref target="hello_block"/>.
- The payload <bcp14>MUST</bcp14> be considered for the local routing table by
- trying to establish a connection to the peer using the information
- from the HELLO block. If a connection can be established,
- the peer is added to the k-buckets of the routing table.
+ If the BTYPE is supported, then the <tt>BLOCK</tt>
+ <bcp14>MUST</bcp14> be validated against the
+ requested BTYPE. To do this, the peer attempts to compute the
+ key using <tt>DeriveBlockKey</tt>. If the result is "fail", the
+ message <bcp14>MUST</bcp14> be discarded. Note that the result
+ "none" does not count as a failure. The computed key also
+ does not have to match the <tt>QUERY_HASH</tt> at this time.
</li>
<li>
- If the sender peer of the message is already found in the
+ If the sender of the message is already found in the
GETPATH, the path <bcp14>MUST</bcp14> be truncated at this position.
The implementation <bcp14>MAY</bcp14> log a warning in such a case.
</li>
<li>
- If the <tt>QUERY_HASH</tt> of this <tt>ResultMessage</tt> is found in the
- list of pending local queries and the BTYPE is supported, then
- the <tt>QUERY_HASH</tt> and <tt>XQUERY</tt>
- <bcp14>MUST</bcp14> be validated against the requested BTYPE using the respective
- block type implementation of <tt>ValidateBlockReply</tt>.
- If the approximate flag was not set in the query and the BTYPE allows the
- implementation to compute the key from the block, the computed key <bcp14>MUST</bcp14> match
- the QUERY_HASH. If there is a mismatch, the message <bcp14>MUST</bcp14> be discarded.
- </li>
- <li>
- The implementation <bcp14>SHOULD</bcp14> cache RESULT messages
- if the DemultiplexEverywhere flag was set on the query.
+ If the MTYPE of the message indicates a HELLO block, the
+ peer <bcp14>MUST</bcp14> be considered for the local routing
+ table if the respective k-bucket is not yet full. In this case,
+ the local peer <bcp14>MUST</bcp14> try to establish a connection
+ to the peer indicated in the HELLO block using the address information
+ from the HELLO block. If a connection is established,
+ the peer is added to the respective k-bucket of the routing table.
</li>
<li>
- <t>
- If requests by other peers for this QUERY_HASH or BTYPE are
- known,
- the result block is validated against each request using
- the respective <tt>ValidateBlockReply</tt> function. If
- the BTYPE is not supported, filtering by the result Bloom
- filter <bcp14>MUST</bcp14> still be performed.
- <!-- FIXME-CG: check that it can be! Check implementation! -->
- </t>
- <t>
- If the request FLAGS include <tt>FindApproximate</tt> and the result
- message block type is HELLO the block validation must use the
- key derived using <tt>DeriveBlockKey</tt> as the key included in
- the request is only approximate.
- </t>
- <t>
- If the result message block cannot be verified against the
- <tt>QUERY_HASH</tt> of the result message or if <tt>BLOCK</tt> is
- malformed, the message <bcp14>MUST</bcp14> be discarded.
- </t>
- <t>
- For each pending request the reply is routed to the requesting
- peer <tt>P'</tt>. <!--FIXME routed to peer or forwarded to peer?-->
+ <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 BTYPE is supported, result block <bcp14>MUST</bcp14>
+ be validated against the specific query using
+ the respective <tt>ValidateBlockReply</tt> function.
+ </li>
+ <li>
+ If the BTYPE is not supported, filtering of exact duplicate
+ replies <bcp14>MUST</bcp14> still be performed before forwarding
+ the reply. Such duplicate filtering <bcp14>MAY</bcp14> be implemented
+ probabilistically, for example using a Bloom filter.
+ </li>
+ <li>
+ If the approximate flag was not set in the query and the BTYPE allowed the
+ implementation to compute the key from the block, the computed key must
+ exactly match the QUERY_HASH.
+ </li>
+ </ol>
+ <t>
+ If all of the above are satisfied, the result is forwarded to the
+ origin of the query. Furthermore, the implementation <bcp14>SHOULD</bcp14>
+ cache RESULT messages if the DemultiplexEverywhere flag was set on any
+ of queries that the RESULT provided a new valid answer to.
+ </t>
</li>
</ol>
</section>
@@ -1839,10 +1840,10 @@ bchar = *(ALPHA / DIGIT)
The validation <bcp14>MUST</bcp14> include a check of the block payload against the
key under which it is requested to be stored.
</dd>
- <dt>DeriveBlockKey(Block) -> Key</dt>
+ <dt>DeriveBlockKey(Block) -> Key | None | Fail</dt>
<dd>
is used to synthesize the block key from the block payload
- and metadata. It is used as part of FIND-peer message processing.
+ and metadata. It is used as part of FIND-peer message processing.
</dd>
<dt>FilterResult(Block, XQuery, Key) -> ReplyEvaluationResult</dt>
<dd>
