forked from I2P_Developers/i2p.www
Migrated I2CP and I2NP pages
This commit is contained in:
str4d
@@ -46,6 +46,13 @@
|
||||
<li><a href="{{ site_url('docs/api/i2pcontrol') }}"><span>{{ _('I2PControl') }}</span></a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="has-sub"><a href="#"><span>{{ _('Protocols') }}</span></a>
|
||||
<ul>
|
||||
<li><a href="{{ site_url('docs/protocol') }}"><span>{{ _('Protocol stack') }}</span></a></li>
|
||||
<li><a href="{{ site_url('docs/protocol/i2cp') }}"><span>I2CP</span></a></li>
|
||||
<li><a href="{{ site_url('docs/protocol/i2np') }}"><span>I2NP</span></a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="has-sub"><a href="#"><span>{{ _('Transports') }}</span></a>
|
||||
<ul>
|
||||
<li><a href="{{ site_url('docs/transport') }}"><span>{{ _('Transport layer overview') }}</span></a></li>
|
||||
|
||||
251
i2p2www/pages/site/docs/protocol/i2cp.html
Normal file
251
i2p2www/pages/site/docs/protocol/i2cp.html
Normal file
@@ -0,0 +1,251 @@
|
||||
{% extends "global/layout.html" %}
|
||||
{% block title %}I2CP{% endblock %}
|
||||
{% block content %}
|
||||
Updated November 2012, current as of router version 0.9.3
|
||||
|
||||
<p>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
|
||||
to the router only through signatures. With I2CP, a client application tells the
|
||||
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>
|
||||
|
||||
<p>
|
||||
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>.
|
||||
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>
|
||||
|
||||
<p>
|
||||
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.
|
||||
Together, implementing I2CP and the streaming library would be a sizable task.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
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,
|
||||
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>
|
||||
|
||||
<p>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>
|
||||
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>
|
||||
|
||||
<p>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>
|
||||
|
||||
<h2>I2CP Protocol Specification</h2>
|
||||
<p>
|
||||
Now on the
|
||||
<a href="{{ site_url('docs/specs/i2cp') }}">I2CP Specification page</a>.
|
||||
</p>
|
||||
|
||||
|
||||
<h2>I2CP Initialization</h2>
|
||||
<p>
|
||||
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
|
||||
have been built, and responds with a CreateLeaseSetMessage containing the signed LeaseSet.
|
||||
The client may now initiate or receive connections from other I2P destinations.
|
||||
|
||||
<h2 id="options">I2CP Options</h2>
|
||||
<p>
|
||||
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>
|
||||
<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> <td> <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> <td> <td>Name of tunnel - generally ignored unless inbound.nickname is unset.
|
||||
<tr><td>inbound.allowZeroHop <td>true, false<td> <td>true<td>If incoming zero hop tunnel is allowed
|
||||
<tr><td>outbound.allowZeroHop <td>true, false<td> <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> <td>false<td>Should generally be set to true for clients
|
||||
and false for servers
|
||||
<tr><td>i2cp.messageReliability <td> <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> <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> <td> <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> <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>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" 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
|
||||
in the "unknown options" properties of the outbound tunnel pool's settings.
|
||||
</table>
|
||||
<p>
|
||||
Note: Large quantity, length, or variance settings may cause significant performance or reliability problems.
|
||||
<p>
|
||||
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.
|
||||
|
||||
<p>
|
||||
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>
|
||||
<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.
|
||||
<tr><td>i2cp.tcp.port <td> <td> <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> <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> <td>true<td>Gzip outbound data
|
||||
<tr><td>i2cp.reduceOnIdle<td>0.7.1<td>true, false <td> <td>false<td>Reduce tunnel quantity when idle
|
||||
<tr><td>i2cp.closeOnIdle<td>0.7.1<td>true, false <td> <td>false<td>Close I2P session when idle
|
||||
<tr><td>i2cp.reduceIdleTime<td>0.7.1<td>1200000<td>300000 minimum<td> <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> <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> <td>false<td>Encrypt the lease
|
||||
<tr><td>i2cp.leaseSetKey<td>0.7.1<td> <td> <td> <td>Base64 SessionKey (44 characters)
|
||||
<tr><td>i2cp.messageReliability<td> <td> <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> <td>true, false<td>true<td>If true, the router just sends the MessagePayload instead
|
||||
of sending a MessageStatus and awaiting a ReceiveMessageBegin.
|
||||
</table>
|
||||
<p>
|
||||
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.
|
||||
|
||||
<h2 id="format">I2CP Payload Data Format and Multiplexing</h2>
|
||||
<p>
|
||||
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>
|
||||
and received by the client in a
|
||||
<a href="{{ site_url('docs/specs/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>.
|
||||
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>
|
||||
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>
|
||||
<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)
|
||||
</table>
|
||||
|
||||
<p>
|
||||
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>
|
||||
|
||||
|
||||
<h2 id="future">Future Work</h2>
|
||||
<ul><li>
|
||||
Implement I2CP and the streaming library in another programming language.
|
||||
</li><li>
|
||||
Is the initial Get Date / Set Date handshake required?
|
||||
</li><li>
|
||||
The current authorization mechanism could be modified to use hashed passwords.
|
||||
</li><li>
|
||||
Private Keys are included in the Create Lease Set message,
|
||||
are they really required? Revocation is unimplemented.
|
||||
</li><li>
|
||||
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>
|
||||
(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>
|
||||
|
||||
|
||||
|
||||
{% endblock %}
|
||||
185
i2p2www/pages/site/docs/protocol/i2np.html
Normal file
185
i2p2www/pages/site/docs/protocol/i2np.html
Normal file
@@ -0,0 +1,185 @@
|
||||
{% extends "global/layout.html" %}
|
||||
{% block title %}I2NP{% endblock %}
|
||||
{% block content %}
|
||||
Updated August 2010, current as of router version 0.8
|
||||
<h2>I2P Network Protocol (I2NP)</h2>
|
||||
<p>
|
||||
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>
|
||||
|
||||
<h3>I2NP Definition</h3>
|
||||
<p>
|
||||
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>
|
||||
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
|
||||
messages with priorities 400-499, for example, the same.
|
||||
(The priority queues are 100, 200, 300, 400, 500, and 1000)
|
||||
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.
|
||||
|
||||
<h3>Message Format</h3>
|
||||
<p>
|
||||
|
||||
<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
|
||||
</table>
|
||||
|
||||
<p>
|
||||
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>.
|
||||
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>
|
||||
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>
|
||||
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>
|
||||
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.
|
||||
|
||||
<h3>Message Types</h3>
|
||||
Higher-numbered priority is higher priority.
|
||||
The majority of traffic is TunnelDataMessages (priority 400),
|
||||
so anything above 400 is essentially high priority, and
|
||||
anything below is low priority.
|
||||
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>
|
||||
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>
|
||||
|
||||
|
||||
<table border=1>
|
||||
<tr><th>Message<th>Type<th>Payload Length<th>Priority<th>Comments
|
||||
<tr><td>
|
||||
DatabaseLookupMessage
|
||||
<td align=right>2
|
||||
<td>
|
||||
<td align=right>100/400
|
||||
<td>400 normally; 100 if from HarvesterJob and sent directly;
|
||||
400 for a router lookup
|
||||
<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
|
||||
three floodfill routers are returned.
|
||||
<tr><td>
|
||||
DatabaseStoreMessage
|
||||
<td align=right>1
|
||||
<td align=right>Varies
|
||||
<td align=right>100/400
|
||||
<td>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.
|
||||
<tr><td>
|
||||
DataMessage
|
||||
<td align=right>20
|
||||
<td align=right>4 - 62080
|
||||
<td align=right>400
|
||||
<td>
|
||||
<tr><td>
|
||||
DeliveryStatusMessage
|
||||
<td align=right>10
|
||||
<td align=right>12
|
||||
<td>
|
||||
<td>Used for message replies, and for testing tunnels - generally wrapped in a GarlicMessage
|
||||
<tr><td>
|
||||
<a href="{{ site_url('docs/how/techintro') }}#op.garlic">GarlicMessage</a>
|
||||
<td align=right>11
|
||||
<td>
|
||||
<td>
|
||||
<td>Generally wrapped in a DataMessage -
|
||||
but when unwrapped, given a priority of 100 by the forwarding router
|
||||
<tr><td>
|
||||
<a href="tunnel-alt-creation.html#tunnelCreate.requestRecord">TunnelBuildMessage</a>
|
||||
<td align=right>21
|
||||
<td align=right>4224
|
||||
<td align=right>300/500
|
||||
<td>Usually 500 (why?)
|
||||
<tr><td>
|
||||
<a href="tunnel-alt-creation.html#tunnelCreate.replyRecord">TunnelBuildReplyMessage</a>
|
||||
<td align=right>22
|
||||
<td align=right>4224
|
||||
<td align=right>300
|
||||
<td>
|
||||
<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.
|
||||
<tr><td>
|
||||
TunnelGatewayMessage
|
||||
<td align=right>19
|
||||
<td>
|
||||
<td align=right>300/400
|
||||
<td>
|
||||
<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
|
||||
<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>0,4-9,12
|
||||
<td>
|
||||
<td>
|
||||
<td>Obsolete, Unused
|
||||
</table>
|
||||
|
||||
<h3>Full Protocol Specification</h3>
|
||||
<a href="{{ site_url('docs/specs/i2np') }}">On the I2NP Specification page</a>.
|
||||
See also the
|
||||
<a href="{{ site_url('docs/specs/common_structures') }}">Common Data Structure Specification page</a>.
|
||||
|
||||
<h3>Future Work</h3>
|
||||
<p>
|
||||
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.
|
||||
|
||||
{% endblock %}
|
||||
Reference in New Issue
Block a user