The Invisible Internet Network Protocol (I2NP) is only a part of how an application can send messages over the network.


Interface Summary
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

Class Summary
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 I2NPMessageHandler) and passes out events to a registered listener, where events are either messages being received, exceptions being thrown, or the connection being closed.
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

Exception Summary
I2NPMessageException Represent an error serializing or deserializing an APIMessage

Package Description

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

Destination Sends a Message

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.