commit 2bde8964191faa51f4a5efc4e34d540b120ea6c7
parent a231f2087141c0729dc66d3eb3c1267e13c12eac
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 3 Jan 2022 16:39:54 +0100
minor updates
Diffstat:
1 file changed, 42 insertions(+), 35 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -409,6 +409,8 @@ see how we can offer even the most minimal protections against node
<dd>
A function which allows a node to attempt the establishment of
a connection to another node using an address.
+ When the connection attempt is successful, information on the new
+ peer is offered through the <tt>NODE_CONNECTED</tt> signal.
</dd>
<dt>HOLD(NodeID)</dt>
<dd>
@@ -457,29 +459,18 @@ see how we can offer even the most minimal protections against node
<section anchor="routing" numbered="true" toc="default">
<name>Routing</name>
- <section>
- <name>Distance Metric</name>
- <t>
- The distance between two keys <tt>KeyA</tt> and <tt>KeyB</tt> is
- calculated relative to their shared prefix.
- The prefix length is determined by the number of low order bits
- that succesively match between <tt>KeyA</tt> and <tt>KeyB</tt>
- starting from the first bit.
- </t>
+ <section anchor="peer_storage">
+ <name>Peer Storage</name>
<t>
- Relative to the (identical) bits in the shared prefix, differences
- in the lower bits must count stronger than higher bits.
- The resulting distance value is a FIXME: I think we wanted to
- move to a 512-bit distance value. And I think we may have decided
- to use a "regular" xor.
- </t>
- </section>
-
-
- <section anchor="routing_table">
- <name>Routing Table</name>
- <t>
- A R5N implementation must store the information on connected nodes.
+ A R5N implementation must store the information on connected nodes
+ and update changes accordingly in a local persistance component such
+ as a database.
+ Upon receiving a connection notification from the Underlay through
+ <tt>NODE_CONNECTED</tt>, information on the new peer is added to the
+ local peer storage.
+ When disconnect is indicated by the Underlay through
+ <tt>NODE_DISCONNECTED</tt> the peer MUST be removed from the local
+ peer storage.
The data structure for managing connected nodes and their
metadata may be implemented using the k-buckets concept of
<xref target="Kademlia"/>.
@@ -489,6 +480,9 @@ see how we can offer even the most minimal protections against node
first N hops is random. After the initial N hops, node selection
follows an XOR-based node distance calculation.
</t>
+ </section>
+ <section anchor="routing_table">
+ <name>Routing Table</name>
<t>
As the message traverses a random path through the network for the
first N hops, it is essential that routing loops are avoided.
@@ -543,6 +537,14 @@ see how we can offer even the most minimal protections against node
</section>
<section anchor="p2p_messages" numbered="true" toc="default">
<name>Message Processing</name>
+ <t>
+ The implementation MUST listen for <tt>RECEIVE(P, M)</tt> signals
+ from the Underlay and respond to the respective messages sent by
+ the peer <tt>P</tt>.
+ In the following, the wire formats of the messages and the required
+ processing are detailed.
+ The local node ID is referred to as <tt>N</tt>.
+ </t>
<section anchor="p2p_bf" numbered="true" toc="default">
<name>Bloomfilter</name>
<t>
@@ -679,7 +681,7 @@ END
<section anchor="p2p_put_processing">
<name>Processing</name>
<t>
- Upon receiving a <tt>PutMessage</tt> from a connected node.
+ Upon receiving a <tt>PutMessage</tt> from a peer <tt>P</tt>.
An implementation MUST process it step by step as follows:
</t>
<ol>
@@ -701,7 +703,7 @@ END
it MUST be discarded.
</li>
<li>
- The sender node ID SHOULD be in <tt>BLOOMFILTER</tt>.
+ The node ID of the sender peer <tt>P</tt> SHOULD be in <tt>BLOOMFILTER</tt>.
If not, the implementation MAY log an error, but MUST continue.
</li>
<li>
@@ -711,19 +713,21 @@ END
</li>
<li>
If the local node is the closest node
- (cf. <tt>IsClosestNode</tt>) or the <tt>DemultiplexEverywhere</tt>
+ (cf. <tt>IsClosestNode(N, Key)</tt>) or the <tt>DemultiplexEverywhere</tt>
options flag ist set, the message MUST
be stored locally in the block storage.
</li>
<li>
- Given the value in <tt>REPL_LVL</tt>, the number of nodes to
+ Given the value in <tt>REPL_LVL</tt>, the number of peers to
forward to MUST be calculated. If there is at least one
- node to forward to, the implementation SHOULD select up to this
- number of nodes to forward the message to. The implementation MAY
- forward to fewer or no nodes in order to handle resource constraints
+ peers to forward to, the implementation SHOULD select up to this
+ number of peers to forward the message to. The implementation MAY
+ forward to fewer or no peers in order to handle resource constraints
such as bandwidth.
Finally, the local node ID MUST be added to the
<tt>BLOOMFILTER</tt> of the forwarded message.
+ For all peers with node ID <tt>P</tt> chosen to forward the message
+ to, <tt>SEND(P, PutMessage)</tt> is called.
</li>
</ol>
</section>
@@ -828,13 +832,14 @@ END
the message MUST be discarded.
</li>
<li>
- The sender node ID SHOULD be in the BLOOMFILTER. If not, the
+ The node ID of the sender peer <tt>P</tt> SHOULD be in the
+ BLOOMFILTER. If not, the
implementation MAY log an error, but MUST continue.
</li>
<li>
<t>
If the local node is the closest node
- (cf. <tt>IsClosestNode</tt>) or the
+ (cf. <tt>IsClosestNode (N, Key)</tt>) or the
<tt>DemultiplexEverywhere</tt> options flag is set, a reply
MUST be produced:
</t>
@@ -866,7 +871,9 @@ END
number of nodes to forward the message to. The implementation MAY
forward to fewer or no nodes in order to handle resource constraints
such as bandwidth.
- The message BLOOMFILTER MUST be updated with the local node ID.
+ The message BLOOMFILTER MUST be updated with the local node ID <tt>N</tt>.
+ For all peers with node ID <tt>P'</tt> chosen to forward the message
+ to, <tt>SEND(P', PutMessage)</tt> is called.
</li>
</ol>
</section>
@@ -1003,7 +1010,7 @@ END
the respective <tt>ValidateBlockReply</tt> function.
</t>
<t>
- If the request options include <tt>Findnode</tt> and the result
+ If the request options include <tt>FindNode</tt> and the result
message block type is HELLO the block validation must use the
key derived using <tt>DeriveBlockKey</tt> as the key included in
the request is only approximate. (FIXME: So we extract the key
@@ -1015,8 +1022,8 @@ END
malformed, the message MUST be discarded.
</t>
<t>
- For each pending request the reply is sent to the requesting
- node.
+ For each pending request the reply is routed to the requesting
+ node <tt>N'</tt>. FIXME routed to node or forwarded to peer?
</t>
</li>
</ol>
