From 985a9cfaa28538ba86c35b57fa0d45fb94c25cdf Mon Sep 17 00:00:00 2001 From: zzz Date: Tue, 5 Oct 2010 00:15:27 +0000 Subject: [PATCH] drop package-*.html now that we have real javadocs --- www.i2p2/pages/i2cp.html | 2 +- www.i2p2/pages/package-client.html | 37 ------ www.i2p2/pages/package-client_de.html | 39 ------- www.i2p2/pages/package-datagram.html | 17 --- www.i2p2/pages/package-datagram_de.html | 20 ---- www.i2p2/pages/package-naming.html | 9 -- www.i2p2/pages/package-naming_de.html | 10 -- www.i2p2/pages/package-streaming.html | 26 ----- www.i2p2/pages/package-streaming_de.html | 30 ----- www.i2p2/pages/package-tcp.html | 143 ----------------------- www.i2p2/pages/techintro.html | 2 +- 11 files changed, 2 insertions(+), 333 deletions(-) delete mode 100644 www.i2p2/pages/package-client.html delete mode 100644 www.i2p2/pages/package-client_de.html delete mode 100644 www.i2p2/pages/package-datagram.html delete mode 100644 www.i2p2/pages/package-datagram_de.html delete mode 100644 www.i2p2/pages/package-naming.html delete mode 100644 www.i2p2/pages/package-naming_de.html delete mode 100644 www.i2p2/pages/package-streaming.html delete mode 100644 www.i2p2/pages/package-streaming_de.html delete mode 100644 www.i2p2/pages/package-tcp.html diff --git a/www.i2p2/pages/i2cp.html b/www.i2p2/pages/i2cp.html index 599b6537..30bdfb2b 100644 --- a/www.i2p2/pages/i2cp.html +++ b/www.i2p2/pages/i2cp.html @@ -16,7 +16,7 @@ for some tunnels to be used.

The protocol itself has only been implemented in Java, to provide the -Client SDK. +Client SDK. This SDK is exposed in the i2p.jar package, which implements the client-side of I2CP. Clients should never need to access the router.jar package, which contains the router itself and the router-side of I2CP. diff --git a/www.i2p2/pages/package-client.html b/www.i2p2/pages/package-client.html deleted file mode 100644 index 68f83275..00000000 --- a/www.i2p2/pages/package-client.html +++ /dev/null @@ -1,37 +0,0 @@ -{% extends "_layout.html" %} -{% block title %}Client Package{% endblock %} -{% block content %} -

Implements the base I2P SDK for developing applications that communicate -through I2P.

- -

