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

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 befintliga 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

Den här algoritmfinjusteringen kommer endast vara relevant för applikationer som vill att deras jämlikar ska svara dem (men det inkluderar allt 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

Alla TCP-anslutningar gör för tillfället all sin jämlike-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 jämlikar 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

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

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 jämlike. 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

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

Ministreamingprotokollet drar nytta av ett felaktigt 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.