If you'd like to help improve or translate the documentation, or
help with other aspects of the project, please see the documentation for
volunteers.
Further assistance is available here: -
-
+
Further assistance is available here: -
-
You may also try the I2P forum @@ -31,44 +31,44 @@ Many of the stats on the summary bar may be
General
-
-
- Ident: +
- Ident: The first four characters (24 bits) of your 44-character (256-bit) Base64 router hash. The full hash is shown on your router info page. Never reveal this to anyone, as your router info contains your IP. -
- Version: +
- Version: The version of the I2P software you are running. -
- Now: +
- Now: The current time (UTC) and the skew, if any. I2P requires your computer's time be accurate. If the skew is more than a few seconds, please correct the problem by adjusting your computer's time. -
- Reachability: +
- Reachability: The router's view of whether it can be contacted by other routers. Further information is on the configuration page.
Peers
-
-
- Active: +
- Active: The first number is the number of peers you've sent or received a message from in the last few minutes. This may range from 8-10 to several hundred, depending on your total bandwidth, shared bandwidth, and locally-generated traffic. The second number is the number of peers seen in the last hour or so. Do not be concerned if these numbers vary widely. Enable graphing -
- Fast: +
- Fast: This is the number of peers you use for building client tunnels. It is generally in the range 8-15. Your fast peers are shown on the profiles page. Enable graphing -
- High Capacity: +
- High Capacity: This is the number of peers you use for building some of your exploratory tunnels. It is generally in the range 8-25. The fast peers are included in the high capacity tier. Your high capacity peers are shown on the profiles page. Enable graphing -
- Well Integrated: +
- Well Integrated: This is the number of peers you use for network database inquiries. These are usually the "floodfill" peers. Your well integrated peers are shown on the bottom of the profiles page. -
- Known: +
- Known:
This is the total number of routers you know about.
They are listed on the network database page.
This may range from under 100 to 1000 or more.
@@ -91,26 +91,25 @@ or external programs connecting through SAM, BOB, or directly to I2CP.
Tunnels in/out
The actual tunnels are shown on the the tunnels page.-
-
- Exploratory: +
- Exploratory: Tunnels built by your router and used for communication with the floodfill peers, building new tunnels, and testing existing tunnels. -
- Client: +
- Client: Tunnels built by your router for each client's use. -
- Participating: +
- Participating: Tunnels built by other routers through your router. This may vary widely depending on network demand, your shared bandwidth, and amount of locally-generated traffic. The recommended method for limiting participating tunnels is to change your share percentage on the configuration page. You may also limit the total number by setting router.maxParticipatingTunnels=nnn on -the advanced configuration page. -Enable graphing +the advanced configuration page. [Enable graphing].
Congestion
-Some basic indications of router overload. +Some basic indications of router overload:-
-
- Job lag: +
- Job lag: How long jobs are waiting before execution. The job queue is listed on the jobs page. Unfortunately, there are several other job queues in the router that may be congested, and their status is not available in the router console. @@ -118,27 +117,27 @@ The job lag should generally be zero. If it is consistently higher than 500ms, your computer is very slow, or the router has serious problems. Enable graphing -
- Message delay: +
- Message delay: How long an outbound message waits in the queue. This should generally be a few hundred milliseconds or less. If it is consistently higher than 1000ms, your computer is very slow, or you should adjust your bandwidth limits, or your (bittorrent?) clients may be sending too much data and should have their transmit bandwidth limit reduced. Enable graphing (transport.sendProcessingTime) -
- Tunnel lag: +
- Tunnel lag: This is the round trip time for a tunnel test, which sends a single message out a client tunnel and in an exploratory tunnel, or vice versa. It should usually be less than 5 seconds. If it is consistently higher than that, your computer is very slow, or you should adjust your bandwidth limits, or there are network problems. Enable graphing (tunnel.testSuccessTime) -
- Handle backlog: +
- Handle backlog: This is the number of pending requests from other routers to build a participating tunnel through your router. It should usually be close to zero. If it is consistently high, your computer is too slow, and you should reduce your share bandwidth limits. -
- Accepting/Rejecting: +
- Accepting/Rejecting:
Your routers' status on accepting or rejecting
requests from other routers to build a
participating tunnel through your router.
@@ -150,12 +149,12 @@ local clients.
Legal stuff
The I2P router (router.jar) and SDK (i2p.jar) are almost entirely public domain, with -a few notable exceptions:-
-
- ElGamal and DSA code, under the BSD license, written by TheCrypto -
- SHA256 and HMAC-SHA256, under the MIT license, written by the Legion of the Bouncycastle -
- AES code, under the Cryptix (MIT) license, written by the Cryptix team -
- SNTP code, under the BSD license, written by Adam Buckley -
- The rest is outright public domain, written by jrandom, mihi, hypercubus, oOo,
+a few notable exceptions:
-
+
- ElGamal and DSA code, under the BSD license, written by TheCrypto +
- SHA256 and HMAC-SHA256, under the MIT license, written by the Legion of the Bouncycastle +
- AES code, under the Cryptix (MIT) license, written by the Cryptix team +
- SNTP code, under the BSD license, written by Adam Buckley +
- The rest is outright public domain, written by jrandom, mihi, hypercubus, oOo, ugha, duck, shendaras, and others.
A more complete list of changes can be found in the history.txt file in your i2p directory. -
+