When a client application wants to communicate over I2P, the first thing it -needs to do is get a {@link net.i2p.client.I2PClient} from the -{@link net.i2p.client.I2PClientFactory}. If it does not already have a {@link -net.i2p.data.Destination}, it must generate one with the {@link -net.i2p.client.I2PClient#createDestination} before proceeding. Once it has -one, it then creates an {@link net.i2p.client.I2PSession} which serves as the -bridge to the I2P network, allowing it to send messages (via -{@link net.i2p.client.I2PSession#sendMessage}) and receive messages (via -{@link net.i2p.client.I2PSession#receiveMessage}). In addition, the client -receives asynchronous notification of network activity by providing an implementation -of {@link net.i2p.client.I2PSessionListener}.

- -

A simple example of how these base client classes can be used is the -{@link net.i2p.client.ATalk} application. It isn't really useful, but it is -heavily documented code.

- -

This client package provides the basic necessity for communicating over I2P, -but there are three other subpackages that are helpful. Specifically:

- -

The {@link net.i2p.client.I2PSession} implementation itself communicates with -the I2P router by the I2CP (the client protocol).

-{% endblock %} diff --git a/www.i2p2/pages/package-client_de.html b/www.i2p2/pages/package-client_de.html deleted file mode 100644 index c17b2a2a..00000000 --- a/www.i2p2/pages/package-client_de.html +++ /dev/null @@ -1,39 +0,0 @@ -{% extends "_layout_de.html" %} -{% block title %}Klient Packet{% endblock %} -{% block content %} -

Implementiert das Basis I2P SDK zum Entwickeln von Anwendungen, die -über I2P kommunizieren.

- -

Sobald eine Klientanwendung über I2P kommunizieren will, braucht -sie zuerst ein {@link net.i2p.client.I2PClient} von der -{@link net.i2p.client.I2PClientFactory}. Falls es nicht schon eine -{@link net.i2p.data.Destination} hat, muss es mit dem -{@link net.i2p.client.I2PClient#createDestination} eine erstellen bevor -sie weiter machen kann. Sobald es eine hat erstellt sie eine -{@link net.i2p.client.I2PSession} die als Brücke ins I2P Netzwerk -arbeitet. Dieses erlaubt das Senden von Nachrichten (via -{@link net.i2p.client.I2PSession#sendMessage}) und das Empfangen von Nachrichten -(via {@link net.i2p.client.I2PSession#receiveMessage}). Zusätzlich -erhält der Klient asynchrone Informationen zur Netzaktivität -aus der Implementation des {@link net.i2p.client.I2PSessionListener}.

- -

Ein einfaches Beispiel zur Nutzung dieser Basisklassen kann in der -{@link net.i2p.client.ATalk} Anwendung gefunden werden. Sie ist nicht -wirklich nützlich, ist aber ein sehr stark dokumentierter Quelltext.

- -

Dieses Klient Packet hält die Basis Anforderungen zur Kommunikation -mit I2P bereit, hinzu kommen drei weitere, hilfreiche Unterpackete. -Diese sind:

- -

Die {@link net.i2p.client.I2PSession} Implementation alleine kommuniziert -mit dem I2P Router mittels des I2CP (das Klientenprotokoll).

-{% endblock %} diff --git a/www.i2p2/pages/package-datagram.html b/www.i2p2/pages/package-datagram.html deleted file mode 100644 index 6f06a5e9..00000000 --- a/www.i2p2/pages/package-datagram.html +++ /dev/null @@ -1,17 +0,0 @@ -{% extends "_layout.html" %} -{% block title %}Datagram Package{% endblock %} -{% block content %} -

Provides a standard way for reading and writing messages transferred over I2P -so that the recipient has an authenticated mechanism to reply to it. This is -necessary because the base I2P message sent through {@link net.i2p.client.I2PSession#sendMessage} -has no "from" address, and simply providing a raw "from" address would be -insecure as it could be spoofed. An application that needs to know for certain -who sent a message to them should use the {@link net.i2p.client.datagram.I2PDatagramDissector} -to parse the raw message received from the {@link net.i2p.client.I2PSession}, and -in turn, use the {@link net.i2p.client.datagram.I2PDatagramMaker} to build a -message that can be parsed.

- -

The datagram format implemented here includes -the sender's {@link net.i2p.data.Destination}, the payload, and a hash of the -payload (signed by the sender's {@link net.i2p.data.SigningPrivateKey}).

-{% endblock %} diff --git a/www.i2p2/pages/package-datagram_de.html b/www.i2p2/pages/package-datagram_de.html deleted file mode 100644 index da0e07d4..00000000 --- a/www.i2p2/pages/package-datagram_de.html +++ /dev/null @@ -1,20 +0,0 @@ -{% extends "_layout_de.html" %} -{% block title %}Datagram Package{% endblock %} -{% block content %} -

Hält einen Standardweg zum Lesen und Schreiben von über I2P -transportierten Nachrichten bereit, damit der Empfänger einen -authentifizierten Mechanismus zum Beantworten derselben hat. Dieses -ist notwendig, da die Standard I2P Nachrichten, die über -{@link net.i2p.client.I2PSession#sendMessage} gesendet werden, keine -"von" Adresse haben. Und das hinzufügen einer Klartext "von" Adresse -ist unsicher, da dieses manipuliert werden kann. Eine Anwendung, die -sicher wissen muss, von wem eine Nachricht stammt, sollte die -{@link net.i2p.client.datagram.I2PDatagramDissector} nutzen um die von -{@link net.i2p.client.I2PSession} empfangenen Klartext Nachricht zu -bearbeiten und mit der Ausgabe die {@link net.i2p.client.datagram.I2PDatagramMaker} -nutzen zum bauen einer Nachricht, die geparst werden kann.

- -

Das hier implementierte Datagramm Format inkludiert die {@link net.i2p.data.Destination} -des Senders, die Nutzdaten und einen Hash der Nutzdaten (signiert mit dem -{@link net.i2p.data.SigningPrivateKey} des Senders).

-{% endblock %} diff --git a/www.i2p2/pages/package-naming.html b/www.i2p2/pages/package-naming.html deleted file mode 100644 index 94b5b129..00000000 --- a/www.i2p2/pages/package-naming.html +++ /dev/null @@ -1,9 +0,0 @@ -{% extends "_layout.html" %} -{% block title %}Naming Package{% endblock %} -{% block content %} -

Provides a standard way for querying the local naming service to resolve a -name into a {@link net.i2p.data.Destination} (without the complexity of JNDI). -The default implementation is a simple hosts.txt driven system, though that can -be overridden by specifying the "i2p.naming.impl" environment property to point -at the requested classname.

-{% endblock %} diff --git a/www.i2p2/pages/package-naming_de.html b/www.i2p2/pages/package-naming_de.html deleted file mode 100644 index f3ec23fe..00000000 --- a/www.i2p2/pages/package-naming_de.html +++ /dev/null @@ -1,10 +0,0 @@ -{% extends "_layout_de.html" %} -{% block title %}Namensgebung der Packete{% endblock %} -{% block content %} -

Hält einen Standardweg zum Abfragen des lokalen Namensgebungsservices -bereit, um einen Namen in eine {@link net.i2p.data.Destination} aufzulöen -(ohne die Komplexität von JNDI). -Die Standardimplementation ist ein einfaches System aus einer hosts.txt Datei, -wobei dieses übergangen werden kann, in dem man die Umgebungsvariable -"i2p.naming.impl" auf den entsprechenden Klassennamen setzt.

-{% endblock %} diff --git a/www.i2p2/pages/package-streaming.html b/www.i2p2/pages/package-streaming.html deleted file mode 100644 index b3ed59a8..00000000 --- a/www.i2p2/pages/package-streaming.html +++ /dev/null @@ -1,26 +0,0 @@ -{% extends "_layout.html" %} -{% block title %}Streaming Package{% endblock %} -{% block content %} -

Implements a TCP-like (reliable, authenticated, in order) set of sockets for -communicating over the IP-like (unreliable, unauthenticated, unordered) I2P -messages.

- -

When an application wants to use streams, it must fetch an {@link -net.i2p.client.streaming.I2PSocketManager} from the {@link -net.i2p.client.streaming.I2PSocketManagerFactory}, which in turn builds its own -{@link net.i2p.client.I2PSession} internally. All communication over that -{@link net.i2p.client.I2PSession} is handled by the {@link -net.i2p.client.streaming.I2PSocketManager}, as it imposes its own formatting on -the raw messages sent and received. If an application wants to receive streams -from other clients on the network, it should access the blocking {@link -net.i2p.client.streaming.I2PServerSocket#accept} method, which will provide an -{@link net.i2p.client.streaming.I2PSocket} when a new one is available. If an -application wants to create a new stream to a peer, it should do so with the -appropriate {@link net.i2p.client.streaming.I2PSocketManager#connect} call.

- -

There is a simple pair of demo applications available as well - {@link -net.i2p.client.streaming.StreamSinkServer} listens to a destination and dumps -the data from all sockets it accepts to individual files, while {@link -net.i2p.client.streaming.StreamSinkClient} connects to a particular destination -and sends a specific amount of random data then disconnects.

-{% endblock %} diff --git a/www.i2p2/pages/package-streaming_de.html b/www.i2p2/pages/package-streaming_de.html deleted file mode 100644 index e90b7990..00000000 --- a/www.i2p2/pages/package-streaming_de.html +++ /dev/null @@ -1,30 +0,0 @@ -{% extends "_layout_de.html" %} -{% block title %}Streaming Packet{% endblock %} -{% block content %} -

Implementiert einen TCP-ähnliche (zuverlässlich, authentifiziert, -in Reihenfolge) Satz an Sockets zum Kommunizieren über die IP-ähnlichen -(unzuverlässlich, unauthentifiziert, unsortiert) I2P Nachrichten.

- -

Falls eine Anwendugn Streams nutzen möchte, muss es einen -{@link net.i2p.client.streaming.I2PSocketManager} von der{@link -net.i2p.client.streaming.I2PSocketManagerFactory} anfordern, welche -als Antwort intern eine eigene {@link net.i2p.client.I2PSession} aufbaut. -Jede Kommunikation über diese {@link net.i2p.client.I2PSession} -wird vom {@link net.i2p.client.streaming.I2PSocketManager} verwaltet, -da dieser eine eigene Art an Formatierung der gesendeten und empfangenen -RAW Nachrichten beinhaltet. Falls eine Anwendung Streams von anderen -Klienten aus dem Netzwerk empfangen will, sollte es die blockierenden -{@link net.i2p.client.streaming.I2PServerSocket#accept} Methoden nutzen, -welche einen {@link net.i2p.client.streaming.I2PSocket} zur Verfügung -stellen sobald ein neuer Socket verfügbar ist. Falls eine Anwendung -einen neuen Stream zu einem Knoten erstellen will, sollte sie dieses mit dem -passendem {@link net.i2p.client.streaming.I2PSocketManager#connect} Aufruf -erledigen.

- -

Es exisitieren auch hier einige einfache Demoanwendungen - {@link -net.i2p.client.streaming.StreamSinkServer} lauscht zu einer Destination -und schreibt die Daten aller Sockets, die es akzeptiert, in individuelle -Dateien, während {@link net.i2p.client.streaming.StreamSinkClient} -zu einer bestimmten Destination verbindet und eine bestimmte Anzahl an -Zufallsdaten sendet und sich dann disconnected.

-{% endblock %} diff --git a/www.i2p2/pages/package-tcp.html b/www.i2p2/pages/package-tcp.html deleted file mode 100644 index 4ed5abda..00000000 --- a/www.i2p2/pages/package-tcp.html +++ /dev/null @@ -1,143 +0,0 @@ -{% extends "_layout.html" %} -{% block title %}Old TCP Package{% endblock %} -{% block content %} -

Implements the transport for communicating with other routers via TCP/IP.

- -

Connection protocol

- -

The protocol used to establish the connection between the peers is -implemented in the {@link net.i2p.router.transport.tcp.ConnectionBuilder} -for "Alice", the initiator, and in -{@link net.i2p.router.transport.tcp.ConnectionHandler} for "Bob", the -receiving peer. (+ implies concatenation)

- -

Common case:

-

1) Alice to Bob:
- #bytesFollowing + #versions + v1 [+ v2 [etc]] + tag? + tagData + properties

-

2) Bob to Alice:
- #bytesFollowing + versionOk + #bytesIP + IP + tagOk? + nonce + properties

- - - -

Whether or not the tagData is specified by Alice and is accepted -by Bob determines which of the scenarios below are used. In addition, the IP -address provided by Bob gives Alice the opportunity to fire up a socket listener -on that interface and include it in her list of reachable addresses. The -properties mappings are left for future expansion.

- -

Connection establishment with a valid tag:

-

With a valid tag and nonce received, both Alice and -Bob load up the previously negotiated sessionKey and set the -iv to the first 16 bytes of H(tag + nonce). The -remainder of the communication is AES256 encrypted per -{@link net.i2p.crypto.AESInputStream} and {@link net.i2p.crypto.AESOutputStream}

- -

3) Alice to Bob:
- H(nonce)

-

4) Bob to Alice:
- H(tag)

-

5) If the hashes are not correct, disconnect immediately and do not - consume the tag

