[lsd0004] branch master updated: More peer discovery. Lots WIP and unclear

[gnunet]

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

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

The following commit(s) were added to refs/heads/master by this push:
     new 75a3164  More peer discovery. Lots WIP and unclear
75a3164 is described below

commit 75a3164358a2c5b36abd319ddf22fcdeaad864af
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Dec 26 00:01:11 2022 +0900

    More peer discovery. Lots WIP and unclear
---
 draft-schanzen-r5n.xml | 45 +++++++++++++++++++++------------------------
 1 file changed, 21 insertions(+), 24 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index e5b8218..2e1bf76 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -652,12 +652,27 @@ Connectivity | |Underlay|  |Underlay|
            <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
-          <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.
+          In order to facilitate the above,
+          the Underlay is expected to provide the implementation with one or 
more
+          addresses signalled through <tt>ADDRESS_ADDED</tt>. Zero addresses 
<bcp14>MAY</bcp14> be
+          provided if a peer can only establish outgoing connections and is 
otherwise unreachable.
+          <!-- Periodically? sometimes? on change? -->
+          An implementation <bcp14>MUST</bcp14> advertise its addresses by:
+        </t>
+        <!-- FIXME both things here are grossly underdefined for a MUST:
+             Message flags, BF, REPL_LVL etc
+             -->
+        <ul>
+          <li>Initiating <tt>HelloMessage</tt>s to the peers in its routing 
table (<xref target="p2p_hello_wire"/>).</li>
+          <li>Initiating <tt>PutMessage</tt>s containing <tt>HELLO</tt> blocks 
(<xref target="hello_block"/>).</li>
+        </ul>
+        <t>
+          <!-- FIXME This here sais that this is a mandatory functionality. in 
HelloMessage it
+               sais RECOMMENDED
+               FIXME: Expiration time of messages unclear -->
+          The specific frequency of advertisements <bcp14>MAY</bcp14> depend 
on available bandwidth,
+          the set of already connected neighbors,  the workload of the system 
and other factors which are at the discretion of
+          the developer, but <bcp14>SHOULD</bcp14> be a fraction of the 
expiration period.
           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 <tt>HELLO</tt> expires) and serve it in response to
@@ -665,24 +680,6 @@ Connectivity | |Underlay|  |Underlay|
                maybe a <tt>HELLO</tt> GET request?
           -->
           Peer Discovery requests.
-          Details about the format of the
-          <tt>HELLO</tt> message are given in <xref target="p2p_hello_wire"/>.
-        </t>
-        <t>
-          The frequency of advertisement and peer discovery messages
-          <bcp14>MAY</bcp14> be adapted according to network conditions,
-          the set of already connected neighbors,
-          the workload of the system and other factors which are at the 
discretion of
-          the developer.
-        </t>
-        <t>
-          Furthermore, the Underlay <bcp14>SHOULD</bcp14> provide the 
implementation with one or more
-          addresses signalled through <tt>ADDRESS_ADDED</tt>. Zero addresses 
<bcp14>MAY</bcp14> be
-          provided if a peer can only establish outgoing connections and is 
otherwise unreachable.
-          <!-- FIXME: What about HelloMessages? What is the distinction 
between <tt>HELLO</tt> blocks
-               and <tt>HELLO</tt> messages? -->
-          The implementation periodically advertises all
-          active addresses in a <tt>HELLO</tt> block <xref 
target="hello_block"/>.
         </t>
       </section>
       <section anchor="routing_bloomfilter">

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