gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lsd0004] 01/02: HelloMessage processing the connection establishment cl


From: gnunet
Subject: [lsd0004] 01/02: HelloMessage processing the connection establishment clarification.
Date: Mon, 26 Dec 2022 03:01:26 +0100

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

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

commit 3a2ed928c57940dd07a4cf6aae59d54af9b59fc8
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Dec 26 11:00:08 2022 +0900

    HelloMessage processing the connection establishment clarification.
---
 draft-schanzen-r5n.xml | 21 +++++++++------------
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 2e1bf76..0024d8e 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -1307,7 +1307,11 @@ BEGIN
         <section anchor="p2p_hello_processing">
           <name>Processing</name>
           <t>
-            Upon receiving a <tt>HelloMessage</tt> from a peer <tt>P</tt>
+            If the initiator of a <tt>HelloMessage</tt> is <tt>SELF</tt>, the 
message
+            is simply sent to all neighbors <tt>P</tt> currently in the 
routing table
+            using <tt>SEND</tt>.
+          <t>
+            Otherwise, upon receiving a <tt>HelloMessage</tt> from a peer 
<tt>P</tt>
             an implementation <bcp14>MUST</bcp14> process it step by step as 
follows:
           </t>
           <ol>
@@ -1325,21 +1329,14 @@ BEGIN
               <!-- FIXME same problem as for <tt>HELLO</tt> blocks: We do not 
need to TRY_CONNECT here because we already have
                    a connection, obviously. But we may want to TRY_CONNECT on 
the new addresses? Adding for now -->
               The implementation <bcp14>MAY</bcp14> instruct the Underlay to 
connect to all now available addresses
-              using <tt>TRY_CONNECT</tt> in order to make the underlay aware 
of alternative addresses for this connection.
+              using <tt>TRY_CONNECT</tt> in order to make the underlay aware 
of alternative addresses for this connection and
+              to maintain optimal connectivity.
             </li>
             <li>
-              <!-- We need a statement like this here. Should they? Can they? 
What if they are (not)? -->
-              <tt>HelloMessages</tt> <bcp14>SHOULD NOT</bcp14> be forwarded.
+              <!-- FIXME: We need a statement like this here. Should they? Can 
they? What if they are (not)? -->
+              Received <tt>HelloMessages</tt> <bcp14>MUST NOT</bcp14> be 
forwarded.
             </li>
           </ol>
-         <t>
-            <!-- FIXME: How? What function of the underlay? The underlay also 
already knows so...
-                 what is the point? -->
-           The address information about P should then also be made
-           available to each respective Underlays to enable the
-           Underlay to maintain optimal connectivity to the
-           neighbor.
-         </t>
         </section>
       </section>
       <section anchor="p2p_put" numbered="true" toc="default">

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]