forked from I2P_Developers/i2p.www
merge of 'b86bd2c66d4280de170168f9262c11df71852640'
and 'bd4e068f9810696195f4b6374a04da2508f36570'
This commit is contained in:
dev
@ -300,3 +300,5 @@ true.i2p=Jeb1Ctlh55wWezbA~sCxYQsreDPS~qFJ6DeNMPl7~Kx0w1Odh8YE3QKrZS7WlNqeoRNJLyP
|
||||
krabs.i2p=k6qIwzff6s1RiRQQy9O6cliBTfHffKZ2F~pVG8nmCqMxEpPnywynFa9XVS6VBbhxGRAMG~PIb2IaFRYS5GFdM3fnnJ~Cn2AbN-qsqbl6cXExj5Fy9Cd-aPR44XW0NE9qjFPiN~6JUOg0fitF65RmsMrFvHq9LM2zOFxOfnPKVsBJGRpjhp6EPRNrkXvzQTw7x6~kqUJ-VGW0avjrz4EmgT6Wias5z0EPioneKOhG-1NepL8HqEv9ryGt31~kmI1-B0cS8v1riaXH0rZWjJ0VvUFEoJ3sHCir4vsnSf1YQIKMUO~zKlgTVZBsw8P2ILFFihs0g9KMIWVjJqqo0PzCM1O-LW90hirn~Ryh4zOZI-orIiV9Oqu96Fj2bvBYSka11TY7erLOCk64tc5NwxvlJQ3F-lk0ZFGvYuU~l45mi0khFLnDnzhDFtcY6YNLRG8hmv9IR2MrG9TJFfSwXdx11LI-57tkRi9Jw4s8OjLijNNDOJX~rVgwZVVIEQcOhGxkAAAA
|
||||
www.i2p2.i2p=-KR6qyfPWXoN~F3UzzYSMIsaRy4udcRkHu2Dx9syXSzUQXQdi2Af1TV2UMH3PpPuNu-GwrqihwmLSkPFg4fv4yQQY3E10VeQVuI67dn5vlan3NGMsjqxoXTSHHt7C3nX3szXK90JSoO~tRMDl1xyqtKm94-RpIyNcLXofd0H6b02683CQIjb-7JiCpDD0zharm6SU54rhdisIUVXpi1xYgg2pKVpssL~KCp7RAGzpt2rSgz~RHFsecqGBeFwJdiko-6CYW~tcBcigM8ea57LK7JjCFVhOoYTqgk95AG04-hfehnmBtuAFHWklFyFh88x6mS9sbVPvi-am4La0G0jvUJw9a3wQ67jMr6KWQ~w~bFe~FDqoZqVXl8t88qHPIvXelvWw2Y8EMSF5PJhWw~AZfoWOA5VQVYvcmGzZIEKtFGE7bgQf3rFtJ2FAtig9XXBsoLisHbJgeVb29Ew5E7bkwxvEe9NYkIqvrKvUAt1i55we0Nkt6xlEdhBqg6xXOyIAAAA
|
||||
i2p-projekt.i2p=8ZAW~KzGFMUEj0pdchy6GQOOZbuzbqpWtiApEj8LHy2~O~58XKxRrA43cA23a9oDpNZDqWhRWEtehSnX5NoCwJcXWWdO1ksKEUim6cQLP-VpQyuZTIIqwSADwgoe6ikxZG0NGvy5FijgxF4EW9zg39nhUNKRejYNHhOBZKIX38qYyXoB8XCVJybKg89aMMPsCT884F0CLBKbHeYhpYGmhE4YW~aV21c5pebivvxeJPWuTBAOmYxAIgJE3fFU-fucQn9YyGUFa8F3t-0Vco-9qVNSEWfgrdXOdKT6orr3sfssiKo3ybRWdTpxycZ6wB4qHWgTSU5A-gOA3ACTCMZBsASN3W5cz6GRZCspQ0HNu~R~nJ8V06Mmw~iVYOu5lDvipmG6-dJky6XRxCedczxMM1GWFoieQ8Ysfuxq-j8keEtaYmyUQme6TcviCEvQsxyVirr~dTC-F8aZ~y2AlG5IJz5KD02nO6TRkI2fgjHhv9OZ9nskh-I2jxAzFP6Is1kyAAAA
|
||||
nickyb.i2p=9On6d3cZ27JjwYCtyJJbowe054d5tFnfMjv4PHsYs-EQn4Y4mk2zRixatvuAyXz2MmRfXG-NAUfhKr0KCxRNZbvHmlckYfT-WBzwwpiMAl0wDFY~Pl8cqXuhfikSG5WrqdPfDNNIBuuznS0dqaczf~OyVaoEOpvuP3qV6wKqbSSLpjOwwAaQPHjlRtNIW8-EtUZp-I0LT45HSoowp~6b7zYmpIyoATvIP~sT0g0MTrczWhbVTUZnEkZeLhOR0Duw1-IRXI2KHPbA24wLO9LdpKKUXed05RTz0QklW5ROgR6TYv7aXFufX8kC0-DaKvQ5JKG~h8lcoHvm1RCzNqVE-2aiZnO2xH08H-iCWoLNJE-Td2kT-Tsc~3QdQcnEUcL5BF-VT~QYRld2--9r0gfGl-yDrJZrlrihHGr5J7ImahelNn9PpkVp6eIyABRmJHf2iicrk3CtjeG1j9OgTSwaNmEpUpn4aN7Kx0zNLdH7z6uTgCGD9Kmh1MFYrsoNlTp4AAAA
|
||||
tracker.welterde.i2p=BGKmlDOoH3RzFbPRfRpZV2FjpVj8~3moFftw5-dZfDf2070TOe8Tf2~DAVeaM6ZRLdmFEt~9wyFL8YMLMoLoiwGEH6IGW6rc45tstN68KsBDWZqkTohV1q9XFgK9JnCwE~Oi89xLBHsLMTHOabowWM6dkC8nI6QqJC2JODqLPIRfOVrDdkjLwtCrsckzLybNdFmgfoqF05UITDyczPsFVaHtpF1sRggOVmdvCM66otyonlzNcJbn59PA-R808vUrCPMGU~O9Wys0i-NoqtIbtWfOKnjCRFMNw5ex4n9m5Sxm9e20UkpKG6qzEuvKZWi8vTLe1NW~CBrj~vG7I3Ok4wybUFflBFOaBabxYJLlx4xTE1zJIVxlsekmAjckB4v-cQwulFeikR4LxPQ6mCQknW2HZ4JQIq6hL9AMabxjOlYnzh7kjOfRGkck8YgeozcyTvcDUcUsOuSTk06L4kdrv8h2Cozjbloi5zl6KTbj5ZTciKCxi73Pn9grICn-HQqEAAAA
|
||||
|
||||
@ -208,6 +208,7 @@ while each router chooses which peers it wants to treat as part of the netdb
|
||||
ignored, essentially eliminating them from the netdb).
|
||||
</p><p>
|
||||
Another alternative is a blast from the past, going back to the DTSTTCPW
|
||||
(Do The Simplest Thing That Could Possibly Work)
|
||||
mentality - a floodfill netdb, but like the alternative above, using only a
|
||||
subset of the full network. When a user wants to publish an entry into the
|
||||
floodfill netdb, they simply send it to one of the participating routers, wait
|
||||
@ -332,6 +333,36 @@ The netDb implementation more than adequately meets our
|
||||
needs at the moment, but there will likely be further tuning and bugfixing as
|
||||
the network grows.</p>
|
||||
|
||||
<h3>Update of Calculations 03-2008</h3>
|
||||
<p>Current numbers:
|
||||
<pre>
|
||||
recvKBps = N * (L + 1) * (1 + F) * (1 + R) * S / T
|
||||
</pre>where<pre>
|
||||
N = number of routers in the entire network
|
||||
L = average number of client destinations on each router
|
||||
(+1 for the routerInfo)
|
||||
F = tunnel failure percentage
|
||||
R = tunnel rebuild period, as a fraction of the tunnel lifetime
|
||||
S = average netdb entry size
|
||||
T = tunnel lifetime
|
||||
</pre>
|
||||
Changes in assumptions:
|
||||
<ul>
|
||||
<li>L is now about .5, compared to .1 above, due to the popularity of i2psnark
|
||||
and other apps.
|
||||
<li>F is about .33, but bugs in tunnel testing are fixed in 0.6.1.33, so it will get much better.
|
||||
<li>Since netDb is about 2/3 5K routerInfos and 1/3 2K leaseSets, S = 4K.
|
||||
RouterInfo size is shrinking in 0.6.1.32 and 0.6.1.33 as we remove unnecessary stats.
|
||||
<li>R = tunnel build period: 0.2 was a very low - it was maybe 0.7 -
|
||||
but build algorithm improvements in 0.6.1.32 should bring it down to about 0.2
|
||||
as the network upgrades. Call it 0.5 now with half the network at .30 or earlier.
|
||||
</ul>
|
||||
<pre> recvKBps = 700 * (0.5 + 1) * (1 + 0.33) * (1 + 0.5) * 4KB / 10m
|
||||
~= 28KBps
|
||||
</pre>
|
||||
This just accounts for the stores - what about the queries?
|
||||
|
||||
|
||||
<h3>The Return of the Kademlia Algorithm?</h3>
|
||||
<p>
|
||||
(this is adapted from <a href="meeting195.html">the I2P meeting Jan. 2, 2007</a>)
|
||||
|
||||
@ -54,12 +54,16 @@ Here is the protocol stack for I2P.
|
||||
<td>Network Protocol
|
||||
<td align="center" colspan=2><a href="i2np.html">I2NP</a>
|
||||
|
||||
<tr>
|
||||
<td>Garlic Encryption
|
||||
<td align="center" colspan=2><a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
|
||||
|
||||
<tr>
|
||||
<td>Tunnel Messages
|
||||
<td align="center" colspan=2><a href="tunnel-alt.html#tunnel.preprocessing">Tunnel Messages</a>
|
||||
|
||||
<tr>
|
||||
<td>Hop Encryption
|
||||
<td>Tunnel Message Encryption
|
||||
<td align="center" colspan=2><a href="techintro.html#op.crypto">AES256/CBC</a>
|
||||
|
||||
<tr>
|
||||
@ -67,6 +71,10 @@ Here is the protocol stack for I2P.
|
||||
<td align="center"><a href="ntcp.html">NTCP</a>
|
||||
<td align="center"><a href="udp.html">SSU</a>
|
||||
|
||||
<tr>
|
||||
<td>Transport Encryption
|
||||
<td align="center" colspan=2><a href="techintro.html#op.crypto">AES256/CBC</a>
|
||||
|
||||
<tr>
|
||||
<td>
|
||||
<td align="center">Java NIO TCP
|
||||
|
||||
@ -113,6 +113,12 @@ Time values are in ms.
|
||||
</ul>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The streaming lib uses standard slow-start (exponential window growth) and congestion avoidance (linear window growth)
|
||||
phases. However, before the 0.6.1.33 release, window growth was substantially slower than optimal;
|
||||
these issues were fixed in release 0.6.1.33.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The interaction of the routing algorithms with the streaming lib strongly affects performance.
|
||||
In particular, random distribtion of messages to multiple tunnels in a pool
|
||||
@ -133,4 +139,45 @@ NTCP and SSU transport layers.
|
||||
See <a href="ntcp.html">the NTCP page</a> for a discussion.
|
||||
</p>
|
||||
|
||||
|
||||
<h2>Packet Format</h2>
|
||||
<p>
|
||||
Here is the format of a single packet transferred as part of a streaming connection.
|
||||
<ul>
|
||||
<li>sendStreamId [4 byte value]</li>
|
||||
<li>receiveStreamId [4 byte value]</li>
|
||||
<li>sequenceNum [4 byte unsigned integer]</li>
|
||||
<li>ackThrough [4 byte unsigned integer]</li>
|
||||
<li>number of NACKs [1 byte unsigned integer]</li>
|
||||
<li>that many NACKs</li>
|
||||
<li>resendDelay [1 byte integer]</li>
|
||||
<li>flags [2 byte value]</li>
|
||||
<li>option data size [2 byte integer]</li>
|
||||
<li>option data specified by those flags [0 or more bytes]</li>
|
||||
<li>payload [remaining packet size]</li>
|
||||
</ul>
|
||||
|
||||
<p>The flags field above specifies some metadata about the packet, and in
|
||||
turn may require certain additional data to be included. The flags are
|
||||
as follows (with any data structures specified added to the options area
|
||||
in the given order):</p><ol>
|
||||
<li>FLAG_SYNCHRONIZE: no option data</li>
|
||||
<li>FLAG_CLOSE: no option data</li>
|
||||
<li>FLAG_RESET: no option data</li>
|
||||
<li>FLAG_SIGNATURE_INCLUDED: net.i2p.data.Signature</li>
|
||||
<li>FLAG_SIGNATURE_REQUESTED: no option data</li>
|
||||
<li>FLAG_FROM_INCLUDED net.i2p.data.Destination</li>
|
||||
<li>FLAG_DELAY_REQUESTED: 1 byte integer</li>
|
||||
<li>FLAG_MAX_PACKET_SIZE_INCLUDED: 2 byte integer</li>
|
||||
<li>FLAG_PROFILE_INTERACTIVE: no option data</li>
|
||||
</ol>
|
||||
|
||||
<p>If the signature is included, it uses the Destination's DSA key
|
||||
to sign the entire header and payload with the space in the options
|
||||
for the signature being set to all zeroes.</p>
|
||||
|
||||
<p>If the sequenceNum is 0 and the SYN is not set, this is a plain ACK
|
||||
packet that should not be ACKed</p>
|
||||
|
||||
|
||||
{% endblock %}
|
||||
|
||||
Reference in New Issue
Block a user