- Proposed new I2CP options for 0.9.2

- I2NP Garlic clove/message clarifications
This commit is contained in:
zzz
2012-06-25 19:15:48 +00:00
parent f343b42edc
commit 6e9003be28
2 changed files with 49 additions and 2 deletions

View File

@ -79,6 +79,7 @@ The following options are traditionally passed to the router via
a <a href="i2cp_spec.html#type_SessionConfig">SessionConfig</a> contained in a <a href="i2cp_spec.html#msg_CreateSession">CreateSession Message</a> or a <a href="i2cp_spec.html#msg_ReconfigureSession">ReconfigureSession Message</a>.
<p>
<table border=1>
<tr><th colspan="5">Router-side Options</th></tr>
<tr><th>Option <th>Recommended Arguments <th>Allowable Range<th>Default<th>Description
<tr><td>inbound.quantity <td>number from 1 to 3 <td>1 to 16<td>2<td>Number of tunnels in.
Limit was increased from 6 to 16 in release 0.9; however, numbers higher than 6 are not
@ -116,6 +117,32 @@ a <a href="i2cp_spec.html#type_SessionConfig">SessionConfig</a> contained in a <
If the client is running in the same JVM as a router, this option is not required.
<tr><td>i2cp.password<td>string<td>&nbsp;<td>&nbsp;<td>For authorization, if required by the router (since 0.8.2).
If the client is running in the same JVM as a router, this option is not required.
<tr><td>crypto.tagsToSend<td>&nbsp;<td>1-128<td>40<td>Number of ElGamal/AES Session Tags to send at a time (since 0.9.2).
For clients with relatively low bandwidth per-client-pair (IRC, some UDP apps), this may be set lower.
<tr><td>crypto.lowTagThreshold<td>&nbsp;<td>1-128<td>30<td>Minimum number of ElGamal/AES Session Tags before we send more (since 0.9.2).
Recommended: approximately tagsToSend * 2/3
<tr><td>shouldBundleReplyInfo<td>true, false<td>&nbsp;<td>true<td>Set to false to disable ever bundling a reply LeaseSet (since 0.9.2).
For clients that do not publish their LeaseSet, this option must be true
for any reply to be possible. "true" is also recommended for multihomed servers
with long connection times.
<p> Setting to "false" may save significant outbound bandwidth, especially if
the client is configured with a large number of inbound tunnels (Leases).
If replies are still required, this may shift the bandwidth burden to
the far-end client and the floodfill.
There are several cases where "false" is may be appropriate:
<ul><li>
Unidirectional communication, no reply required
<li>
LeaseSet is published and higher reply latency is acceptable
<li>
LeaseSet is published, client is a "server", all connections are inbound
so the connecting far-end destination obviously has the leaseset already.
Connections are either short, or it is acceptable for latency on a long-lived
connection to temporarily increase while the other end re-fetches the LeaseSet
after expiration.
HTTP servers may fit these requirements.
</li></ul>
<tr><td>inbound.*<td>&nbsp;<td>&nbsp;<td>&nbsp;<td>Any other options prefixed with "inbound." are stored
in the "unknown options" properties of the inbound tunnel pool's settings.
<tr><td>outbound.*<td>&nbsp;<td>&nbsp;<td>&nbsp;<td>Any other options prefixed with "outbound." are stored
@ -134,6 +161,7 @@ and will be interpreted if passed to the I2PSession via the I2PClient.createSess
The streaming lib should also pass these options through to I2CP.
<p>
<table border=1>
<tr><th colspan="6">Client-side Options</th></tr>
<tr><th>Option <th>As Of Release<th>Recommended Arguments <th>Allowable Range<th>Default<th>Description
<tr><td>i2cp.tcp.host <td>&nbsp;<td>&nbsp;<td>&nbsp;<td>127.0.0.1<td>Router hostname.
If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.

View File

@ -2,7 +2,7 @@
{% block title %}I2NP Specification{% endblock %}
{% block content %}
Updated January 2012, current as of router version 0.8.12
Updated June 2012, current as of router version 0.9
<h1>I2P Network Protocol (I2NP) Specification</h1>
<p>
@ -366,10 +366,17 @@ Certificate :: Always NULL in the current implementation (3 bytes total, all zer
See also the <a href="how_garlicrouting.html">garlic routing specification</a>.
<li>
See also <a href="tunnel_message_spec.html#delivery">Delivery Instructions definition</a>
<li>
Maximum length is a function of the total length of all the cloves and the
maximum length of the GarlicMessage.
<li>
In the future, the certificate could possibly be used for a HashCash to "pay" for the routing.
<li>
The message is always a DataMessage?
The message can be any I2NP message (including a GarlicMessage, although that is not used in practice).
The messages used in practice are DataMessage, DeliveryStatusMessage, and DatabaseStoreMessage.
<li>
The Clove ID is generally set to a random number on transmit and is checked for
duplicates on receive (same message ID space as top-level Message IDs)
</ul>
@ -785,12 +792,24 @@ Expiration :: Date (8 bytes)
<ul>
<li>
When unencrypted, data contains one or more <a href="#struct_GarlicClove">Garlic Cloves</a>.
<li>
The AES encrypted block is padded to a minimum of 128 bytes; with the 32-byte Session Tag
the minimum size of the encrypted message is 160 bytes; with the 4 length bytes
the minimum size of the Garlic Message is 164 bytes.
<li>
Actual max length is less than 64 KB; see the <a href="i2np.html">I2NP Overview</a>.
<li>
See also the <a href="how_elgamalaes.html">ElGamal/AES specification</a>.
<li>
See also the <a href="how_garlicrouting.html">garlic routing specification</a>.
<li>
The 128 byte minimum size of the AES encrypted block is not currently configurable,
however the minimum size of a DataMessage in a GarlicClove in a GarlicMessage, with
overhead, is 128 bytes anyway. A configurable option to increase the minimum size
may be added in the future.
<li>
The message ID is generally set to a random number on transmit and
appears to be ignored on receive.
<li>
In the future, the certificate could possibly be used for a HashCash to "pay" for the routing.
</ul>