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)
downloadlsd0004-370224b3cbb79d11a570d67337d68fa0f395e8e9.tar.gz
lsd0004-370224b3cbb79d11a570d67337d68fa0f395e8e9.zip
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|
436 API: 436 API:
437 </t> 437 </t>
438 <dl> 438 <dl>
439 <!-- FIXME: Not used anywhere in draft -->
440 <dt> 439 <dt>
441 <tt>TRY_CONNECT(N, A)</tt> 440 <tt>TRY_CONNECT(N, A)</tt>
442 </dt> 441 </dt>
@@ -564,9 +563,13 @@ Connectivity | |Underlay| |Underlay|
564 information about its current set of neighbors. 563 information about its current set of neighbors.
565 Upon receiving a connection notification from the Underlay through 564 Upon receiving a connection notification from the Underlay through
566 <tt>PEER_CONNECTED</tt>, information on the new neighbor 565 <tt>PEER_CONNECTED</tt>, information on the new neighbor
567 <bcp14>MUST</bcp14> be added, and similarly when 566 <bcp14>MUST</bcp14> be added.
568 a disconnect is indicated by the Underlay through 567 Similarly when a disconnect is indicated by the Underlay through
569 <tt>PEER_DISCONNECTED</tt> the peer <bcp14>MUST</bcp14> be removed. 568 <tt>PEER_DISCONNECTED</tt> messages for all addresses of the peer it
569 <bcp14>MUST</bcp14> be removed.
570 The implementation <bcp14>MAY</bcp14> try to re-establish connection
571 to the peer by issuing <tt>TRY_CONNECT</tt> requests on the Underlay
572 using valid HELLO caches.
570 </t> 573 </t>
571 <t> 574 <t>
572 In order to achieve O(log n) routing performance, 575 In order to achieve O(log n) routing performance,
@@ -596,7 +599,8 @@ Connectivity | |Underlay| |Underlay|
596 Initially, the implementation depends upon either the Underlay providing at 599 Initially, the implementation depends upon either the Underlay providing at
597 least one initial connection to a peer (signalled through 600 least one initial connection to a peer (signalled through
598 <tt>PEER_CONNECTED</tt>), or the application/end-user providing at 601 <tt>PEER_CONNECTED</tt>), or the application/end-user providing at
599 least one working HELLO to the DHT for bootstrapping. 602 least one working HELLO which is then in turn used to call <tt>TRY_CONNECT</tt>
603 on the Underlay.
600 While details on how the first connection is established <bcp14>MAY</bcp14> 604 While details on how the first connection is established <bcp14>MAY</bcp14>
601 depend on the specific implementation, this <bcp14>SHOULD</bcp14> usually be done 605 depend on the specific implementation, this <bcp14>SHOULD</bcp14> usually be done
602 by an out-of-band exchange of the information from a HELLO block. 606 by an out-of-band exchange of the information from a HELLO block.
@@ -638,14 +642,20 @@ Connectivity | |Underlay| |Underlay|
638 HELLOs of peers that are useful somewhere in the routing table. 642 HELLOs of peers that are useful somewhere in the routing table.
639 </t> 643 </t>
640 <t> 644 <t>
645 <!-- This here sais that this is a mandatory functionality. in HelloMessage it
646 sais RECOMMENDED -->
641 To facilitate peer discovery, each peer <bcp14>MUST</bcp14> broadcast its own 647 To facilitate peer discovery, each peer <bcp14>MUST</bcp14> broadcast its own
642 HELLO message to all peers in the routing table periodically. 648 HELLO message to all peers in the routing table periodically.
643 The specific frequency <bcp14>MAY</bcp14> depend on available bandwidth 649 The specific frequency <bcp14>MAY</bcp14> depend on available bandwidth
644 but <bcp14>SHOULD</bcp14> be a fraction of the expiration period. 650 but <bcp14>SHOULD</bcp14> be a fraction of the expiration period.
645 Whenever a peer receives such a HELLO message from another peer, 651 Whenever a peer receives such a HELLO message from another peer that is
646 it must cache it as long as that peer is in its routing table 652 already in the routing table, it must cache it as long as that peer is in its routing table
647 (or until the HELLO expires) and serve it in response to 653 (or until the HELLO expires) and serve it in response to
648 Peer Discovery requests. Details about the format of the 654 <!-- FIXME wat is a Peer Discovery request??
655 maybe a HELLO GET request?
656 -->
657 Peer Discovery requests.
658 Details about the format of the
649 HELLO message are given in <xref target="p2p_hello_wire"/>. 659 HELLO message are given in <xref target="p2p_hello_wire"/>.
650 </t> 660 </t>
651 <t> 661 <t>