|PREV PACKAGE NEXT PACKAGE||FRAMES NO FRAMES|
|I2NPMessage||Base interface for all I2NP messages|
|I2NPMessageImpl.Builder||interface for extending the types of messages handled - unused|
|I2NPMessageReader.I2NPMessageEventListener||Defines the different events the reader produces while reading the stream|
|BuildRequestRecord||Hold the tunnel request record, managing its encryption and decryption.|
|BuildResponseRecord||Read and write the reply to a tunnel build message record.|
|DatabaseLookupMessage||Defines the message a router sends to another router to search for a key in the network database.|
|DatabaseSearchReplyMessage||Defines the message a router sends to another router in response to a search (DatabaseFindNearest or DatabaseLookup) when it doesn't have the value, specifying what routers it would search.|
|DatabaseStoreMessage||Defines the message a router sends to another router to test the network database reachability, as well as the reply message sent back.|
|DataMessage||Defines a message containing arbitrary bytes of data|
|DeliveryInstructions||Contains the delivery instructions|
|DeliveryStatusMessage||Defines the message sent back in reply to a message when requested, containing the private ack id.|
|GarlicClove||Contains one deliverable message encrypted to a router along with instructions and a certificate 'paying for' the delivery.|
|GarlicMessage||Defines the wrapped garlic message|
|I2NPMessageHandler||Handle messages from router to router.|
|I2NPMessageImpl||Defines the base message implementation.|
|I2NPMessageReader||The I2NPMessageReader reads an InputStream (using
|TunnelBuildReplyMessage||Transmitted from the new outbound endpoint to the creator through a reply tunnel|
|TunnelDataMessage||Defines the message sent between routers as part of the tunnel delivery|
|TunnelGatewayMessage||Defines the message sent between one tunnel's endpoint and another's gateway.|
|UnknownI2NPMessage||This is the same as DataMessage but with a variable message type.|
|VariableTunnelBuildReplyMessage||Transmitted from the new outbound endpoint to the creator through a reply tunnel|
|I2NPMessageException||Represent an error serializing or deserializing an APIMessage|
The Invisible Internet Network Protocol (I2NP) is only a part of how an application can send messages over the network. The Invisible Internet Client Protocol (I2CP) defines how client applications written in any language can communicate with the network routers. In addition, various transport protocols define the specifics of how data is passed from one router to another over the network. I2NP does not specify or require any particular transport layer, allowing transport protocols to work over TCP, Polling HTTP, SMTP+POP3/IMAP, UDP, among anything else that can pass data. I2NP merely requires that they:
Transports themselves can implement advanced features, such as steganography, constant rate delivery, dummy message delivery, and may even run on top of existing networks, such as mixminion, kazaa, gnunet, and freenet. Transports can even be written to run over I2P itself, accessing it as a client and mixing the message through other routers.
Sandwiched between I2CP and the various I2P transport protocols, I2NP manages the routing and mixing of messages between routers, as well as the selection of what
Following is a common usage for I2NP Messages. For other usages, including tunnel building, see the I2NP specification or the tunnel build document.
Whenever a Destination wants to send a message to to another Destination, it provides its local router with both the Destination structure and the raw bytes of the message to be sent. The router then determines where to send it, delivers it through outbound tunnels, instructing the end point to pass it along to the appropriate inbound tunnel, where it is passed along again to that tunnel's end point and made available to the target for reception. To understand fully, each step in the process must be explained in detail.
There are several important points of note in this scenario. First, the source router determines how many messages to send, how many outbound tunnels to send them out, how many inbound tunnels to send them to, and how many cloves should include DeliveryStatusMessage responses. The algorithm deciding these choices depends both on the router implementation as well as the Destination's session configuration options specified to balance the bandwidth, latency, reliability, and anonymity constraints. Also, instead of using outbound tunnels to get the message to the inbound tunnel's gateway, the router may decide to source router the message instead. If the message id for a clove has already been processed or its expiration has passed, the clove is dropped.
|PREV PACKAGE NEXT PACKAGE||FRAMES NO FRAMES|