Base interface for all I2NP messages
interface for extending the types of messages handled - unused
Holds the unencrypted 222-byte tunnel request record, with a constructor for ElGamal decryption and a method for ElGamal encryption.
Class that creates an encrypted tunnel build message record.
Defines the message a router sends to another router to search for a key in the network database.
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.
Defines the message a router sends to another router to test the network database reachability, as well as the reply message sent back.
Defines a message containing arbitrary bytes of data This is what goes in a GarlicClove.
Contains the delivery instructions for garlic cloves.
Defines the message sent back in reply to a message when requested, containing the private ack id.
ElGamal-encrypted request or response.
Ignore, but save, the SHA-256 checksum in the full 16-byte header when read in.
Contains one deliverable message encrypted to a router along with instructions and a certificate 'paying for' the delivery.
Defines the wrapped garlic message
Handle messages from router to router.
Defines the base message implementation.
The basic build message with 8 records.
Base for TBM, TBRM, VTBM, VTBRM Retrofitted over them.
The basic build reply message with 8 records.
Defines the message sent between routers as part of the tunnel delivery The tunnel ID is changed in-place by TunnelParticipant.send(), so we can't reuse the checksum on output, but we still subclass FastI2NPMessageImpl so we don't verify the checksum on input...
Defines the message sent between one tunnel's endpoint and another's gateway.
This is similar to DataMessage or GarlicMessage but with a variable message type.
Variable number of records.
Transmitted from the new outbound endpoint to the creator through a reply tunnel.
Represent an error serializing or deserializing an APIMessage
This package defines the low-level messages sent between routers, called the Invisible Internet Network Protocol (I2NP).
Not for use by apps, clients or plugins.
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.