Özet
Streaming kitaplığı, bir çekirdek yöneltici işlevi olmadığından teknik olarak "uygulama" katmanının bir parçasıdır. Ancak pratikte, I2P üzerinden TCP benzeri bir akış sağlayarak ve var olan uygulamaların kolayca I2P üzerine taşınmasını sağladığından, neredeyse var olan tüm I2P uygulamaları için hayati bir işlev sağlar. İstemci iletişimi için kullanılan diğer uçtan uca taşıyıcı kitaplığı veri şeması kitaplığıdır.
Streaming kitaplığı, güvenilir, düzenli ve kimliği doğrulanmış ileti akışlarının güvenilir olmayan, sıralanmamış ve kimliği doğrulanmamış bir ileti katmanında çalışmasını sağlayan ve I2CP API çekirdeği üstünde bulunan bir katmandır. TCP ile IP ilişkisinde olduğu gibi, bu akış işlevselliğinde karşılıklı bazı özveriler ve iyileştirmeler vardır. Ancak bu işlevsellik temel I2P koduna yerleştirilmek yerine, TCP benzeri karmaşıklıkların ayrı tutulması ve farklı uygulamalara uygun şekilde eklenebilmesi için kendi kitaplığını kullanacak şekilde hazırlanmıştır.
İletilerin nispeten yüksek maliyeti göz önüne alındığında, Streaming kitaplığının bu iletileri programlamak ve iletmek için kullandığı iletişim kuralı, iletilen bireysel iletilerin olabildiğince çok bilgi içermesini sağlayacak şekilde iyileştirilmiştir. Örneğin, Streaming kitaplığı aracılığıyla vekil sunucu üzerinden geçirilen küçük bir HTTP işlemi tek bir gidiş-dönüşte tamamlanabilir. İlk iletiler bir SYN, FIN komutları ve küçük bir HTTP isteği yükünü birleştirir ve yanıt SYN, FIN, ACK komutları ile HTTP yanıt yükü olur. HTTP sunucusuna SYN/FIN/ACK komutlarının alındığını söylemek için ek bir ACK komutu iletilmesi gerekirken, yerel HTTP vekil sunucusu genellikle tarayıcıya tam yanıtı hemen teslim edebilir.
Streaming kitaplığı, kayan pencereleri, tıkanıklık kontrol algoritmaları (hem yavaş başlatma hem de tıkanıklıktan kaçınma) ve genel paket davranışı (ACK, SYN, FIN, RST, rto hesaplama, vb.) ile bir TCP soyutlamasına çok benzer.
Streaming kitaplığı, I2P üzerinde çalışması için iyileştirilmiş sağlam bir kitaplıktır. Kurulumu tek aşamalıdır ve tam bir pencereleme uygulaması içerir.
API
Streaming kitaplığı API yazılımı, Java uygulamalarına standart bir soket paradigması sağlar. Alt düzey I2CP API, uygulamaların I2CP parametrelerini Streaming kitaplığı üzerinden I2CP tarafından yorumlanmak üzere geçirebilmesi dışında tamamen gizlidir.
Streaming kitaplığının standart arabirimi, uygulamanın I2PSocketManagerFactory kullanarak bir I2PSocketManager oluşturmak içindir. Uygulama daha sonra soket yöneticisinden I2PSession ister ve bu da yöneltici ile I2CP üzerinden bağlantı kurulmasına neden olur. Uygulama daha sonra bir I2PSocket ile bağlantılar kurabilir ya da bir I2PServerSocket üzerinden bağlantılar alabilir.
Buradan tam Streaming kitaplığı Javadocs belgelerine bakabilirsiniz .
İyi bir kullanım örneği için i2psnark koduna bakabilirsiniz.
Ayarlar ve Varsayılanlar
Seçenekler ve var olan varsayılan değerler aşağıda listelenmiştir. Seçenekler büyük/küçük harfe duyarlıdır ve yöneltici genelinde, belirli bir istemci için ya da bağlantı bazında ayrı bir soket için ayarlanabilir. Tipik I2P koşulları üzerinde HTTP başarımı için birçok değer ayarlanmıştır. Eşler arası hizmetler gibi diğer uygulamaların, seçenekleri ayarlayarak ve I2PSocketManagerFactory.createManager(_i2cpHost, _i2cpPort, opts) çağrısı yoluyla ileterek gerektiği şekilde değiştirmeleri önemle önerilir. Zaman değerleri ms cinsindendir.
SAM, BOB ve I2PTunnel gibi daha yüksek katman API yazılımlarının bu varsayılanları kendi varsayılan ayarları ile değiştirebileceğini unutmayın. Ayrıca, birçok seçeneğin yalnızca geliş bağlantılarını dinleyen sunucular için geçerli olduğunu unutmayın.
0.9.1 sürümünden başlayarak, seçeneklerin tümü olmasa da çoğu etkin bir soket yöneticisi veya oturumda değiştirilebilir. Ayrıntılı bilgi almak için javadocs belgelerine bakabilirsiniz.
| Seçenek | Varsayılan | Notlar |
|---|---|---|
| i2cp.accessList | null | Erişim listesi veya kara liste için kullanılan Base64 eş karmalarının virgül ya da boşluk ile ayrılmış listesi. 0.7.13 sürümündeki gibi. |
| i2cp.destination.sigType | DSA_SHA1 | Geliş bağlantıları için erişim listesi beyaz liste olarak kullanılsın. Geçici bir hedef için imza türünün adı veya numarası. 0.9.12 sürümündeki gibi. |
| i2cp.enableAccessList | false | Geliş bağlantıları için erişim listesi beyaz liste olarak kullanılsın. 0.7.13 sürümündeki gibi. |
| i2cp.enableBlackList | false | Geliş bağlantıları için erişim listesi kara liste olarak kullanılsın. 0.7.13 sürümündeki gibi. |
| i2p.streaming.answerPings | true | Gelen ping paketlerine yanıt verilip verilmeyeceği |
| i2p.streaming.blacklist | null | Bağlamdaki TÜM hedeflerin geliş bağlantıları için kara listeye alınacak Base64 eş karmalarının virgül ya da boşluk ile ayrılmış listesi. Bu seçenek, createManager() options argümanında DEĞİL, bağlam özelliklerinden ayarlanmalıdır. Bunu yöneltici bağlamında ayarlamanın, ayrı bir JVM içindeki ve bağlamdaki yöneltici dışındaki istemcileri etkilemeyeceğini unutmayın. 0.9.3 sürümündeki gibi. |
| i2p.streaming.bufferSize | 64K | Henüz yazılmamış ne kadar iletim verisinin (bayt cinsinden) kabul edileceği. |
| i2p.streaming.congestionAvoidanceGrowthRateFactor | 1 | Tıkanıklıktan kaçınma durumundayken pencere boyutunu 1/(windowSize*factor)
oranında büyütürüz. Standart TCP için pencere boyutları bayt cinsindendir, I2P üzerinde
ise pencere boyutları iletilerdedir.
Daha yüksek bir sayı, daha yavaş büyüme anlamına gelir. |
| i2p.streaming.connectDelay | -1 | Yeni bir bağlantı başlattıktan sonra gerçekten bağlantı kurmaya çalışmadan önce ne kadar bekleneceği. Bu değer <= 0 ise, başlangıç verisi olmadan hemen bağlantı kurulur. Değer 0 üzerindeyse, çıktı akışı temizlenene, ara bellek dolana veya bu kadar milisaniye geçene kadar bekleyin ve SYN komutuna herhangi bir başlangıç verisi ekleyin. |
| i2p.streaming.connectTimeout | 5*60*1000 | Milisaniye cinsinden, bağlantının kurulurken ne kadar süreyle bloke edileceği. Negatif süresiz anlamına gelir. Varsayılan değer 5 dakikadır. |
| i2p.streaming.disableRejectLogging | false | Bağlantı sınırları nedeniyle bir geliş bağlantısı reddedildiğinde günlüklerdeki uyarıların devre dışı bırakılıp bırakılmayacağı. 0.9.4 sürümündeki gibi. |
| i2p.streaming.dsalist | null | Alternatif bir DSA hedefi kullanılarak iletişim kurulacak Base64 eş karmalarının ya da ana bilgisayar adlarının virgül ya da boşluk ile ayrılmış listesi. Yalnızca çoklu oturum etkinleştirildiyse ve birincil oturum DSA değilse geçerlidir (genellikle yalnızca paylaşılan istemciler için). Bu seçenek, createManager() options argümanında DEĞİL, bağlam özelliklerinde ayarlanmalıdır. Bunu yöneltici bağlamında ayarlamanın, ayrı bir JVM içindeki ve bağlamdaki yöneltici dışındaki istemcileri etkilemeyeceğini unutmayın. 0.9.21 sürümündeki gibi. |
| i2p.streaming.enforceProtocol | true | Yalnızca Streaming iletişim kuralının dinlenip dinlenmeyeceği. True olarak ayarlamak, Hedeflerle 0.7.1 sürümünden (Mart 2009 tarihinde yayınlandı) önceki iletişimleri yasaklar. Bu hedefte birden çok iletişim kuralı çalıştırıyorsanız true olarak ayarlayın. 0.9.1 sürümündeki gibi. Default true as of release 0.9.36. |
| i2p.streaming.inactivityAction | 2 (send) | (0=bir şey yapma, 1=bağlantıyı kes) Hareketsizlik zaman aşımında yapılması gerekenler - bir şey yapmayın, bağlantıyı kesin ya da yinelenen bir onay gönderin. |
| i2p.streaming.inactivityTimeout | 90*1000 | Canlı tut komutu gönderilmeden önce beklenecek süre |
| i2p.streaming.initialAckDelay | 750 | ACK komutu gönderilmeden önceki gecikme |
| i2p.streaming.initialResendDelay | 1000 | Paket üst bilgisindeki yeniden gönderme gecikmesi alanının ilk değeri, çarpı 1000. Tam olarak kullanılmıyor. Aşağıya bakın. |
| i2p.streaming.initialRTO | 9000 | Başlangıç zaman aşımı (kullanılabilecek paylaşılan veri yoksa). 0.9.8 sürümündeki gibi. |
| i2p.streaming.initialRTT | 8000 | İlk gidiş dönüş süresi öngörüsü kullanılabilecek paylaşılan veri yoksa). 0.9.8 sürümünden beri devre dışı bırakıldı; gerçek RTT kullanır. |
| i2p.streaming.initialWindowSize | 6 | (kullanılabilecek paylaşılan veri yoksa) Standart TCP için pencere boyutları bayt cinsindendir, I2P üzerinde ise pencere boyutları iletilerdedir. |
| i2p.streaming.limitAction | reset | What action to take when an incoming connection exceeds limits. Valid values are: reset (reset the connection); drop (drop the connection); or http (send a hardcoded HTTP 429 response). Any other value is a custom response to be sent. backslash-r and backslash-n will be replaced with CR and LF. 0.9.34 sürümündeki gibi. |
| i2p.streaming.maxConcurrentStreams | -1 | (0 veya negatif değer sınırsız anlamına gelir) Geliş ve gidiş için birleşik toplam sınırdır. |
| i2p.streaming.maxConnsPerMinute | 0 | Geliş bağlantısı sınırı (per peer; 0, devre dışı anlamına gelir) 0.7.14 sürümündeki gibi. |
| i2p.streaming.maxConnsPerHour | 0 | (per peer; 0 devre dışı anlamına gelir) 0.7.14 sürümündeki gibi. |
| i2p.streaming.maxConnsPerDay | 0 | (per peer; 0 devre dışı anlamına gelir) 0.7.14 sürümündeki gibi. |
| i2p.streaming.maxMessageSize | 1730 | Yükün en fazla boyutu, yani bayt cinsinden MTU. |
| i2p.streaming.maxResends | 8 | Başarısız sayılmadan önce en fazla yeniden aktarım sayısı. |
| i2p.streaming.maxTotalConnsPerMinute | 0 | Geliş bağlantısı sınırı (all peers; 0, devre dışı anlamına gelir) 0.7.14 sürümündeki gibi. |
| i2p.streaming.maxTotalConnsPerHour | 0 | (all peers; 0 devre dışı anlamına gelir) Bunu aşmak bir sunucuyu uzun süre devre dışı bırakacağından dikkatli kullanın. 0.7.14 sürümündeki gibi. |
| i2p.streaming.maxTotalConnsPerDay | 0 | (all peers; 0 devre dışı anlamına gelir) Bunu aşmak bir sunucuyu uzun süre devre dışı bırakacağından dikkatli kullanın. 0.7.14 sürümündeki gibi. |
| i2p.streaming.maxWindowSize | 128 | |
| i2p.streaming.profile | 1 (bulk) | 1=bulk; 2=interactive; see important notes below. |
| i2p.streaming.readTimeout | -1 | Milisaniye cinsinden, okunurken ne kadar süreyle bloke edileceği. Negatif süresiz anlamına gelir. |
| i2p.streaming.slowStartGrowthRateFactor | 1 | Yavaş başlatma durumundayken pencere boyutunu 1/(factor)
oranında büyütürüz. Standart TCP için pencere boyutları bayt cinsindendir,
I2P üzerinde ise pencere boyutları iletilerdedir.
Daha yüksek bir sayı, daha yavaş büyüme anlamına gelir. |
| i2p.streaming.tcbcache.rttDampening | 0.75 | Ref: RFC 2140. Kayan nokta değeri. Bağlantı seçenekleriyle değil, yalnızca bağlam özellikleriyle ayarlanabilir. 0.9.8 sürümündeki gibi. |
| i2p.streaming.tcbcache.rttdevDampening | 0.75 | Ref: RFC 2140. Kayan nokta değeri. Bağlantı seçenekleriyle değil, yalnızca bağlam özellikleriyle ayarlanabilir. 0.9.8 sürümündeki gibi. |
| i2p.streaming.tcbcache.wdwDampening | 0.75 | Ref: RFC 2140. Kayan nokta değeri. Bağlantı seçenekleriyle değil, yalnızca bağlam özellikleriyle ayarlanabilir. 0.9.8 sürümündeki gibi. |
| i2p.streaming.writeTimeout | -1 | Milisaniye cinsinden, yazılırken/boşaltılırken ne kadar süreyle bloke edileceği. Negatif süresiz anlamına gelir. |
İletişim Kuralı Teknik Özellikleri
Streaming kitaplığı teknik özellikleri sayfasına bakın.
Uygulama Ayrıntıları
Kurulum
Başlatıcı, SYNCHRONIZE işaret kümesi ile bir paket gönderir. Bu pakette ilk veriler de bulunabilir.
Karşıdaki eş, SYNCHRONIZE işaret kümesi ile bir paketle yanıt verir. Bu pakette ilk yanıt verileri de bulunabilir.
Başlatıcı, SYNCHRONIZE yanıtını almadan önce ilk pencere boyutuna kadar ek veri paketleri gönderebilir. Bu paketler ayrıca gönderme akış kimliği alanını 0 olarak ayarlar. Alıcılar, bilinmeyen akışlarda alınan paketleri, SYNCHRONIZE paketinden önce düzensiz sırada alabileceğinden kısa bir süre için ara belleğe almalıdır.
MTU Seçimi ve Uzlaşma
En büyük ileti boyutu (MTU / MRU olarak da adlandırılır), iki eş arasında desteklenen daha düşük değere göre belirlenir. Tünel iletileri 1 KB olarcak şekilde doldurulduğundan, zayıf bir MTU seçimi büyük miktarda ek yüke yol açar. MTU, i2p.streaming.maxMessageSize seçeneğiyle belirtilir. Var olan varsayılan 1730 MTU değeri, tipik durum için ek yük ile birlikte iki 1K I2NP tünel iletisine tam olarak uyacak şekilde seçilmiştir. Note: This is the maximum size of the payload only, not including the header.
Note: For ECIES connections, which have reduced overhead, the recommended MTU is 1812. The default MTU remains 1730 for all connections, no matter what key type is used. Clients must use the minimum of the sent and received MTU, as usual. See proposal 155.
Bir bağlantıdaki ilk iletide, akış katmanı tarafından eklenen 387 baytlık (tipik) bir hedef ve genellikle yöneltici tarafından Garlic iletisinde paketlenmiş 898 baytlık (tipik) bir "Kiralama kümesi" (LeaseSet) ile oturum anahtarları bulunur. (Daha önce bir ElGamal oturumu kurulmuşsa, "Kiralama kümesi" (LeaseSet) ve oturum anahtarları paketlenmez). Bu nedenle, her zaman tam bir HTTP isteğini tek bir 1KB I2NP iletisine uydurma hedefine ulaşılamaz. Bununla birlikte, tünel ağ geçidi işlemcisinde parçalanma ve gruplama stratejilerinin dikkatli bir şekilde uygulanmasıyla birlikte MTU değerinin seçimi, özellikle uzun ömürlü bağlantılar için ağ bant genişliği, gecikme süresi, güvenilirlik ve verimlilik açısından önemli faktörlerdir.
Veri Bütünlüğü
Veri bütünlüğü, I2CP katmanında uygulanan gzip CRC-32 sağlaması kullanılarak sağlanır. Streaming iletişim kuralında sağlama alanı yoktur.
Paket Kapsülleme
Her paket, I2P aracılığıyla tek bir ileti olarak (ya da bir Garlic iletisi içindeki tek bir diş olarak) gönderilir. İleti kapsüllemesi için I2CP, I2NP ve tünel ileti katmanları kullanılır. Streaming iletişim kuralında paket sınırlayıcı bir yöntem veya uzunluk alanı yoktur.
İsteğe Bağlı Gecikme
Veri paketlerinde, alıcının paketi onaylamasından önce, istenilen gecikmeyi ms cinsinden belirten bir isteğe bağlı gecikme alanı bulunabilir. Geçerli değerler 0 ile 60000 arasındadır. 0 değeri anında onay ister. Bu yalnızca bir öneridir ve alıcılar, ek paketlerin tek seferde onaylanabilmesi için biraz gecikmelidir. Bazı uygulamalarda bu alanda (ölçülen RTT/2) bir öneri değeri bulunabilir. Sıfır olmayan isteğe bağlı gecikme değerleri için, alıcılar bir onay göndermeden önce en fazla gecikmeyi en çok birkaç saniye ile sınırlamalıdır. 60000 üzerinde isteğe bağlı gecikme değerleri boğulmayı gösterir. Ayrıntılı bilgi almak için aşağıya bakın.
Alma Penceresi ve Kısma
TCP üst bilgilerinde, bayt cinsinden alma penceresi bulunur. Streaming iletişim kuralında bir alma penceresi bulunmaz. Yalnızca basit bir kısma/açma göstergesi kullanılır. Her uç nokta, bayt veya paket olarak uzak uçtaki alma penceresine ilişkin kendi öngörüsünü korumalıdır. Alıcı uygulamaları için önerilen en az ara bellek 128 paket veya 217 KB boyutundadır (yaklaşık 128x1730). I2P ağ gecikmesi, paket kayıpları ve bunun sonucunda oluşan tıkanıklık denetimi nedeniyle, bu boyuttaki bir ara bellek nadiren doldurulur. Ancak, yüksek bant genişliğine sahip "yerel geri döngü" (aynı yöneltici) bağlantılarında taşma oluşabilir.
Taşma koşullarını hızlı bir şekilde belirtmek ve sorunsuz bir şekilde kurtarmak için Streaming iletişim kuralında basit bir geri bildirim için yöntemi vardır. 60001 ya da daha yüksek değerde isteğe bağlı gecikme alanına sahip bir paket alınırsa, bu "kısma" veya alma penceresinin sıfır olduğunu gösterir. 60000 veya daha düşük değerde isteğe bağlı gecikme alanına sahip bir paket "açmayı" gösterir. İsteğe bağlı gecikme alanı olmayan paketler, kısma/açma durumunu etkilemez.
Tıkandıktan sonra, olası kayıp açılmamış paketleri telafi etmek için ara sıra "yoklama" veri paketleri dışında, vericinin tıkanması açılana kadar veri içeren başka paket gönderilmemelidir. Tıkanmış uç nokta, TCP üzerinde olduğu gibi araştırmayı kontrol etmek için bir "kalıcı zamanlayıcı" başlatmalıdır. Açılan uç nokta, bu alan kümesi ile birkaç paket göndermeli veya veri paketleri yeniden alınana kadar bunları belirli aralıklarla göndermeyi sürdürmelidir. Tıkanıklığın çözülmesi için beklenecek en fazla süre uygulamaya bağlıdır. Açıldıktan sonra verici penceresi boyutu ve tıkanıklık denetimi stratejisi uygulamaya bağlıdır.
Tıkanıklık Denetimi
Streaming kitaplığı, üstel geri çekilme ile standart yavaş başlangıç (üstel pencere büyümesi) ve tıkanıklıktan kaçınma (doğrusal pencere büyümesi) aşamalarını kullanır. Pencereleme ve bildirimler, bayt sayısını değil paket sayısını kullanır.
Kapatma
SYNCHRONIZE işaret kümesi ile birlikte herhangi bir pakette CLOSE işareti de gönderilebilir. Eş CLOSE işaretiyle yanıt verene kadar bağlantı kapatılmaz. CLOSE paketleri de veri içerebilir.
Ping / Pong
I2CP katmanında (ICMP echo eşdeğeri) veya veri şemalarında ping işlevi yoktur. Bu işlev akışta sağlanır. Ping ve pong standart bir akış paketiyle birleştirilemez; ECHO seçeneği ayarlanmışsa, diğer birçok işaret, seçenek, ackThrough, sequenceNum, NACK gibi şeyler yok sayılır.
Bir ping paketinin ECHO, SIGNATURE_INCLUDED ve FROM_INCLUDED işaretleri ayarlanmış olmalıdır. sendStreamId sıfırdan büyük olmalıdır ve alıcıStreamId yok sayılır. sendStreamId, var olan bir bağlantıya karşılık gelebilir veya gelmeyebilir.
Bir pong paketinin ECHO işlaretinin ayarlanmış olması gerekir. sendStreamId sıfır olmalıdır ve alıcıStreamId, ping ile gelen sendStreamId olur. 0.9.18 sürümünden önce, pong paketinde, ping içinde bulunan herhangi bir yük bulunmaz.
0.9.18 sürümünden başlayarak, ping ve pong içinde bir yük içerebilir. Ping içindeki en fazla 32 bayta kadar olan yük, pong içinde döndürülür.
Streaming üzerinde, i2p.streaming.answerPings=false yapılandırmasıyla pong gönderme devre dışı bırakılabilir.
i2p.streaming.profile Notes
This option supports two values; 1=bulk and 2=interactive. The option provides a hint to the streaming library and/or router as to the traffic pattern that is expected.
"Bulk" means to optimize for high bandwidth, possibly at the expense of latency. This is the default. "Interactive" means to optimize for low latency, possibly at the expense of bandwidth or efficiency. Optimization strategies, if any, are implementation-dependent, and may include changes outside of the streaming protocol.
Through API version 0.9.63, Java I2P would return an error for any value other than 1 (bulk) and the tunnel would fail to start. As of API 0.9.64, Java I2P ignores the value. Through API version 0.9.63, i2pd ignored this option; it is implemented in i2pd as of API 0.9.64.
While the streaming protocol includes a flag field to pass the profile setting to the other end, this is not implemented in any known router.
Denetim Bloğunu Paylaşma
Streaming kitaplığı, "TCP" Kontrol Bloğu paylaşımını destekler. Bu paylaşımda, aynı uzak eşe bağlantılar arasında üç önemli Streaming kitaplığı parametresi (pencere boyutu, gidiş dönüş süresi, gidiş dönüş süresi farkı) bulunur. Bu paylaşım, bağlantı sırasında "toplu" paylaşım için değil, bağlantı açma/kapama zamanında "geçici" paylaşım için kullanılır (Bkz. 1RFC 21401). Aynı yöneltici üzerindeki diğer hedeflere bilgi sızıntısı olmaması için ConnectionManager başına (yani yerel hedef başına) ayrı bir paylaşım bulunur. Belirli bir eş için paylaşım verilerinin süresi birkaç dakika sonra sona erer. Her yöneltici için aşağıdaki kontrol bloğu paylaşımı parametreleri ayarlanabilir:
- RTT_DAMPENING = 0.75
- RTTDEV_DAMPENING = 0.75
- WINDOW_DAMPENING = 0.75
Diğer Parametreler
Aşağıdaki parametreler sabit kodlanmıştır, ancak inceleme için ilgi çekici olabilir:
- MIN_RESEND_DELAY = 100 ms (minimum RTO)
- MAX_RESEND_DELAY = 45 sec (maximum RTO)
- MIN_WINDOW_SIZE = 1
- TREND_COUNT = 3
- MIN_MESSAGE_SIZE = 512 (minimum MTU)
- INBOUND_BUFFER_SIZE = maxMessageSize * (maxWindowSize + 2)
- INITIAL_TIMEOUT (valid only before RTT is sampled) = 9 sec
- "alpha" ( RTT dampening factor as per RFC 6298 ) = 0.125
- "beta" ( RTTDEV dampening factor as per RFC 6298 ) = 0.25
- "K" ( RTDEV multiplier as per RFC 6298 ) = 4
- PASSIVE_FLUSH_DELAY = 175 ms
- Maximum RTT estimate: 60 sec
Geçmiş
Streaming kitaplığı I2P için organik olarak büyüdü - ilk önce mihi, I2PTunnel üzerinde bir parça olarak "mini streaming kitaplığını" uyguladı. Bu pencere boyutu 1 ileti ile sınırlıydı (bir sonraki iletiyi göndermeden önce bir ACK gerekiyordu). Ardından yeniden düzenlendi genel bir akış arayüzüne (TCP soketlerini yansıtma) ve tam akış uygulaması, yüksek bant genişliği x gecikme ürününü hesaba katacak şekilde kayan bir pencere iletişim kuralı ve iyileştirmeler yapıldı. Bireysel akışlar, en fazla paket boyutunu ve diğer seçenekleri ayarlayabilir. Varsayılan ileti boyutu, tam olarak iki 1K I2NP tünel iletisine uyacak şekilde seçilir ve kayıp iletilerin yeniden iletilmesinin bant genişliği maliyetleri ile birden fazla iletinin gecikmesi ve ek yükü arasında makul bir denge sağlar.
Gelecekte Yapılacak Çalışmalar
Streaming kitaplığının davranışının, uygulama düzeyinde başarım üzerinde etkisi büyüktür ve bu nedenle, daha fazla inceleme için önemli bir alandır.
- Streaming kitaplığı parametrelerinin ayrıca ayarlanması gerekebilir.
- Araştırma için başka bir alan, Streaming kitaplığının NTCP ve SSU taşıyıcı katmanlarıyla etkileşimidir. Ayrıntılar için NTCP tartışma sayfasına bakabilirsiniz.
- Yöneltme algoritmalarının Streaming kitaplığı ile etkileşiminin, başarım üzerinde önemli bir etkisi vardır. Özellikle, iletilerin bir havuzdaki birden çok tünele rastgele dağıtılması, aksi durumda olacağından daha küçük pencere boyutlarıyla sonuçlanan yüksek derecede sıra dışı teslimata yol açar. Yöneltici şu anda tek bir nereden/nereye hedef çifti için iletileri, tünelin süresi dolana veya teslimat hatası oluşana kadar tutarlı bir tünel kümesi üzerinden yöneltir. Olası iyileştirmeler için yönelticisi sorunları ve tünel seçim algoritmaları gözden geçirilmelidir.
- İlk SYN paketindeki veriler, alıcının MTU değerini aşabilir.
- DELAY_REQUESTED alanı daha fazla kullanılabilir.
- Kısa ömürlü akışlarda yinelenen ilk SYNCHRONIZE paketleri tanınmadığından kaldırılabilir.
- Yeniden aktarımda MTU verisini göndermeyin.
- Gidiş penceresi dolu olmadığı sürece veriler birlikte gönderilir. (yani, no-Nagle ya da TCP_NODELAY) Büyük olasılıkla bunun için bir yapılandırma seçeneği bulunmalıdır.
- zzz, paketleri wireshark uyumlu (pcap) biçimde günlüğe kaydetmek için Streaming kitaplığına hata ayıklama kodu ekledi. Başarımı daha fazla incelemek için bunu kullanın. Daha fazla Streaming kitaplığı parametresini TCP alanlarıyla eşleştirmek için biçimi geliştirmek gerekebilir.
- Streaming kitaplığını standart TCP (veya belki de ham yuvalarla birlikte boş bir katman) ile değiştirmek için öneriler var. Bunu yapmak, ne yazık ki Streaming kitaplığı ile uyumsuz olur. Ancak ikisinin başarımını karşılaştırmak iyi olur.