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

Migrated glossary and performance improvements

Browse Source
This commit is contained in:
str4d
2012-12-11 04:17:36 +00:00
parent ceed5eb5bc
commit 500f536d33
4 changed files with 12 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
i2p2www/pages/global/nav.html
View File

@ -72,6 +72,8 @@
<li class="has-sub"><a href="#"><span>{{ _('Support') }}</span></a>
<ul>
<li><a href="{{ site_url('support/faq') }}"><span>{{ _('FAQ') }}</span></a></li>
<li><a href="{{ site_url('support/glossary') }}"><span>{{ _('Glossary') }}</span></a></li>
<li><a href="{{ site_url('support/performance') }}"><span>{{ _('Performance') }}</span></a></li>
<li><a href="{{ site_url('support/contact') }}"><span>{{ _('Contact us') }}</span></a></li>
<li><a href="http://{{ i2pconv('forum.i2p') }}/"><span>{{ _('Forums') }}</span></a></li>
<li><a href="http://{{ i2pconv('trac.i2p2.i2p') }}/"><span>Trac</span></a></li>

2
www.i2p2/pages/glossary.html → i2p2www/pages/site/support/glossary.html
View File

@ -1,4 +1,4 @@
{% extends "_layout.html" %}
{% extends "global/layout.html" %}
{% block title %}Glossary{% endblock %}
{% block content %}
This page lists often-used terminology when discussing I2P and cryptography.

16
www.i2p2/pages/performance.html → i2p2www/pages/site/support/performance/future.html
View File

@ -1,19 +1,15 @@
{% extends "_layout.html" %}
{% block title %}Performance{% endblock %}
{% extends "global/layout.html" %}
{% block title %}Future Performance Improvements{% endblock %}
{% block content %}
Updated August 2010, current as of router version 0.8
<p>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 <b>yes</b>.</p>
<p>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.</p>
<p>For past performance improvements see the <a href="performance-history.html">
<p>For past performance improvements see the <a href="{{ site_url('support/performance/history') }}">
Performance History</a>.
<h2>Better peer profiling and selection</h2>
@ -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.</p>
<h2>Session Tag Tuning and Improvements</h2>
<p>The way the <a href="how_elgamalaes">ElGamal/AES+SessionTag</a> algorithm
<p>The way the <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> 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.</p>
<p>
Additional ideas for improving Session Tag delivery are described on the
<a href="how_elgamalaes.html#future">ElGamal/AES+SessionTag page</a>.
<a href="{{ site_url('docs/how/elgamalaes') }}#future">ElGamal/AES+SessionTag page</a>.
</p>
<h2 id="prng">Migrate sessionTag to synchronized PRNG</h2>
<p>Right now, our <a href="how_elgamalaes.html">ElGamal/AES+SessionTag</a>
<p>Right now, our <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
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

6
www.i2p2/pages/performance-history.html → i2p2www/pages/site/support/performance/history.html
View File

@ -1,8 +1,8 @@
{% extends "_layout.html" %}
{% extends "global/layout.html" %}
{% block title %}Performance History{% endblock %}
{% block content %}
<p>Notable performance improvements have been made using the techniques below.
There is more to do, see the <a href="performance.html">Performance</a> page
There is more to do, see the <a href="{{ site_url('support/performance') }}">Performance</a> page
for current issues and thoughts.</p>
<h2>Native math <b>[implemented]</b></h2>
@ -99,7 +99,7 @@ message, and Bob piggybacked his first reply with the ACK - and perhaps also
included the CLOSE flag - transient streams such as HTTP requests could be
reduced to a pair of messages, instead of the SYN+ACK+request+response+CLOSE.</p>
<h2>Implement full streaming protocol</h2> [<a href="streaming.html">implemented</a>]
<h2>Implement full streaming protocol</h2> [<a href="{{ site_url('docs/api/streaming') }}">implemented</a>]
<p>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