Minor fixes for how_networkdatabase

This commit is contained in:
dg2-new
2013-10-29 23:26:46 +00:00
parent d69f2e2181
commit c4697105f6

View File

@ -3,7 +3,7 @@
{% block content %}
<p>
Updated June 2013, current as of router version 0.9.6
Updated October 2013, current as of router version 0.9.9
</p>
<h2>Overview</h2>
@ -388,7 +388,7 @@ the netdb item.
After a floodfill router receives a DatabaseStoreMessage containing a
valid RouterInfo or LeaseSet which is newer than that previously stored in its
local NetDb, it "floods" it.
To flood a NetDb entry, it looks up several (currently 4) floodfill routers closest to the routing key
To flood a NetDb entry, it looks up several (currently 3) floodfill routers closest to the routing key
of the NetDb entry. (The routing key is the SHA256 Hash of the RouterIdentity or Destination with the date (yyyyMMdd) appended.)
By flooding to those closest to the key, not closest to itself, the floodfill ensures that the storage
gets to the right place, even if the storing router did not have good knowledge of the
@ -546,7 +546,7 @@ the netdb item.
<h3>General Mitigation Through Growth</h3>
<p>
There are currently almost 100 floodfill routers in the network.
There are currently around 600 floodfill routers in the network.
Most of the following attacks will become more difficult, or have less impact,
as the network size and number of floodfill routers increase.
</p>
@ -554,7 +554,7 @@ the netdb item.
<h3>General Mitigation Through Redundancy</h3>
<p>
Via flooding, all netdb entries are stored on the 8 floodfill routers closest to the key.
Via flooding, all netdb entries are stored on the 3 floodfill routers closest to the key.
</p>