Există câteva tehnici majore care pot fi făcute pentru a îmbunătăți percepția performanța I2P - unele dintre următoarele sunt legate de procesor, altele de lățimea de bandă , iar altele sunt în continuare legate de protocol. Cu toate acestea, toate acestea dimensiunile afectează latența, randamentul și performanța percepută a de rețea, deoarece reduc conținutul pentru resursele limitate. Această listă desigur nu este cuprinzătoare, dar le acoperă pe cele majore văzute.

Pentru îmbunătățiri ale performanței anterioare, consultați secțiunea Istoricul performanțelor.

Mai bună profilare și selecție de la egal la egal

Probabil una dintre cele mai importante părți ale obținerii unei performanțe mai rapide o va face să îmbunătățească modul în care routerele aleg colegii prin care își construiesc tunelurile - asigurându-vă că nu folosesc colegi cu legături lente sau cele cu legături rapide care sunt supraîncărcate etc. În plus, trebuie să ne asigurăm că nu ne expunem noi înșine la un atac Sybil de la un adversar puternic, cu o mulțime de mașini rapide.

Reglarea bazelor de date în rețea

Vom dori să fim mai eficienți cu vindecarea bazei de date a rețelei și algoritmi de întreținere - în loc să exploreze constant spațiul cheie pentru noi colegii - provocând un număr semnificativ de mesaje de rețea și încărcare de router - noi poate încetini sau chiar opri explorarea până când detectăm că este ceva nou merită găsit (de exemplu, decăderea ratei de explorare în funcție de ultima dată pe cineva ne-a dat o referire la cineva despre care nu auzisem niciodată). Putem face și unele acordarea a ceea ce trimitem de fapt - câți colegi ne respingem înapoi (sau chiar dacă noi respingeți un răspuns), precum și câte căutări simultane efectuăm.

Ajustarea și îmbunătățirile etichetelor de sesiune

Modul în care algoritmul ElGamal / AES + SessionTag funcționează este prin gestionarea unui set de matrițe aleatorii cu o singură dată, cu 32 de octeți, și expiră dacă nu sunt folosite destul de repede. Dacă le expirăm prea curând, suntem forțati să cadă din nou pe o criptare ElGamal (scumpă) completă, dar dacă nu expirați-le suficient de repede, trebuie să le reducem cantitatea, astfel încât să nu facem rămâne fără memorie (și dacă destinatarul este cumva corupt și pierde unele etichete, pot apărea chiar mai multe eșecuri de criptare înainte de detectare). Cu careva algoritmi mai activi de detecție și feedback, putem asigura în siguranță și mai mult reglați eficient durata de viață a etichetelor, înlocuind criptarea ElGamal cu o operație AES banală.

Idei suplimentare pentru îmbunătățirea livrării Etichetelor de sesiune sunt descrise pe document Pagina ElGamal / AES + SessionTag.

Migrează sesiunea Tag către PRNG sincronizat

În acest moment, algoritmul ElGamal / AES + SessionTag funcționează prin etichetarea fiecărui mesaj criptat cu un random unic 32 byte nonce (o „etichetă de sesiune”), identificând mesajul ca fiind criptat cu cheia sesiunii AES asociate. Acest lucru împiedică semenii să distingă mesaje care fac parte din aceeași sesiune, deoarece fiecare mesaj are o etichetă complet nouă aleatorie. Pentru a realiza acest lucru, fiecare câteva mesaje conțin un nou întreg set de etichete de sesiune din mesajul criptat în sine, în mod transparent livrarea unei modalități de identificare a mesajelor viitoare. Atunci trebuie să urmărim ce mesaje sunt livrate cu succes, astfel încât să știm ce etichete putem folosi.

Acest lucru funcționează bine și este destul de robust, însă este ineficient din punct de vedere de utilizare a lățimii de bandă, deoarece necesită livrarea acestor etichete înainte timp (și nu toate etichetele pot fi necesare sau unele pot fi pierdute din cauza expirarii lor). Totuși, în medie, predelectarea costă eticheta de sesiune 32 de octeți pe mesaj (dimensiunea unei etichete). După cum sugera Taral, totuși dimensiunea poate fi evitată înlocuind livrarea etichetelor cu una sincronizată PRNG - când se stabilește o nouă sesiune (printr-un cod ElGamal criptat bloc), ambele părți plantează un PRNG pentru utilizare și generează etichetele de sesiune la cerere (destinatarul precalculând următoarele câteva valori posibile să se ocupe de livrare fără comandă).

Tuneluri de durată mai lungă

Cu toate acestea, durata actuală a tunelului implicită de 10 minute este destul de arbitrară se "simte bine". Odată ce avem cod de vindecare a tunelului și detectarea mai eficienta a eșecului, vom putea varia mai în siguranță aceste durate, reducând rețea și încărcarea procesorului (datorită mesajelor costisitoare de creare a tunelului).

Aceasta pare a fi o soluție ușoară pentru încărcare mare pe routerele cu lățime mare de bandă, dar nu trebuie să recurgem la asta până nu am reglat mai departe algoritmii de construire a tunelului. Cu toate acestea, durata de viață a tunelului de 10 minute este codată în câteva locuri, astfel încât să fie nevoie de efort substanțial pentru modificarea duratei. De asemenea, ar fi dificil să se mențină compatibilitatea înapoi cu o astfel de modificare.

În prezent, întrucât rata medie de succes a construirii tunelurilor din rețea este destul de mare, nu există planuri actuale de prelungire a duratei de viață a tunelului.

Reglați intervalele de timp

Cu toate acestea, alte lucruri destul de arbitrare, dar „bine”, le avem intervale de timp curente pentru diverse activități. De ce avem un coleg de 60 de secunde "timeout" de neatins? De ce încercăm să trimitem prin alt tunel care a LeaseSet face reclame după 10 secunde? De ce sunt interogările bazei de date din rețea delimitat cu 60 sau 20 de limite? De ce sunt configurate destinațiile pentru a cere a nou set de tunele la fiecare 10 minute? De ce permitem 60 de secunde pentru un coleg răspundeți la solicitarea noastră de a se alătura unui tunel? De ce considerăm un tunel care nu ne trece testul în 60 de secunde „mort”?

Fiecare dintre aceste necondiționate poate fi adresat și cu un cod mai adaptiv ca parametri reglabili care să permită compensări mai adecvate între lățimea de bandă, latența și utilizarea procesorului.

Îmbunătățirea completă a protocolului de streaming

• Poate reactivă profilul fluxului interactiv ( implementarea curentă folosește doar profilul fluxului în vrac).
• Limitarea lățimii de bandă la nivel de client (în oricare sau ambele direcții ale unui flux, sau posibil împărtășit pe mai multe fluxuri). Acest lucru ar fi în plus față de limitarea generală a lățimii de bandă a routerului, desigur.
• Listele de control de acces (care permit doar fluxuri către sau din anumite destinații altor persoane cunoscute).
• Controale web și monitorizarea stării de sănătate a diferitelor fluxuri ca abilitatea de a le închide sau accelera explicit.

Idei suplimentare pentru îmbunătățirea bibliotecii de streaming sunt descrise pe site pagina bibliotecii streaming.