i2p.www/www.i2p2/pages/i2np_de.html

{% extends "_layout_de.html" %}
{% block title %}I2NP{% endblock %}
{% block content %}
<h2>I2P Netzwerk Protokoll (I2NP)</h2>
<p>
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.
</p>

<p>W&auml;hrend I2NP seit seiner Einf&uuml;hrung im August 2003 recht stabil
geblieben ist, hat es dennoch gelegentlich kleinere Modifikationen erfahren.
Hier ist die 
<a href="/_static/pdf/I2NP_spec.pdf">I2NP Protokol Spezifikation Version 0.9</a>
(pdf), datiert auf den 28. August 2003.
Dieses Dokument referenziert auch auf die 
<a href="/_static/pdf/datastructures.pdf">Allgemeine Daten Struktur Spezifikation Version 0.9</a>.
Achtung - durch einen fl&uuml;chtigen Blick auf den Quelltext zeigt sich,
das es bedeutende Unterschiede zwischen der derzeitigen Implementierung und
der Spezifikation von 2003 gibt.
</p>

<h3>I2NP Definition</h3>
<p>
<i>Hinweis</i> - Die folgenden Informationen sind aus dem derzeitigem (2008)
Quelltext extrahiert und k&ouml;nnen nicht komplett oder fehlerhaft sein.
Kontrolliere zur Sicherheit den Quelltext.
<p>
I2NP (I2P Netzwerk Protokoll) Nachrichten k&ouml;nnen f&uuml;r Ein-Hop, 
Router-zu-Router oder Punkt-zu-Punkt Nachrichten benutzt werden.
Durch das verschl&uuml;sseln und Einpacken in anderen Nachrichten
k&ouml;nnen sie auf einem sicheren Weg &uuml;ber mehrere Hops bis zum
endg&uuml;ltigen Ziel transportiert werden.
Priorit&auml;ten werden nur lokal am Ursprung benutzt, z.B. beim 
Puffern der Ausgehenden Daten.
<p>
Sowohl die NTCP als auch die UDP Transporte haben &Uuml;bertragungen mit
Priorit&auml;ten implementiert, jedoch in recht unterschiedlichen Arten.
UDP hat komplexen Code mit Puffern f&uuml;r jede Priorit&auml;t, doch
behandelt es z.B. Nachrichten mit der Priorit&auml;t 400-499 ident.
(Die Nachrichten Priorit&auml;ten sind 100,200,300,400,500 und 1000)
Dieses sind globale Puffer f&uuml;r alle Knoten.
NTCP hat eine triviale lineare Suche nach der h&ouml;chsten Priorit&auml;t
in einem Puffer f&uuml;r einen bestimmten Knoten.
Dieses ist bedeutend weniger effektiv.
<p>
Es ist nicht klar, ob das derzeitige Schema der Priorit&auml;ten im
Ganzem effektiv ist und ob die Priorit&auml;ten der einzelnen Nachrichten
weiter angepasst werden sollten.
Dieses ist ein weiteres Feld an Nachforschungen, Analysen und Testen.


<h3>Nachrichten Format</h3>
<p>

<table border=1>
<tr><td>Feld<td>Bytes
<tr><td>Eindeutige ID<td>4
<tr><td>Lebensdauer<td>8
<tr><td>Nutzdaten L&auml;nge<td>2
<tr><td>Checksumme<td>1
<tr><td>Nutzdaten<td>0 - 64K
</table>

<p>
Arten von Nachrichten:
Das folgende wurde vom Quelltext &uuml;bernommen, nicht alle
dieser Nachrichten m&uuml;ssen aktiv genutzt werden.
Eine h&ouml;here Nummer bedeutet eine h&ouml;here Priorit&auml;t.
Die meiste Anzahl des Traffics sind TunnelDataMessages (Priorit&auml;t 400),
somit ist alles &uuml;ber 400 wirklich hohe Priorit&auml;t und alles
darunter niedrige Priorit&auml;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&uuml;ssen,
es sei denn, der erste Hop ist auf dem selben Knoten.
<p>
Auch werden nicht alle Nachrichtenarten unverschl&uuml;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.
<p>


