Det finns flera viktiga tekniker som kan utföras för att förbättra den uppfattade prestandan av I2P - vissa av de följande är CPU-relaterade, andra bandbredds-relaterade och andra är protokoll-relaterade. Dock, så påverkar alla de aspekterna fördröjning, kapacitet och uppfattad prestanda av nätverket, eftersom de minskar kampen om otillräckliga resurser. Denna listan är naturligtvis inte komplett, men den täcker de viktigaste som tekniker ses.
För tidigare prestandaförbättringar se Prestanda Historiken.
Bättre jämlike-profilering och urval
Troligvis kommer en av de viktigaste delarna för att få bättre prestanda vara att förbättra hur routrar väljer de jämlikar de bygger sina tunnlar genom - genom att övertyga sig om att de inte använder jämlikar med långsamma uppkopplingar eller sådana med snabba uppkopplingar men som är överbelastade, t.ex. Utöver det, så måste vi vara säkra på att vi inte utsätter oss själva för en Sybil-attack från en kraftfull motståndare med massor av snabba maskiner.
Inställning av nätverksdatas
Vi kommer vilja vara mer effektiva med nätverksdatabasens läkande och underhållande algoritmer - istället för att konstant utforska nyckelrymden efter nya jämlikar - som orsakar ett stort antal nätverksmeddelanden och routerbelastning - vi kan sakta ner eller till och med stanna utforskningen tills vi finner något nytt värt att hitta (t.ex minska utforskningshastigheten baserat på den senaste gången någon gav oss en referens till någon vi aldrig hört talas om). Vi kan också göra några inställningar för vad vi faktiskt skickar - hur många jämlikar vi skickar tillbaka (eller till och med om vi skickar tillbaka ett svar), såväl som hur många samtidiga sökningar vi utför.
Session Tag Inställning och Förbättring
Sättet ElGamal/AES+SessionTag algoritmen fungerar är genom att hantera ett set av slumpmässiga engångsanvändnings 32 bytes arrayer, och att låta deras tidsgiltighet rinna ut om dom inte används snabbt nog. Om vi låter deras tidsgiltighet rinna ut för snabbt så faller vi tillbaka till en full (dyr) ElGamal kryptering, men om vi inte låter deras tidsfrist rinna ut snabbt nog, så måste vi reducera deras kvantitet så att vi inte tar slut på minne (och om mottagaren på något vis blir korrupt och förlorar några taggar, så kan ännu fler krypteringsfel inträffa innan det hittas). Med lite mer aktiv diagnosticering och responsdrivna algoritmer, så kan vi säker och mer effektivt ställa in lifstiden av taggarna, som ersätter ElGamal-krypteringen med en enkel AES operation.
Fler idéer för att förbättra Session Tag utdelningen beskrivs på ElGamal/AES+SessionTag sidan.
Migrera sessionTag till synkroniserad PRNG
Just nu, så fungerar vår ElGamal/AES+SessionTag-algoritm genom att tagga varje krypterat meddelande med ett unikt slumpmässigt 32 bytes nonce (en "session tag"), som identifierar att meddelandet krypteras med den associerade AES-sessionsnyckeln. Detta hindrar jämlikar från att urskilja meddelanden som är en del av samma session, eftersom varje meddelande har en helt ny slumpmässig tagg. För att uppnå detta, måste ett nytt set av sessionstaggar skickas med ett meddelande efter några få meddelanden, vilket transparent ger ett sätt att identifiera framtida meddelanden. Vi måste sedan hålla koll på vilka meddelanden som lyckats skickas så vi vet vilka taggar vi kan använda.
Detta fungerar utmärkt och är tämligen robust, däremot är det ineffektivt i frågan om bandbreddsanvändning, eftersom det kräver att taggarna mottages i förväg (och alla taggar behövs kanske inte, vissa är onödiga, p.g.a. tidsbegränsningar). I det genomsnittliga fallet, kostar det 32 bytes (storleken av en tagg) att förleverera sessionstaggar per meddelande. Som Taral föreslog så, kan den storleken undvikas denom att ersätta skickande av taggarna med en synkroniserad PRNG - när en ny session etableras (genom ett ElGamal-krypterat block), båda sidorna distribuerar ett PRNG som används för att generera sessions taggarna på begäran (med mottagaren förberäknar de nästkommande möjliga värdna för att hantera mottagning i annan ordning).
Tunnlar som varar längre
Den nuvarande standardtunnelns varaktighet på 10 minuter är ganska godtycklig, även om det "känns okej". När vi har tunnelläkningskod och effektivare feldetektering, kommer vi att kunna variera dessa varaktigheter på ett säkrare sätt, vilket minskar nätverks- och CPU-belastningen (på grund av dyra tunnelskapande meddelanden).
Detta verkar vara en enkel lösning för hög belastning på routrar med mycket bandbredd, men vi borde inte använda den utvägen innan vi ställt int algoritmerna för att bygga tunnlar vidare. Dock, så är livstiden för tunnlar, 10 minuter, hårdkodad på ett antal platset, så en stor ansträngning hade krävts för att ändra livstident. Det hade också varit svårt att bibehålla bakåtkompabilitet med en sådan förändring.
Eftersom nätverkets genomsnittliga sannolikthet att lyckas bygga en tunnel för närvarande är ganska hög, så finns det för tillfället inga planer att förlänga tunnlars livstid.
Justera timeouterna
Ytterligare en av det ganska slumpmässiga sakerna som "känns okej" som vi har är de nuvarande timeouterna för olika aktiviteter. Varför har vi en 60 sekunders "onåbar jämlike"-timeout? Varför försöker vi skicka genom en annan tunnel som ett LeaseSet annonserar efter 10 sekunder? Varför är nätverksdatabas-förfrågningar begränsade mellan 60 och 20 sekunders gränser? Varför är destinationer inställda att fråga efter ett nytt set av tunnlar var 10:e minute? Varför väntar vi upp till 60 sekunder efter ett svar från en jämlike efter vi begärt att de går med i en tunnel? Varför tycker vi att en tunnel som inte klarar våra tester inom 60 sekunder är "död"?
Var och en av dessa tankeställare kan lösas med mer adaptiv kod, men även med inställningsbara parametrear för att tillåta mer lämpliga utbyten mellan bandbredd, fördröjning och CPU-användning.
Förbättringar i det fulla streaming protokollet
- Kanske återaktivera den interaktiva stream progilen (den nuvarande implementationen använder bara bulk stream profilen).
- Begränsningar av klient-nivå bandbredd (i antingen eller båda riktningarna av en stream, eller möjligtvis delat över flera streams). Detta skulle vara utöver routerns generella bandbredds-begränsningar, så klart.
- Tillgångs kontroll-listor (bara tillåta streams till eller från vissa andra kända destinationer).
- Webbkontroller och övervakning av hälsan av de olika streamarna, men även möjligheten att explicit stänga eller begränsa dom.
Ytterligare idéer för att förbättra streaming biblioteket är beskrivna på streaming biobliotekets sida.