commit 5093a473fce70ea7478d5cfce9f63b795706f0b9
parent 64b24d05f08e6bdd2aaa49aec54799b18ea21604
Author: Christian Grothoff <christian@grothoff.org>
Date: Fri, 12 Jul 2024 10:04:04 +0200
justify 1024 bits more
Diffstat:
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -954,13 +954,17 @@ Connectivity | |Underlay| |Underlay| | Underlay | ...
added to it. It is constant in size at <tt>L=1024</tt> bits
(128 bytes) and sets <tt>k=16</tt> bits per element. (At
this size, the Bloom filter reaches a false-positive rate of
- approximately fifty percent at about 200 entries; with 5
- peers per bucket 200 entries would be enough for 40 buckets
- which corresponds to an overlay network size of
- approximately 1 trillion peers.) For the next hop selection
- in both the random and the deterministic case, any peer
- which is in the peer Bloom filter for the respective message
- is excluded from the peer selection process.
+ approximately fifty percent at about 200 entries. For peer
+ discovery where the Bloom filter is initially populated with
+ peer identities from the local routing table, the 200
+ entries would still be enough for 40 buckets assuming 5
+ peers per bucket, which corresponds to an overlay network
+ size of approximately 1 trillion peers. Thus,
+ <tt>L=1024</tt> bits should suffice for all conceivable
+ use-cases.) For the next hop selection in both the random
+ and the deterministic case, any peer which is in the peer
+ Bloom filter for the respective message is excluded from the
+ peer selection process.
</t>
<t>
Any peer which is forwarding <tt>GetMessage</tt>s or <tt>PutMessage</tt>s
