diff options
Diffstat (limited to 'draft-schanzen-r5n.xml')
| -rw-r--r-- | draft-schanzen-r5n.xml | 26 |
1 files changed, 18 insertions, 8 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml index fe62993..e5f72b2 100644 --- a/draft-schanzen-r5n.xml +++ b/draft-schanzen-r5n.xml @@ -436,7 +436,6 @@ Connectivity | |Underlay| |Underlay| API: </t> <dl> - <!-- FIXME: Not used anywhere in draft --> <dt> <tt>TRY_CONNECT(N, A)</tt> </dt> @@ -564,9 +563,13 @@ Connectivity | |Underlay| |Underlay| information about its current set of neighbors. Upon receiving a connection notification from the Underlay through <tt>PEER_CONNECTED</tt>, information on the new neighbor - <bcp14>MUST</bcp14> be added, and similarly when - a disconnect is indicated by the Underlay through - <tt>PEER_DISCONNECTED</tt> the peer <bcp14>MUST</bcp14> be removed. + <bcp14>MUST</bcp14> be added. + Similarly when a disconnect is indicated by the Underlay through + <tt>PEER_DISCONNECTED</tt> messages for all addresses of the peer it + <bcp14>MUST</bcp14> be removed. + The implementation <bcp14>MAY</bcp14> try to re-establish connection + to the peer by issuing <tt>TRY_CONNECT</tt> requests on the Underlay + using valid HELLO caches. </t> <t> In order to achieve O(log n) routing performance, @@ -596,7 +599,8 @@ Connectivity | |Underlay| |Underlay| Initially, the implementation depends upon either the Underlay providing at least one initial connection to a peer (signalled through <tt>PEER_CONNECTED</tt>), or the application/end-user providing at - least one working HELLO to the DHT for bootstrapping. + least one working HELLO which is then in turn used to call <tt>TRY_CONNECT</tt> + on the Underlay. While details on how the first connection is established <bcp14>MAY</bcp14> depend on the specific implementation, this <bcp14>SHOULD</bcp14> usually be done by an out-of-band exchange of the information from a HELLO block. @@ -638,14 +642,20 @@ Connectivity | |Underlay| |Underlay| HELLOs 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 HELLO 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. - Whenever a peer receives such a HELLO message from another peer, - it must cache it as long as that peer is in its routing table + Whenever a peer receives such a HELLO 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 HELLO expires) and serve it in response to - Peer Discovery requests. Details about the format of the + <!-- FIXME wat is a Peer Discovery request?? + maybe a HELLO GET request? + --> + Peer Discovery requests. + Details about the format of the HELLO message are given in <xref target="p2p_hello_wire"/>. </t> <t> |