[lsd0004] 01/02: More connectivity description

[gnunet]

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository lsd0004.

commit 811fe601faf9753db1dede2b8cf0d66bd0beafba
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Sun Dec 25 23:45:40 2022 +0900

    More connectivity description
---
 draft-schanzen-r5n.xml | 66 +++++++++++++++++++++++++++-----------------------
 1 file 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|
       <section anchor="routing_table">
         <name>Routing Table</name>
         <t>
+          Whenever a <tt>PEER_CONNECTED</tt> signal is received from the 
Underlay,
+          the respective peer is considered for insertion into the routing 
table.
           The routing table consists of an array of k-buckets. Each
           k-bucket contains a list of neighbors.
           The i-th k-bucket stores neighbors whose peer IDs are between 
distance 2^i and 2^(i+1) from the local peer.
           System constraints will typically force an implementation to impose 
some
           upper limit on the number of neighbors kept per k-bucket.
-        </t>
-        <t>
-          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 which is then in turn used to call 
<tt>TRY_CONNECT</tt>
-          on the Underlay.
-          This is commonly achieved through the configuration of hardcoded 
bootstrap peers
-          or bootstrap servers either for the Underlay or the R<sup>5</sup>N 
implementation.
-          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.
-          <!-- FIXME: Is this really an encoding of a block? It seems to me 
that "HELLO"
-               is not properly defined.
-               FIXME: Should? Isn't this part of the HelloMessage? -->
-          For this, section <xref target="hello_url"/> specifies a URL format 
for encoding HELLO
-          blocks as text strings which <bcp14>SHOULD</bcp14> be supported by 
implementations.
+          Upon insertion, the implementation <bcp14>MUST</bcp14> call
+          <tt>HOLD</tt> on the respective connection.
         </t>
         <t>
           Implementations <bcp14>SHOULD</bcp14> try to keep at least
@@ -635,32 +622,51 @@ Connectivity | |Underlay|  |Underlay|
       <section anchor="find_peer">
         <name>Peer Discovery</name>
         <t>
-          To build its routing table, a peer will send out requests
-          asking for blocks of type HELLO using its own location as the key,
-          but filtering all of its neighbors via the Bloom filter described
-          in <xref target="result_filter"/>.
-          These requests <bcp14>MUST</bcp14> use the FindApproximate and 
DemultiplexEverywhere
-          flags. FindApproximate will ensure that other peers will reply
-          with keys they merely consider close-enough, while 
DemultiplexEverywhere
+          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 <tt>HELLO</tt> which is then in turn used to call 
<tt>TRY_CONNECT</tt>
+          on the Underlay in order to trigger a subsequent 
<tt>PEER_CONNECTED</tt> signal
+          from the Underlay.
+          This is commonly achieved through the configuration of hardcoded 
bootstrap peers
+          or bootstrap servers either for the Underlay or the R<sup>5</sup>N 
implementation.
+          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 <tt>HELLO</tt> 
block.
+          <!-- FIXME: Is this really an encoding of a block? It seems to me 
that "HELLO"
+               is not properly defined.
+               FIXME: Should? Isn't this part of the HelloMessage? -->
+          For this, section <xref target="hello_url"/> specifies a URL format 
for encoding HELLO
+          blocks as text strings which <bcp14>SHOULD</bcp14> be supported by 
implementations.
+        </t>
+        <t>
+          <!-- FIXME REPL_LVL unclear, RF_SIZE unclear -->
+          To discover peers for its routing table, a peer will initiate 
<tt>GetMessage</tt> requests
+          <xref target="p2p_get"/> asking for blocks of type  <tt>HELLO</tt>  
using its own peer address as
+          <tt>QUERY_HASH</tt>, filtering all of its neighbors via the Bloom 
filter described
+          in <xref target="result_filter"/> and <xref target="hello_block"/>.
+          These requests <bcp14>MUST</bcp14> use the <tt>FindApproximate</tt> 
and <tt>DemultiplexEverywhere</tt>
+          flags. <tt>FindApproximate</tt> will ensure that other peers will 
reply
+          with keys they merely consider close-enough, while 
<tt>DemultiplexEverywhere</tt>
           will cause each peer on the path to respond, which is likely to yield
-          HELLOs of peers that are useful somewhere in the routing table.
+           <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
-          HELLO message to all peers in the routing table periodically.
+          <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.
-          Whenever a peer receives such a HELLO message from another peer that 
is
+          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 HELLO expires) and serve it in response to
+          (or until the <tt>HELLO</tt> expires) and serve it in response to
           <!-- FIXME wat is a Peer Discovery request??
-               maybe a HELLO GET request?
+               maybe a <tt>HELLO</tt> GET request?
           -->
           Peer Discovery requests.
           Details about the format of the
-          HELLO message are given in <xref target="p2p_hello_wire"/>.
+          <tt>HELLO</tt> message are given in <xref target="p2p_hello_wire"/>.
         </t>
         <t>
           The frequency of advertisement and peer discovery messages

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.