Bemärkningsvärda prestandaförbättringar har gjorts genom att använda teknikerna nedan. Det finns mer att göra, se Prestanda sidan för nuvarande problem och tankar.

Native matte

[implementerad]

När jag senast profilerade I2P koden, så spenderades majoriteten av tiden inom en funktion i java.math.BigInteger, modPow. Hellre än att försöka finjustera denna metod, så kallar vi ut till GNU MP - ett galet snabbt matte-bibliotek (med finjusterad assembler för många arkitekturer). (Redaktör: se NativeBigInteger för snabbare asymmetrisk kryptografi)

ugha och duck arbetar på C/JNI länkkod, och den existerande javakoden är redan utrustad med hooks för det när det är färdigt. Preliminära resultat ser fantastiska ut - att köra routern med native GMP modPow ger över 800% hastighetsökning i krypteringsprestanda, och lasten halverades. Detta var bara på en användares maskin, och saker och ting är långt ifrån färdiga för paketering och leverans än.

Lök inpackning av "svars" LeaseSet

[implementerad men behöver finjustering]

Denna algoritm-finjustering kommer bara vara relevant för program som vill att deras noder ska svara dem (men det inkluderar allting som använder I2PTunnel eller mihis ministreaming-bibliotek):

Tidigare, när Alice skickade Bob ett meddelande, när Bob svarade var han tvungen att göra ett uppslag i nätverksdatabasen - genom att skicka ut några förfrågningar för att få Alices nuvarande LeaseSet. Om han redan har Alices nuvarande LeaseSet, så kan han istället bara skicka sitt svar direkt - detta är (en del av) varför det typiskt tar lite längre tid att prata med någon första gången du ansluter, men efterföljande kommunikation är snabbare. För nuvarande - för alla klienter - packar vi in avsändarens nuvarande LeasSet i lök:en som skickas till mottagaren, så att när dom svarar, så kommer dom alltid ha ett LeaseSet sparat lokalt - vilket totalt förebygger alla behov av förfrågningar till nätverksdatabasen vid svar. Detta byter bort en stor del av avsändarens bandbredd för ett snabbare svar. Om vi inte gjorde detta ofta, så hade den genomsnittliga nätverksbandbredd minska, eftersom mottagaren inte måste göra förfrågningen mot nätverksdatabasen.

För icke publicerade LeaseSets som "Delade Klienter", är detta enda sättet att få LeaseSettet til Bob. Olyckligtvis ökar denna packetering varje gång nästan 100% overhead till en high-bandwidth anslutning, och mycket mer till anslutningar med mindre meddelanden.

Förändringar som är planerade för release 0.6.2 kommer skicka med LeaseSet bara när det behövs, vid början av en anslutning eller när LeaseSet:et förändras. Detta kommer rejält minska den totala overheaden av I2P meddelanden.

Effektivare TCP avslag

[implementerad]

Alla TCP-anslutningar gör för tillfället all sin nod-validering efter att hela det fulla (dyra) Diffie-Hellman handslaget gått genom för att förhandla fram en privat sessionsnyckel. Detta betyder att om någons klocka är väldigt fel eller deras NAT/brandvägg/etc är felaktigt inställd (eller om de bara kör en icke-kompatibel version av routern), så kommer de konsekvent (men inte konstant, tack vare svartlistan) orsaka meningslösa dyra kryptografiska beräkningar på alla noder de känner till. Eftersom vi vill behålla en del verifiering/validering inom krypteringsgränsen, så kommer vi vilja uppdatera protokollet så att en del görs först, så att vi kan avvisa dom direkt, utan att slösa massor av CPU-tid eller andra resurser.

Justera tunneltestning

[implementerad]

Istället för att använda den ganska slumpmässiga metod vi har nu, borde vi använda en mer kontext-medveten algoritm för att testa tunnlar. T.ex. om vi redan vet att den skickar giltig data korrekt, så finns inget behov för att testa den, men om vi inte har sett någon data genom den nyligen, så är det kanske meningsfullt att kasta lite data åt dess håll. Detta kommer minska tunnel tvister från överflödiga meddelanden, men även förbättra hastigheten med vilken vi hittar - och löser - misslyckade tunnlar.

Beständig Tunnel / Lease-val

Utåtgående tunnel-val implementerades i 0.6.1.30, inåtgående lease-val implementerades i release 0.6.2.

Att välja tunnlar och lease slumpmässigt för varje meddelande skapare en stor förekomst av meddelande som kommer fram ur ordning, vilket förhindrar streaming biblioteket från att öka dess fönsterstorlek så mycket som det kunde gjort. Genom att bibehålla samma val för en given anslutning, är överföringshastigheten mycket snabbare.

Komprimera vissa datastruktuerer

[implementerad]

I2NP meddelanden och den datande innehåller är redan definierad i en ganska kompakt struktur, men ett av attributen i RouterInfo-strukturen är inte det - "alternativ" är ett vanligt ASCII-namn = värde-mappning. Just nu fyller vi det med den publicerade statistiken - runt 3300 byte per nod. Det är enkelt att implementera GZip-komprimering vilket skulle minska det till 1/3 av sin storlek och när du tänker på hur ofta RouterInfo-strukturer skickas över nätverket, så är det viktiga besparingar - varje gång en router frågar en annan router efter något ur nätverksdatabasen som mottagaren inte har, så skickar den tillbaka 3-10 RouterInfos till förfrågaren.

Uppdatera ministreaming protokollet

[ersatt av fullt streaming protokoll]

För närvarande har mihis ministreamingbibliotek ett tämligen enkelt strömförhandlingsprotokoll - Alice skickar ett SYN-meddelande till Bob, Bob svarar med ett ACK-meddelande, sen skickar Alice och Bob varandra lite data, tills en av dem skickar den andre ett CLOSE-meddelande. För längre anslutningar (exempelvis till en IRC-server), är overheaden försumbar, men för enkla request/response engångssituationer (ett HTTP-utbyte t ex), så är det mer än dubbelt så många meddelanden än vad som är nödvändigt. Om emellertid Alice häftade sin första payload vid sitt SYN och Bob häftade sitt första svar vid sitt ACK - och kanske också inkluderade CLOSE-flaggan - så kunde tillfälliga strömmar som HTTP-requests reduceras till ett par meddelanden, i stället för SYN+ACK+request+response+CLOSE.

Implementera komplett streamingprotokoll

[implementerad]

Ministreamingprotokollet drar nytta av ett dåligt designbeslut i I2P-klientprotokollet (I2CP) - blottandet av "mode=GUARANTEED", vilket tillåter vad som annars skulle vara ett opålitligt, bästa-försök, meddelandebaserat protokoll att användas i stället för en pålitligt blockerande operation (under ytan är det fortfarande helt opålitligt och meddelandebaserat, med routern som leverantör av garantier genom lök wrapping av "ACK"-meddelande tillsammans med datalasten, så när datan når målet returneras ACK-meddelandet till oss [genom tunnlar naturligvtis]).

Som jag sa, att låta I2PTunnel (och ministreamingbiblioteket) ta den här riktningen var det bästa som kunde göras, men mer effektiva mekanismer är tillgängliga. När vi tar bort "mode=GUARANTEED" funktionaliteten, återstår i huvudsak en I2CP som ser ut som ett anonymt IP-lager, som sådant kommer vi att kunna implementera streamingbiblioteket till att dra fördel av TCP-lagrets designerfarenheter - selektiv ACK, överbelastningsdetektering etc.