From 6b1ac31c06758c6670ebee023d0cf4862d1f1c7c Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 30 Aug 2013 08:58:59 +0000 Subject: [PATCH] More archive.org link treatment --- i2p2www/pages/site/about/performance/history.html | 2 +- i2p2www/pages/site/docs/discussions/tunnel.html | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/i2p2www/pages/site/about/performance/history.html b/i2p2www/pages/site/about/performance/history.html index d919c51a..646f6440 100644 --- a/i2p2www/pages/site/about/performance/history.html +++ b/i2p2www/pages/site/about/performance/history.html @@ -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 %}

-

{% trans link='http://dev.i2p.net/pipermail/i2p/2004-March/000167.html' -%} +

{% trans link='http://web.archive.org/web/20070607220008/http://dev.i2p.net/pipermail/i2p/2004-March/000167.html' -%} As I've said, 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 diff --git a/i2p2www/pages/site/docs/discussions/tunnel.html b/i2p2www/pages/site/docs/discussions/tunnel.html index e8a3b5ce..bd8995b7 100644 --- a/i2p2www/pages/site/docs/discussions/tunnel.html +++ b/i2p2www/pages/site/docs/discussions/tunnel.html @@ -35,7 +35,7 @@ None of these are currently implemented.

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 statistics +and reviewing some statistics 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