kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Added translation tags to docs/protocol/*

Browse Source
This commit is contained in:
str4d
2013-02-05 02:09:57 +00:00
parent de4e51e0b6
commit ad0f759014
3 changed files with 745 additions and 248 deletions
Download Patch File Download Diff File Expand all files Collapse all files

738
i2p2www/pages/site/docs/protocol/i2cp.html
View File

@@ -1,9 +1,10 @@
{% extends "global/layout.html" %}
{% block title %}I2CP{% endblock %}
{% block lastupdated %}November 2012{% endblock %}
{% block lastupdated %}{% trans %}November 2012{% endtrans %}{% endblock %}
{% block accuratefor %}0.9.3{% endblock %}
{% block content %}
<p>The I2P Client Protocol (I2CP) exposes a strong separation of concerns between
<p>{% trans -%}
The I2P Client Protocol (I2CP) exposes a strong separation of concerns between
the router and any client that wishes to communicate over the network. It enables
secure and asynchronous messaging by sending and receiving messages over a
single TCP socket, yet never exposing any private keys and authenticating itself
@@ -12,194 +13,580 @@ router who they are (their "destination"), what anonymity, reliability, and
latency tradeoffs to make, and where to send messages. In turn the router uses
I2CP to tell the client when any messages have arrived, and to request authorization
for some tunnels to be used.
</p>
{%- endtrans %}</p>
<p>
<p>{% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/client/package-summary.html' -%}
The protocol itself has only been implemented in Java, to provide the
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/client/package-summary.html">Client SDK</a>.
<a href="{{ url }}">Client SDK</a>.
This SDK is exposed in the i2p.jar package, which implements the client-side of I2CP.
Clients should never need to access the router.jar package, which contains the
router itself and the router-side of I2CP.
</p>
{%- endtrans %}</p>
<p>
<p>{% trans streaming=site_url('docs/api/streaming') -%}
While implementing the client side of I2CP in a non-Java language is certainly feasible,
a non-Java client would also have to implement the
<a href="{{ site_url('docs/api/streaming') }}">streaming library</a> for TCP-style connections.
<a href="{{ streaming }}">streaming library</a> for TCP-style connections.
Together, implementing I2CP and the streaming library would be a sizable task.
</p>
{%- endtrans %}</p>
<p>
<p>{% trans streaming=site_url('docs/api/streaming'), datagrams=site_url('docs/spec/datagrams'),
sam=site_url('docs/api/sam'), bob=site_url('docs/api/bob') -%}
Applications can take advantage of the base I2CP plus the
<a href="{{ site_url('docs/api/ministreaming') }}">streaming</a> and <a href="{{ site_url('docs/specs/datagrams') }}">datagram</a> libraries
by using the <a href="{{ site_url('docs/api/sam') }}">Simple Anonymous Messaging</a> or <a href="{{ site_url('docs/api/bob') }}">BOB</a> protocols,
<a href="{{ streaming }}">streaming</a> and <a href="{{ datagrams }}">datagram</a> libraries
by using the <a href="{{ sam }}">Simple Anonymous Messaging</a> or <a href="{{ bob }}">BOB</a> protocols,
which do not require clients to deal with any sort of cryptography.
Also, clients may access the network by one of several proxies -
HTTP, CONNECT, and SOCKS 4/4a/5.
Alternatively, Java clients may access those libraries in ministreaming.jar and streaming.jar.
So there are several options for both Java and non-Java applications.
</p>
{%- endtrans %}</p>
<p>Client-side end-to-end encryption (encrypting the data over the I2CP connection)
<p>{% trans elgamalaes=site_url('docs/how/elgamal-aes'),
cryptography=site_url('docs/how/cryptography'),
i2cp=site_url('docs/spec/i2cp') -%}
Client-side end-to-end encryption (encrypting the data over the I2CP connection)
was disabled in I2P release 0.6,
leaving in place the <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES end-to-end encryption</a>
leaving in place the <a href="{{ elgamalaes }}">ElGamal/AES end-to-end encryption</a>
which is implemented in the router.
The only cryptography that client libraries must still implement is
<a href="{{ site_url('docs/how/cryptography') }}#DSA">DSA public/private key signing</a>
for <a href="{{ site_url('docs/specs/i2cp') }}#msg_CreateLeaseSet">LeaseSets</a> and
<a href="{{ site_url('docs/specs/i2cp') }}#type_SessionConfig">Session Configurations</a>, and management of those keys.
</p>
<a href="{{ cryptography }}#DSA">DSA public/private key signing</a>
for <a href="{{ i2cp }}#msg_CreateLeaseSet">LeaseSets</a> and
<a href="{{ i2cp }}#struct_SessionConfig">Session Configurations</a>, and management of those keys.
{%- endtrans %}</p>
<p>In a standard I2P installation, port 7654 is used by external java clients to communicate
<p>{% trans -%}
In a standard I2P installation, port 7654 is used by external java clients to communicate
with the local router via I2CP.
By default, the router binds to address 127.0.0.1. To bind to 0.0.0.0, set the
router advanced configuration option <tt>i2cp.tcp.bindAllInterfaces=true</tt> and restart.
Clients in the same JVM as the router pass messages directly to the router
through an internal JVM interface.
</p>
{%- endtrans %}</p>
<h2>I2CP Protocol Specification</h2>
<p>
Now on the
<a href="{{ site_url('docs/specs/i2cp') }}">I2CP Specification page</a>.
</p>
<h2>{% trans %}I2CP Protocol Specification{% endtrans %}</h2>
<p>{% trans i2cp=site_url('docs/spec/i2cp') -%}
Now on the <a href="{{ i2cp }}">I2CP Specification page</a>.
{%- endtrans %}</p>
<h2>I2CP Initialization</h2>
<p>
<h2>{% trans %}I2CP Initialization{% endtrans %}</h2>
<p>{% trans i2cp=site_url('docs/spec/i2cp') -%}
When a client connects to the router, it first sends a single protocol version byte (0x2A).
Then it sends a <a href="{{ site_url('docs/specs/i2cp') }}#msg_GetDate">GetDate Message</a> and waits for the <a href="{{ site_url('docs/specs/i2cp') }}#msg_GetDate">SetDate Message</a> response.
Next, it sends a <a href="{{ site_url('docs/specs/i2cp') }}#msg_GetDate">CreateSession Message</a> containing the session configuration.
It next awaits a <a href="{{ site_url('docs/specs/i2cp') }}#msg_GetDate">RequestLeaseSet Message</a> from the router, indicating that inbound tunnels
Then it sends a <a href="{{ i2cp }}#msg_GetDate">GetDate Message</a> and waits for the <a href="{{ i2cp }}#msg_SetDate">SetDate Message</a> response.
Next, it sends a <a href="{{ i2cp }}#msg_CreateSession">CreateSession Message</a> containing the session configuration.
It next awaits a <a href="{{ i2cp }}#msg_RequestLeaseSet">RequestLeaseSet Message</a> from the router, indicating that inbound tunnels
have been built, and responds with a CreateLeaseSetMessage containing the signed LeaseSet.
The client may now initiate or receive connections from other I2P destinations.
{%- endtrans %}</p>
<h2 id="options">I2CP Options</h2>
<p>
<h2 id="options">{% trans %}I2CP Options{% endtrans %}</h2>
<p>{% trans i2cp=site_url('docs/spec/i2cp') -%}
The following options are traditionally passed to the router via
a <a href="{{ site_url('docs/specs/i2cp') }}#type_SessionConfig">SessionConfig</a> contained in a <a href="{{ site_url('docs/specs/i2cp') }}#msg_CreateSession">CreateSession Message</a> or a <a href="{{ site_url('docs/specs/i2cp') }}#msg_ReconfigureSession">ReconfigureSession Message</a>.
<p>
a <a href="{{ i2cp }}#struct_SessionConfig">SessionConfig</a> contained in a <a href="{{ i2cp }}#msg_CreateSession">CreateSession Message</a> or a <a href="{{ i2cp }}#msg_ReconfigureSession">ReconfigureSession Message</a>.
{%- endtrans %}</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
currently recommended, as this is untested and is incompatible with older releases.
<tr><td>outbound.quantity <td>number from 1 to 3 <td>No limit<td>2<td>Number of tunnels out
<tr><td>inbound.length <td>number from 0 to 3 <td>0 to 7<td>2<td>Length of tunnels in
<tr><td>outbound.length <td>number from 0 to 3 <td>0 to 7<td>2<td>Length of tunnels out
<tr><td>inbound.lengthVariance <td>number from -1 to 2 <td>-7 to 7<td>0<td>Random amount to add or subtract to the length of tunnels in.
A positive number x means add a random amount from 0 to x inclusive.
A negative number -x means add a random amount from -x to x inclusive.
The router will limit the total length of the tunnel to 0 to 7 inclusive.
The default variance was 1 prior to release 0.7.6.
<tr><td>outbound.lengthVariance <td>number from -1 to 2 <td>-7 to 7<td>0<td>Random amount to add or subtract to the length of tunnels out.
A positive number x means add a random amount from 0 to x inclusive.
A negative number -x means add a random amount from -x to x inclusive.
The router will limit the total length of the tunnel to 0 to 7 inclusive.
The default variance was 1 prior to release 0.7.6.
<tr><td>inbound.backupQuantity <td>number from 0 to 3 <td>No limit<td>0<td>Number of redundant fail-over for tunnels in
<tr><td>outbound.backupQuantity <td>number from 0 to 3 <td>No limit<td>0<td>Number of redundant fail-over for tunnels out
<tr><td>inbound.nickname <td>string<td>&nbsp;<td>&nbsp;<td>Name of tunnel - generally used in routerconsole, which will
use the first few characters of the Base64 hash of the destination by default.
<tr><td>outbound.nickname <td>string<td>&nbsp;<td>&nbsp;<td>Name of tunnel - generally ignored unless inbound.nickname is unset.
<tr><td>inbound.allowZeroHop <td>true, false<td>&nbsp;<td>true<td>If incoming zero hop tunnel is allowed
<tr><td>outbound.allowZeroHop <td>true, false<td>&nbsp;<td>true<td>If outgoing zero hop tunnel is allowed
<tr><td>inbound.IPRestriction <td>number from 0 to 4 <td>0 to 4<td>2<td>Number of IP bytes to match to determine if
two routers should not be in the same tunnel. 0 to disable.
<tr><td>outbound.IPRestriction <td>number from 0 to 4 <td>0 to 4<td>2<td>Number of IP bytes to match to determine if
two routers should not be in the same tunnel. 0 to disable.
<tr><td>outbound.priority<td>number from -25 to 25 <td>-25 to 25<td>0<td>Priority adjustment for outbound messages.
Higher is higher priority. As of 0.9.4.
<tr><td>i2cp.dontPublishLeaseSet <td>true, false<td>&nbsp;<td>false<td>Should generally be set to true for clients
and false for servers
<tr><td>i2cp.messageReliability <td>&nbsp;<td>BestEffort, None<td>BestEffort<td>Guaranteed is disabled;
None implemented in 0.8.1; the streaming lib default is None as of 0.8.1, the client side default is None as of 0.9.4
<tr><td>i2cp.fastReceive<td>&nbsp;<td>true, false<td>false<td>If true, the router just sends the MessagePayload instead
of sending a MessageStatus and awaiting a ReceiveMessageBegin.
As of 0.9.4
<tr><td>explicitPeers<td>&nbsp;<td>&nbsp;<td>null<td>Comma-separated list of Base 64 Hashes of peers to build tunnels through; for debugging only
<tr><td>i2cp.username<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>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.
<tr>
<th colspan="6">{% trans %}Router-side Options{% endtrans %}</th>
</tr>
<tr>
<th>{% trans %}Option{% endtrans %}</th>
<th>{% trans %}As Of Release{% endtrans %}</th>
<th>{% trans %}Recommended Arguments{% endtrans %}</th>
<th>{% trans %}Allowable Range{% endtrans %}</th>
<th>{% trans %}Default{% endtrans %}</th>
<th>{% trans %}Description{% endtrans %}</th>
</tr>
<tr>
<td>inbound.quantity</td>
<td>&nbsp;</td>
<td>{% trans from=1, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}</td>
<td>{% trans from=1, to=16 %}{{ from }} to {{ to }}{% endtrans %}</td>
<td>2</td>
<td>{% trans -%}
Number of tunnels in.
Limit was increased from 6 to 16 in release 0.9; however, numbers higher than 6 are not
currently recommended, as this is untested and is incompatible with older releases.
{%- endtrans %}</td>
</tr>
<tr>
<td>outbound.quantity
<td>&nbsp;</td>
<td>{% trans from=1, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}</td>
<td>{% trans %}No limit{% endtrans %}</td>
<td>2
<td>{% trans %}Number of tunnels out{% endtrans %}</td>
</tr>
<tr>
<td>inbound.length
<td>&nbsp;</td>
<td>{% trans from=0, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}</td>
<td>{% trans from=0, to=7 %}{{ from }} to {{ to }}{% endtrans %}</td>
<td>2
<td>{% trans %}Length of tunnels in{% endtrans %}</td>
</tr>
<tr>
<td>outbound.length
<td>&nbsp;</td>
<td>{% trans from=0, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}</td>
<td>{% trans from=0, to=7 %}{{ from }} to {{ to }}{% endtrans %}</td>
<td>2
<td>{% trans %}Length of tunnels out{% endtrans %}</td>
</tr>
<tr>
<td>inbound.lengthVariance
<td>&nbsp;</td>
<td>{% trans from=-1, to=2 %}number from {{ from }} to {{ to }}{% endtrans %}</td>
<td>{% trans from=-7, to=7 %}{{ from }} to {{ to }}{% endtrans %}</td>
<td>0
<td>{% trans -%}
Random amount to add or subtract to the length of tunnels in.
A positive number x means add a random amount from 0 to x inclusive.
A negative number -x means add a random amount from -x to x inclusive.
The router will limit the total length of the tunnel to 0 to 7 inclusive.
The default variance was 1 prior to release 0.7.6.
{%- endtrans %}</td>
</tr>
<tr>
<td>outbound.lengthVariance
<td>&nbsp;</td>
<td>{% trans from=-1, to=2 %}number from {{ from }} to {{ to }}{% endtrans %}</td>
<td>{% trans from=-7, to=7 %}{{ from }} to {{ to }}{% endtrans %}</td>
<td>0
<td>{% trans -%}
Random amount to add or subtract to the length of tunnels out.
A positive number x means add a random amount from 0 to x inclusive.
A negative number -x means add a random amount from -x to x inclusive.
The router will limit the total length of the tunnel to 0 to 7 inclusive.
The default variance was 1 prior to release 0.7.6.
{%- endtrans %}</td>
</tr>
<tr>
<td>inbound.backupQuantity
<td>&nbsp;</td>
<td>{% trans from=0, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}</td>
<td>{% trans %}No limit{% endtrans %}</td>
<td>0
<td>{% trans %}Number of redundant fail-over for tunnels in{% endtrans %}</td>
</tr>
<tr>
<td>outbound.backupQuantity
<td>&nbsp;</td>
<td>{% trans from=0, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}</td>
<td>{% trans %}No limit{% endtrans %}</td>
<td>0
<td>{% trans %}Number of redundant fail-over for tunnels out{% endtrans %}</td>
</tr>
<tr>
<td>inbound.nickname
<td>&nbsp;</td>
<td>string
<td>&nbsp;
<td>&nbsp;
<td>{% trans -%}
Name of tunnel - generally used in routerconsole, which will
use the first few characters of the Base64 hash of the destination by default.
{%- endtrans %}</td>
</tr>
<tr>
<td>outbound.nickname
<td>&nbsp;</td>
<td>string
<td>&nbsp;
<td>&nbsp;
<td>{% trans %}Name of tunnel - generally ignored unless inbound.nickname is unset.{% endtrans %}</td>
</tr>
<tr>
<td>inbound.allowZeroHop
<td>&nbsp;</td>
<td>true, false
<td>&nbsp;
<td>true
<td>{% trans %}If incoming zero hop tunnel is allowed{% endtrans %}</td>
</tr>
<tr>
<td>outbound.allowZeroHop
<td>&nbsp;</td>
<td>true, false
<td>&nbsp;
<td>true
<td>{% trans %}If outgoing zero hop tunnel is allowed{% endtrans %}</td>
</tr>
<tr>
<td>inbound.IPRestriction
<td>&nbsp;</td>
<td>{% trans from=0, to=4 %}number from {{ from }} to {{ to }}{% endtrans %}</td>
<td>{% trans from=0, to=4 %}{{ from }} to {{ to }}{% endtrans %}</td>
<td>2
<td>{% trans -%}
Number of IP bytes to match to determine if
two routers should not be in the same tunnel. 0 to disable.
{%- endtrans %}</td>
</tr>
<tr>
<td>outbound.IPRestriction
<td>&nbsp;</td>
<td>{% trans from=0, to=4 %}number from {{ from }} to {{ to }}{% endtrans %}</td>
<td>{% trans from=0, to=4 %}{{ from }} to {{ to }}{% endtrans %}</td>
<td>2
<td>{% trans -%}
Number of IP bytes to match to determine if
two routers should not be in the same tunnel. 0 to disable.
{%- endtrans %}</td>
</tr>
<tr>
<td>outbound.priority
<td>0.9.4</td>
<td>{% trans from=-25, to=25 %}number from {{ from }} to {{ to }}{% endtrans %}</td>
<td>{% trans from=-25, to=25 %}{{ from }} to {{ to }}{% endtrans %}</td>
<td>0
<td>{% trans -%}
Priority adjustment for outbound messages.
Higher is higher priority.
{%- endtrans %}</td>
</tr>
<tr>
<td>i2cp.dontPublishLeaseSet
<td>&nbsp;</td>
<td>true, false
<td>&nbsp;
<td>false
<td>{% trans %}Should generally be set to true for clients and false for servers{% endtrans %}</td>
</tr>
<tr>
<td>i2cp.messageReliability
<td>&nbsp;</td>
<td>&nbsp;
<td>BestEffort, None
<td>BestEffort
<td>{% trans -%}
Guaranteed is disabled;
None implemented in 0.8.1; the streaming lib default is None as of 0.8.1, the client side default is None as of 0.9.4
{%- endtrans %}</td>
</tr>
<tr>
<td>i2cp.fastReceive
<td>0.9.4</td>
<td>&nbsp;
<td>true, false
<td>false
<td>{% trans -%}
If true, the router just sends the MessagePayload instead
of sending a MessageStatus and awaiting a ReceiveMessageBegin.
{%- endtrans %}</td>
</tr>
<tr>
<td>explicitPeers
<td>&nbsp;</td>
<td>&nbsp;
<td>&nbsp;
<td>null
<td>{% trans %}Comma-separated list of Base 64 Hashes of peers to build tunnels through; for debugging only{% endtrans %}</td>
</tr>
<tr>
<td>i2cp.username
<td>0.8.2</td>
<td>string
<td>&nbsp;
<td>&nbsp;
<td>{% trans -%}
For authorization, if required by the router.
If the client is running in the same JVM as a router, this option is not required.
{%- endtrans %}</td>
</tr>
<tr>
<td>i2cp.password
<td>0.8.2</td>
<td>string
<td>&nbsp;
<td>&nbsp;
<td>{% trans -%}
For authorization, if required by the router.
If the client is running in the same JVM as a router, this option is not required.
{%- endtrans %}</td>
</tr>
<tr>
<td>crypto.tagsToSend
<td>0.9.2</td>
<td>&nbsp;
<td>1-128
<td>40
<td>{% trans -%}
Number of ElGamal/AES Session Tags to send at a time.
For clients with relatively low bandwidth per-client-pair (IRC, some UDP apps), this may be set lower.
{%- endtrans %}</td>
</tr>
<tr>
<td>crypto.lowTagThreshold
<td>0.9.2</td>
<td>&nbsp;
<td>1-128
<td>30
<td>{% trans -%}
Minimum number of ElGamal/AES Session Tags before we send more.
Recommended: approximately tagsToSend * 2/3
{%- endtrans %}</td>
</tr>
<tr>
<td>shouldBundleReplyInfo
<td>0.9.2</td>
<td>true, false
<td>&nbsp;
<td>true
<td>{% trans -%}
Set to false to disable ever bundling a reply LeaseSet.
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.
{%- endtrans %}
<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" 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
in the "unknown options" properties of the outbound tunnel pool's settings.
<p>{% trans -%}
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" may be appropriate:
{%- endtrans %}</p>
<ul>
<li>{% trans %}Unidirectional communication, no reply required{% endtrans %}</li>
<li>{% trans %}LeaseSet is published and higher reply latency is acceptable{% endtrans %}</li>
<li>{% trans -%}
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.
{%- endtrans %}</li>
</ul>
</td>
</tr>
<tr>
<td>inbound.*
<td>&nbsp;</td>
<td>&nbsp;
<td>&nbsp;
<td>&nbsp;
<td>{% trans -%}
Any other options prefixed with "inbound." are stored
in the "unknown options" properties of the inbound tunnel pool's settings.
{%- endtrans %}</td>
</tr>
<tr>
<td>outbound.*
<td>&nbsp;</td>
<td>&nbsp;
<td>&nbsp;
<td>&nbsp;
<td>{% trans -%}
Any other options prefixed with "outbound." are stored
in the "unknown options" properties of the outbound tunnel pool's settings.
{%- endtrans %}</td>
</tr>
</table>
<p>
<p>{% trans -%}
Note: Large quantity, length, or variance settings may cause significant performance or reliability problems.
<p>
{%- endtrans %}</p>
<p>{% trans -%}
Note: As of release 0.7.7, option names and values must use UTF-8 encoding.
This is primarily useful for nicknames.
Prior to that release, options with multi-byte characters were corrupted.
{%- endtrans %}</p>
<p>
<p>{% trans -%}
The following options are interpreted on the client side,
and will be interpreted if passed to the I2PSession via the I2PClient.createSession() call.
The streaming lib should also pass these options through to I2CP.
Other implementations may have different defaults.
<p>
{%- endtrans %}</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.
<tr><td>i2cp.tcp.port <td>&nbsp;<td>&nbsp;<td>1-65535<td>7654<td>Router I2CP port.
If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.
<tr><td>i2cp.SSL<td>0.8.3<td>true, false<td>&nbsp;<td>false<td>Connect to the router using SSL.
If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.
<tr><td>i2cp.gzip<td>0.6.5<td>true, false <td>&nbsp;<td>true<td>Gzip outbound data
<tr><td>i2cp.reduceOnIdle<td>0.7.1<td>true, false <td>&nbsp;<td>false<td>Reduce tunnel quantity when idle
<tr><td>i2cp.closeOnIdle<td>0.7.1<td>true, false <td>&nbsp;<td>false<td>Close I2P session when idle
<tr><td>i2cp.reduceIdleTime<td>0.7.1<td>1200000<td>300000 minimum<td>&nbsp;<td>(ms) Idle time required (default 20 minutes, minimum 5 minutes)
<tr><td>i2cp.closeIdleTime<td>0.7.1<td>1800000<td>300000 minimum<td>&nbsp;<td>(ms) Idle time required (default 30 minutes)
<tr><td>i2cp.reduceQuantity<td>0.7.1<td>1<td>1 to 5<td>1<td>Tunnel quantity when reduced (applies to both inbound and outbound)
<tr><td>i2cp.encryptLeaseSet<td>0.7.1<td>true, false <td>&nbsp;<td>false<td>Encrypt the lease
<tr><td>i2cp.leaseSetKey<td>0.7.1<td>&nbsp;<td>&nbsp;<td>&nbsp;<td>Base64 SessionKey (44 characters)
<tr><td>i2cp.messageReliability<td>&nbsp;<td>&nbsp;<td>BestEffort, None<td>None<td>Guaranteed is disabled;
None implemented in 0.8.1; None is the default as of 0.9.4
<tr><td>i2cp.fastReceive<td>0.9.4<td>&nbsp;<td>true, false<td>true<td>If true, the router just sends the MessagePayload instead
of sending a MessageStatus and awaiting a ReceiveMessageBegin.
<tr>
<th colspan="6">{% trans %}Client-side Options{% endtrans %}</th></tr>
</tr>
<tr>
<th>{% trans %}Option{% endtrans %}</th>
<th>{% trans %}As Of Release{% endtrans %}</th>
<th>{% trans %}Recommended Arguments{% endtrans %}</th>
<th>{% trans %}Allowable Range{% endtrans %}</th>
<th>{% trans %}Default{% endtrans %}</th>
<th>{% trans %}Description{% endtrans %}</th>
</tr>
<tr>
<td>i2cp.tcp.host
<td>&nbsp;
<td>&nbsp;
<td>&nbsp;
<td>127.0.0.1
<td>{% trans -%}
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.
{%- endtrans %}</td>
</tr>
<tr>
<td>i2cp.tcp.port
<td>&nbsp;
<td>&nbsp;
<td>1-65535
<td>7654
<td>{% trans -%}
Router I2CP port.
If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.
{%- endtrans %}</td>
</tr>
<tr>
<td>i2cp.SSL
<td>0.8.3
<td>true, false
<td>&nbsp;
<td>false
<td>{% trans -%}
Connect to the router using SSL.
If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally.
{%- endtrans %}</td>
</tr>
<tr>
<td>i2cp.gzip
<td>0.6.5
<td>true, false
<td>&nbsp;
<td>true
<td>{% trans %}Gzip outbound data{% endtrans %}</td>
</tr>
<tr>
<td>i2cp.reduceOnIdle
<td>0.7.1
<td>true, false
<td>&nbsp;
<td>false
<td>{% trans %}Reduce tunnel quantity when idle{% endtrans %}</td>
</tr>
<tr>
<td>i2cp.closeOnIdle
<td>0.7.1
<td>true, false
<td>&nbsp;
<td>false
<td>{% trans %}Close I2P session when idle{% endtrans %}</td>
</tr>
<tr>
<td>i2cp.reduceIdleTime
<td>0.7.1
<td>1200000
<td>{% trans num=300000 %}{{ num }} minimum{% endtrans %}
<td>&nbsp;
<td>{% trans %}(ms) Idle time required (default 20 minutes, minimum 5 minutes){% endtrans %}</td>
</tr>
<tr>
<td>i2cp.closeIdleTime
<td>0.7.1
<td>1800000
<td>{% trans num=300000 %}{{ num }} minimum{% endtrans %}
<td>&nbsp;
<td>{% trans %}(ms) Idle time required (default 30 minutes){% endtrans %}</td>
</tr>
<tr>
<td>i2cp.reduceQuantity
<td>0.7.1
<td>1
<td>{% trans from=1, to=5 %}{{ from }} to {{ to }}{% endtrans %}</td>
<td>1
<td>{% trans %}Tunnel quantity when reduced (applies to both inbound and outbound){% endtrans %}</td>
</tr>
<tr>
<td>i2cp.encryptLeaseSet
<td>0.7.1
<td>true, false
<td>&nbsp;
<td>false
<td>{% trans %}Encrypt the lease{% endtrans %}</td>
</tr>
<tr>
<td>i2cp.leaseSetKey
<td>0.7.1
<td>&nbsp;
<td>&nbsp;
<td>&nbsp;
<td>{% trans %}Base64 SessionKey (44 characters){% endtrans %}</td>
</tr>
<tr>
<td>i2cp.messageReliability
<td>&nbsp;
<td>&nbsp;
<td>BestEffort, None
<td>None
<td>{% trans -%}
Guaranteed is disabled;
None implemented in 0.8.1; None is the default as of 0.9.4
{%- endtrans %}</td>
</tr>
<tr>
<td>i2cp.fastReceive
<td>0.9.4
<td>&nbsp;
<td>true, false
<td>true
<td>{% trans -%}
If true, the router just sends the MessagePayload instead
of sending a MessageStatus and awaiting a ReceiveMessageBegin.
{%- endtrans %}</td>
</tr>
</table>
<p>
<p>{% trans -%}
Note: All arguments, including numbers, are strings. True/false values are case-insensitive strings.
Anything other than case-insensitive "true" is interpreted as false.
All option names are case-sensitive.
{%- endtrans %}</p>
<h2 id="format">I2CP Payload Data Format and Multiplexing</h2>
<p>
<h2 id="format">{% trans %}I2CP Payload Data Format and Multiplexing{% endtrans %}</h2>
<p>{% trans i2cp=site_url('docs/spec/i2cp') -%}
The end-to-end messages handled by I2CP (i.e. the data sent by the client in a
<a href="{{ site_url('docs/specs/i2cp') }}#msg_SendMessage">SendMessageMessage</a>
<a href="{{ i2cp }}#msg_SendMessage">SendMessageMessage</a>
and received by the client in a
<a href="{{ site_url('docs/specs/i2cp') }}#msg_MessagePayload">MessagePayloadMessage</a>)
<a href="{{ i2cp }}#msg_MessagePayload">MessagePayloadMessage</a>)
are gzipped with a standard 10-byte gzip
header beginning with 0x1F 0x8B 0x08 as
specified by <a href="http://www.ietf.org/rfc/rfc1952.txt">RFC 1952</a>.
@@ -207,44 +594,83 @@ As of release 0.7.1, I2P uses ignored portions of the gzip header to include
protocol, from-port, and to-port information, thus supporting streaming and
datagrams on the same destination, and allowing query/response using datagrams
to work reliably in the presence of multiple channels.
<p>
{%- endtrans %}</p>
<p>{% trans -%}
The gzip function cannot be completely turned off, however setting i2cp.gzip=false
turns the gzip effort setting to 0, which may save a little CPU.
<p>
{%- endtrans %}</p>
<table border=1>
<tr><th>Bytes<th>Content
<tr><td>0-2<td>Gzip header 0x1F 0x8B 0x08
<tr><td>3<td>Gzip flags
<tr><td>4-5<td>I2P Source port (Gzip mtime)
<tr><td>6-7<td>I2P Destination port (Gzip mtime)
<tr><td>8<td>Gzip xflags
<tr><td>9<td>I2P Protocol (6 = Streaming, 17 = Datagram, 18 = Raw Datagrams) (Gzip OS)
<tr>
<th>{% trans %}Bytes{% endtrans %}</th>
<th>{% trans %}Content{% endtrans %}</th>
</tr>
<tr>
<td>0-2
<td>{% trans %}Gzip header{% endtrans %} 0x1F 0x8B 0x08</th>
</tr>
<tr>
<td>3
<td>{% trans %}Gzip flags{% endtrans %}</td>
</tr>
<tr>
<td>4-5
<td>{% trans %}I2P Source port (Gzip mtime){% endtrans %}</td>
</tr>
<tr>
<td>6-7
<td>{% trans %}I2P Destination port (Gzip mtime){% endtrans %}</td>
</tr>
<tr>
<td>8
<td>{% trans %}Gzip xflags{% endtrans %}</td>
</tr>
<tr>
<td>9
<td>{% trans %}I2P Protocol (6 = Streaming, 17 = Datagram, 18 = Raw Datagrams) (Gzip OS){% endtrans %}</td>
</tr>
</table>
<p>
<p>{% trans -%}
Data integrity is verified with the standard gzip CRC-32 as
specified by <a href="http://www.ietf.org/rfc/rfc1952.txt">RFC 1952</a>.
</p>
{%- endtrans %}</p>
<h2 id="future">Future Work</h2>
<ul><li>
<h2 id="future">{% trans %}Future Work{% endtrans %}</h2>
<ul>
<li>{% trans -%}
Implement I2CP and the streaming library in another programming language.
</li><li>
{%- endtrans %}</li>
<li>{% trans -%}
Is the initial Get Date / Set Date handshake required?
</li><li>
{%- endtrans %}</li>
<li>{% trans -%}
The current authorization mechanism could be modified to use hashed passwords.
</li><li>
{%- endtrans %}</li>
<li>{% trans -%}
Private Keys are included in the Create Lease Set message,
are they really required? Revocation is unimplemented.
</li><li>
{%- endtrans %}</li>
<li>{% trans pdf1=url_for('static', filename='pdf/I2CP_spec.pdf'), pdf2=url_for('static', filename='pdf/datastructures.pdf') -%}
Some improvements may be able to use messages previously defined but not implemented.
For reference, here is the
<a href="{{ url_for('static', filename='pdf/I2CP_spec.pdf') }}">I2CP Protocol Specification Version 0.9</a>
<a href="{{ pdf1 }}">I2CP Protocol Specification Version 0.9</a>
(PDF) dated August 28, 2003.
That document also references the
<a href="{{ url_for('static', filename='pdf/datastructures.pdf') }}">Common Data Structures Specification Version 0.9</a>.
</li></ul>
<a href="{{ pdf2 }}">Common Data Structures Specification Version 0.9</a>.
{%- endtrans %}</li>
</ul>

156
i2p2www/pages/site/docs/protocol/i2np.html
View File

@@ -1,24 +1,26 @@
{% extends "global/layout.html" %}
{% block title %}I2NP{% endblock %}
{% block lastupdated %}August 2010{% endblock %}
{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %}
{% block accuratefor %}0.8{% endblock %}
{% block content %}
<h2>I2P Network Protocol (I2NP)</h2>
<p>
<h2>{% trans %}I2P Network Protocol{% endtrans %} (I2NP)</h2>
<p>{% trans -%}
The I2P Network Protocol (I2NP),
which is sandwiched between I2CP and the various I2P transport protocols, manages the
routing and mixing of messages between routers, as well as the selection of what
transports to use when communicating with a peer for which there are multiple
common transports supported.
</p>
{%- endtrans %}</p>
<h3>I2NP Definition</h3>
<p>
<h3>{% trans %}I2NP Definition{% endtrans %}</h3>
<p>{% trans -%}
I2NP (I2P Network Protocol) messages can be used for one-hop, router-to-router, point-to-point messages.
By encrypting and wrapping messages in other messages, they can be sent in a secure way
through multiple hops to the ultimate destination.
Priority is only used locally at the origin, i.e. when queuing for outbound delivery.
<p>
{%- endtrans %}</p>
<p>{% trans -%}
Both the NTCP and UDP transports implement priority transmission,
but in quite different manners.
UDP has complex code with queues for each priority, however it treats
@@ -28,42 +30,49 @@ These are global queues for all peers.
NTCP has a trivial linear search for the highest priority within
each buffer for a particular peer.
This is much less effective.
{%- endtrans %}</p>
<h3>Message Format</h3>
<p>
<h3>{% trans %}Message Format{% endtrans %}</h3>
<table border=1>
<tr><th>Field<th>Bytes
<tr><td>Unique ID<td>4
<tr><td>Expiration<td>8
<tr><td>Payload Length<td>2
<tr><td>Checksum<td>1
<tr><td>Payload<td>0 - 61.2KB
<tr><th>{% trans %}Field{% endtrans %}</th><th>{% trans %}Bytes{% endtrans %}</th></tr>
<tr><td>{% trans %}Unique ID{% endtrans %}</td><td>4</td></tr>
<tr><td>{% trans %}Expiration{% endtrans %}</td><td>8</td></tr>
<tr><td>{% trans %}Payload Length{% endtrans %}</td><td>2</td></tr>
<tr><td>{% trans %}Checksum{% endtrans %}</td><td>1</td></tr>
<tr><td>{% trans %}Payload{% endtrans %}</td><td>0 - 61.2KB</td></tr>
</table>
<p>
<p>{% trans tunnelimpl=site_url('docs/tunnels/implementation') -%}
While the maximum payload size is nominally 64KB, the size is further constrained by the
method of fragmenting I2NP messages into multiple 1KB tunnel messages as described in
<a href="tunnel-alt.html">tunnel-alt.html</a>.
method of fragmenting I2NP messages into multiple 1KB tunnel messages as described on
<a href="{{ tunnelimpl }}">the tunnel implementation page</a>.
The maximum number of fragments is 64, and the message may not be perfectly aligned,
So the message must nominally fit in 63 fragments.
<p>
{%- endtrans %}</p>
<p>{% trans -%}
The maximum size of an initial fragment is 956 bytes (assuming TUNNEL delivery mode);
the maximum size of a follow-on fragment is 996 bytes.
Therefore the maximum size is approximately 956 + (62 * 996) = 62708 bytes, or 61.2 KB.
</p>
<p>
{%- endtrans %}</p>
<p>{% trans -%}
In addition, the transports may have additional restrictions.
NTCP currently limits to 16KB - 6 = 16378 bytes but this will be increased in a future release.
The SSU limit is approximately 32 KB.
<p>
{%- endtrans %}</p>
<p>{% trans -%}
Note that these are not the limits for datagrams that the client sees, as the
router may bundle a reply leaseset and/or session tags together with the client message
in a garlic message. The leaseset and tags together may add about 5.5KB.
Therefore the current datagram limit is about 10KB. This limit will be
increased in a future release.
{%- endtrans %}</p>
<h3>Message Types</h3>
<h3>{% trans %}Message Types{% endtrans %}</h3>
<p>{% trans -%}
Higher-numbered priority is higher priority.
The majority of traffic is TunnelDataMessages (priority 400),
so anything above 400 is essentially high priority, and
@@ -72,115 +81,162 @@ Note also that many of the messages are generally routed
through exploratory tunnels, not client tunnels, and
therefore may not be in the same queue unless the
first hops happen to be on the same peer.
<p>
{%- endtrans %}</p>
<p>{% trans -%}
Also, not all message types are sent unencrypted.
For example, when testing a tunnel, the router wraps a
DeliveryStatusMessage, which is wrapped in a GarlicMessage,
which is wrapped in a DataMessage.
<p>
{%- endtrans %}</p>
<table border=1>
<tr><th>Message<th>Type<th>Payload Length<th>Priority<th>Comments
<tr>
<th>{% trans %}Message{% endtrans %}</th>
<th>{% trans %}Type{% endtrans %}</th>
<th>{% trans %}Payload Length{% endtrans %}</th>
<th>{% trans %}Priority{% endtrans %}</th>
<th>{% trans %}Comments{% endtrans %}</th>
</tr>
<tr><td>
DatabaseLookupMessage
<td align=right>2
<td>&nbsp;
<td align=right>100/400
<td>400 normally; 100 if from HarvesterJob and sent directly;
<td>{% trans -%}
400 normally; 100 if from HarvesterJob and sent directly;
400 for a router lookup
{%- endtrans %}</td>
</tr>
<tr><td>
DatabaseSearchReplyMessage
<td align=right>3
<td align=right>Typ. 161
<td align=right>300
<td>Size is 65 + 32*(number of hashes) where typically, the hashes for
<td>{% trans -%}
Size is 65 + 32*(number of hashes) where typically, the hashes for
three floodfill routers are returned.
{%- endtrans %}</td>
</tr>
<tr><td>
DatabaseStoreMessage
<td align=right>1
<td align=right>Varies
<td align=right>{% trans %}Varies{% endtrans %}</td>
<td align=right>100/400
<td>Usually 100 (why?)
<td>{% trans -%}
Usually 100 (why?)
Size is 898 bytes for a typical 2-lease leaseSet.
RouterInfo structures are compressed, and size varies; however
there is a continuing effort to reduce the amount of data published in a RouterInfo
as we approach release 1.0.
{%- endtrans %}</td>
</tr>
<tr><td>
DataMessage
<td align=right>20
<td align=right>4 - 62080
<td align=right>400
<td>
</tr>
<tr><td>
DeliveryStatusMessage
<td align=right>10
<td align=right>12
<td>&nbsp;
<td>Used for message replies, and for testing tunnels - generally wrapped in a GarlicMessage
<td>{% trans %}Used for message replies, and for testing tunnels - generally wrapped in a GarlicMessage{% endtrans %}</td>
</tr>
<tr><td>
<a href="{{ site_url('docs/how/techintro') }}#op.garlic">GarlicMessage</a>
<a href="{{ site_url('docs/how/tech-intro') }}#op.garlic">GarlicMessage</a>
<td align=right>11
<td>&nbsp;
<td>&nbsp;
<td>Generally wrapped in a DataMessage -
<td>{% trans -%}
Generally wrapped in a DataMessage -
but when unwrapped, given a priority of 100 by the forwarding router
{%- endtrans %}</td>
</tr>
<tr><td>
<a href="tunnel-alt-creation.html#tunnelCreate.requestRecord">TunnelBuildMessage</a>
<a href="{{ site_url('docs/spec/tunnel-creation') }}#tunnelCreate.requestRecord">TunnelBuildMessage</a>
<td align=right>21
<td align=right>4224
<td align=right>300/500
<td>Usually 500 (why?)
<td>{% trans %}Usually 500 (why?){% endtrans %}</td>
</tr>
<tr><td>
<a href="tunnel-alt-creation.html#tunnelCreate.replyRecord">TunnelBuildReplyMessage</a>
<a href="{{ site_url('docs/spec/tunnel-creation') }}#tunnelCreate.replyRecord">TunnelBuildReplyMessage</a>
<td align=right>22
<td align=right>4224
<td align=right>300
<td>
</tr>
<tr><td>
TunnelDataMessage
<td align=right>18
<td align=right>1028
<td align=right>400
<td>The most common message. Priority for tunnel participants, outbound endpoints, and inbound gateways was
reduced to 200 as of release 0.6.1.33.
Outbound gateway messages (i.e. those originated locally) remains at 400.
<td>{% trans -%}
The most common message. Priority for tunnel participants, outbound endpoints, and inbound gateways was
reduced to 200 as of release 0.6.1.33.
Outbound gateway messages (i.e. those originated locally) remains at 400.
{%- endtrans %}</td>
</tr>
<tr><td>
TunnelGatewayMessage
<td align=right>19
<td>&nbsp;
<td align=right>300/400
<td>
</tr>
<tr><td>
VariableTunnelBuildMessage
<td align=right>23
<td align=right>1057 - 4225
<td align=right>300/500
<td>Shorter TunnelBuildMessage as of 0.7.12
<td>{% trans %}Shorter TunnelBuildMessage as of 0.7.12{% endtrans %}</td>
</tr>
<tr><td>
VariableTunnelBuildReplyMessage
<td align=right>24
<td align=right>1057 - 4225
<td align=right>300
<td>Shorter TunnelBuildReplyMessage as of 0.7.12
<tr><td>
Others listed in
<a href="{{ url_for('static', filename='pdf/I2NP_spec.pdf') }}">2003 Spec</a>
<td>{% trans %}Shorter TunnelBuildReplyMessage as of 0.7.12{% endtrans %}</td>
</tr>
<tr><td>{% trans pdf=url_for('static', filename='pdf/I2NP_spec.pdf') -%}
Others listed in <a href="{{ pdf }}">2003 Spec</a>
{%- endtrans %}
<td>0,4-9,12
<td>&nbsp;
<td>&nbsp;
<td>Obsolete, Unused
<td>{% trans %}Obsolete, Unused{% endtrans %}
</tr>
</table>
<h3>Full Protocol Specification</h3>
<a href="{{ site_url('docs/specs/i2np') }}">On the I2NP Specification page</a>.
<h3>{% trans %}Full Protocol Specification{% endtrans %}</h3>
<p>{% trans i2npspec=site_url('docs/specs/i2np'), commonstructures=site_url('docs/specs/common-structures') -%}
<a href="{{ i2npspec }}">On the I2NP Specification page</a>.
See also the
<a href="{{ site_url('docs/specs/common_structures') }}">Common Data Structure Specification page</a>.
<a href="{{ commonstructures }}">Common Data Structure Specification page</a>.
{%- endtrans %}</p>
<h3>Future Work</h3>
<p>
<h3>{% trans %}Future Work{% endtrans %}</h3>
<p>{% trans -%}
It isn't clear whether the current priority scheme is generally effective,
and whether the priorities for various messages should be adjusted further.
This is a topic for further research, analysis and testing.
{%- endtrans %}</p>
{% endblock %}

99
i2p2www/pages/site/docs/protocol/index.html
View File

@@ -1,73 +1,88 @@
{% extends "global/layout.html" %}
{% block title %}Protocol Stack{% endblock %}
{% block lastupdated %}August 2010{% endblock %}
{% block title %}{% trans %}Protocol Stack{% endtrans %}{% endblock %}
{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %}
{% block accuratefor %}0.8{% endblock %}
{% block content %}
<p>
<p>{% trans docs=site_url('docs') -%}
Here is the protocol stack for I2P.
See also the <a href="{{ site_url('docs/how') }}">Index to Technical Documentation</a>.
<p>
See also the <a href="{{ docs }}">Index to Technical Documentation</a>.
{%- endtrans %}</p>
<p>
<p>{% trans -%}
Each of the layers in the stack provides extra capabilities.
The capabilities are listed below, starting at the bottom of the protocol stack.
{%- endtrans %}</p>
<ul>
<li>
<b>Internet Layer:</b>
<b>{% trans %}Internet Layer:{% endtrans %}</b>
<br />
IP: Internet Protocol, allow addressing hosts on the regular internet and routing packets across the internet using best-effort delivery.
{% trans %}IP: Internet Protocol, allow addressing hosts on the regular internet and routing packets across the internet using best-effort delivery.{% endtrans %}
</li>
<li>
<b>Transport Layer:</b>
<b>{% trans %}Transport Layer:{% endtrans %}</b>
<br />
TCP: Transmission Control Protocol, allow reliable, in-order delivery of packets across the internet.
{% trans %}TCP: Transmission Control Protocol, allow reliable, in-order delivery of packets across the internet.{% endtrans %}
<br />
UDP: User Datagram Protocol, allow unreliable, out-of-order delivery of packets across the internet.
{% trans %}UDP: User Datagram Protocol, allow unreliable, out-of-order delivery of packets across the internet.{% endtrans %}
</li>
<li>
<b>I2P Transport Layer:</b> provide encrypted connections between 2 I2P routers. These are not anonymous yet, this is strictly a hop-to-hop connection.
Two protocols are implemented to provide these capabilities. NTCP builds on top of TCP, while SSU uses UDP.
{% trans -%}
<b>I2P Transport Layer:</b> provide encrypted connections between 2 I2P routers. These are not anonymous yet, this is strictly a hop-to-hop connection.
Two protocols are implemented to provide these capabilities. NTCP builds on top of TCP, while SSU uses UDP.
{%- endtrans %}
<br />
<a href="{{ site_url('docs/transport/ntcp') }}">NTCP</a>: NIO-based TCP
<a href="{{ site_url('docs/transport/ntcp') }}">NTCP</a>: {% trans %}NIO-based TCP{% endtrans %}
<br />
<a href="{{ site_url('docs/transport/ssu') }}">SSU</a>: Secure Semi-reliable UDP
<a href="{{ site_url('docs/transport/ssu') }}">SSU</a>: {% trans %}Secure Semi-reliable UDP{% endtrans %}
</li>
<li>
<b>I2P Tunnel Layer:</b> provide full encrypted tunnel connections.
{% trans %}<b>I2P Tunnel Layer:</b> provide full encrypted tunnel connections.{% endtrans %}
<br />
<a href="tunnel_message_spec.html">Tunnel messages</a>: tunnel messages are large messages containing encrypted I2NP (see below) messages and encrypted instructions for their delivery.
The encryption is layered. The first hop will decrypt the tunnel message and read a part. Another part can still be encrypted (with another key),
so it will be forwarded.
{% trans tunnelmessage=site_url('docs/spec/tunnel-message') -%}
<a href="{{ tunnelmessage }}">Tunnel messages</a>: tunnel messages are large messages containing encrypted I2NP (see below) messages and encrypted instructions for their delivery.
The encryption is layered. The first hop will decrypt the tunnel message and read a part. Another part can still be encrypted (with another key),
so it will be forwarded.
{%- endtrans %}
<br />
<a href="{{ site_url('docs/protocol/i2np') }}">I2NP messages</a>: I2P Network Protocol messages are used to pass messages through multiple routers. These I2NP messages are combined in tunnel messages.
{% trans i2np=site_url('docs/protocol/i2np') -%}
<a href="{{ i2np }}">I2NP messages</a>: I2P Network Protocol messages are used to pass messages through multiple routers. These I2NP messages are combined in tunnel messages.
{%- endtrans %}
</li>
<li>
<b>I2P Garlic Layer:</b> provide encrypted and anonymous end-to-end I2P message delivery.
{% trans %}<b>I2P Garlic Layer:</b> provide encrypted and anonymous end-to-end I2P message delivery.{% endtrans %}
<br />
<a href="{{ site_url('docs/protocol/i2np') }}">I2NP messages</a>: I2P Network Protocol messages are wrapped in each other and used to ensure encryption between two tunnels and are passed along from source to destination, keeping both anonymous.
{% trans i2np=site_url('docs/protocol/i2np') -%}
<a href="{{ i2np }}">I2NP messages</a>: I2P Network Protocol messages are wrapped in each other and used to ensure encryption between two tunnels and are passed along from source to destination, keeping both anonymous.
{%- endtrans %}
</li>
</ul>
</p>
<p>
<p>{% trans -%}
The following layers are strictly speaking no longer part of the I2P Protocol stack, they are not part of the core 'I2P router' functionality.
However, each of these layers adds additional functionality, to allow applications simple and convenient I2P usage.
{%- endtrans %}</p>
<ul>
<li>
<b>I2P Client Layer:</b> allow any client to use I2P functionality, without requiring the direct use of the router API.
{% trans %}<b>I2P Client Layer:</b> allow any client to use I2P functionality, without requiring the direct use of the router API.{% endtrans %}
<br />
<a href="{{ site_url('docs/protocol/i2cp') }}">I2CP</a>: I2P Client Protocol, allows secure and asynchronous messaging over I2P by communicating messages over the I2CP TCP socket.
{% trans i2cp=site_url('docs/protocol/i2cp') -%}
<a href="{{ i2cp }}">I2CP</a>: I2P Client Protocol, allows secure and asynchronous messaging over I2P by communicating messages over the I2CP TCP socket.
{%- endtrans %}
</li>
<li>
<b>I2P End-to-end Transport Layer:</b> allow TCP- or UDP-like functionality on top of I2P.
{% trans %}<b>I2P End-to-end Transport Layer:</b> allow TCP- or UDP-like functionality on top of I2P.{% endtrans %}
<br />
<a href="{{ site_url('docs/api/streaming') }}">Streaming Library</a>: an implementation of TCP-like streams over I2P. This allows easier porting of existing applications to I2P.
{% trans streaming=site_url('docs/api/streaming') -%}
<a href="{{ streaming }}">Streaming Library</a>: an implementation of TCP-like streams over I2P. This allows easier porting of existing applications to I2P.
{%- endtrans %}
<br />
<a href="{{ site_url('docs/spec/datagrams') }}">Datagram Library</a>: an implementation of UDP-like messages over I2P. This allows easier porting of existing applications to I2P.
{% trans datagrams=site_url('docs/spec/datagrams') -%}
<a href="{{ datagrams }}">Datagram Library</a>: an implementation of UDP-like messages over I2P. This allows easier porting of existing applications to I2P.
{%- endtrans %}
</li>
<li>
<b>I2P Application Interface Layer:</b> additional (optional) libraries allowing easier implementations on top of I2P.
{% trans %}<b>I2P Application Interface Layer:</b> additional (optional) libraries allowing easier implementations on top of I2P.{% endtrans %}
<br />
<a href="{{ site_url('docs/api/i2ptunnel') }}">I2PTunnel</a>
<br />
@@ -75,32 +90,32 @@ However, each of these layers adds additional functionality, to allow applicatio
<a href="{{ site_url('docs/api/bob') }}">BOB</a>
</li>
<li>
<b>I2P Application Proxy Layer:</b> proxy systems.
{% trans %}<b>I2P Application Proxy Layer:</b> proxy systems.{% endtrans %}
<br />
HTTP Client/Server, IRC Client, <a href="{{ site_url('docs/api/socks') }}">SOCKS</a>, Streamr
{% trans socks=site_url('docs/api/socks') %}HTTP Client/Server, IRC Client, <a href="{{ socks }}">SOCKS</a>, Streamr{% endtrans %}
</li>
</ul>
</p>
<p>
<p>{% trans -%}
Finally, what could be considered the <b>'I2P application layer'</b>, is a large number of applications on top of I2P.
We can order this based on the I2P stack layer they use.
{%- endtrans %}</p>
<ul>
<li><b>Streaming/datagram applications</b>: i2psnark, Syndie, i2phex...</li>
<li><b>SAM/BOB applications</b>: IMule, i2p-bt, i2prufus, Robert...</li>
<li><b>Other I2P applications</b>: Syndie, EepGet, <a href="{{ site_url('docs/plugins') }}">plugins...</a></li>
<li><b>Regular applications</b>: Jetty, Apache, Monotone, CVS, browsers, e-mail...</li>
<li>{% trans %}<b>Streaming/datagram applications</b>: i2psnark, Syndie, i2phex...{% endtrans %}</li>
<li>{% trans %}<b>SAM/BOB applications</b>: IMule, i2p-bt, i2prufus, Robert...{% endtrans %}</li>
<li>{% trans plugins=site_url('docs/plugins') %}<b>Other I2P applications</b>: Syndie, EepGet, <a href="{{ plugins }}">plugins</a>...{% endtrans %}</li>
<li>{% trans %}<b>Regular applications</b>: Jetty, Apache, Monotone, CVS, browsers, e-mail...{% endtrans %}</li>
</ul>
</p>
<div class="box" style="text-align:center;">
<img src="{{ url_for('static', filename='images/protocol_stack.png') }}" alt="I2P Network stack" title="I2P Network stack" />
<img src="{{ url_for('static', filename='images/protocol_stack.png') }}" alt="{{ _('I2P Network stack') }}" title="{{ _('I2P Network stack') }}" />
<br /><br />
Figure 1: The layers in the I2P Network stack.
{% trans %}Figure 1: The layers in the I2P Network stack.{% endtrans %}
</div>
<br/>
<p>
* Note: SAM/SAMv2 can use both the streaming lib and datagrams.
* {% trans %}Note: SAM/SAMv2 can use both the streaming lib and datagrams.{% endtrans %}
</p>
{% endblock %}