From aa18ef23625e8151062adafc88bf6285f13b92f6 Mon Sep 17 00:00:00 2001
From: zzz While it may be redundant, just for clarity the
GPL'ed code included within
-I2PTunnel must be released under the GPL with an additional "exception"
+I2PTunnel and other apps must be released under the GPL with an additional "exception"
explicitly authorizing the use of Java's standard libraries:2007
2006
-
2005
-
2004
2007
2006
-
2005
-
2004
Long version: see the monotone page.
+
Cryptix
MIT
- jrandom
+ zzz
I2P Router
@@ -74,10 +74,10 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib
BSD
Cryptix
MIT
- jrandom
+ zzz
-
+ ministreaming
+ Ministreaming
apps/ministreaming
mstreaming.jar
@@ -88,6 +88,18 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib
MIT
mihi
+
Streaming
+ apps/streaming
+ streaming.jar
+
+ Public domain
+
+ BSD
+
+ Cryptix
+ MITzzz
+
+ I2PTunnel
apps/i2ptunnel
@@ -194,16 +206,43 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib
BSD
Ragnarok
+
+ I2PSnark
+ apps/i2psnark
+ i2psnark.jar
+
+ GPL + exception
+
+ zzz
+
+
+ Susidns
+ apps/susidns
+ susidns.war
+
+ GPL + exception
+
+
+
+
Susimail
+ apps/susimail
+ susimail.war
+
+ GPL + exception
+
+
+
Other apps not mentioned
apps/
...
- Public domain
- Cryptix
-
- BSD
- MITjrandom
+ probably
+ Public domain
+ but check the source
+
+
Installer
@@ -216,14 +255,14 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib
BSD
Cryptix
MIT
- jrandom
+
GPL + java exception
In addition, as a special exception, XXXX gives permission to link the
diff --git a/www.i2p2/pages/newdevelopers.html b/www.i2p2/pages/newdevelopers.html
index 495fca44..fa6b6db7 100644
--- a/www.i2p2/pages/newdevelopers.html
+++ b/www.i2p2/pages/newdevelopers.html
@@ -29,6 +29,12 @@ get the monotone source repository installed - short instructions:
0.7
-Late 2008
+Early 2009
copied from the tech intro
The streaming library has grown organically for I2P - first mihi implemented the "mini streaming library" as part of I2PTunnel, which was limited to a window @@ -29,8 +28,9 @@ size of 1 message (requiring an ACK before sending the next one), and then it wa refactored out into a generic streaming interface (mirroring TCP sockets) and the full streaming implementation was deployed with a sliding window protocol and optimizations to take into account the high bandwidth x delay product. Individual -streams may adjust the maximum packet size and other options, though the default -of 4KB compressed seems a reasonable tradeoff between the bandwidth costs of +streams may adjust the maximum packet size and other options. The default +message size is selected to fit precisely in two 1K I2NP tunnel messages, +and is a reasonable tradeoff between the bandwidth costs of retransmitting lost messages and the latency of multiple messages.
@@ -39,11 +39,11 @@ In addition, in consideration of the relatively high cost of subsequent messages the streaming library's protocol for scheduling and delivering messages has been optimized to allow individual messages passed to contain as much information as is available. For instance, a small HTTP transaction proxied through the streaming library can -be completed in a single round trip - the first message bundles a SYN, FIN, and -the small payload (an HTTP request typically fits) and the reply bundles the SYN, -FIN, ACK, and the small payload (many HTTP responses fit). While an additional +be completed in a single round trip - the first messages bundle a SYN, FIN, and +the small HTTP request payload, and the reply bundles the SYN, +FIN, ACK, and the HTTP response payload. While an additional ACK must be transmitted to tell the HTTP server that the SYN/FIN/ACK has been -received, the local HTTP proxy can deliver the full response to the browser +received, the local HTTP proxy can often deliver the full response to the browser immediately. @@ -84,8 +84,10 @@ it contains a full windowing implementation.Significant tuning of the streaming lib parameters, greatly increasing outbound performance, was implemented in 0.6.1.28. -After the changes in that release, the current default values -in the implementation are listed below. +Subsequent releases include additional tuning and bug fixes. +The current default values are listed below. +Lower case values are streaming lib parameters that can changed on a +per-connection basis. These values are tuned for HTTP performance over typical I2P conditions. Other applications such as peer-to-peer services are strongly encouraged to modify as necessary, by setting the options and passing them via the call to @@ -94,22 +96,27 @@ Time values are in ms.
+The maximum message size (also called the MTU / MRU) is negotiated to the lower value supported by +the two peers. As tunnel messages are padded to 1KB, a poor MTU selection will lead to +a large amount of overhead. +The MTU is chosen to fit precisely in an integral number of 1K I2NP tunnel messages, +including overhead for the typical case. +The first message in a connection includes a 387 byte (typical) Destination added by the streaming layer, +and usually a 898 byte (typical) LeaseSet bundled in the Garlic message. +Therefore, the goal of fitting a complete HTTP request in a single 1KB I2NP message is not realistic. +However, the selection of the MTU, together with careful implementation of fragmentation +and batching strategies in the tunnel gateway procesor, are important factors in network bandwidth, +latency, reliability, and efficiency, especially for long-lived connections. +
+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 @@ -128,9 +149,8 @@ In release 0.6.1.30, the routing of messages to the outbound tunnels was made consistent, with pushback when a tunnel was backlogged. This had a significant positive impact on bandwidths. The pushback code was reverted in release 0.6.1.31 due to anonymity concerns. -Consistent message routing to inbound tunnels is more difficult, -as there is currently no tracking in the code of the message source. -Perhaps to be implemented in 0.6.1.32. +Consistent message routing to inbound tunnels +was implemented in release 0.6.1.32.
@@ -144,8 +164,8 @@ See the NTCP page for a discussion.
Here is the format of a single packet transferred as part of a streaming connection.
If the sequenceNum is 0 and the SYN is not set, this is a plain ACK packet that should not be ACKed
++There are proposals to replace the streaming lib with standard TCP +(or perhaps a null layer together with raw sockets). +This would unfortunately be incompatible with the streaming lib +but it would be good to compare the performance of the two. +
{% endblock %}