{% extends "_layout_de.html" %} {% block title %}I2NP{% endblock %} {% block content %}

Die Webseite wird gerade überholt und dieses Dokument kann alte Informationen enthalten

I2P Netzwerk Protokoll (I2NP)

Das I2P Netzwerk Protokoll (I2NP), welches zwischen I2CP und den verschiedenen I2P Transport Protokollen ist, verwaltet neben dem Routen und Mischen der Nachrichten zwischen den Routern auch die Auswahl des Transportes bei der Kommunikation zu anderen Routern, falls mehrere zur Auswahl stehen.

Während I2NP seit seiner Einführung im August 2003 recht stabil geblieben ist, hat es dennoch gelegentlich kleinere Modifikationen erfahren. Hier ist die I2NP Protokol Spezifikation Version 0.9 (pdf), datiert auf den 28. August 2003. Dieses Dokument referenziert auch auf die Allgemeine Daten Struktur Spezifikation Version 0.9. Achtung - durch einen flüchtigen Blick auf den Quelltext zeigt sich, das es bedeutende Unterschiede zwischen der derzeitigen Implementierung und der Spezifikation von 2003 gibt.

I2NP Definition

Hinweis - Die folgenden Informationen sind aus dem derzeitigem Quelltext extrahiert und können nicht komplett oder fehlerhaft sein. Kontrolliere zur Sicherheit den Quelltext.

I2NP (I2P Netzwerk Protokoll) Nachrichten können für Ein-Hop, Router-zu-Router oder Punkt-zu-Punkt Nachrichten benutzt werden. Durch das verschlüsseln und Einpacken in anderen Nachrichten können sie auf einem sicheren Weg über mehrere Hops bis zum endgültigen Ziel transportiert werden. Prioritäten werden nur lokal am Ursprung benutzt, z.B. beim Puffern der Ausgehenden Daten.

Sowohl die NTCP als auch die UDP Transporte haben Übertragungen mit Prioritäten implementiert, jedoch in recht unterschiedlichen Arten. UDP hat komplexen Code mit Puffern für jede Priorität, doch behandelt es z.B. Nachrichten mit der Priorität 400-499 ident. (Die Nachrichten Prioritäten sind 100,200,300,400,500 und 1000) Dieses sind globale Puffer für alle Knoten. NTCP hat eine triviale lineare Suche nach der höchsten Priorität in einem Puffer für einen bestimmten Knoten. Dieses ist bedeutend weniger effektiv.

Es ist nicht klar, ob das derzeitige Schema der Prioritäten im Ganzem effektiv ist und ob die Prioritäten der einzelnen Nachrichten weiter angepasst werden sollten. Dieses ist ein weiteres Feld an Nachforschungen, Analysen und Testen.

Nachrichten Format

FeldBytes
Eindeutige ID4
Lebensdauer8
Nutzdaten Länge2
Checksumme1
Nutzdaten0 - 64K

Arten von Nachrichten: Das folgende wurde vom Quelltext übernommen, nicht alle dieser Nachrichten müssen aktiv genutzt werden. Eine höhere Nummer bedeutet eine höhere Priorität. Die meiste Anzahl des Traffics sind TunnelDataMessages (Priorität 400), somit ist alles über 400 wirklich hohe Priorität und alles darunter niedrige Priorität. Zu beachten ist auch, dass viele dieser Nachrichten normalerweise durch die Erkundungstunnel geleitet werden und nicht durch die Kliententunnel un dsomit nicht in der selben Queue sein müssen, es sei denn, der erste Hop ist auf dem selben Knoten.

Auch werden nicht alle Nachrichtenarten unverschlüsselt versendet. Zum Beispiel packt ein Router zum Testen eines Tunnels eine DeliveryStatusMessage ein, die in einer GarlicMessage eingepackt ist, welche wiederrum in einer DataMessage eingepackt ist.

NachrichtTypusNutzdatenlängePrioritätKommentare
DatabaseLookupMessage 2 Typ. 71 100/400 400 normal; 100 wenn vom HarvesterJob und direkt gesendet; 400 zum Nachschlagen eines Routers
DatabaseSearchReplyMessage 3 Typ. 161 300 Grösse ist 65 + 32*(Anzahl der Hashes) üblicherweise, die Hashes zu drei Floodfillrrouter werden zurückgesendet.
DatabaseStoreMessage 1 Varies 100/400 Normalerweise 100 (warum?) Länge ist 898 Bytes für ein typisches 2-lease leaseSet. RouterInfo Strukturen sind gepackt und die Länge variert. In einer andauernden Arbeit bis zum Release 1.0 wird versucht, die in einer RouterInfo veröffentlichen Daten zu verringern.
DataMessage 20 4 - 65540 400
DeliveryStatusMessage 10 12   Zu Nachrichtenantworten und zum Tunneltesten genutzt - normalerweise in einer GarlicMessage eingepackt
GarlicMessage 11     Üblicherweise in einer DataMessage eingepackt- jedoch falls nicht eingepackt mit einer Priorität von 100 vom weiterreichendem Router versehen
TunnelBuildMessage 21 4224 300/500 Normalerweise 500 (warum?)
TunnelBuildReplyMessage 22 4224 300
TunnelDataMessage 18 1028 400 Die am meisten genutzte Nachricht. Priorität für Tunnelteilnehmer, ausgehende Endpunkte und eingehende Gateways ist seit Version 0.6.1.33 200. Ausgehende Gatewaynachrichten (z.B. die vom lokalem Knoten ausgehenden) haben eine Priorität von 400.
TunnelGatewayMessage 19   300/400
VariableTunnelBuildMessage 23 1057 - 4225 300/500 Shorter TunnelBuildMessage as of 0.7.12
VariableTunnelBuildReplyMessage 24 1057 - 4225 300 Shorter TunnelBuildReplyMessage as of 0.7.12
Weitere sind in den 2003 Spec aufgelistet. 0,4-9,12     Unbenutzt
{% endblock %}