summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMartin Schanzenbach <schanzen@gnunet.org>2022-12-25 20:28:47 +0900
committerMartin Schanzenbach <schanzen@gnunet.org>2022-12-25 20:28:47 +0900
commit370224b3cbb79d11a570d67337d68fa0f395e8e9 (patch)
tree12af853c576beaae590d8f2e184621e1c652083f
parent23e204ee1d6e8fe113fcee4e417ac6ddcb24a773 (diff)
Various connection changes
-rw-r--r--draft-schanzen-r5n.xml26
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>