From c024398b939fe7a682ade32c2a328df17c0f58a3 Mon Sep 17 00:00:00 2001
From: zzz
+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.
+
+These classes define the common data structures used by the various
+I2P protocols.
+
+These classes define the statistics package used extensively throughout
+the I2P router - both for adaptive operation of the router
+and for debugging.
+
+These classes define the several useful utilities used
+throughout the router and applications.
+
+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:
+Requirements
+Threat Model
+Messages
+
+
+
+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. +