[lsd0004] branch master updated: minor updates

[gnunet]

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

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

The following commit(s) were added to refs/heads/master by this push:
     new 2bde896  minor updates
2bde896 is described below

commit 2bde8964191faa51f4a5efc4e34d540b120ea6c7
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Jan 3 16:39:54 2022 +0100

    minor updates
---
 draft-schanzen-r5n.xml | 77 +++++++++++++++++++++++++++-----------------------
 1 file changed, 42 insertions(+), 35 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index b6ca63c..d1039c3 100644
--- 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>

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