[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.