[lsd0004] branch master updated: add some test

[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 471282c  add some test
471282c is described below

commit 471282c82949765c0e32068ea7e01c5d1f800bde
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Fri Jan 7 21:47:35 2022 +0100

    add some test
---
 draft-schanzen-r5n.xml | 128 ++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 99 insertions(+), 29 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 0c01fa1..ddbda76 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -91,6 +91,21 @@
     <section anchor="introduction" numbered="true" toc="default">
       <name>Introduction</name>
       <t>
+        <!--
+          - Lean. Can be implemented. Not overengineered.
+          - Path tracking (more difficult) -> Not built in
+          - Certificates central server ?
+          - "self-signed certificates can be used in closed networks."
+          - "Security Framework:  A P2P network will often be established 
among a
+      set of peers that do not trust each other.  RELOAD leverages a
+      central enrollment server to provide credentials for each peer,
+      which can then be used to authenticate each operation.  This
+          greatly reduces the possible attack surface." bizarre statement.
+          - For a PUT, reload requires that
+          "Each element is signed by a credential which is authorized to
+      write this Kind at this Resource-ID.  If this check fails, the
+      request MUST be rejected with an Error_Forbidden error."
+        -->
         FIXME: Here we should also cite and discuss RELOAD 
(https://datatracker.ietf.org/doc/html/rfc6940)
         and establish why we need this spec and are not a "Topology plugin"
         in RELOAD. The argumentation revolves around the trust model 
(openness) and
@@ -135,6 +150,42 @@
           when, they appear in all capitals, as shown here.
         </t>
       </section>
+      <section>
+        <name>Structure of This Document</name>
+        <ul>
+          <li>
+            Section X defines...
+          </li>
+        </ul>
+      </section>
+    </section>
+    <section>
+      <name>Terminology</name>
+      <dl>
+        <dt>Node:</dt>
+        <dd>
+          A node is participant in the network and addressable through the
+          network overlay.
+        </dd>
+        <dt>Node Address:</dt>
+        <dd>
+          The <tt>Node Address</tt> is the identifier used on the Overlay
+          to address a node.
+        </dd>
+        <dt>Node ID:</dt>
+        <dd>
+          The <tt>Node ID</tt> is the identity which is used to authenticate
+          a node in the underlay.
+          The <tt>Node Address</tt> is derived from the <tt>Node ID</tt>.
+        </dd>
+        <dt>Neighbour:</dt>
+        <dd>
+          A neighbour is a node which is directly connected to our node.
+        </dd>
+        <dt>Block:</dt>
+        <dd>
+        </dd>
+      </dl>
     </section>
     <section anchor="architecture" numbered="true" toc="default">
       <name>Architecture</name>
@@ -210,29 +261,7 @@ Connectivity | |Underlay|  |Underlay|
       <t>
         Other glossary
       </t>
-      <dl>
-        <dt>Node</dt>
-        <dd>
-          A node is participant in the network and addressable through the
-          network overlay.
-        </dd>
-        <dt>Node Address</dt>
-        <dd>
-          The <tt>Node Address</tt> is the identifier used on the Overlay
-          to address a node.
-        </dd>
-        <dt>Node ID</dt>
-        <dd>
-          The <tt>Node ID</tt> is the identity which is used to authenticate
-          a node in the underlay.
-          The <tt>Node Address</tt> is derived from the <tt>Node ID</tt>.
-        </dd>
-        <dt>Peer</dt>
-        <dd>
-          A peer is a node which is directly connected to our peer.
-        </dd>
-      </dl>
-    </section>
+       </section>
     <section anchor="overlay" numbered="true" toc="default">
       <name>Overlay</name>
       <t>
@@ -240,10 +269,8 @@ Connectivity | |Underlay|  |Underlay|
         <tt>Node Address</tt>.
         The <tt>Node Address</tt> is a SHA-512 hash <xref target="RFC4634"/>
         of the <tt>Node ID</tt>.
-        <!-- FIXME should the node ID be agile? Should the signature then
-        also be agile?-->
-        <!--The node public key is the public key of the corresponding
-        Ed25519<xref target="ed25519" /> node private key.-->
+        The Node ID is the public key of the corresponding
+        Ed25519<xref target="ed25519" /> node private key.
       </t>
       <t>
         Any implementation of this specification MUST expose the two API
@@ -526,8 +553,9 @@ Connectivity | |Underlay|  |Underlay|
           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
+          In order to achieve O(log n) routing performance,
+          the data structure for managing connected nodes and their
+          metadata MUST be implemented using the k-buckets concept of
           <xref target="Kademlia"/>.
           In order to select nodes which are suitable destinations for
           routing messages, R5N uses a hybrid approach:
@@ -546,6 +574,16 @@ Connectivity | |Underlay|  |Underlay|
       </section>
       <section anchor="routing_table">
         <name>Routing Table</name>
+        <t>
+          The routing table consists of an array of lists of connected nodes.
+          The i-th list stores neighbours whose identifiers are between
+          distance 2^i 2^(i+1) from the local node.
+          An implementation MAY choose an upper limit on the length of the
+          lists, but SHOULD try to keep at least 5 entries per bucket.
+          For example, in case of system constraints with respect to active
+          connections, an implementation SHOULD evict nodes in large buckets
+          rather than nodes from shallow ones.
+        </t>
         <t>
           As the message traverses a random path through the network for the
           first N hops, it is essential that routing loops are avoided.
@@ -637,6 +675,9 @@ Connectivity | |Underlay|  |Underlay|
         <t>TODO: Talk about XQuery in the context of messages.</t>
       </section>
       <section anchor="p2p_put" numbered="true" toc="default">
+        <!-- FIXME: Blocks have KEYs. GETs only have
+        QueryHashes the reply refers to the QueryHash, but
+        QueryHash MAY not be Block key -->
         <name>PutMessage</name>
         <section anchor="p2p_put_wire">
           <name>Wire Format</name>
@@ -1254,6 +1295,23 @@ tor+onionv3://rasdflkjasdfliasduf.onion/
       <!-- FIXME: Here we should (again) discuss how the system is open and
         does not have/require a trust anchor a priori. This is (again) in 
contrast
       to RELOAD -->
+      <t>
+        An implementation MAY limit the number the number of neighbours
+        it stores is any k-bucket of the routing table.
+        However, the lower bound MUST be adhered to. <!-- FIXME define 
somewhere-->
+        If there is a limit to the maximum number of neighbours in a
+        k-bucket, the implementation must be careful when choosing the
+        which nodes to replace:
+        For example, a simple optimization of the peer selection algorithm may
+        be to oder all nodes within the k-bucket by distance and evict the
+        nodes which are the farthest away.
+        However, this is not a good idea from a resilience perspective.
+        It is much more important to preserve older connections than closer
+        ones.
+        Preferring long-term connections over close connections makes it more
+        difficult for an attacker to execute a Sibyl attack as more resources
+        need to be invested over time.
+      </t>
     </section>
     <section anchor="gana" numbered="true" toc="default">
       <name>GANA Considerations</name>
@@ -1299,6 +1357,18 @@ Purpose | Name            | References | Description
 ]]></artwork>
       </figure>
     </section>
+    <section>
+      <name>Local Storage</name>
+      <!--
+        - Store(Key, Exp, BType, PUTPATH (combined with old GETPATH), BLOCK)
+         - What to do with duplicates with diff PUTPATH or diff Exps
+          => Use max Exp and corresponding PUTPATH
+          => Else use any
+        - Find(Key, BType) -> List<(Exp,PUTPATH,BLOCK)> #Approximate
+        - Get(Key, BType) -> List<(Exp,PUTPATH,BLOCK)> # Exact
+        - Cache eviction (closest, expiration)
+      -->
+    </section>
     <!-- gana -->
     <section>
       <name>Test Vectors</name>

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