commit bb023bdbb21eed4a1002c26fd7b9b15d30fa63e3
parent 8c8f802fe43690e284655429dfe50161973f7441
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 26 Dec 2022 15:37:48 +0900
Cleanup some fixmes. Identified further unclarities.
Diffstat:
1 file changed, 21 insertions(+), 39 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -1214,23 +1214,10 @@ BEGIN
<section anchor="p2p_hello" numbered="true" toc="default">
<name>HelloMessage</name>
<t>
- <!-- FIXME: While it is discussed here how to hangle HelloMessages
- nowhere in the draft is a HelloMessage created at the
- initiator so it is completely irrelevant atm -->
When the Underlay notifies the implementation of added or removed
addresses through <tt>ADDRESS_ADDED</tt> and <tt>ADDRESS_DELETED</tt>
it <bcp14>MAY</bcp14> disseminate those changes to neighbors using
<tt>HelloMessage</tt>s.
- <!-- FIXME yesyes this is blabla and obvious when reading the processing section.
- In contrast to a <tt>HELLO</tt> block, a
- <tt>HelloMessage</tt> does not contain the ID of
- the peer the address information is about: in a
- <tt>HelloMessage</tt>, the address information is always
- about the sender.
- Since the Underlay is responsible to determine the
- peer ID of the sender for all messages, it would thus be
- redundant to also include the peer ID in the
- <tt>HelloMessage</tt>.-->
<!-- FIXME: Are hello messages should or must?
Only recommended not, if so, what if that is not done?
-->
@@ -1657,7 +1644,7 @@ BEGIN
<dt>PEER_BF</dt>
<dd>
A peer Bloom filter to stop circular routes (see <xref target="routing_bloomfilter"/>).
- Set by the initiator to include itself. <!-- Is that so? -->
+ Set by the initiator to include itself. <!-- FIXME Is that so? -->
Modified by processing peers to include their own peer address.
</dd>
<dt>QUERY_HASH</dt>
@@ -1740,36 +1727,31 @@ BEGIN
steps:
</t>
<ol type="%c)">
- <!-- FIXME: It is not clear that this is a fallthrough statement -->
- <!-- FIXME: Are <tt>HELLO</tt> blocks according to the spec stored in block storage but never looked for? -->
+ <!-- FIXME it seems to me as if some blocks need to be "synthesized", e.g.
+ HELLOs from HelloMessages... this needs to be specified.-->
<li>
- If <tt>BTYPE</tt> indicates a request for a <tt>HELLO</tt> block or
+ If the <tt>BTYPE</tt> does not indicate a request for a <tt>HELLO</tt> block or
<tt>ANY</tt>,
- the peer <bcp14>MUST</bcp14> consult its own <tt>HELLO</tt> as well as
- the HELLOs it has cached for the
- peers in its routing table instead of the local block
- storage (while continuing to respect flags like
- <tt>DemultiplexEverywhere</tt>
- and <tt>FindApproximate</tt>).
+ the implementation <bcp14>MUST</bcp14> only consider blocks in the local block storage.
+ Otherwise, the implementation <bcp14>MUST</bcp14> only consider its own <tt>HELLO</tt> and
+ the <tt>HELLO</tt>s it has cached for the peers in its routing table as blocks.
</li>
<li>
If <tt>FLAGS</tt> indicate a <tt>FindApproximate</tt> request,
- the peer <bcp14>SHOULD</bcp14> try to respond with the closest block it
- has that is not filtered by the
- <tt>RESULT_BF</tt>.
- </li>
- <li>
- Else, the peer <bcp14>MUST</bcp14> respond if it has a valid block
- that matches the key exactly and that is
+ the peer <bcp14>SHOULD</bcp14> try to 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
+ 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>
</ol>
<t>
- Any such resulting block <bcp14>MUST</bcp14> be encapsulated in a
+ The resulting block, if any, <bcp14>MUST</bcp14> be encapsulated in a
<tt>ResultMessage</tt> and <bcp14>SHOULD</bcp14> be transmitted to the
- neighbor from which the request was received. Implementations
- <bcp14>MAY</bcp14> drop messages if they are resource-constrained.
- However, <tt>ResultMessage</tt>s <bcp14>SHOULD</bcp14> be given the
+ neighbor from which the request was received.
+ Implementations <bcp14>MAY</bcp14> drop messages if they are resource-constrained.
+ However, <tt>ResultMessage</tt>s <bcp14>MUST</bcp14> be given the
highest priority among competing transmissions.
</t>
<t>
@@ -1780,7 +1762,7 @@ BEGIN
</t>
</li>
<li>
- Given the value in <tt>REPL_LVL</tt>, the number of peers to forward to
+ Using the value in <tt>REPL_LVL</tt>, the number of peers to forward to
<bcp14>MUST</bcp14> be calculated using
<tt>ComputeOutDegree()</tt>.
If there is at least one
@@ -1789,9 +1771,9 @@ BEGIN
forward to fewer or no peers in order to handle resource constraints
such as bandwidth.
The peer Bloom filter <tt>PEER_BF</tt> <bcp14>MUST</bcp14> be updated with the local
- peer address <tt>SELF</tt>.
- For all peers with peer address <tt>P'</tt> chosen to forward the message
- to, <tt>SEND(P', GetMessage')</tt> is called. Here, <tt>GetMessage'</tt>
+ peer address <tt>SELF</tt> for any forwarded message.
+ For all peers with peer address <tt>P</tt> chosen to forward the message
+ 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>.
</li>
@@ -2448,7 +2430,7 @@ BEGIN
of decreasing proximity.
</dd>
</dl>
- <section>
+ <section anchor="approx_search">
<name>Approximate Search Considerations</name>
<t>
Over time a peer may accumulate a significant number of blocks
