diff options
Diffstat (limited to 'draft-schanzen-r5n.xml')
| -rw-r--r-- | draft-schanzen-r5n.xml | 45 |
1 files changed, 21 insertions, 24 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml index e5b8218..2e1bf76 100644 --- 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"> |