I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

More archive.org link treatment

Browse Source
This commit is contained in:
str4d
2013-08-30 08:58:59 +00:00
parent 5611daf7be
commit 6b1ac31c06
2 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
i2p2www/pages/site/about/performance/history.html
View File

@ -140,7 +140,7 @@ message based, with the router providing delivery guarantees by garlic wrapping
an "ACK" message in with the payload, so once the data gets to the target, the
ACK message is forwarded back to us [through tunnels, of course]).
{%- endtrans %}</p>
<p>{% trans link='http://dev.i2p.net/pipermail/i2p/2004-March/000167.html' -%}
<p>{% trans link='http://web.archive.org/web/20070607220008/http://dev.i2p.net/pipermail/i2p/2004-March/000167.html' -%}
As I've <a href="{{ link }}">said</a>, having
I2PTunnel (and the ministreaming lib) go this route was the best thing that
could be done, but more efficient mechanisms are available. When we rip out the

2
i2p2www/pages/site/docs/discussions/tunnel.html
View File

@ -35,7 +35,7 @@ None of these are currently implemented.
<p>These padding strategies can be used on a variety of levels, addressing the
exposure of message size information to different adversaries. After gathering
and reviewing some <a href="http://dev.i2p.net/~jrandom/messageSizes/">statistics</a>
and reviewing some <a href="http://web.archive.org/web/20050413140457/http://dev.i2p.net/~jrandom/messageSizes/">statistics</a>
from the 0.4 network, as well as exploring the anonymity tradeoffs, we're starting
with a fixed tunnel message size of 1024 bytes. Within this however, the fragmented
messages themselves are not padded by the tunnel at all (though for end to end