Aşağıdaki yöntemler kullanılarak önemli başarım iyileştirmeleri yapılmıştır. Yapılacak daha çok şey var. Güncel sorunlar ve düşünceler için Başarım sayfasına bakabilirsiniz.

Doğal matematik

I2P kodunun profilini en son çıkardığımda, zamanın büyük çoğunluğu tek bir işlev içinde harcanıyordu: java.math.BigInteger modPow. Bu yöntemi ayarlamaya çalışmak yerine, delicesine hızlı bir matematik kitaplığı olan (birçok mimari için ayarlanmış birleştirici ile) GNU MP kitaplığını çağıracağız. (Editör: Daha hızlı ortak anahtar şifrelemesi için NativeBigInteger inceleyebilirsiniz)

ugha ve duck, C/JNI yapıştırıcı kodu üzerinde çalışıyor ve var olan Java kodu, hazır olduğunda bunun için zaten kancalarla konuşlandırılıyor. İlk sonuçlar harika görünüyor. Yönelticiyi yerel GMP modPow ile çalıştırmak 800% şifreleme başarımında hızlanma sağladı ve yükü yarıya indirdi. Bu sonuç yalnızca bir kullanıcının bilgisayarında alındı ve henüz paketleme ve dağıtım için hazır bir şey yok.

Garlic sarmalama bir "yanıt" "Kiralama kümesi" (LeaseSet)

Bu algoritma ince ayarı, yalnızca eşlerin kendilerine yanıt vermesini isteyen uygulamalar için geçerli olacaktır (ancak bu I2PTunnel veya mihi mini akış kitaplığını kullanan her şeyi kapsar):

Önceden, Alice Bob'a bir ileti gönderdiğinde, Bob yanıt verdiğinde "Ağ veri tabanında" (netDB) bir arama yapmak zorundaydı. Alice'in var olan "Kiralama kümesini" (LeaseSet) almak için birkaç istek gönderiyordu. Bunun yerine, Alice'in kullandığı "Kiralama kümesini" (LeaseSet) zaten biliyorsa yanıtını hemen gönderebilir. Bu nedenle (bunun bir parçası) ilk kez bağlantı kurduğunuzda birisiyle konuşmanız genellikle biraz daha uzun sürer. Ancak sonraki iletişim daha hızlıdır. Şu anda - tüm istemciler için - göndericinin kullandığı "Kiralama kümesinin" alıcıya teslim edildiği Garlic ile sarmalıyoruz. Böylece yanıt verecekleri zaman, "Kiralama kümesi" (LeaseSet) her zaman yerel olarak depolanmış olacak. Yanıtlar için herhangi bir "Ağ veri tabanı" (netDB) araması gereksinimi tamamen ortadan kalkacak ve daha hızlı yanıt için göndericinin bant genişliğinin büyük bir bölümü kullanılmış olacak. Bunu çok sık yapmasaydık, alıcının "Ağ veri tabanı" (netDB) aramasını yapması gerekmeyeceğinden genel ağ bant genişliği kullanımı azalacaktı.

"Paylaşılan istemciler" gibi yayınlanmamış "Kiralama kümeleri" (LeaseSets) için, kiralama kümesini Bob'a almanın tek yolu budur. Ne yazık ki bu paketleme her seferinde neredeyse 100% yüksek bant genişliğine sahip bir bağlantıya ek yük ve daha küçük iletiler içeren bir bağlantıya çok daha fazla yük oluşturur.

0.6.2 sürümü için planlanan değişiklikler, yalnızca gerektiğinde, bir bağlantının başlangıcında veya "Kiralama kümesi" (LeaseSet) değiştiğinde, "Kiralama kümesini" (LeaseSet) paketleyecek. Böylece, I2P iletişiminin toplam ek yükü önemli ölçüde azalacak.

Daha verimli TCP reddi

Şu anda, tüm TCP bağlantıları, özel bir oturum anahtarı üzerinde anlaşmak için tam (pahalı) Diffie-Hellman el sıkışmasından geçtikten sonra tüm eşlerin doğrulamasını yapıyor. Bu durum, birinin saati gerçekten yanlışsa veya NAT/güvenlik duvarı/vb. yanlış yapılandırılmışsa (veya yalnızca uyumsuz bir yöneltici sürümü çalıştırıyorsa), sürekli olarak (yasaklama listesi sayesinde sürekli olmasa da) bildikleri tüm eşler üzerinde boşuna pahalı bir şifreleme işlemi yapılmasına neden olur. Bazı doğrulama/onaylama işlemlerini şifreleme sınırı içinde tutmak isteyecek olsak da, iletişim kuralını öncelikle bazılarını yapacak şekilde güncellemek isteriz. Böylece çok fazla işlemci gücünü veya başka kaynakları boşa harcamadan bunları temiz bir şekilde reddedebiliriz.

