commit 2014704d5c8c5746e3a7e2594aa852253ba90cf4
parent c42ae3ae99341c1708599900a67fa117ec553e54
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 3 Jan 2022 21:04:35 +0100
update
Diffstat:
1 file changed, 30 insertions(+), 15 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -484,20 +484,28 @@ Connectivity | |Underlay| |Underlay|
<section>
<name>Bootstrapping</name>
<t>
- It is assumed that the node is already connected to at least
- one other node.
- First, those initial nodes are sorted into their respective buckets.
+ Initially, the implementation depends upon the Underlay to provide at
+ least one initial connection to a peer signalled through
+ <tt>PEER_CONNECTED</tt>.
+ The initial set of peers is stored in the routing table component
+ <xref target="routing_table"/>.
</t>
<t>
- In order to find the closest nodes in the network to itself, an
- implementation MUST now periodically send HELLO GET queries for its own
- node address.
- Both the "record route" and "find node" message options are set in the
- GET queries in order to learn nodes and network topology from the
- message route and in order to receive approximate replies to the
- query key (the node address).
+ Further, the Underlay must provide the implementation with one or more
+ addresses signalled through <tt>ADDRESS_ADDED</tt>.
+ The implementation then proceeds to periodically advertise all
+ active addresses in a HELLO block <xref target="hello_block"/>.
+ </t>
+ <t>
+ In order to find more close nodes in the network, an
+ implementation MUST now periodically <xref target="find_peer"/> messages.
+ </t>
+ <t>
+ In both cases the frequency of advertisements and peer discovery
+ MAY be adapted according to network conditions, connected peers,
+ workload of the system and other factors which are at the discretion of
+ the developer.
</t>
- <t>FIXME: Periodically -> more specific? No. Frequency may be adapted depending on network conditions, known nodes, busy/idle etc.</t>
<t>
Any implementation encountering a HELLO GET request initially
sends its own node address if it.
@@ -527,6 +535,12 @@ Connectivity | |Underlay| |Underlay|
follows an XOR-based node distance calculation.
</t>
</section>
+ <section anchor="find_peer">
+ <name>Peer Discovery</name>
+ <t>
+ FIXME: Elaborate on FindPeer here
+ </t>
+ </section>
<section anchor="routing_table">
<name>Routing Table</name>
<t>
@@ -1263,10 +1277,11 @@ tor+onionv3://rasdflkjasdfliasduf.onion/
</t>
<figure anchor="figure_btypenums">
<artwork name="" type="" align="left" alt=""><![CDATA[
-Number | Name | Contact | References | Description
--------+--------+---------+------------+-------------------------
+Number| Name | Contact | References | Description
+------+--------+---------+------------+-------------------------
0 ANY N/A [This.I-D] Reserved
-7 HELLO N/A [This.I-D] Type of a block that contains a HELLO for a node
+7 HELLO N/A [This.I-D] Type of a block that contains
+ a HELLO for a node
11 GNS N/A GNS Block for storing record data
]]></artwork>
</figure>
@@ -1277,7 +1292,7 @@ Number | Name | Contact | References | Description
<figure anchor="figure_purposenums">
<artwork name="" type="" align="left" alt=""><![CDATA[
Purpose | Name | References | Description
---------+-----------------+------------+--------------------------
+--------+-----------------+------------+---------------
]]></artwork>
</figure>
</section>