<table border=1>
<tr><td>Nachricht<td>Typus<td>Nutzdatenl&auml;nge<td>Priorit&auml;t<td>Kommentare
<tr><td>
DatabaseLookupMessage
<td align=right>2
<td>Typ. 71
<td align=right>100/400
<td>400 normal; 100 wenn vom HarvesterJob und direkt gesendet;
400 zum Nachschlagen eines Routers
<tr><td>
DatabaseSearchReplyMessage
<td align=right>3
<td align=right>Typ. 161
<td align=right>300
<td>Gr&ouml;sse ist 65 + 32*(Anzahl der Hashes) &uuml;blicherweise, die Hashes zu
drei Floodfillrrouter werden zur&uuml;ckgesendet.
<tr><td>
DatabaseStoreMessage
<td align=right>1
<td align=right>Varies
<td align=right>100/400
<td>Normalerweise 100 (warum?)
L&auml;nge ist 898 Bytes f&uuml;r ein typisches 2-lease leaseSet.
RouterInfo Strukturen sind gepackt und die L&auml;nge variert. In 
einer andauernden Arbeit bis zum Release 1.0 wird versucht, die
in einer RouterInfo ver&ouml;ffentlichen Daten zu verringern.
<tr><td>
DataMessage
<td align=right>20
<td align=right>4 - 65540
<td align=right>400
<tr><td>
DateMessage
<td align=right>16
<td>&nbsp;
<td>&nbsp;
<td>Obsolet (wurde von TCP genutzt), Datennachrichten sind jetzt im <a href="i2cp.html">I2CP</a> Layer ?
<tr><td>
DeliveryStatusMessage
<td align=right>10
<td align=right>12
<td>&nbsp;
<td>Zu Nachrichtenantworten und zum Tunneltesten genutzt - normalerweise
in einer GarlicMessage eingepackt
<tr><td>
<a href="techintro.html#op.garlic">GarlicMessage</a>
<td align=right>11
<td>&nbsp;
<td>&nbsp;
<td>&Uuml;blicherweise in einer DataMessage eingepackt- jedoch falls
nicht eingepackt mit einer Priorit&auml;t von 100 vom weiterreichendem
Router versehen
<tr><td>
<a href="tunnel-alt-creation.html#tunnelCreate.requestRecord">TunnelBuildMessage</a>
<td align=right>21
<td align=right>4224
<td align=right>300/500
<td>Normalerweise 500 (warum?)
<tr><td>
<a href="tunnel-alt-creation.html#tunnelCreate.replyRecord">TunnelBuildReplyMessage</a>
<td align=right>22
<td align=right>4224
<td align=right>300
<tr><td>
TunnelCreateMessage
<td align=right>6
<td>&nbsp;
<td>&nbsp;
<td>Obsolet - <a href="tunnel.html#tunnel.request">Alte Tunnelaufbaumethode</a>
<tr><td>
TunnelCreateStatusMessage
<td align=right>7
<td>&nbsp;
<td>&nbsp;
<td>Obsolet - <a href="tunnel.html#tunnel.request">Alte Tunnelaufbaumethode</a>
<tr><td>
TunnelDataMessage
<td align=right>18
<td align=right>1028
<td align=right>400
<td>Die am meisten genutzte Nachricht. Priorit&auml;t f&uuml;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&auml;t von 400.
<tr><td>
TunnelGatewayMessage
<td align=right>19
<td>&nbsp;
<td align=right>300/400
<tr><td>
Weitere sind in den
<a href="/_static/pdf/I2NP_spec.pdf">2003 Spec</a> aufgelistet.
<td>4,5,8,9,12
<td>&nbsp;
<td>&nbsp;
<td>Unbenutzt
</table>

{% endblock %}