forked from I2P_Developers/i2p.www
Remove part about router info store verification
This commit is contained in:
@ -286,14 +286,12 @@ one of these URLs, selected at random.
|
|||||||
|
|
||||||
<h2 id="floodfill">{% trans %}Floodfill{% endtrans %}</h2>
|
<h2 id="floodfill">{% trans %}Floodfill{% endtrans %}</h2>
|
||||||
<p>{% trans -%}
|
<p>{% trans -%}
|
||||||
The floodfill netDb is a simple distributed storage mechanism.
|
The floodfill netDb is a simple distributed storage mechanism. The storage
|
||||||
The storage algorithm is simple: send the data to the closest peer that has advertised itself
|
algorithm is simple: send the data to the closest peer that has advertised
|
||||||
as a floodfill router. Then wait 10 seconds, pick another floodfill router and ask them
|
itself as a floodfill router. When the peer in the floodfill netDb receives a
|
||||||
for the entry to be sent, verifying its proper insertion / distribution. If the
|
netDb store from a peer not in the floodfill netDb, they send it to a subset of
|
||||||
verification peer doesn't reply, or they don't have the entry, the sender
|
the floodfill netDb-peers. The peers selected are the ones closest (according
|
||||||
repeats the process. When the peer in the floodfill netDb receives a netDb
|
to the <a href="#kad">XOR-metric</a>) to a specific key.
|
||||||
store from a peer not in the floodfill netDb, they send it to a subset of the floodfill netDb-peers.
|
|
||||||
The peers selected are the ones closest (according to the <a href="#kad">XOR-metric</a>) to a specific key.
|
|
||||||
{%- endtrans %}</p>
|
{%- endtrans %}</p>
|
||||||
|
|
||||||
<p>{% trans -%}
|
<p>{% trans -%}
|
||||||
|
Reference in New Issue
Block a user