+The Invisible Internet Client Protocol (I2CP) allows applications simplified access to +the I2P network without requiring them to deal with the issues involved with the +Invisible Internet Network Protocol (I2NP). Specifically, it defines the wire level +protocol as well as semantics for the messages passed between clients and the router +for communicating with the router over bidirectional TCP/IP sockets. I2CP does not +specify how the client libraries are created, what APIs they expose to applications, or +even what language they're written in. +
++I2CP requires that the client can access the router over bidirectional TCP sockets. In +nearly all cases, these connections will be over to the local machine. +
++I2CP does not provide data confidentiality or handle lossy connections beyond what +TCP has built in. For this reason, I2CP really should only be run between clients and +routers on the same machine or over trusted networks. Secured I2CP transports may +be added in the future. I2CP however does not expose any private keys across the +wire - proof of authorization to collect messages for a Destination is provided by +public key signatures. +
++These classes are the currently defined messages in the Invisible Internet Client +Protocol (I2CP), though common data structures are located in the I2P Common Data +Structure Specification. For simplicity, all I2CP messages begin with the same +structure, though that structure is not listed below. Specifically, all I2CP messages +transmitted begin with a 4 byte Integer specifying the entire size of the current +message's body (the body being what's specified below), followed by a 1 byte +Integer specifying the type of message (the id field below), after which the rest of +the message is formatted according to the type of message, as specified below. +
+If there is a fatal error causing either the client or the router to desire to cancel sending +a message part way through, it should drop its connection. Administrative sessions are +not stateful (aka each administrative message from client to router must provide +authentication), but normal client sessions are stateful and survive disconnects. Client +sessions expire when either the client sends a DestroySessionMessage or the router +times out the session according to its own configurable timer. If a client sends any +message other than a CreateSessionMessage when there is no valid session, the +router must reply with a SessionStatusMessage specifying that the session is not +valid. +
+Note: the contents and bitbuckets for specific DataStructures are detailed in the +I2P Data Structures Spec. +
+ diff --git a/core/java/src/net/i2p/data/package.html b/core/java/src/net/i2p/data/package.html new file mode 100644 index 000000000..5b9be2f54 --- /dev/null +++ b/core/java/src/net/i2p/data/package.html @@ -0,0 +1,6 @@ + ++These classes define the common data structures used by the various +I2P protocols. +
+ diff --git a/core/java/src/net/i2p/stat/package.html b/core/java/src/net/i2p/stat/package.html new file mode 100644 index 000000000..745e9d001 --- /dev/null +++ b/core/java/src/net/i2p/stat/package.html @@ -0,0 +1,7 @@ + ++These classes define the statistics package used extensively throughout +the I2P router - both for adaptive operation of the router +and for debugging. +
+ diff --git a/core/java/src/net/i2p/util/package.html b/core/java/src/net/i2p/util/package.html new file mode 100644 index 000000000..3c08401d2 --- /dev/null +++ b/core/java/src/net/i2p/util/package.html @@ -0,0 +1,6 @@ + ++These classes define the several useful utilities used +throughout the router and applications. +
+ diff --git a/router/java/src/net/i2p/data/i2np/package.html b/router/java/src/net/i2p/data/i2np/package.html new file mode 100644 index 000000000..666c5bf22 --- /dev/null +++ b/router/java/src/net/i2p/data/i2np/package.html @@ -0,0 +1,129 @@ + ++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. +
+ diff --git a/router/java/src/net/i2p/router/transport/tcp/package.html b/router/java/src/net/i2p/router/transport/tcp/package.html index 7df3c1952..c236f03a3 100644 --- a/router/java/src/net/i2p/router/transport/tcp/package.html +++ b/router/java/src/net/i2p/router/transport/tcp/package.html @@ -1,5 +1,8 @@ -Implements the transport for communicating with other routers via TCP/IP.
++OBSOLETE - see NTCP. +Implements the transport for communicating with other routers via TCP/IP. +