gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lsd0004] branch master updated: update peer selection


From: gnunet
Subject: [lsd0004] branch master updated: update peer selection
Date: Tue, 07 Sep 2021 17:29:18 +0200

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 8153f62  update peer selection
8153f62 is described below

commit 8153f62a68fd2fa19deb7f57944d60db388ad311
Author: Martin Schanzenbach <mschanzenbach@posteo.de>
AuthorDate: Tue Sep 7 17:28:37 2021 +0200

    update peer selection
---
 draft-schanzen-r5n.xml | 45 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 42 insertions(+), 3 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 1d78c5b..c4e1780 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -251,11 +251,50 @@ see how we can offer even the most minimal protections 
against peer
    </section>
    <section anchor="routing" numbered="true" toc="default">
      <name>Routing</name>
-     <section anchor="peer_distance" numbered="true" toc="default">
-       <name>Peer distance</name>
-     </section>
      <section anchor="peer_selection" numbered="true" toc="default">
        <name>Peer selection</name>
+       <t>
+         In order to select peers from the routing table which are suitable
+         destinations for sending messages, R5N uses a hybrid approach:
+         Given an estimated network size N, the peer selection for the
+         first N hops is random. After the initial N hops, peer selection
+         follows an XOR-based peer distance calculation.
+       </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.
+         In R5N, a bloomfilter is used as part of the routing metadata in
+         messages. The bloomfilter is updates at each hop with the hops
+         peer identity.
+         For the next hop selection in both the random and the deterministic
+         case, any peer which is in the bloomfilter for the respective message
+         is not included in the peer selection process.
+       </t>
+       <!-- Fixme: We may want to propose our modified, optimized XOR metric 
here or reference Kademlia -->
+       <t>
+         The procedure to select a peer for a given message key and bloomfilter
+         is defined as follows:
+       </t>
+       <figure>
+         <artwork name="" type="" align="left" alt=""><![CDATA[
+PEER-SELECT(key, bloomfilter)
+  peers := <Select all known peers NOT in message bloomfilter>
+  IF hops >= N
+    dist := MAX_VALUE
+    FOR EACH p IN peers
+      IF XOR(p, key) < dist
+        dist := XOR(p, key)
+        target := p
+      END
+    END
+  ELSE
+    r := rand()
+    target := peers[r]
+  END
+END
+         ]]></artwork>
+     </figure>
+
      </section>
    </section>
    <section anchor="p2p_messages" numbered="true" toc="default">

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]