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

minor updates

Browse Source
This commit is contained in:
zzz
2008-04-24 13:38:12 +00:00
parent e6e4d31496
commit 91afa8f72d
4 changed files with 34 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
www.i2p2/pages/faq.html
View File

@@ -164,6 +164,14 @@ Two key settings are the inbound and outbund bandwidth limiters on
With the default settings of 16KBps you will generally get no better than 5KBps data transfer in I2PSnark.
Increasing the settings (but keeping within your actual connection limitations)
will increase the potential transfer rate for I2PSnark and all other applications.
</p><p>
Also, do you have sufficient share bandwidth configured to allow participating tunnels
to route through your router? Believe it or not, allowing participating traffic
keeps you well-integrated in the network and helps your own transfer speeds.
</p><p>
I2P is a work in progress. Lots of improvements and fixes are being implemented, and
generally speaking, running the latest release will help your performance.
If you haven't, <a href="download.html">install the latest release</a>.
</p>
<h3 id="snark">Bittorrent / I2PSnark / Azureus I2P Plugin Questions?

12
www.i2p2/pages/how_intro.html
View File

@@ -1,11 +1,11 @@
{% extends "_layout.html" %}
{% block title %}Introduction to How I2P Works{% endblock %}
{% block content %}<i>Note: these documents have not yet been updated to include the changes made
in I2P 0.5 - the new
{% block content %}<i>Note: the "how" documents have not been fully updated to include several changes
including the new
<a href="tunnel-alt.html">tunnel
routing and encryption</a> algorithms, addressing <a href="todo#tunnelId">several</a>
<a href="todo#tunnelLength">issues</a> (with the groundwork for addressing
<a href="todo#ordering">others</a>).</i>
<a href="todo#ordering">others</a>), and other changes.</i>
<p>I2P is an effort to build, deploy, and maintain a network to support secure and anonymous
communication. People using I2P are in control of the tradeoffs between anonymity, reliability,
@@ -91,11 +91,13 @@ a full laundry list includes 2048bit ElGamal encryption, 256bit AES in CBC mode
1024bit DSA signatures, SHA256 hashes, 2048bit Diffie-Hellman negotiated connections with station to
station authentication, and <a href="how_elgamalaes">ElGamal / AES+SessionTag</a>.</p>
<p>Content sent over I2P is encrypted through three or four layers - end to end encryption (absolutely
no routers get the plaintext, ever), garlic encryption (used to verify the delivery of the message to
<p>Content sent over I2P is encrypted through three <strike>or four</strike> layers - <strike>end to end encryption (absolutely
no routers get the plaintext, ever),</strike> garlic encryption (used to verify the delivery of the message to
the recipient), tunnel encryption (all messages passing through a tunnel is encrypted by the tunnel
gateway to the tunnel endpoint), and interrouter transport layer encryption (e.g. the TCP transport
uses AES256 with ephemeral keys):</p>
<p>End-to-end (I2CP) encryption was disabled in I2P release 0.6; end-to-end (garlic) encryption
remains. Disregard the "Alice-to-Bob" encryption in the picture below.
<p><img src="/_static/images/endToEndEncryption.png" alt="end to end layered encryption" /></p>

6
www.i2p2/pages/i2cp.html
View File

@@ -22,6 +22,12 @@ Instead, applications can take advantage of the base I2CP plus the
by using the <a href="sam">Simple Anonymous Messaging</a> protocol (which does not
require clients to deal with any sort of cryptography).</p>
<p>Actually, I2CP end-to-end encryption was disabled in I2P release 0.6,
leaving in place the end-to-end garlic encryption.
However, client libraries must still implement public/private key signing
for leasesets, and key management.
</p>
<p>While the I2CP has been quite stable since its inception in
August of 2003, there have been minor modifications on occasion.
Here is the

16
www.i2p2/pages/i2np.html
View File

@@ -41,6 +41,10 @@ These are globabl queues for all peers.
NTCP has a trivial linear search for the highest priority within
each buffer for a particular peer.
This is much less effective.
<p>
It isn't clear whether the current priority scheme is generally effective,
and whether the priorities for various messages should be adjusted further.
This is a topic for further research, analysis and testing.
<h3>Message Format</h3>
@@ -87,14 +91,20 @@ DatabaseLookupMessage
<tr><td>
DatabaseSearchReplyMessage
<td align=right>3
<td>&nbsp;
<td align=right>Typ. 161
<td align=right>300
<td>Size is 65 + 32*(number of hashes) where typically, the hashes for
three floodfill routers are returned.
<tr><td>
DatabaseStoreMessage
<td align=right>1
<td>&nbsp;
<td align=right>Varies
<td align=right>100/400
<td>Usually 100 (why?)
Size is 898 bytes for a typical 2-lease leaseSet.
RouterInfo structures are compressed, and size varies; however
there is a continuing effort to reduce the amount of data published in a RouterInfo
as we appproach release 1.0.
<tr><td>
DataMessage
<td align=right>20
@@ -105,7 +115,7 @@ DateMessage
<td align=right>16
<td>&nbsp;
<td>&nbsp;
<td>Obsolete (was used by TCP), date messages now at the I2CP layer ?
<td>Obsolete (was used by TCP), date messages now at the <a href="i2cp.html">I2CP</a> layer ?
<tr><td>
DeliveryStatusMessage
<td align=right>10