Man kann mehrere Ansätze verfolgen, mit denen die gefühlte Performanz von I2P verbessert werden kann - manche der folgenden beziehen sich auf die Nutzung der CPU, andere auf die der Bandbreite, und wiederum andere auf das Protokoll. Jedoch wirken sich alle diese Faktoren auf Latenz, Durchsatz und gefühlte Netzwerkperformanz aus, da sie die Konkurrenz um knappe Ressourcen verringern. Diese Liste ist natürlich nicht umfassend, aber sie deckt die wichtigsten ab, die auftreten.

Für bisherige Leistungsverbesserungen, schauen Sie in der Performance Historie nach.

Besseres Profiling und Auswahl der Knoten

Vielleicht das Wichtigste, dass getan werden kann, um eine schnellere Performance zu erzielen, ist zu verbessern, wie Router die Peers auswählen, durch die sie ihre Tunnel bauen. - sicherzustellen, dass sie keine Peers mit langsamer Verbindung benutzen oder solche mit schneller Verbindung, die aber überlastet sind, etc. Zusätzlich müssen wir sicherstellen, dass wir uns keiner Sybil Attacke eines mächtigen Gegners mit vielen schnellen Maschinen aussetzen.

Netzwerkdatenbankabstimmung

Wir sind auf dem Weg, bei der Selbstheilung der Datenbank und bei Wartungsalgorhytmen effizienter werden zu wollen, anstatt permanent die Übersicht der Schlüssel nach neuen Peers zu überwachen - was zu einer erheblichen Zahl an Netzwerknachrichten und Belastung des Routers führt. Wir können diese reduzieren oder die Suche komplett stoppen, bis wir erkennen, dass es etwas Neues von Relevanz gibt (z.B. die Erkundungsrate in Abhängigkeit davon zu verringern, wann uns jemand zuletzt eine uns zuvor nicht bekannte Referenz übermittelte). Wir können auch einstellen, was wir tatsächlich senden - wie viele Peers wir zurückspielen oder sogar ob wir überhaupt eine Antwort übermitteln, so wie die Anzahl, wie viele parallele Erkundungen durchführt werden.

Session-Tag Optimierungen Verbesserungen

Die Art wie der ElGamal/AES+SessionTag Algorithmus arbeitet, ist durch Management eines Satzes von zufälligen Einmal-32-Byte-Arrays und deren Verfall, wenn sie nicht schnell genug abgerufen werden. Wenn wir diese zu schnell verwerfen, dann sind wir gezwungen, auf eine vollständige (teure) ElGamal Verschlüsselung zurückzugreifen, aber wenn wir sie nicht schnell genug auslaufen lassen, dann müssen wir deren Menge reduzieren, damit uns der Speicher nicht ausgeht (und wenn der Empfänger fehlerhafte Pakete erhält, damit einige verliert, könnten sogar noch mehr Verschlüsselungsfehler entstehen, bevor dies erkannt wird). Mit einem etwas aktiverem Algorithmus mit Ausrichtung auf Erkennung und Feedback, können wir sicherer und effektiver die Laufzeit der Tags bestimmen und dabei die ElGamal-Verschlüsselung mit einer trivialeren AES Operationi ersetzen.

Zusätzliche Ideen zur Verbesserung des Session Tags, Bereitstellung und Beschreibung auf der ElGamal/AES+SessionTag Seite.

sessionTag nach synchoronized PRNG migrieren

Right now, our ElGamal/AES+SessionTag algorithm works by tagging each encrypted message with a unique random 32 byte nonce (a "session tag"), identifying that message as being encrypted with the associated AES session's key. This prevents peers from distinguishing messages that are part of the same session, since each message has a completely new random tag. To accomplish this, every few messages bundle a whole new set of session tags within the encrypted message itself, transparently delivering a way to identify future messages. We then have to keep track of what messages are successfully delivered so that we know what tags we may use.

This works fine and is fairly robust, however it is inefficient in terms of bandwidth usage, as it requires the delivery of these tags ahead of time (and not all tags may be necessary, or some may be wasted, due to their expiration). On average though, predelivering the session tag costs 32 bytes per message (the size of a tag). As Taral suggested though, that size can be avoided by replacing the delivery of the tags with a synchronized PRNG - when a new session is established (through an ElGamal encrypted block), both sides seed a PRNG for use and generate the session tags on demand (with the recipient precalculating the next few possible values to handle out of order delivery).

Tunnel von längerer Dauer

Die derzeitige Voreinstellung von 10 Minuten für die Dauer von Tunnelverbindungen ist ziemlich willkürlich gewählt, aber "dem Gefühl nach" in Ordnung. Sobald wir Tunnel wiederherstellen und effektiver Probleme erkennen können, werden wir es leichter haben, diese Dauer zu variieren, was zur Entlastung der Netzwerkverbindung und der CPU (aufgrund des sonst aufwändigen Tunnelneuaufbaus) führt.

Dies scheint eine einfache Lösung für hohe Belastung auf Routern mit großer Bandbreite zu sein, aber wir sollten nicht darauf bauen, bevor wir nicht den Algorithmus der Tunnelerzeugung weiter ausgefeilt haben. Zu beachten ist, dass eine Tunnel-Lebenszeit von 10 Minuten an vielen Stellen fest programmiert ist und die Änderung der Laufzeit ist mit nicht unerheblichem Aufwand verbunden. Darüber hinaus wäre es bei einer solchen Änderung schwierig, die Rückwärtskompatibilität zu warhen.

Currently, since the network average tunnel build success rate is fairly high, there are no current plans to extend tunnel lifetime. Da die Erfolgsrate des durchschnittlichen Tunnelaufbaus relativ hoch ist, gibt es momentan keine Pläne, die Laufzeit von Tunneln zu verlängern.

Die Zeitüberschreitungen anpassen

Yet another of the fairly arbitrary but "okay feeling" things we've got are the current timeouts for various activities. Why do we have a 60 second "peer unreachable" timeout? Why do we try sending through a different tunnel that a LeaseSet advertises after 10 seconds? Why are the network database queries bounded by 60 or 20 second limits? Why are destinations configured to ask for a new set of tunnels every 10 minutes? Why do we allow 60 seconds for a peer to reply to our request that they join a tunnel? Why do we consider a tunnel that doesn't pass our test within 60 seconds "dead"?

Jeder von diesen Unwägbarkeiten kann mit adaptiverem Programmcode begegnet werden, sowie mit Abstimmung von Parametern, um einen angemessenen Kompromiss zwischen Bandbreite, Latenz und CPU-Auslastung zu finden.

Vollständige Streaming Protokoll Verbesserungen

• Vielleicht die Wiederermöglichung des Interactive-Stream-Profils (die momentane Implementierung nutzt nur das Block-Stream-Profil).
• Limitierung der Bandbreite auf Cient-Ebene (in entweder eine oder beide Richtungen eines Steams, oder möglicherweise verteilt über multiple Streams). Dies wäre natürlich zusätzlich zu der gesamten Limitierung der Routerbandbreite
• Zugriffs-Kontroll-Listen (nur Streams zu oder von bestimmten Zieladressen Zugriff gewähren)
• Web Kontrolle und Monitoring der Gesundheit der vielfachen Streams, so wie die Möglichkeit diese explizit zu schliessen bzw. zu drosseln.

Zusätzliche Ideen zur Verbesserung der Streaming Bibliothek sind beschrieben auf der Streaming Bibliothek Seite.