Übersicht
Das I2P-Netzwerkprotokoll (I2NP), das zwischen I2CP und den verschiedenen I2P-Transportprotokollen liegt, verwaltet das Routing und die Vermischung von Nachrichten zwischen Routern sowie die Auswahl der zu verwendenden Transporte, wenn mit einem Peer kommuniziert wird, für den mehrere gemeinsame Transporte unterstützt werden.
I2NP-Definition
I2NP-(I2P-Netzwerkprotokoll-)Nachrichten können für Ein-Sprung-, Router-zu-Router-, Punkt-zu-Punkt-Nachrichten verwendet werden. Durch Verschlüsselung und Einbetten von Nachrichten in andere Nachrichten können sie sicher über mehrere Zwischenstationen an das endgültige Ziel gesendet werden. Die Priorität wird nur lokal am Ursprungsort verwendet, d. h. beim Warten auf den Ausgangsversand.
Die unten aufgeführten Prioritäten sind möglicherweise nicht aktuell und können sich ändern. Die Implementierung der Prioritätswarteschlangen kann variieren.
Nachrichtenformat
Die folgende Tabelle legt den traditionellen 16-Byte-Header fest, der in NTCP verwendet wird. Die SSU- und NTCP2-Transportschichten verwenden modifizierte Header.
| Field | Bytes |
|---|---|
| Type | 1 |
| Unique ID | 4 |
| Expiration | 8 |
| Payload Length | 2 |
| Checksum | 1 |
| Payload | 0 - 61.2KB |
Die maximale Anzahl an Fragmenten beträgt 64, und die Nachricht ist möglicherweise nicht perfekt ausgerichtet, sodass die Nachricht nominell in 63 Fragmenten Platz haben muss.
Die maximale Größe eines anfänglichen Fragments beträgt 956 Bytes (unter der Annahme des TUNNEL-Liefermodus); die maximale Größe eines nachfolgenden Fragments beträgt 996 Bytes. Daher beträgt die maximale Größe ungefähr 956 + (62 × 996) = 62708 Bytes oder 61,2 KB.
Zusätzlich können die Transportschichten zusätzliche Beschränkungen aufweisen. Die NTCP-Begrenzung liegt bei 16KB - 6 = 16378 Bytes. Die SSU-Begrenzung beträgt etwa 32 KB. Die NTCP2-Begrenzung liegt bei etwa 64KB - 20 = 65516 Bytes, was höher ist als das, was ein Tunnel unterstützen kann.
Beachten Sie, dass dies nicht die Grenzwerte für Datagramme sind, die der Client wahrnimmt, da der Router ein Antwort-LeaseSet und/oder Sitzungstags zusammen mit der Client-Nachricht in einer Garlic-Nachricht bündeln kann. Das LeaseSet und die Tags können zusammen etwa 5,5 KB hinzufügen. Daher beträgt die aktuelle Datagramm-Grenze etwa 10 KB. Diese Grenze wird in einer zukünftigen Version erhöht werden.
Nachrichtentypen
Eine höhere Prioritätsnummer bedeutet eine höhere Priorität. Der Großteil des Datenverkehrs besteht aus TunnelDataMessages (Priorität 400), sodass alles darüber im Wesentlichen hohe Priorität hat und alles darunter niedrige Priorität. Beachten Sie außerdem, dass viele Nachrichten im Allgemeinen über explorative Tunnel und nicht über Client-Tunnel weitergeleitet werden und sich daher möglicherweise nicht in derselben Warteschlange befinden, es sei denn, die ersten Hops liegen zufällig auf demselben Peer.
Außerdem werden nicht alle Nachrichtentypen unverschlüsselt gesendet. Beispielsweise umfasst der Router beim Testen eines Tunnels eine DeliveryStatusMessage, die in eine GarlicMessage eingepackt ist, die wiederum in eine DataMessage eingepackt ist.
| Message | Type | Payload Length | Priority | Comments |
|---|---|---|---|---|
| DatabaseLookupMessage | 2 | 500 | May vary | |
| DatabaseSearchReplyMessage | 3 | Typ. 161 | 300 | Size is 65 + 32*(number of hashes) where typically, the hashes for three floodfill routers are returned. |
| DatabaseStoreMessage | 1 | Varies | 460 | Priority may vary. Size is 898 bytes for a typical 2-lease leaseSet. RouterInfo structures are compressed, and size varies; however there is a continuing effort to reduce the amount of data published in a RouterInfo. |
| DataMessage | 20 | 4 - 62080 | 425 | Priority may vary on a per-destination basis |
| DeliveryStatusMessage | 10 | 12 | Used for message replies, and for testing tunnels - generally wrapped in a GarlicMessage | |
| GarlicMessage | 11 | Generally wrapped in a DataMessage - but when unwrapped, given a priority of 100 by the forwarding router | ||
| TunnelBuildMessage | 21 | 4224 | 500 | |
| TunnelBuildReplyMessage | 22 | 4224 | 300 | |
| TunnelDataMessage | 18 | 1028 | 400 | The most common message. Priority for tunnel participants, outbound endpoints, and inbound gateways was reduced to 200 as of release 0.6.1.33. Outbound gateway messages (i.e. those originated locally) remains at 400. |
| TunnelGatewayMessage | 19 | 300/400 | ||
| VariableTunnelBuildMessage | 23 | 1057 - 4225 | 500 | Shorter TunnelBuildMessage as of 0.7.12 |
| VariableTunnelBuildReplyMessage | 24 | 1057 - 4225 | 300 | Shorter TunnelBuildReplyMessage as of 0.7.12 |
| Others (Types 0, 4-9, 12) | 0, 4-9, 12 | Obsolete, Unused |
Siehe die I2NP-Spezifikationsseite für die vollständige Protokollspezifikation. Siehe auch die Spezifikationsseite für gemeinsame Datenstrukturen .
Zukünftige Arbeiten
Es ist unklar, ob das derzeitige Prioritätenschema allgemein wirksam ist und ob die Prioritäten für verschiedene Nachrichten weiter angepasst werden sollten. Dies ist ein Thema für weitere Forschung, Analyse und Tests.