commit 75a3164358a2c5b36abd319ddf22fcdeaad864af
parent e0b7c4a66155163ef8005ea1bd9d5db594390ec9
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 26 Dec 2022 00:01:11 +0900
More peer discovery. Lots WIP and unclear
Diffstat:
1 file changed, 21 insertions(+), 24 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -652,12 +652,27 @@ Connectivity | |Underlay| |Underlay|
<tt>HELLO</tt> s of peers that are useful somewhere in the routing table.
</t>
<t>
- <!-- This here sais that this is a mandatory functionality. in HelloMessage it
- sais RECOMMENDED -->
- To facilitate peer discovery, each peer <bcp14>MUST</bcp14> broadcast its own
- <tt>HELLO</tt> message to all peers in the routing table periodically.
- The specific frequency <bcp14>MAY</bcp14> depend on available bandwidth
- but <bcp14>SHOULD</bcp14> be a fraction of the expiration period.
+ In order to facilitate the above,
+ the Underlay is expected to provide the implementation with one or more
+ addresses signalled through <tt>ADDRESS_ADDED</tt>. Zero addresses <bcp14>MAY</bcp14> be
+ provided if a peer can only establish outgoing connections and is otherwise unreachable.
+ <!-- Periodically? sometimes? on change? -->
+ An implementation <bcp14>MUST</bcp14> advertise its addresses by:
+ </t>
+ <!-- FIXME both things here are grossly underdefined for a MUST:
+ Message flags, BF, REPL_LVL etc
+ -->
+ <ul>
+ <li>Initiating <tt>HelloMessage</tt>s to the peers in its routing table (<xref target="p2p_hello_wire"/>).</li>
+ <li>Initiating <tt>PutMessage</tt>s containing <tt>HELLO</tt> blocks (<xref target="hello_block"/>).</li>
+ </ul>
+ <t>
+ <!-- FIXME This here sais that this is a mandatory functionality. in HelloMessage it
+ sais RECOMMENDED
+ FIXME: Expiration time of messages unclear -->
+ The specific frequency of advertisements <bcp14>MAY</bcp14> depend on available bandwidth,
+ the set of already connected neighbors, the workload of the system and other factors which are at the discretion of
+ the developer, but <bcp14>SHOULD</bcp14> be a fraction of the expiration period.
Whenever a peer receives such a <tt>HELLO</tt> message from another peer that is
already in the routing table, it must cache it as long as that peer is in its routing table
(or until the <tt>HELLO</tt> expires) and serve it in response to
@@ -665,24 +680,6 @@ Connectivity | |Underlay| |Underlay|
maybe a <tt>HELLO</tt> GET request?
-->
Peer Discovery requests.
- Details about the format of the
- <tt>HELLO</tt> message are given in <xref target="p2p_hello_wire"/>.
- </t>
- <t>
- The frequency of advertisement and peer discovery messages
- <bcp14>MAY</bcp14> be adapted according to network conditions,
- the set of already connected neighbors,
- the workload of the system and other factors which are at the discretion of
- the developer.
- </t>
- <t>
- Furthermore, the Underlay <bcp14>SHOULD</bcp14> provide the implementation with one or more
- addresses signalled through <tt>ADDRESS_ADDED</tt>. Zero addresses <bcp14>MAY</bcp14> be
- provided if a peer can only establish outgoing connections and is otherwise unreachable.
- <!-- FIXME: What about HelloMessages? What is the distinction between <tt>HELLO</tt> blocks
- and <tt>HELLO</tt> messages? -->
- The implementation periodically advertises all
- active addresses in a <tt>HELLO</tt> block <xref target="hello_block"/>.
</t>
</section>
<section anchor="routing_bloomfilter">
