From ad0f759014da8dcc717aec2765de00fa000b089b Mon Sep 17 00:00:00 2001 From: str4d Date: Tue, 5 Feb 2013 02:09:57 +0000 Subject: [PATCH] Added translation tags to docs/protocol/* --- i2p2www/pages/site/docs/protocol/i2cp.html | 738 +++++++++++++++----- i2p2www/pages/site/docs/protocol/i2np.html | 156 +++-- i2p2www/pages/site/docs/protocol/index.html | 99 +-- 3 files changed, 745 insertions(+), 248 deletions(-) diff --git a/i2p2www/pages/site/docs/protocol/i2cp.html b/i2p2www/pages/site/docs/protocol/i2cp.html index 26eeca40..00f4eb96 100644 --- a/i2p2www/pages/site/docs/protocol/i2cp.html +++ b/i2p2www/pages/site/docs/protocol/i2cp.html @@ -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 %} -

The I2P Client Protocol (I2CP) exposes a strong separation of concerns between +

{% 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. -

+{%- endtrans %}

-

+

{% 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 -Client SDK. +Client SDK. 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. -

+{%- endtrans %}

-

+

{% 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 -streaming library for TCP-style connections. +streaming library for TCP-style connections. Together, implementing I2CP and the streaming library would be a sizable task. -

+{%- endtrans %}

-

+

{% 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 -streaming and datagram libraries -by using the Simple Anonymous Messaging or BOB protocols, +streaming and datagram libraries +by using the Simple Anonymous Messaging or BOB 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. -

+{%- endtrans %}

-

Client-side end-to-end encryption (encrypting the data over the I2CP connection) +

{% 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 ElGamal/AES end-to-end encryption +leaving in place the ElGamal/AES end-to-end encryption which is implemented in the router. The only cryptography that client libraries must still implement is -DSA public/private key signing -for LeaseSets and -Session Configurations, and management of those keys. -

+DSA public/private key signing +for LeaseSets and +Session Configurations, and management of those keys. +{%- endtrans %}

-

In a standard I2P installation, port 7654 is used by external java clients to communicate +

{% 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 i2cp.tcp.bindAllInterfaces=true and restart. Clients in the same JVM as the router pass messages directly to the router through an internal JVM interface. -

+{%- endtrans %}

-

I2CP Protocol Specification

-

-Now on the -I2CP Specification page. -

+

{% trans %}I2CP Protocol Specification{% endtrans %}

+

{% trans i2cp=site_url('docs/spec/i2cp') -%} +Now on the I2CP Specification page. +{%- endtrans %}

-

I2CP Initialization

-

+

{% trans %}I2CP Initialization{% endtrans %}

+

{% 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 GetDate Message and waits for the SetDate Message response. -Next, it sends a CreateSession Message containing the session configuration. -It next awaits a RequestLeaseSet Message from the router, indicating that inbound tunnels +Then it sends a GetDate Message and waits for the SetDate Message response. +Next, it sends a CreateSession Message containing the session configuration. +It next awaits a RequestLeaseSet Message 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 %}

-

I2CP Options

-

+

{% trans %}I2CP Options{% endtrans %}

+

{% trans i2cp=site_url('docs/spec/i2cp') -%} The following options are traditionally passed to the router via -a SessionConfig contained in a CreateSession Message or a ReconfigureSession Message. -

+a SessionConfig contained in a CreateSession Message or a ReconfigureSession Message. +{%- endtrans %}

- - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Router-side Options
Option Recommended Arguments Allowable RangeDefaultDescription -
inbound.quantity number from 1 to 3 1 to 162Number 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. -
outbound.quantity number from 1 to 3 No limit2Number of tunnels out -
inbound.length number from 0 to 3 0 to 72Length of tunnels in -
outbound.length number from 0 to 3 0 to 72Length of tunnels out -
inbound.lengthVariance number from -1 to 2 -7 to 70Random 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. -
outbound.lengthVariance number from -1 to 2 -7 to 70Random 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. -
inbound.backupQuantity number from 0 to 3 No limit0Number of redundant fail-over for tunnels in -
outbound.backupQuantity number from 0 to 3 No limit0Number of redundant fail-over for tunnels out -
inbound.nickname string  Name of tunnel - generally used in routerconsole, which will - use the first few characters of the Base64 hash of the destination by default. -
outbound.nickname string  Name of tunnel - generally ignored unless inbound.nickname is unset. -
inbound.allowZeroHop true, false trueIf incoming zero hop tunnel is allowed -
outbound.allowZeroHop true, false trueIf outgoing zero hop tunnel is allowed -
inbound.IPRestriction number from 0 to 4 0 to 42Number of IP bytes to match to determine if - two routers should not be in the same tunnel. 0 to disable. -
outbound.IPRestriction number from 0 to 4 0 to 42Number of IP bytes to match to determine if - two routers should not be in the same tunnel. 0 to disable. -
outbound.prioritynumber from -25 to 25 -25 to 250Priority adjustment for outbound messages. - Higher is higher priority. As of 0.9.4. -
i2cp.dontPublishLeaseSet true, false falseShould generally be set to true for clients - and false for servers -
i2cp.messageReliability  BestEffort, NoneBestEffortGuaranteed 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 -
i2cp.fastReceive true, falsefalseIf true, the router just sends the MessagePayload instead - of sending a MessageStatus and awaiting a ReceiveMessageBegin. - As of 0.9.4 -
explicitPeers  nullComma-separated list of Base 64 Hashes of peers to build tunnels through; for debugging only -
i2cp.usernamestring  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. -
i2cp.passwordstring  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. -
crypto.tagsToSend 1-12840Number 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. -
crypto.lowTagThreshold 1-12830Minimum number of ElGamal/AES Session Tags before we send more (since 0.9.2). - Recommended: approximately tagsToSend * 2/3 -
shouldBundleReplyInfotrue, false trueSet 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. +
{% trans %}Router-side Options{% endtrans %}
{% trans %}Option{% endtrans %}{% trans %}As Of Release{% endtrans %}{% trans %}Recommended Arguments{% endtrans %}{% trans %}Allowable Range{% endtrans %}{% trans %}Default{% endtrans %}{% trans %}Description{% endtrans %}
inbound.quantity {% trans from=1, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=1, to=16 %}{{ from }} to {{ to }}{% endtrans %}2{% 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 %}
outbound.quantity + {% trans from=1, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans %}No limit{% endtrans %}2 +{% trans %}Number of tunnels out{% endtrans %}
inbound.length + {% trans from=0, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=0, to=7 %}{{ from }} to {{ to }}{% endtrans %}2 +{% trans %}Length of tunnels in{% endtrans %}
outbound.length + {% trans from=0, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=0, to=7 %}{{ from }} to {{ to }}{% endtrans %}2 +{% trans %}Length of tunnels out{% endtrans %}
inbound.lengthVariance + {% trans from=-1, to=2 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=-7, to=7 %}{{ from }} to {{ to }}{% endtrans %}0 +{% 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 %}
outbound.lengthVariance + {% trans from=-1, to=2 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=-7, to=7 %}{{ from }} to {{ to }}{% endtrans %}0 +{% 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 %}
inbound.backupQuantity + {% trans from=0, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans %}No limit{% endtrans %}0 +{% trans %}Number of redundant fail-over for tunnels in{% endtrans %}
outbound.backupQuantity + {% trans from=0, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans %}No limit{% endtrans %}0 +{% trans %}Number of redundant fail-over for tunnels out{% endtrans %}
inbound.nickname + string +  +  +{% 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 %}
outbound.nickname + string +  +  +{% trans %}Name of tunnel - generally ignored unless inbound.nickname is unset.{% endtrans %}
inbound.allowZeroHop + true, false +  +true +{% trans %}If incoming zero hop tunnel is allowed{% endtrans %}
outbound.allowZeroHop + true, false +  +true +{% trans %}If outgoing zero hop tunnel is allowed{% endtrans %}
inbound.IPRestriction + {% trans from=0, to=4 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=0, to=4 %}{{ from }} to {{ to }}{% endtrans %}2 +{% trans -%} +Number of IP bytes to match to determine if +two routers should not be in the same tunnel. 0 to disable. +{%- endtrans %}
outbound.IPRestriction + {% trans from=0, to=4 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=0, to=4 %}{{ from }} to {{ to }}{% endtrans %}2 +{% trans -%} +Number of IP bytes to match to determine if +two routers should not be in the same tunnel. 0 to disable. +{%- endtrans %}
outbound.priority +0.9.4{% trans from=-25, to=25 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=-25, to=25 %}{{ from }} to {{ to }}{% endtrans %}0 +{% trans -%} +Priority adjustment for outbound messages. +Higher is higher priority. +{%- endtrans %}
i2cp.dontPublishLeaseSet + true, false +  +false +{% trans %}Should generally be set to true for clients and false for servers{% endtrans %}
i2cp.messageReliability +   +BestEffort, None +BestEffort +{% 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 %}
i2cp.fastReceive +0.9.4  +true, false +false +{% trans -%} +If true, the router just sends the MessagePayload instead +of sending a MessageStatus and awaiting a ReceiveMessageBegin. +{%- endtrans %}
explicitPeers +   +  +null +{% trans %}Comma-separated list of Base 64 Hashes of peers to build tunnels through; for debugging only{% endtrans %}
i2cp.username +0.8.2string +  +  +{% 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 %}
i2cp.password +0.8.2string +  +  +{% 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 %}
crypto.tagsToSend +0.9.2  +1-128 +40 +{% 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 %}
crypto.lowTagThreshold +0.9.2  +1-128 +30 +{% trans -%} +Minimum number of ElGamal/AES Session Tags before we send more. +Recommended: approximately tagsToSend * 2/3 +{%- endtrans %}
shouldBundleReplyInfo +0.9.2true, false +  +true +{% 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 %} -

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: -

  • - Unidirectional communication, no reply required -
  • - LeaseSet is published and higher reply latency is acceptable -
  • - 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. -
-
inbound.*   Any other options prefixed with "inbound." are stored - in the "unknown options" properties of the inbound tunnel pool's settings. -
outbound.*   Any other options prefixed with "outbound." are stored - in the "unknown options" properties of the outbound tunnel pool's settings. +

{% 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 %}

+
    +
  • {% trans %}Unidirectional communication, no reply required{% endtrans %}
    • +
  • {% trans %}LeaseSet is published and higher reply latency is acceptable{% endtrans %}
    • +
  • {% 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 %}
    • +
+
inbound.* +   +  +  +{% trans -%} +Any other options prefixed with "inbound." are stored +in the "unknown options" properties of the inbound tunnel pool's settings. +{%- endtrans %}
outbound.* +   +  +  +{% trans -%} +Any other options prefixed with "outbound." are stored +in the "unknown options" properties of the outbound tunnel pool's settings. +{%- endtrans %}
-

+ +

{% trans -%} Note: Large quantity, length, or variance settings may cause significant performance or reliability problems. -

+{%- endtrans %}

+ +

{% 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 %}

-

+

{% 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. -

+{%- endtrans %}

- - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Client-side Options
Option As Of ReleaseRecommended Arguments Allowable RangeDefaultDescription -
i2cp.tcp.host    127.0.0.1Router 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. -
i2cp.tcp.port   1-655357654Router 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. -
i2cp.SSL0.8.3true, false falseConnect 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. -
i2cp.gzip0.6.5true, false  trueGzip outbound data -
i2cp.reduceOnIdle0.7.1true, false  falseReduce tunnel quantity when idle -
i2cp.closeOnIdle0.7.1true, false  falseClose I2P session when idle -
i2cp.reduceIdleTime0.7.11200000300000 minimum (ms) Idle time required (default 20 minutes, minimum 5 minutes) -
i2cp.closeIdleTime0.7.11800000300000 minimum (ms) Idle time required (default 30 minutes) -
i2cp.reduceQuantity0.7.111 to 51Tunnel quantity when reduced (applies to both inbound and outbound) -
i2cp.encryptLeaseSet0.7.1true, false  falseEncrypt the lease -
i2cp.leaseSetKey0.7.1   Base64 SessionKey (44 characters) -
i2cp.messageReliability  BestEffort, NoneNoneGuaranteed is disabled; - None implemented in 0.8.1; None is the default as of 0.9.4 -
i2cp.fastReceive0.9.4 true, falsetrueIf true, the router just sends the MessagePayload instead - of sending a MessageStatus and awaiting a ReceiveMessageBegin. +
{% trans %}Client-side Options{% endtrans %}
{% trans %}Option{% endtrans %}{% trans %}As Of Release{% endtrans %}{% trans %}Recommended Arguments{% endtrans %}{% trans %}Allowable Range{% endtrans %}{% trans %}Default{% endtrans %}{% trans %}Description{% endtrans %}
i2cp.tcp.host +  +  +  +127.0.0.1 +{% 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 %}
i2cp.tcp.port +  +  +1-65535 +7654 +{% 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 %}
i2cp.SSL +0.8.3 +true, false +  +false +{% 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 %}
i2cp.gzip +0.6.5 +true, false +  +true +{% trans %}Gzip outbound data{% endtrans %}
i2cp.reduceOnIdle +0.7.1 +true, false +  +false +{% trans %}Reduce tunnel quantity when idle{% endtrans %}
i2cp.closeOnIdle +0.7.1 +true, false +  +false +{% trans %}Close I2P session when idle{% endtrans %}
i2cp.reduceIdleTime +0.7.1 +1200000 +{% trans num=300000 %}{{ num }} minimum{% endtrans %} +  +{% trans %}(ms) Idle time required (default 20 minutes, minimum 5 minutes){% endtrans %}
i2cp.closeIdleTime +0.7.1 +1800000 +{% trans num=300000 %}{{ num }} minimum{% endtrans %} +  +{% trans %}(ms) Idle time required (default 30 minutes){% endtrans %}
i2cp.reduceQuantity +0.7.1 +1 +{% trans from=1, to=5 %}{{ from }} to {{ to }}{% endtrans %}1 +{% trans %}Tunnel quantity when reduced (applies to both inbound and outbound){% endtrans %}
i2cp.encryptLeaseSet +0.7.1 +true, false +  +false +{% trans %}Encrypt the lease{% endtrans %}
i2cp.leaseSetKey +0.7.1 +  +  +  +{% trans %}Base64 SessionKey (44 characters){% endtrans %}
i2cp.messageReliability +  +  +BestEffort, None +None +{% trans -%} +Guaranteed is disabled; +None implemented in 0.8.1; None is the default as of 0.9.4 +{%- endtrans %}
i2cp.fastReceive +0.9.4 +  +true, false +true +{% trans -%} +If true, the router just sends the MessagePayload instead +of sending a MessageStatus and awaiting a ReceiveMessageBegin. +{%- endtrans %}
-

+ +

{% 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 %}

-

I2CP Payload Data Format and Multiplexing

-

+

{% trans %}I2CP Payload Data Format and Multiplexing{% endtrans %}

+

{% 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 -SendMessageMessage +SendMessageMessage and received by the client in a -MessagePayloadMessage) +MessagePayloadMessage) are gzipped with a standard 10-byte gzip header beginning with 0x1F 0x8B 0x08 as specified by RFC 1952. @@ -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. -

+{%- endtrans %}

+ +

{% 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. -

+{%- endtrans %}

- + + + + + + + + + + + + + + + + + + + + + + + + + +
BytesContent -
0-2Gzip header 0x1F 0x8B 0x08 -
3Gzip flags -
4-5I2P Source port (Gzip mtime) -
6-7I2P Destination port (Gzip mtime) -
8Gzip xflags -
9I2P Protocol (6 = Streaming, 17 = Datagram, 18 = Raw Datagrams) (Gzip OS) +
{% trans %}Bytes{% endtrans %}{% trans %}Content{% endtrans %}
0-2 +{% trans %}Gzip header{% endtrans %} 0x1F 0x8B 0x08 +
3 +{% trans %}Gzip flags{% endtrans %}
4-5 +{% trans %}I2P Source port (Gzip mtime){% endtrans %}
6-7 +{% trans %}I2P Destination port (Gzip mtime){% endtrans %}
8 +{% trans %}Gzip xflags{% endtrans %}
9 +{% trans %}I2P Protocol (6 = Streaming, 17 = Datagram, 18 = Raw Datagrams) (Gzip OS){% endtrans %}
-

+

{% trans -%} Data integrity is verified with the standard gzip CRC-32 as specified by RFC 1952. -

+{%- endtrans %}

-

Future Work

- diff --git a/i2p2www/pages/site/docs/protocol/i2np.html b/i2p2www/pages/site/docs/protocol/i2np.html index 8cb24255..3ee58d06 100644 --- a/i2p2www/pages/site/docs/protocol/i2np.html +++ b/i2p2www/pages/site/docs/protocol/i2np.html @@ -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 %} -

I2P Network Protocol (I2NP)

-

+

{% trans %}I2P Network Protocol{% endtrans %} (I2NP)

+

{% 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. -

+{%- endtrans %}

-

I2NP Definition

-

+

{% trans %}I2NP Definition{% endtrans %}

+

{% 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. -

+{%- endtrans %}

+ +

{% 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 %}

-

Message Format

-

+

{% trans %}Message Format{% endtrans %}

- + + + + +
FieldBytes -
Unique ID4 -
Expiration8 -
Payload Length2 -
Checksum1 -
Payload0 - 61.2KB +
{% trans %}Field{% endtrans %}{% trans %}Bytes{% endtrans %}
{% trans %}Unique ID{% endtrans %}4
{% trans %}Expiration{% endtrans %}8
{% trans %}Payload Length{% endtrans %}2
{% trans %}Checksum{% endtrans %}1
{% trans %}Payload{% endtrans %}0 - 61.2KB
-

+

{% 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 -tunnel-alt.html. +method of fragmenting I2NP messages into multiple 1KB tunnel messages as described on +the tunnel implementation page. The maximum number of fragments is 64, and the message may not be perfectly aligned, So the message must nominally fit in 63 fragments. -

+{%- endtrans %}

+ +

{% 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. -

-

+{%- endtrans %}

+ +

{% 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. -

+{%- endtrans %}

+ +

{% 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 %}

-

Message Types

+

{% trans %}Message Types{% endtrans %}

+

{% 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. -

+{%- endtrans %}

+ +

{% 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. -

+{%- endtrans %}

- + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MessageTypePayload LengthPriorityComments +
{% trans %}Message{% endtrans %}{% trans %}Type{% endtrans %}{% trans %}Payload Length{% endtrans %}{% trans %}Priority{% endtrans %}{% trans %}Comments{% endtrans %}
DatabaseLookupMessage 2   100/400 -400 normally; 100 if from HarvesterJob and sent directly; +{% trans -%} +400 normally; 100 if from HarvesterJob and sent directly; 400 for a router lookup +{%- endtrans %}
DatabaseSearchReplyMessage 3 Typ. 161 300 -Size is 65 + 32*(number of hashes) where typically, the hashes for +{% trans -%} +Size is 65 + 32*(number of hashes) where typically, the hashes for three floodfill routers are returned. +{%- endtrans %}
DatabaseStoreMessage 1 -Varies +{% trans %}Varies{% endtrans %} 100/400 -Usually 100 (why?) +{% 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 %}
DataMessage 20 4 - 62080 400 +
DeliveryStatusMessage 10 12   -Used for message replies, and for testing tunnels - generally wrapped in a GarlicMessage +{% trans %}Used for message replies, and for testing tunnels - generally wrapped in a GarlicMessage{% endtrans %}
-GarlicMessage +GarlicMessage 11     -Generally wrapped in a DataMessage - +{% trans -%} +Generally wrapped in a DataMessage - but when unwrapped, given a priority of 100 by the forwarding router +{%- endtrans %}
-TunnelBuildMessage +TunnelBuildMessage 21 4224 300/500 -Usually 500 (why?) +{% trans %}Usually 500 (why?){% endtrans %}
-TunnelBuildReplyMessage +TunnelBuildReplyMessage 22 4224 300 +
TunnelDataMessage 18 1028 400 -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. +{% 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 %}
TunnelGatewayMessage 19   300/400 +
VariableTunnelBuildMessage 23 1057 - 4225 300/500 -Shorter TunnelBuildMessage as of 0.7.12 +{% trans %}Shorter TunnelBuildMessage as of 0.7.12{% endtrans %}
VariableTunnelBuildReplyMessage 24 1057 - 4225 300 -Shorter TunnelBuildReplyMessage as of 0.7.12 -
-Others listed in -2003 Spec +{% trans %}Shorter TunnelBuildReplyMessage as of 0.7.12{% endtrans %}
{% trans pdf=url_for('static', filename='pdf/I2NP_spec.pdf') -%} +Others listed in 2003 Spec +{%- endtrans %} 0,4-9,12     -Obsolete, Unused +{% trans %}Obsolete, Unused{% endtrans %} +
-

Full Protocol Specification

-On the I2NP Specification page. +

{% trans %}Full Protocol Specification{% endtrans %}

+

{% trans i2npspec=site_url('docs/specs/i2np'), commonstructures=site_url('docs/specs/common-structures') -%} +On the I2NP Specification page. See also the -Common Data Structure Specification page. +Common Data Structure Specification page. +{%- endtrans %}

-

Future Work

-

+

{% trans %}Future Work{% endtrans %}

+

{% 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 %}

{% endblock %} diff --git a/i2p2www/pages/site/docs/protocol/index.html b/i2p2www/pages/site/docs/protocol/index.html index 117d7f55..d2869502 100644 --- a/i2p2www/pages/site/docs/protocol/index.html +++ b/i2p2www/pages/site/docs/protocol/index.html @@ -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 %} -

+

{% trans docs=site_url('docs') -%} Here is the protocol stack for I2P. -See also the Index to Technical Documentation. -

+See also the Index to Technical Documentation. +{%- endtrans %}

-

+

{% 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 %}

-

-

+

{% 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 %}

-

-

+ +

{% trans -%} Finally, what could be considered the 'I2P application layer', is a large number of applications on top of I2P. We can order this based on the I2P stack layer they use. +{%- endtrans %}

-

- I2P Network stack + {{ _('I2P Network stack') }}

- Figure 1: The layers in the I2P Network stack. + {% trans %}Figure 1: The layers in the I2P Network stack.{% endtrans %}

-* Note: SAM/SAMv2 can use both the streaming lib and datagrams. +* {% trans %}Note: SAM/SAMv2 can use both the streaming lib and datagrams.{% endtrans %}

{% endblock %}