Tünel sınamasını ayarlama

Şu anda kullandığımız oldukça rastgele şema ile gitmek yerine, tünelleri sınamak için daha fazla bağlam farkındalığı olan bir algoritma kullanmalıyız. Örneğin. Geçerli verilerin geçtiğini zaten biliyorsak, sınamaya gerek kalmaz. Son zamanlarda herhangi bir veri görmediysek, belki de yoluna biraz veri göndermeye değer. Böylece, çok sayıda iletiden kaynaklanan tünel çekişmesi azalacak ve hatalı tünelleri algılama ve çözme hızımız iyileşecek.

Kalıcı Tünel / Kiralama Seçimi

0.6.1.30 sürümünde uygulanan gidiş tüneli seçimi, 0.6.2 sürümünde uygulanan geliş kiralaması seçimi.

Her ileti için rastgele tüneller ve kiralamalar seçmek, akış kitaplığının pencere boyutunu olabildiğince büyütmesini engelleyen büyük bir hizmet dışı aktarım durumuna yol açar. Belirli bir bağlantı için aynı seçimler korunduğunda aktarım hızı çok daha fazladır.

Bazı veri yapılarını sıkıştırma

I2NP iletileri ve içerdikleri veriler, "Yöneltici bilgileri" (RouterInfo) yapısının bir özelliği olmasa da, zaten oldukça kompakt bir yapıda tanımlanmıştır. "Seçenekler", düz bir ASCII ad = değer çiftidir. Şu anda, bunu yayınlanan istatistiklerle dolduruyoruz. Eş başına yaklaşık 3300 bayt. GZip sıkıştırmasını uygulamak önemsiz bir işlem ve boyutu neredeyse 1/3 oranında düşürür. "Yöneltici bilgileri" (RouterInfo) yapılarının ağ üzerinden ne sıklıkta geçtiğini düşündüğünüzde, bu önemli bir tasarruf sağlar. Bir yöneltici başka bir yönelticiden kendisinde bulunmayan bir "Ağ veri tabanı" (netDB) kaydı istediğinde geriye 3-10 "Yöneltici bilgileri" (RouterInfo) gelir.

Mini akış iletişim kuralında güncelleme

Şu anda kullanılan mihi mini akış kitaplığı oldukça basit bir akış anlaşma iletişim kuralı kullanır. Alice, Bob'a bir SYN iletisi gönderir. Bob bir ACK iletisi ile yanıt verir. Ardından Alice ve Bob, biri diğerine bir KAPAT iletisi gönderene kadar birbirlerine bazı veriler gönderir. Uzun süreli bağlantılar için (örneğin bir IRC sunucusu), bu ek yük ihmal edilebilir. Ancak basit bir kerelik istek/yanıt durumları (örneğin bir HTTP isteği/yanıtı) için bu durum, gerekenden iki kat daha fazla iletiye yol açar. Bununla birlikte, Alice ilk yükünü SYN iletisiyle bindirdiyse ve Bob ilk yanıtını ACK ile döndürdüyse - ve belki KAPAT işaretini de eklediyse - HTTP istekleri gibi geçici akışlar bir çift iletiye indirgenebilir. SYN+ACK+istek+yanıt+KAPAT.

Tam akış iletişim kuralı eklendi

Mini akış iletişim kuralı, I2P istemci iletişim kuralındaki (I2CP) zayıf bir tasarım kararından yararlanır. "mode=GUARANTEED" ifadesinin ortaya çıkması. aksi durumda güvenilir olmayan, en çok çaba gerektiren, ileti tabanlı olan iletişim kuralının güvenilir bir şekilde engelleme işlemi için kullanılmasını sağlar (kapakların altında, hala tamamen güvenilmez ve ileti tabanlıdır. Yöneltici, bir "ACK" iletisini yük ile birleştirerek Garlic kapsamayla teslim garantisi sağlar. Böylece veriler hedefe ulaştığında, ACK iletisi bize geri iletilir [tabii ki tünellerden]).

Dediğim gibi, I2PTunnel (ve ministreaming kitaplığı) için bu yolun seçilmesi yapılabilecek en iyi şeydi. Ancak daha verimli yöntemler var. "Mode=GUARANTEED" işlevini kaldırdığımızda, aslında elimizde anonim bir IP katmanına benzeyen bir I2CP kalıyor. Bu nedenle, TCP katmanının tasarım deneyimlerinden - seçici ACK, tıkanıklık algılama, nagle vb. - yararlanmak için akış kitaplığını ekleyebileceğiz.