[lsd0004] branch master updated: more routing

[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 3e58a5b  more routing
3e58a5b is described below

commit 3e58a5b4aa9eaffac3f1b7d67ae9b1f5e42c5003
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Wed Dec 29 19:49:36 2021 +0100

    more routing
---
 draft-schanzen-r5n.xml | 49 ++++++++++++++++++++++++++++---------------------
 1 file changed, 28 insertions(+), 21 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index ea0736f..519fb60 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -514,36 +514,43 @@ PEER-SELECT(key, bloomfilter)
   END
 END
          ]]></artwork>
-     </figure>
-     <t>
-       R5N requires the following procedures for its routing table:
-     </t>
-     <dl>
-       <dt><tt>FindBucket(PeerID, Key) -> k-bucket</tt></dt>
-       <dd>
+       </figure>
+       <t>
+         R5N requires the following procedures for its routing table:
+       </t>
+       <dl>
+         <dt><tt>FindBucket(PeerID, Key) -> k-bucket as List</tt></dt>
+         <dd>
            The <tt>FindBucket</tt> procedure determines how many low
            order bits succesively match between a <tt>PeerID</tt> and a
            <tt>Key</tt> starting from the first bit. The procedure returns
            the k-bucket for this index. It contains all connected nodes which
            share the same prefix length with <tt>PeerID</tt>.
-       </dd>
-       <dt><tt>GetDistance(NodeKey_A, NodeKey_B)</tt></dt>
-       <dd>
-         FIXME: We do NOT do XOR here. We do some kind of
-         fancy calculation. See get_distance()
-       </dd>
-       <dt><tt>AmClosestNode(NodeID, Key, Bloom) -> true | false</tt></dt>
-       <dd>
-         This procedure first determines which k-bucket contains the
+         </dd>
+         <dt><tt>GetDistance(NodeKey_A, NodeKey_B) -> Distance as 
Integer</tt></dt>
+         <dd>
+           FIXME: We do NOT do XOR here. We do some kind of
+           fancy calculation. See get_distance()
+         </dd>
+         <dt><tt>SelectClosestPeer(Key) -> NodeID</tt></dt>
+         <dd>
+           This procedure determines the closest node ID to <tt>Key</tt>
+           of all connected nodes using <tt>GetDistance</tt>.
+           FIXME: Also has a bloomfilter. Isn't AmClosestNode simply
+           !SelectClosestPeer == myID ?
+         </dd>
+         <dt><tt>AmClosestNode(NodeID, Key, Bloom) -> true | false</tt></dt>
+         <dd>
+           This procedure first determines which k-bucket contains the
            closest node IDs to <tt>Key</tt>.
            Any node IDs which match the bloom filter are not considered.
            If there is a node ID <tt>NodeID'</tt> in the k-bucket where
            <tt>GetDistance(NodeID, Key) > GetDistance(NodeID', Key)</tt>,
-             then <tt>false</tt> is returned, otherwise <tt>true</tt>.
-             FIXME: Currently, GDS_am_closest_peer checks for longer matching
-             bits. Not GetDistance. Why?
-       </dd>
-     </dl>
+           then <tt>false</tt> is returned, otherwise <tt>true</tt>.
+           FIXME: Currently, GDS_am_closest_peer checks for longer matching
+           bits. Not GetDistance. Why?
+         </dd>
+       </dl>
      </section>
    </section>
    <section anchor="p2p_messages" numbered="true" toc="default">

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