@@ -69,7 +69,7 @@ Falls deine native jbigi Bibliothek problemlos funktioniert kommt der Grossteil der CPU Last wahrscheinlich vom Routen der "Participating Tunnel". Dieses erzeugt Last auf der CPU, da bei jedem Hop eine Schicht von Verschlüsselung dekodiert werden muss. Du kannst die Ausnutzung durch "Participating -Tunnel" auf 2 Wegen beschräken - durch reduzieren der "shared Bandbreite" +Tunnel" auf 2 Wegen beschränken - durch reduzieren der "shared bandwith" auf der Seite config.jsp oder durch setzen von router.maxParticipatingTunnels=nnn auf der Seite @@ -89,14 +89,14 @@ akzeptieren müssen. Aber lass uns die Frage in 3 Teilen beantworten:
Nein, im Gegensatz zum Tor Netzwerk, sind "Ausgangspunkt" oder "Outproxies" nicht in der Installation von I2P enthalten - und somit nicht Standard Teil des Netzwerkes. - Nur Freiwillige, die eine zusäiche Anwendung installieren und betreiben + und somit nicht Standard-Teil des Netzwerkes. + Nur Freiwillige, die eine zusäiche Anwendung installieren und betreiben, können Daten ins normale Netz umsetzen. Es gibt nur sehr wenige davon.
- Siehe oben. Es gibt nur wenige HTTP "outproxies", diese nicht ein automatischer Teil des - Netzwerkes und sie können nicht aktiv sein. + Siehe oben. Es gibt nur wenige HTTP "outproxies", diese nicht ein offizieller Teil des + Netzwerkes und sie können inaktiv sein. hinzu kommt, das die Outproxies squid.i2p, true.i2p und krabs.i2p nicht mehr aktiv sind. Der einzige aktive zur Zeit ist false.i2p. Um diesen zu benutzen, @@ -181,7 +181,7 @@ von höheren Bandbreitenlimits (Mehr Bandbreite freigeben). möglich, versuche einfach diese zu installieren, mit einem Standard Tunnel zu konfigurieren und probiere es einfach aus! Wie schon mehrmals im oberen Bereich erklärt sind Outproxies nicht Bestandteil des - eigentlichen I2P Netzwerkes, es sind Dienste die von einzelnen Personen betrieben werden + eigentlichen I2P Netzwerkes. Es sind Dienste die von einzelnen Personen betrieben werden und jederzeit funktionieren oder nicht funktionieren können. Falls Du einen Outproxy aufsetzen möchtest, betrachte sorgfältig die möglichen Risiken davon. @@ -335,13 +335,13 @@ verbinden oder mit einem Passwort sichern?
Bitte schaue auf der Todoliste nach für mehr detailiertere Informationen -zu mehreren dieser aufgaben.
+Bitte schaue auf der Todoliste nach nach detaillierteren +Informationen zu diesen Aufgaben.
{% endblock %} diff --git a/www.i2p2/pages/todo_de.html b/www.i2p2/pages/todo_de.html index 06f234a4..bb2e7da7 100644 --- a/www.i2p2/pages/todo_de.html +++ b/www.i2p2/pages/todo_de.html @@ -1,10 +1,10 @@ {% extends "_layout_de.html" %} {% block title %}To Do Liste{% endblock %} -{% block content %}Hier ist eine detailietere (und dennoch unvollständige) +{% block content %}
Hier ist eine detaillietere (und dennoch unvollständige) Diskussion der wichigsten Gebiete zur zukünftigen Entwicklung des grundlegenden I2P Netzwerkes, übergreifend über die zukünftigen geplanten Versionen. Dieses beinhaltet nicht steganographische Transporte, anpassen auf kabellose Geräte -oder Werkzeuge zum sichern der lokale Computer. Ebenfalls sind die Klientenanwendungen +oder Werkzeuge zum absichern der eigenen Computer gegen Angriffe. Ebenfalls sind die Klientenanwendungen nicht dabei, die unverzichtbar für den Erfolg von I2P sind. Es werden mehr Themen folgen, besonders alsbald I2P mehr Überprüfungen bekommt, aber hier sind zumindest die "grossen Themen" aufgelistet. @@ -16,10 +16,11 @@ Möchtest du helfen? Beteilige Dich!
Um dieses zu erreichen, verbinden diese Knoten einfach mit ein paar anderen -Knoten, bauen einen Tunnel durch diese auf und veröffentlichen eine +
Hierfür verbinden sich die nicht erreichbaren Knoten einfach mit ein paar anderen +Knoten, bauen einen Tunnel durch sie auf und veröffentlichen eine Referenz auf diese Tunnel in Ihrer RouterInfo Struktur in der Netzwerk Datenbank.
@@ -81,15 +82,15 @@ Verbindungen empfangen kann (nicht auch versteckt ist). Falls das der Fall ist, kann er einfach die garlic geroutete Nachricht über den Eingangstunnel des Ausgangsrouter zurückrouten.. -Dieses ist nicht dazu gedach, die IP eines Knotens zu verstecken, es ist -eher eine Möglichkeit um Leuten hinter NATs und Firewalls ganz am +
Hierbei geht es nicht darum, die IP eines Knotens zu verstecken, es ist +eher eine Möglichkeit um Nutzern hinter NATs und Firewalls ganz am Netzwerk teilnehmen zu lassen. IPs zu verstecken braucht etwas mehr Arbeit, wie weiter unten beschrieben.
Mit dieser Technik kann jeder Router in einem Tunnel jede Aufgabe annehmen. Aus Effizienzgründen ist ein versteckter Knoten eine schlechte Wahl als -Eingangsgateway und innerhalb eines Tunnels, zwei benachbarte Knoten -sollten nicht versteckt sein, aber das ist technisch nicht nötig.
+Eingangsgateway. Innerhalb eines Tunnels sollten zwei benachbarte Knoten nicht +versteckt sein, dennoch wird diese Regel technisch nicht benötigt.Wir machen das aus CPU Sicht recht effizient - zu jeder Zeit sind fast alle Threads -idle, blockiert mit warten auf etwas zu tun. Jedoch braucht jeder Thread auch reale +
Wir machen das aus CPU-Sicht recht effizient - die meiste Zeit warten fast alle Threads +untätig. Jedoch braucht jeder Thread auch reale Ressourcen (auf älteren Linux Kernels war oft z.B. jeder Thread als ein abgeleiter Prozess implementiert). Sobald das Netzwerk wächst, wächst auch die Anzahl -Knoten, mit der ein jeder Router kommuizieren möchte (denke dran, I2P ist voll -verbunden, was meint, das jeder Knoten wissen sollte, wie er eine Nachricht zu einem -anderen Knoten bekommt und beschränkte Knoten sollten nicht wirklich die Anzahl +Knoten, mit der ein jeder Router kommuizieren möchte (man bedenke, dass I2P voll +verbunden ist, was bedeuted, das jeder Knoten wissen sollte, wie er eine Nachricht zu einem +anderen Knoten bekommt. Eine Einschränung der Routen sollten nicht wirklich die Anzahl der benötigten Verbindungen reduzieren). Somit wird in einem Netzwerk mit 100.000 Routern jeder einzelne bis zu 199.998 Threads NUR zum Abarbeiten der TCP Verbindungen haben!
@@ -119,18 +120,18 @@ Verbindungen haben! Transportschicht. In Java haben wir da 2 grosse Möglichkeiten:Das Senden und Empfangen von UDP Datagrammen geschieht verbindungslos - wenn wir -mit 100.000 Knoten kommunizieren, stecken wir einfach die UDP Pakete in einen -Stack und ein einzelner Thread liest diese aus dem Stack aus und schiebt diese -raus ins Netz (und um zu Empfangen, gibt es einen Thread, der alle eingehenden +
Das Senden und Empfangen von UDP Datagrammen geschieht ohne stehende Verbindung. +Auch bei 100.000 anderen Routern benötigt UDP nur einen einzelnen Thread, der +die ausgehenden Pakete aus einem Stack ausliest und versendet + (und um zu Empfangen, gibt es einen Thread, der alle eingehenden UDP Pakete einsammelt und diese an die Eingehende Queue weiterleitet).
UDP zu nutzen bedeuted aber auch, die Vorteile von TCP zu verlieren, wie z.B. die Reihenfolge der Pakete, Auslastungskontrolle, MTU Erkennung, usw. Dieses alles -zu implementieren wird viel Arbeit sein, aber I2P braucht nicht alle Featuers wie bei TCP. +zu implementieren wird viel Arbeit sein, aber I2P braucht nicht alle Featuers von TCP. Insbesondere habe ich beim Messen im Simulator und im Livenetz festgestellt, dass der Grossteil der transportierten Nachrichten problemlos in ein einzelnes unfragmentierten UDP Paket passt, wogegen die grössten in 20-30 Pakete passen. @@ -145,31 +146,32 @@ optimieren in Hinblick auf die speziellen Bedürfnisse von I2P.
NIO implementiert in I2P 0.6.1.22 ("NTCP")In Java 1.4 wurde ein ganzes Paket von sogenannten "New I/O" eingebaut, die den -Entwicklern die vorteile der nicht blockierende IO Fähigkeiten des Systems zu -nutzen erlauben - dieses erlaubt dir eine grosse Menge von gleichzeitigen IO -Operationen zu verwalten, ohne die Notwendigkeit eines seperaten Threads für -jede einzelne IO Operation. Dieser Ansatz verspricht vieles, da wir so eine grosse -Menge von gleichzeitigen Verbindungen verarbeiten k&oouml;nnen und ben&oouml;tigen -nicht einen selbstgeschriebenen Mini-TCP Stack in UDP. +Entwicklern erlaubt, die Vorteile der nicht-blockierenden IO-Fähigkeiten des Systems zu +Nutzen - dadurch kann eine grosse Menge von gleichzeitigen IO-Operationen verwaltet werden, +ohne die Notwendigkeit eines seperaten Threads für +jede einzelne IO-Operation. Dieser Ansatz ist vielversprechend, da wir auf diese Weise viele +Verbindungen gleichzeitig verarbeiten k&oouml;nnen und keinen +selbstgeschriebenen Mini-TCP Stack in UDP ben&oouml;tigen. Dennoch sind die NIO Pakete nicht ganz fehlerfrei, wie die Freenetentwickler -feststellen mussten Hinzu kommt, das wir mit NIO Support nicht die Open Source +feststellen mussten. Hinzu kommt, das wir mit NIO-Support nicht die Open Source JVMs wie z.B. Kaffe unterstützen, da -GNU/Classpath einen geringen Umfang an NIO +GNU/Classpath NIO nur im geringen Umfang unterstützt. -(Hinweis: dieses ist womöglich nicht mehr der Fall, da es Verbesserungen bei +(Hinweis: das ist womöglich schon/bald der Fall, da es Verbesserungen bei den Classpaths NIO gegeben hat, aber es ist unbekannt, wie weit diese verbessert sind.)
-Eine weitere Alternative in dem selbem Weg ist das +
Eine weitere Alternative in diese Richtung ist das Non Blocking I/O Paket - -eine grundsätzliche saubere NIO Implementierung (geschrieben bevor NIO da war). -Es funktioniert durchs Verwenden von ein paar OS Routinen des nichtblockierenden IO -und weiterreichen von Events an Java. Es scheint mit Kaffee zu funktionieren, obwohl +eine grundsätzliche saubere NIO-Implementierung (geschrieben bevor NIO da war). +Es verwendet einige BEtriebssystem-Routinen des nichtblockierenden IO +und reicht Events an Java weiter. Es scheint mit Kaffee zu funktionieren, obwohl es letztens nicht viel Entwicklung in dem Projekt gab (wohl durch die Java 1.4 NIO Entwicklung bedingt).
In der derzeitigen Netzwerkdatenbank und Profilemanagement Implementation haben wir uns die Freiheit genommen, ein paar praktische Vereinfachungen zu nutzen. Zum Beispiel @@ -195,47 +197,46 @@ für später.
Zur Zeit wissen bei einem 4 Hop Eingangstunnel Tunnel von Alice, von Alice aufgebaut -und bei Elvis startend, über Dave,Charlie und Bob zu Alice gehend -(A<--B<--C<--D<--E), alle 5 beteiligten Knoten die Tunnel ID "123", da die +
Zur Zeit wissen, wenn Alice einen 4-Hop Eingangstunnel aufbaut, der bei Elvis beginnt +und über Dave,Charlie und Bob zu Alice geht (A<--B<--C<--D<--E), +alle 5 beteiligten Knoten die Tunnel ID "123", da die Nachrichten damit bezeichnet sind. Wir möchten jedem Hop seine eigene Tunnel-Hop ID geben - Charlie bekommt Nachrichten über Tunnel 234 and reicht diese zum Tunnel 876 -an Bob weiter. Beabsichtigt wird damit, dass Bob oder Charlie wissen, das sie im Tunnel -von alice teilnehmen, denn wenn jeder Hop im Tunnel die selbe Tunnel ID hat, sind -"Collusion Attacken" nicht schwer auszuführen.
+an Bob weiter. Beabsichtigt wird damit, dass Bob oder Charlie nicht wissen, dass sie im Tunnel +von Alice teilnehmen. Unterschiedliche Tunnel IDs erschweren "Collusion-Attacken".Eine einzigartige TunnelID pro Hop hinzuzufügen ist nicht schwer, aber für sich alleine unzureichend. Falls Dave und Bob unter der Kontrolle des selben Angreifers stehen, könnten sie nicht anhand der Tunnel ID sagen, das sie am selben Tunnel -teilnehmen, jedoch können sie dieses anhand der Nachrichtentexte und -verifikationsstrukturen durch einen simplen Vergleich herausfinden. Um das zu verhindern +teilnehmen, jedoch können sie es anhand der Nachrichtentexte und +Verifikationsstrukturen durch einen simplen Vergleich herausfinden. Um das zu verhindern muss ein Tunnel eine schichtweise Verschlüsselung auf dem Wege nutzen, sowohl auf den Inhalt der getunnelten Nachricht als auch auf der Verifikationsstruktur (die zum -verhindern einfacher Attacken genutzt wird). Dieses braucht ein paar einfache Änderungen -an der TunnelMessage Struktur, als auch die Einbindung von pro-Hop geheimen Schlüsseln, -die beim Tunnelaufbau transportiert werden und zum Tunnel Gateway durchgereicht werden. +verhindern einfacher Attacken genutzt wird). Die TunnelMessage Struktur muss hierfür +geriongfügig geändert werden, als auch die Einbindung von pro-Hop geheimen Schlüsseln, +die beim Tunnelaufbau transportiert und zum Tunnel Gateway durchgereicht werden. Wir müssen eine maximale Tunnellänge setzen (z.B. 16 Hops) und dem Gateway sagen, das dieser die Nachricht mit jedem der 16 empfangenen geheimen Schlüsseln verschlüsseln muss, in umgekehrter Reihenfolge, und auch die Signatur der Prüfsumme der (verschlüsselten) Daten bei jedem Schritt verschlüsseln muss. -Das Gateway senden dann diese 16-fach verschlüsselte Nachricht mitsamt den 16-fachen -16 Felder weiten verschlüsselten Mapping an den ersten Hop. Dieser entschlüsselt +Das Gateway senden dann diese 16-fach verschlüsselte Nachricht mitsamt den 16-fachem, +16 Felder weiten, verschlüsselten Mapping an den ersten Hop. Dieser entschlüsselt die Nachricht und die Nutzdaten mit seinem geheimen Schlüssel, schaut in der 16 Felder weiten Mapping nach dem Eintrag, der zu seinem eigenem Hop passt (mit der Pro- -Hop Tunnel ID verschränkt) und prüft die Nutzdaten durchs checken gegen +Hop Tunnel ID gekennzeichnet) und prüft die Nutzdaten gegen die assoziierte signierte Prüfsumme.
-Der Tunnel Gateway hat immer noch mehr Informationen als die anderen Knoten im Tunnel -und ein übernehmen des Gateways und eines Tunnel Teilnehmers erlaubt diesen -Knoten zu vergleichen und die Tatsache bekanntzugeben, das beide im selben Tunnel sind. +
Das Tunnel Gateway hat immer noch mehr Informationen als die anderen Knoten im Tunnel +und die Übernahme des Gateways und eines Tunnel Teilnehmers erlaubt Angreifern, diesen +Knoten zu vergleichen und festzustellen, dass beide im selben Tunnel sind. Zusätzlich wissen benachbarte Knoten sowieso, das sie im selben Tunnel sind, da sie -wissen, an wen sie die Nachricht gesendet haben (und mit IP basierten Transporten ohne -beschränktes Routing wissen sie auch von wem die Nachricht kam). Dennoch erhöhen -diese genannten Techniken erheblich die Kosten zum Erreichen von aussagekräftigen -Daten bei längeren Tunneln.
+wissen, an wen sie die Nachricht gesendet haben. Mit IP basierten Transporten ohne +beschränktes Routing wissen sie auch von wem die Nachricht kam. Dennoch erhöhen +die oben genannten Techniken erheblich die Kosten um bei längeren Tuuneln +aussagekräftige Daten zu erlangen.