- Proposed new I2CP options for 0.9.2
- I2NP Garlic clove/message clarifications
This commit is contained in:
@ -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> <td> <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> <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> <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> <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> <td> <td> <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> <td> <td> <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> <td> <td> <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.
|
||||
|
@ -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>
|
||||
|
Reference in New Issue
Block a user