[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0004] branch master updated (2572074 -> 4b01724)
|
From: |
gnunet |
|
Subject: |
[lsd0004] branch master updated (2572074 -> 4b01724) |
|
Date: |
Sun, 25 Dec 2022 14:09:07 +0100 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a change to branch master
in repository lsd0004.
from 2572074 clarification try_connect on HELLO block result message
new 227017e Introduce a message header component
new 4b01724 More on connectivity management
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
draft-schanzen-r5n.xml | 103 +++++++++++++++++++++++++++++--------------------
1 file changed, 62 insertions(+), 41 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 037adc5..9495cbf 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -563,13 +563,10 @@ Connectivity | |Underlay| |Underlay|
information about its current set of neighbors.
Upon receiving a connection notification from the Underlay through
<tt>PEER_CONNECTED</tt>, information on the new neighbor
- <bcp14>MUST</bcp14> be added.
+ <bcp14>MUST</bcp14> be added to the routing table.
Similarly when a disconnect is indicated by the Underlay through
<tt>PEER_DISCONNECTED</tt> messages for all addresses of the peer it
- <bcp14>MUST</bcp14> be removed.
- The implementation <bcp14>MAY</bcp14> try to re-establish connection
- to the peer by issuing <tt>TRY_CONNECT</tt> requests on the Underlay
- using valid HELLO caches.
+ <bcp14>MUST</bcp14> be removed from the routing table.
</t>
<t>
In order to achieve O(log n) routing performance,
@@ -601,6 +598,8 @@ Connectivity | |Underlay| |Underlay|
<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.
@@ -627,6 +626,11 @@ Connectivity | |Underlay| |Underlay|
largest number of neighbors. The eviction strategy
<bcp14>MUST</bcp14> be
to drop the shortest-lived connections first.
</t>
+ <t>
+ The implementation <bcp14>MAY</bcp14> cache valid HELLOs of
disconnected
+ peers outside of the routing table and sporadically or periodically
try to (re-)establish connection
+ to the peer by issuing <tt>TRY_CONNECT</tt> requests on the Underlay.
+ </t>
</section>
<section anchor="find_peer">
<name>Peer Discovery</name>
@@ -893,7 +897,34 @@ BEGIN
This section describes some data structures and fields shared
by various message types.
</t>
- <section anchor="route_flags">
+ <section anchor="msg_hdr">
+ <name>Header</name>
+ <t>
+ A message header that identifies the message length and type is
shared across
+ all messages used in the R<sup>5</sup>N protocol.
+ </t>
+ <figure anchor="figure_msghdr" title="The common message header.">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+0 8 16 24
++-----+-----+-----+-----+
+| MSIZE | MTYPE |
++-----+-----+-----+-----+
+]]></artwork>
+ </figure>
+ <t>where:</t>
+ <dl>
+ <dt>MSIZE</dt>
+ <dd>
+ denotes the size of this message in network byte order.
+ </dd>
+ <dt>MTYPE</dt>
+ <dd>
+ is the 16-bit message type. Message types are registered in
+ the GANA "GNUnet Message Type" registry <xref
target="gana_message_type"/>.
+ </dd>
+ </dl>
+ </section>
+ <section anchor="route_flags">
<name>Flags</name>
<t>
Flags is a 16-bit vector representing binary options.
@@ -1217,7 +1248,7 @@ BEGIN
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
-| MSIZE | MTYPE | RESERVED | URL_CTR |
+| HEADER | RESERVED | URL_CTR |
+-----+-----+-----+-----+-----+-----+-----+-----+
| SIGNATURE /
/ (64 byte) |
@@ -1230,13 +1261,9 @@ BEGIN
</figure>
<t>where:</t>
<dl>
- <dt>MSIZE</dt>
- <dd>
- denotes the size of this message in network byte order.
- </dd>
- <dt>MTYPE</dt>
+ <dt>HEADER</dt>
<dd>
- is the 16-bit message type. It must be set to
+ the common message header. Its <tt>MTYPE</tt> field must be set
to
the value 157 in network byte order.
</dd>
<dt>RESERVED</dt>
@@ -1292,6 +1319,10 @@ BEGIN
<li>
The HELLO information is cached in the routing table until it
expires,
the peer is removed from the routing table, or the information
is replaced by another message from the peer.
+ <!-- FIXME same problem as for HELLO 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.
</li>
<li>
<!-- We need a statement like this here. Should they? Can they?
What if they are (not)? -->
@@ -1325,7 +1356,7 @@ BEGIN
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
-| MSIZE | MTYPE | BTYPE |
+| HEADER | BTYPE |
+-----+-----+-----+-----+-----+-----+-----+-----+
| FLAGS | HOPCOUNT | REPL_LVL | PATH_LEN |
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1349,15 +1380,9 @@ BEGIN
</figure>
<t>where:</t>
<dl>
- <dt>MSIZE</dt>
- <dd>
- denotes the size of this message in network byte order.
- Set by the initiator.
- Modified by processing peers when message contents such as the
path lengths change.
- </dd>
- <dt>MTYPE</dt>
+ <dt>HEADER</dt>
<dd>
- is the 16-bit message type. It is set by the initiator to
+ is the common message header. Its <tt>MTYPE</tt> field is set by
the initiator to
the value 146 in network byte order. Read-only.
</dd>
<dt>BTYPE</dt>
@@ -1528,6 +1553,15 @@ BEGIN
the local peer <bcp14>MUST</bcp14> try to establish a connection
to the peer indicated in the HELLO block using the address
information
from the HELLO block and the Underlay function
<tt>TRY_CONNECT</tt>.
+ <!-- FIXME: The above behaviour has a catch: If the
implementation only connects to one
+ address from the hello using TRY_CONNECT, the Underlay also
knows only about that connection
+ If that failes and PEER_DISCONNECT is called, this neighbor
is dead.
+ We could say here that the implementation SHOULD instruct
to connect to ALL
+ addresses or risk flaky connections. The choice of address
is also unclear.
+ R5N does not really know what the Underlay supports (maybe
more than provided in
+ own addresses) - Added this for now: -->
+ The implementation <bcp14>MAY</bcp14> instruct the Underlay to
connect to all provided addresses
+ using <tt>TRY_CONNECT</tt> in order to make the underlay aware
of multiple addresses for this connection.
If a connection is established, the signal
<tt>PEER_CONNECTED</tt> will cause
the peer to be added to the respective k-bucket of the routing
table.
Note that the k-bucket <bcp14>MUST</bcp14> be determined by the
@@ -1571,7 +1605,7 @@ BEGIN
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
-| MSIZE | MTYPE | BTYPE |
+| HEADER | BTYPE |
+-----+-----+-----+-----+-----+-----+-----+-----+
| FLAGS | HOPCOUNT | REPL_LVL | RF_SIZE |
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1590,16 +1624,9 @@ BEGIN
</figure>
<t>where:</t>
<dl>
- <dt>MSIZE</dt>
- <dd>
- denotes the size of this message in network byte order.
- Set by the initiator.
- <!-- FIXME: Is this not fixed-length once set by initiator?-->
- Modified by processing peers when message contents change.
- </dd>
- <dt>MTYPE</dt>
+ <dt>HEADER</dt>
<dd>
- is the 16-bit message type. It is set by the initiator to
+ is the common message header. Its <tt>MTYPE</tt> field is set by
the initiator to
the value 147 in network byte order. Read-only.
</dd>
<dt>BTYPE</dt>
@@ -1793,7 +1820,7 @@ BEGIN
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
-| MSIZE | MTYPE | BTYPE |
+| HEADER | BTYPE |
+-----+-----+-----+-----+-----+-----+-----+-----+
| RESERVED | FLAGS | PUTPATH_L | GETPATH_L |
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1819,15 +1846,9 @@ BEGIN
</figure>
<t>where:</t>
<dl>
- <dt>MSIZE</dt>
- <dd>
- denotes the size of this message in network byte order.
- Set by the initiator.
- Updated by processing peers.
- </dd>
- <dt>MTYPE</dt>
+ <dt>HEADER</dt>
<dd>
- is the 16-bit message type. It must be set to
+ is the common message header. Its <tt>MTYPE</tt> field must be
set to
the value 148 in network byte order.
Set by the initiator. Read-only.
</dd>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [lsd0004] branch master updated (2572074 -> 4b01724),
gnunet <=