diff --git a/www.i2p2/pages/faq.html b/www.i2p2/pages/faq.html index 3cf7921c..95bc968d 100644 --- a/www.i2p2/pages/faq.html +++ b/www.i2p2/pages/faq.html @@ -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. +
+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. +
+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, install the latest release.
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 ElGamal / AES+SessionTag.
-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 +
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
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):
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.
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. +
+While the I2CP has been quite stable since its inception in August of 2003, there have been minor modifications on occasion. Here is the diff --git a/www.i2p2/pages/i2np.html b/www.i2p2/pages/i2np.html index 59682cd3..831f0c05 100644 --- a/www.i2p2/pages/i2np.html +++ b/www.i2p2/pages/i2np.html @@ -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. +
+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.