-

6) Alice to Bob:
- routerInfo + currentTime + H(routerInfo + currentTime + nonce + tag)

-

7) Bob should now verify that he can establish a connection to her through one of the - routerAddresses specified in her RouterInfo. The testing process is described below.

-

8) Bob to Alice:
- routerInfo + status + properties + H(routerInfo + status + properties + nonce + tag)

-

9) If the status is okay, both Alice and Bob consume the - tagData, updating the next tag to be H(E(nonce + tag, sessionKey)) - (with nonce+tag padded with 12 bytes of 0x0 at the end). - Otherwise, both sides disconnect and do not consume the tag. In addition, on error the - properties mapping has a more detailed reason under the key "MESSAGE".

- - - -

Connection establishment without a valid tag:

- -

3) Alice to Bob
- X

-

4) Bob to Alice
- Y

-

5) Both sides complete the Diffie-Hellman exchange, setting the - sessionKey to the first 32 bytes of the result (e.g. (X^y mod p)), - iv to the next 16 bytes, and the nextTag to the 32 - bytes after that. The rest of the data is AES256 encrypted with those settings per - {@link net.i2p.crypto.AESInputStream} and {@link net.i2p.crypto.AESOutputStream}

-

6) Alice to Bob
- H(nonce)

-

7) Bob to Alice
- H(nextTag)

