commit 553fd21c5ca5cc437555580de2281698d348cfe9
parent de76f481524227f6c81af0428d10b6b866085378
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Wed, 28 Dec 2022 12:18:30 +0900
More wording on result message caches and processing.
Diffstat:
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -1682,14 +1682,13 @@ BEGIN
</t>
<ol>
<li>
- The <tt>QUERY_HASH</tt> and <tt>XQUERY</tt> fields are validated
- against the requested <tt>BTYPE</tt> as defined by its respective
- <tt>ValidateBlockQuery</tt> procedure.
- If validation
- function yields <tt>REQUEST_INVALID</tt>, the message <bcp14>MUST</bcp14> be discarded.
+ If the <tt>BTYPE</tt> is supported, the <tt>QUERY_HASH</tt> and <tt>XQUERY</tt> fields are validated
+ as defined by the respective <tt>ValidateBlockQuery</tt> procedure for this type.
+ If the result yields <tt>REQUEST_INVALID</tt>, the message <bcp14>MUST</bcp14> be discarded and
+ processing ends.
If the <tt>BTYPE</tt> is not supported, the message <bcp14>MUST</bcp14>
be forwarded (Skip to step 4).
- If the <tt>BTYPE</tt> is <tt>ANY</tt>, the message is processed
+ If the <tt>BTYPE</tt> is <tt>ANY</tt>, the message is processed further
without validation.
</li>
<li>
@@ -1699,12 +1698,12 @@ BEGIN
</li>
<li>
<t>
- The local peer <bcp14>MUST</bcp14> try to produce a reply in any of the following cases:
+ The local peer <bcp14>SHOULD</bcp14> try to produce a reply in any of the following cases:
(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 a similar <tt>GetRequest</tt> was answered previously
- with a cached result message this request also matches (<xref target="p2p_result_processing"/>).
+ if the local peer is not the closest and a previously
+ cached <tt>ResultMessage</tt> also matches this request (<xref target="p2p_result_processing"/>).
</t>
<t>
The reply is produced (if one is available) using the following
@@ -1712,31 +1711,32 @@ BEGIN
</t>
<ol type="%c)">
<li>
- If the <tt>BTYPE</tt> does not indicate a request for a <tt>HELLO</tt> block or
+ If the <tt>BTYPE</tt> is <tt>HELLO</tt>, the implementation <bcp14>MUST</bcp14> only consider
+ synthesizing its own addresses and the addresses it has cached for the peers in its routing table
+ as <tt>HELLO</tt> block replies.
+ Otherwise, if the <tt>BTYPE</tt> does not indicate a request for a <tt>HELLO</tt> block or
<tt>ANY</tt>,
the implementation <bcp14>MUST</bcp14> only consider blocks in the local block storage
and previously cached <tt>ResultMessage</tt>s.
- Otherwise, the implementation <bcp14>MUST</bcp14> only consider its own addresses and
- the addresses it has cached for the peers in its routing table.
</li>
<li>
- If <tt>FLAGS</tt> indicate a <tt>FindApproximate</tt> request,
- the peer <bcp14>SHOULD</bcp14> try to respond with the closest block (smallest value
+ If the <tt>FLAGS</tt> field includes the flag <tt>FindApproximate</tt>,
+ the peer <bcp14>SHOULD</bcp14> respond with the closest block (smallest value
of <tt>GetDistance(QUERY_HASH, BLOCK_KEY)</tt>) it
can find that is not filtered by the <tt>RESULT_BF</tt>.
- Otherwise, the peer <bcp14>MUST</bcp14> respond if it has a valid block
+ Otherwise, the peer <bcp14>MUST</bcp14> respond with the block
with a <tt>BLOCK_KEY</tt> that matches the <tt>QUERY_HASH</tt> exactly and that is
not filtered by the <tt>RESULT_BF</tt>.
</li>
<li>
- Any resulting (synthesized) block <bcp14>MUST</bcp14> be encapsulated in a
+ Any resulting (synthesized) block is encapsulated in a
<tt>ResultMessage</tt>.
- The cached or created <tt>ResultMessage</tt> <bcp14>SHOULD</bcp14> be transmitted to the
+ The <tt>ResultMessage</tt> <bcp14>SHOULD</bcp14> be transmitted to the
neighbor from which the request was received.
</li>
</ol>
<t>
- Implementations <bcp14>MAY</bcp14> not to reply if they are resource-constrained.
+ Implementations <bcp14>MAY</bcp14> not reply if they are resource-constrained.
However, <tt>ResultMessage</tt>s <bcp14>MUST</bcp14> be given the
highest priority among competing transmissions.
</t>
