diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html index 14f1ad77..e78a5b2a 100644 --- a/i2p2www/pages/global/nav.html +++ b/i2p2www/pages/global/nav.html @@ -72,6 +72,8 @@
Probably one of the most frequent things people ask is "how fast is I2P?", -and no one seems to like the answer - "it depends". After trying out I2P, the -next thing they ask is "will it get faster?", and the answer to that is a most -emphatic yes.
There are a few major techniques that can be done to improve the perceived performance of I2P - some of the following are CPU related, others bandwidth related, and others still are protocol related. However, all of those dimensions affect the latency, throughput, and perceived performance of the network, as they reduce contention for scarce resources. This list is of course not comprehensive, but it does cover the major ones that are seen.
-For past performance improvements see the
+ For past performance improvements see the
Performance History.
Better peer profiling and selection
@@ -36,7 +32,7 @@ tuning on what we actually send - how many peers we bounce back (or even if we
bounce back a reply), as well as how many concurrent searches we perform.
The way the ElGamal/AES+SessionTag algorithm +
The way the ElGamal/AES+SessionTag algorithm works is by managing a set of random one-time-use 32 byte arrays, and expiring them if they aren't used quickly enough. If we expire them too soon, we're forced to fall back on a full (expensive) ElGamal encryption, but if we don't @@ -48,12 +44,12 @@ efficiently tune the lifetime of the tags, replacing the ElGamal encryption with a trivial AES operation.
Additional ideas for improving Session Tag delivery are described on the -ElGamal/AES+SessionTag page. +ElGamal/AES+SessionTag page.
Right now, our ElGamal/AES+SessionTag +
Right now, our ElGamal/AES+SessionTag algorithm works by tagging each encrypted message with a unique random 32 byte nonce (a "session tag"), identifying that message as being encrypted with the associated AES session's key. This prevents peers from distinguishing diff --git a/www.i2p2/pages/performance-history.html b/i2p2www/pages/site/support/performance/history.html similarity index 96% rename from www.i2p2/pages/performance-history.html rename to i2p2www/pages/site/support/performance/history.html index a65fe726..5c7fc0f3 100644 --- a/www.i2p2/pages/performance-history.html +++ b/i2p2www/pages/site/support/performance/history.html @@ -1,8 +1,8 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}Performance History{% endblock %} {% block content %}
Notable performance improvements have been made using the techniques below. -There is more to do, see the Performance page +There is more to do, see the Performance page for current issues and thoughts.
The ministreaming protocol takes advantage of a poor design decision in the I2P client protocol (I2CP) - the exposure of "mode=GUARANTEED", allowing what would otherwise be an unreliable, best-effort, message based protocol to be used