-

8) If they disagree, disconnect immediately and do not persist the tags or keys

-

9) Alice to Bob
- routerInfo + currentTime - + S(routerInfo + currentTime + nonce + nextTag, routerIdent.signingKey)

-

10) Bob should now verify that he can establish a connection to her through one of the - routerAddresses specified in her RouterInfo. The testing process is described below.

-

11) Bob to Alice
- routerInfo + status + properties - + S(routerInfo + status + properties + nonce + nextTag, routerIdent.signingKey)

-

12) If the signature matches on both sides and status is okay, both sides - save the sessionKey negotiated as well as the nextTag. - Otherwise, the keys and tags are discarded and both sides drop the connection.

- - - -

Peer testing

-

As mentioned in steps 7 and 10 above, Bob should verify that Alice is reachable -to prevent a restricted route from being formed (he may decide not to do this once -I2P supports restricted routes)

- -

1) Bob to Alice
- 0xFFFF + #versions + v1 [+ v2 [etc]] + properties

-

2) Alice to Bob
- 0xFFFF + versionOk + #bytesIP + IP + currentTime + properties

-

3) Both sides close the socket

- -{% endblock %} diff --git a/www.i2p2/pages/techintro.html b/www.i2p2/pages/techintro.html index 4d2f627e..ce3491cf 100644 --- a/www.i2p2/pages/techintro.html +++ b/www.i2p2/pages/techintro.html @@ -379,7 +379,7 @@ is the one who should receive a given message. The particulars of how routers communicate with other routers aren't critical - three separate protocols have been used at different points to provide those bare necessities.

-

I2P started with a TCP-based protocol which +

I2P started with a TCP-based protocol which has since been disabled. Then, to accommodate the need for high degree communication (as a number of routers will end up speaking with many others), I2P moved from a TCP based transport to a UDP-based one - "Secure