summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMartin Schanzenbach <schanzen@gnunet.org>2022-12-25 23:45:40 +0900
committerMartin Schanzenbach <schanzen@gnunet.org>2022-12-25 23:45:40 +0900
commit811fe601faf9753db1dede2b8cf0d66bd0beafba (patch)
tree4ac135e4a4920c30cbdd8679d11cca18004e195f
parent4b01724fec786415ce232a0a8b18dc27b06c1902 (diff)
downloadlsd0004-811fe601faf9753db1dede2b8cf0d66bd0beafba.tar.gz
lsd0004-811fe601faf9753db1dede2b8cf0d66bd0beafba.zip
More connectivity description
-rw-r--r--draft-schanzen-r5n.xml66
1 files changed, 36 insertions, 30 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 9495cbf..33eb456 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -586,28 +586,15 @@ Connectivity | |Underlay| |Underlay|
586 <section anchor="routing_table"> 586 <section anchor="routing_table">
587 <name>Routing Table</name> 587 <name>Routing Table</name>
588 <t> 588 <t>
589 Whenever a <tt>PEER_CONNECTED</tt> signal is received from the Underlay,
590 the respective peer is considered for insertion into the routing table.
589 The routing table consists of an array of k-buckets. Each 591 The routing table consists of an array of k-buckets. Each
590 k-bucket contains a list of neighbors. 592 k-bucket contains a list of neighbors.
591 The i-th k-bucket stores neighbors whose peer IDs are between distance 2^i and 2^(i+1) from the local peer. 593 The i-th k-bucket stores neighbors whose peer IDs are between distance 2^i and 2^(i+1) from the local peer.
592 System constraints will typically force an implementation to impose some 594 System constraints will typically force an implementation to impose some
593 upper limit on the number of neighbors kept per k-bucket. 595 upper limit on the number of neighbors kept per k-bucket.
594 </t> 596 Upon insertion, the implementation <bcp14>MUST</bcp14> call
595 <t> 597 <tt>HOLD</tt> on the respective connection.
596 Initially, the implementation depends upon either the Underlay providing at
597 least one initial connection to a peer (signalled through
598 <tt>PEER_CONNECTED</tt>), or the application/end-user providing at
599 least one working HELLO which is then in turn used to call <tt>TRY_CONNECT</tt>
600 on the Underlay.
601 This is commonly achieved through the configuration of hardcoded bootstrap peers
602 or bootstrap servers either for the Underlay or the R<sup>5</sup>N implementation.
603 While details on how the first connection is established <bcp14>MAY</bcp14>
604 depend on the specific implementation, this <bcp14>SHOULD</bcp14> usually be done
605 by an out-of-band exchange of the information from a HELLO block.
606 <!-- FIXME: Is this really an encoding of a block? It seems to me that "HELLO"
607 is not properly defined.
608 FIXME: Should? Isn't this part of the HelloMessage? -->
609 For this, section <xref target="hello_url"/> specifies a URL format for encoding HELLO
610 blocks as text strings which <bcp14>SHOULD</bcp14> be supported by implementations.
611 </t> 598 </t>
612 <t> 599 <t>
613 Implementations <bcp14>SHOULD</bcp14> try to keep at least 600 Implementations <bcp14>SHOULD</bcp14> try to keep at least
@@ -635,32 +622,51 @@ Connectivity | |Underlay| |Underlay|
635 <section anchor="find_peer"> 622 <section anchor="find_peer">
636 <name>Peer Discovery</name> 623 <name>Peer Discovery</name>
637 <t> 624 <t>
638 To build its routing table, a peer will send out requests 625 Initially, the implementation depends upon either the Underlay providing at
639 asking for blocks of type HELLO using its own location as the key, 626 least one initial connection to a peer (signalled through
640 but filtering all of its neighbors via the Bloom filter described 627 <tt>PEER_CONNECTED</tt>), or the application/end-user providing at
641 in <xref target="result_filter"/>. 628 least one working <tt>HELLO</tt> which is then in turn used to call <tt>TRY_CONNECT</tt>
642 These requests <bcp14>MUST</bcp14> use the FindApproximate and DemultiplexEverywhere 629 on the Underlay in order to trigger a subsequent <tt>PEER_CONNECTED</tt> signal
643 flags. FindApproximate will ensure that other peers will reply 630 from the Underlay.
644 with keys they merely consider close-enough, while DemultiplexEverywhere 631 This is commonly achieved through the configuration of hardcoded bootstrap peers
632 or bootstrap servers either for the Underlay or the R<sup>5</sup>N implementation.
633 While details on how the first connection is established <bcp14>MAY</bcp14>
634 depend on the specific implementation, this <bcp14>SHOULD</bcp14> usually be done
635 by an out-of-band exchange of the information from a <tt>HELLO</tt> block.
636 <!-- FIXME: Is this really an encoding of a block? It seems to me that "HELLO"
637 is not properly defined.
638 FIXME: Should? Isn't this part of the HelloMessage? -->
639 For this, section <xref target="hello_url"/> specifies a URL format for encoding HELLO
640 blocks as text strings which <bcp14>SHOULD</bcp14> be supported by implementations.
641 </t>
642 <t>
643 <!-- FIXME REPL_LVL unclear, RF_SIZE unclear -->
644 To discover peers for its routing table, a peer will initiate <tt>GetMessage</tt> requests
645 <xref target="p2p_get"/> asking for blocks of type <tt>HELLO</tt> using its own peer address as
646 <tt>QUERY_HASH</tt>, filtering all of its neighbors via the Bloom filter described
647 in <xref target="result_filter"/> and <xref target="hello_block"/>.
648 These requests <bcp14>MUST</bcp14> use the <tt>FindApproximate</tt> and <tt>DemultiplexEverywhere</tt>
649 flags. <tt>FindApproximate</tt> will ensure that other peers will reply
650 with keys they merely consider close-enough, while <tt>DemultiplexEverywhere</tt>
645 will cause each peer on the path to respond, which is likely to yield 651 will cause each peer on the path to respond, which is likely to yield
646 HELLOs of peers that are useful somewhere in the routing table. 652 <tt>HELLO</tt> s of peers that are useful somewhere in the routing table.
647 </t> 653 </t>
648 <t> 654 <t>
649 <!-- This here sais that this is a mandatory functionality. in HelloMessage it 655 <!-- This here sais that this is a mandatory functionality. in HelloMessage it
650 sais RECOMMENDED --> 656 sais RECOMMENDED -->
651 To facilitate peer discovery, each peer <bcp14>MUST</bcp14> broadcast its own 657 To facilitate peer discovery, each peer <bcp14>MUST</bcp14> broadcast its own
652 HELLO message to all peers in the routing table periodically. 658 <tt>HELLO</tt> message to all peers in the routing table periodically.
653 The specific frequency <bcp14>MAY</bcp14> depend on available bandwidth 659 The specific frequency <bcp14>MAY</bcp14> depend on available bandwidth
654 but <bcp14>SHOULD</bcp14> be a fraction of the expiration period. 660 but <bcp14>SHOULD</bcp14> be a fraction of the expiration period.
655 Whenever a peer receives such a HELLO message from another peer that is 661 Whenever a peer receives such a <tt>HELLO</tt> message from another peer that is
656 already in the routing table, it must cache it as long as that peer is in its routing table 662 already in the routing table, it must cache it as long as that peer is in its routing table
657 (or until the HELLO expires) and serve it in response to 663 (or until the <tt>HELLO</tt> expires) and serve it in response to
658 <!-- FIXME wat is a Peer Discovery request?? 664 <!-- FIXME wat is a Peer Discovery request??
659 maybe a HELLO GET request? 665 maybe a <tt>HELLO</tt> GET request?
660 --> 666 -->
661 Peer Discovery requests. 667 Peer Discovery requests.
662 Details about the format of the 668 Details about the format of the
663 HELLO message are given in <xref target="p2p_hello_wire"/>. 669 <tt>HELLO</tt> message are given in <xref target="p2p_hello_wire"/>.
664 </t> 670 </t>
665 <t> 671 <t>
666 The frequency of advertisement and peer discovery messages 672 The frequency of advertisement and peer discovery messages