[lsd0004] branch master updated: finish first pass

[gnunet]

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

grothoff pushed a commit to branch master
in repository lsd0004.

The following commit(s) were added to refs/heads/master by this push:
     new 85366a8  finish first pass
85366a8 is described below

commit 85366a8836fe69e6df122e4b4693ecafb3fd7ba1
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Fri Mar 11 13:09:51 2022 +0100

    finish first pass
---
 draft-schanzen-r5n.xml | 48 ++++++++++++++++++++++--------------------------
 1 file changed, 22 insertions(+), 26 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 5cb9ad0..be26f96 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -752,7 +752,7 @@ bchar = *(ALPHA / DIGIT)
         defined as follows:
       </t>
       <t>
-       FIXME: actually define the opertions...
+       FIXME: actually define the operations...
       </t>
     </section>
     <section anchor="routing" numbered="true" toc="default">
@@ -925,6 +925,7 @@ bchar = *(ALPHA / DIGIT)
             (cf. <tt>SelectClosestpeer(K)</tt>).
             Peers with a positive test in the Bloom filter <tt>B</tt> are not 
considered.
           </dd>
+         <!--FIXME: add function to calcualte number of next hops here... -->
         </dl>
       </section>
     </section>
@@ -1862,11 +1863,13 @@ bchar = *(ALPHA / DIGIT)
           </dl>
         </section>
         <section anchor="hello_block">
-          <name>Hello Block</name>
+          <name>HELLO Blocks</name>
           <t>
             For bootstrapping and peer discovery, the DHT implementation uses
-            its own block type called "HELLO". A block with this block type
-            contains the peer ID of the peer that published the "HELLO" 
together
+            its own block type called "HELLO".  HELLO blocks are the only type
+           of block that <bcp14>MUST</bcp14> be supported by every
+           R<sup>5</sup>N implementation. A block with this block type
+            contains the peer ID of the peer that published the HELLO together
            with a set of addresses of this peer.  The key of a HELLO block
             is the SHA-512 of the peer ID and thus the peer's address in the 
DHT.
           </t>
@@ -2020,23 +2023,29 @@ gnunet+tcp://12.3.4.5/ \
         <section>
         <name>Persistence</name>
         <t>
-          An implementation MUST provide a local persistence mechanism for
-          blocks.
-          The local storage MUST provide the following API:
+          An implementation <bcp14>SHOULD</bcp14> provide a local persistence 
mechanism for
+          blocks.  Embedded systems that lack storage capability 
<bcp14>MAY</bcp14> use 
+         connection-level signalling to indicate that they are merely a client 
utilizing a 
+         DHT and are not able to participate with storage.
+          The local storage <bcp14>MUST</bcp14> provide the following 
functionality:
         </t>
         <dl>
           <dt>Store(Key, Block)</dt>
           <dd>
-            Stores a block under the specified key.
+            Stores a block under the specified key. If an block with identical
+           payload exists already under the same key, the meta data should
+           be set to the maximum expiration time of both blocks and use the
+           corresponding PUTPATH of that version of the block.
           </dd>
           <dt>Lookup(Key) -&gt; List of Blocks</dt>
           <dd>
-            Retrieves the blocks stored under the specified key.
+            Retrieves blocks stored under the specified key.
           </dd>
           <dt>LookupApproximate(Key) -&gt; List of Blocks</dt>
           <dd>
             Retrieves the blocks stored under the specified key and
-            any blocks under keys close to the specified key.
+            any blocks under keys close to the specified key, in order
+           of decreasing proximity.
           </dd>
         </dl>
         <section>
@@ -2052,11 +2061,11 @@ gnunet+tcp://12.3.4.5/ \
         <t>
           It is <bcp14>RECOMMENDED</bcp14> to limit the number of results
           from the <tt>LookupApproximate</tt> procedure to a result size
-          which is manageable by the local system.
+          which is easily manageable by the local system.
         </t>
         <t>
           In order to efficiently find a suitable result set, the 
implementation
-          SHOULD follow the following procedure:
+          <bcp14>SHOULD</bcp14> follow the following procedure:
         </t>
         <ol>
           <li>
@@ -2073,14 +2082,12 @@ gnunet+tcp://12.3.4.5/ \
           </li>
         </ol>
         <t>
-          An implementation MAY decide to use a custom algorithm in order to
+          An implementation <bcp14>MAY</bcp14> decide to use a custom 
algorithm in order to
           find the closest blocks in the local storage.
           But, especially for more primitive approaches, such as only
           comparing XOR distances for all blocks in the storage, the
           procedure may become ineffective for large storages.
         </t>
-        <!-- FIXME the result set is then filtered again by the block
-        plugin. But we should discuss this elsewhere -->
         </section>
         <section>
           <name>Caching Strategy Considerations</name>
@@ -2110,17 +2117,6 @@ gnunet+tcp://12.3.4.5/ \
             or other constrained resources.
           </t>
         </section>
-      <!--
-         Left-over from "local storage" section, which should be merged here:
-
-        - 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>
     </section>
     <section anchor="security" numbered="true" toc="default">

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