I2P Geliştirici Toplantısı - 18 Nisan 2005

16:09 <jrandom> 0) merhaba 16:09 <jrandom> 1) Ağ durumu ve 0.6.1.16 16:09 <jrandom> 2) Tunnel oluşturma ve tıkanıklık 16:10 <jrandom> 3) Feedspace 16:10 <jrandom> 4) ??? 16:10 <jrandom> 0) merhaba 16:10 * jrandom el sallar 16:10 <jrandom> haftalık durum notları şu adreste yayınlandı: http://dev.i2p.net/pipermail/i2p/2006-April/001281.html 16:10 * frosk da 16:10 <jrandom> (toplantıdan neredeyse iki saat önce, hem de :) 16:11 <jrandom> tamam, notları çoktan didik didik ettiğinizden eminim, hadi 1) Ağ durumu ile başlayalım 16:12 <+Complication> Selam :) 16:12 * Complication hızla notları kapar 16:12 <jrandom> 0.6.1.16 sürümü, prng (sözde rastgele sayı üreteci) içindeki çok uzun süredir var olan bir hatayı düzeltti; bu hata oldukça fazla sayıda gelişigüzel tunnel reddine yol açmıştı 16:13 <jrandom> (temel neden geçen Ekim’de girmişti ama artık düzeltildi) 16:13 <+Complication> Buradaki durum: 1 + 0..1 hop (ara sıçrama) tunnel ile idare eder şekilde çalışıyor, 2 + 0..1 ya da 2 +/- 0..1 ile davranmıyor 16:14 <jrandom> evet, bu da anlaşılır, özellikle daha yavaş bağlantılarda 16:14 <jrandom> (maalesef “daha yavaş” da aslında o kadar yavaş değil) 16:15 <jrandom> yapılacak çok iş var, 0.6.1.16 olması gereken yerde değil, ama bir ilerleme 16:17 <+Complication> “congestion collapse” (ağ tıkanıklığı çöküşü) dediğinle ilgili düşündüğüm bir şey var 16:18 <+Complication> Etkisini sınırlamanın bir yolu, bir router’ın belirli bir katılım isteği kotasını kabul etmesini gerçekten zorunlu tutmak olabilir 16:19 <+Complication> (kullanıcı tarafından doğrudan ya da dolaylı olarak belirtilecek bir şey mi?) 16:19 <jrandom> hangi kullanıcı tarafından belirtilecek? 16:19 <+Complication> (ör. paylaşım yüzdesinin bir parçası ya da ek bir parametre) 16:19 <jrandom> yerel kullanıcı mı, yoksa biz uzak kullanıcılar olarak mı? 16:19 <+Complication> Herkesin kendisi için belirttiği 16:19 <@frosk> o zaman 2)’ye geçelim mi? :) 16:20 <jrandom> evet, 2)’de olduğumuzu varsayalım :) 16:20 <+Complication> Böylece, örneğin router’ıma “tıkanık olsan da en az 4 KB/s yönlendirmeye devam et” diyebilirim 16:21 <jrandom> Complication: bu pek mümkün değil - bir router çok tıkalıysa, diğerleri (umarım ;) onu tunnel’lara katılmaya çağırmayı bırakır. 16:21 <+Complication> (bu elbette, bazı yerel destination (hedef) için bir süre daha çevrimdışı olmak demek olur) 16:21 <jrandom> ve eğer çağrılmıyorlarsa, başkalarının verisini iletemezler 16:22 <+Complication> Ah, belki de çok daha net ifade etmeliydim 16:24 <+Complication> Şunu hayal etmiştim: belirli bir katılımcı trafik kotası altında, katılımcı tunnel’lar yerine kendi tunnel oluşturma iletilerini kısabilir 16:24 <+Complication> örn. “Katılımcı tunnel’larımı asla 4 KB/s’in altına kısmayacağım. Buna ihtiyaç olursa, bunun yerine kendi trafiğimi kısacağım.” 16:26 <jrandom> hmm, bunda anonimlik riskleri var (yine de zaten karşı savunmadığımız seçici DoS çizgisinde) 16:27 <jrandom> fakat tıkanıklık karşısında kendi yerel tunnel build’lerimizi kısmak şu anda test ettiğim bir şey - 4KBps tabanını isteğe bağlı olarak yok sayma desteği eklemek yeterince basit olmalı 16:28 <spinky> Şu anda, çok veri aktarırken hiç örtü trafiği alamıyorsunuz. 16:29 <spinky> Katılım bant genişliği için bir taban olması iyi olur. 16:30 <jrandom> aslında bir tabanımız var (hem paylaşım yüzdesi olarak hem de tüm bant genişliği dağıtıldıktan sonra dahili olarak ayrılan 4KBps) 16:30 <+Complication> Tüh, kopmalar... Umarım söylediklerim çok kaybolmamıştır, ama yanıtları log’dan okumam gerekecek :) 16:32 <@frosk> 4KBps’in özel bir anlamı var mı? 16:33 <jrandom> birkaç şey - 4KB ~= tunnel create message boyutu ve sezgisel olarak, daha azıyla başarıyla çalışan bir router duymadım 16:33 <spinky> O zaman paylaşım yüzdesinin çalışmasını engelleyen hatalar mı var? 16:34 <jrandom> paylaşım yüzdesinin çalışmadığını söylemenize sebep olan ne? 16:34 <@frosk> anladım 16:34 <+Complication> frosk: hayır, şu anki koddaki bir sayı sadece, ben de hayal ettiğimi anlatırken ona referans verdim 16:35 <+Complication> (anlamlı nedenlerden değil, sadece hayal ettiğim şey bir bakıma onun tam zıddıydı) 16:35 <spinky> 80% olarak ayarlı ve yerelde veri üretirken katılım 0’a gidiyor. Belki bir şeyleri yanlış anlıyorumdur. 16:36 <jrandom> ah, evet, paylaşım yüzdesi bunu yapmıyor 16:36 <+Complication> spinky: bu, fiilen paylaşım için mevcut bant genişliğine bağlı olarak paylaşılabilecek şeyin en üst sınırı 16:37 <+Complication> Yerel trafik %70’i kaplıyorsa, paylaşım için sadece %10’unuz kalır 16:37 <+Complication> Yerel trafik ağırsa %0 kalır ve %80’lik üst sınıra hiç dokunulmaz 16:37 <spinky> Tamam. ‘en fazla’ dediğini görüyorum... 16:38 <+Complication> Ayrıca 4 KB/s rezervi de var 16:38 <jrandom> ah, bu elinde mevcut olanın paylaşım yüzdesi 16:38 <spinky> Router’ın daha fazla tunnel kabul edeceği katılım bant genişliği tabanı için başka bir ayar? 16:38 <jrandom> bant genişliğinizin %95’ini kullanıyorsanız, kalan %5’in en fazla %80’ini paylaşır 16:39 <+Complication> O halde ben de kısmen yanlış anlamışım 16:40 <fox> <zorglu1> i2p diğer yerel uygulamaların kullandığı bant genişliği miktarını nasıl ölçüyor? 16:40 <spinky> (Sadece diyorum ki, örtü trafiğini iyi bir şey olarak görüyorsanız, yoğun yerel bant genişliği kullanımında bile yapılandırılabilir olması iyi olabilir) 16:40 <+Complication> Sürdürülebilir sınıra karşı uygulandığını sanıyordum 16:40 <jrandom> zorglu1: i2p’nin bant genişliği kullanımını ölçer ve i2p’nin bant genişliği sınırlarını bilir 16:41 <jrandom> oh, hmm, koda tekrar bakınca, int availBps = (int)(((maxKBps*1024)*share) - used); 16:41 <jrandom> yani haklısın Complication 16:42 <jrandom> spinky: örtü trafiği düşük gecikmeli bir mixnet’te ancak bu kadar faydalı 16:42 <jrandom> daha yüksek bant genişliğine sahip router’lar için bir teşvik ekler, ancak yedek bant genişliği olmayanların pek çaresi yok 16:49 <jrandom> her neyse, tunnel tıkanıklığı konusu bir süredir vardı ama sadece son zamanlarda çılgın tunnel reddetme oranlarıyla daha da kötüleşti 16:49 <jrandom> umarım bir sonraki revizyon bunu çözer 16:49 <jrandom> tamam, 2) tunnel oluşturma ve tıkanıklık hakkında başka bir şey var mı? 16:50 <@frosk> tunnel oluşturma şemasında bazı değişiklikler gerektirecek gibi görünüyor 16:50 <+Complication> Umarım işleri iyileştirmeye yardımcı olur :) 16:51 <+Complication> Bu arada... 16:52 <jrandom> ucuz düzeltmelerimiz var, örneğin azami eşzamanlılığı azaltma, tıkalıyken build girişimlerimizi kısma, düşürme sıklığını azaltma (açık reddetmeye kıyasla) ve profillemeyi düşürme yerine açık reddi teşvik edecek şekilde ayarlama 16:52 <+Complication> ...ham bant genişliği göstergeleri ile tunnel payload göstergeleri arasındaki büyük farkı açıklayabilecek bir şey buldunuz mu? 16:52 <+Complication> (ör. toplam bant genişliği 1 GB, tunnel payload toplamı 300 MB) 16:52 <jrandom> ama doğru, bunlar sadece büyüklüğü etkiliyor 16:52 <+Complication> (son zamanlarda IRC’de pek yoktum, bunu yakınlarda incelediniz mi emin değilim) 16:54 <jrandom> buna çok dalmadım, ama unutmayın, outbound tunnel’lar için tunnel build istekleri tunnel mesajı değildir (ve yalnızca %0.1’i başarılıysa çok sayıda olur. ve her biri 4KB...) 16:54 * Complication bunun göstergeler mi yoksa gerçek bir etki mi olduğundan emin değil 16:55 <+Complication> Oh... outbound build istekleri... gerçekten 16:55 <jrandom> yaklaşan -1 build, mesaj türü başına paket izleme için bir sürü istatistik ekliyor 16:55 <+Complication> Bu tam da o olabilir 16:55 <jrandom> (bu outbound build isteklerine build katılım istekleri de dahil - bir yanıtı iletme) 16:56 <jrandom> ((yani sadece yerel şeyler değil)) 17:00 <+Complication>> Teşekkürler, bu çok şeyi açıklıyor :) 17:00 <+Complication>> O zaman vudu değilmiş, gayet gerçek trafikmiş; ben sadece kontrol ettiğim yerlerde özel olarak sayılmadığı için unutmuşum 17:00 <+Complication> Gerçekten de olmak zorunda ve gerçekten de çok bayta mal olur 17:00 <+Complication> Özellikle başarı oranı düşükse 17:01 <jrandom> evet, yine de olduğundan daha pahalıya mal olmamalı; çünkü olduğundan daha yüksek başarı oranına sahip olmalıyız :) 17:01 <jrandom> tamam, 2) hakkında başka bir şey? 17:02 <jrandom> yoksa 3) Feedspace’e geçelim 17:02 <jrandom> frosk: bize bir güncelleme vermek ister misin? 17:03 <jrandom> (ya da bize fsck olup eepsite okumamızı söylemek ister misin? ;) 17:04 <@frosk> frosk.i2p veya feedspace.i2p’ye dikkat etmeyenler için, feedspace artık temelde çalışıyor (benim “temel” tanımıma göre) 17:04 <jrandom> (w00t) 17:05 <@frosk> son zamanlarda bazı güzel eklemeler oldu, i2p dışındaki taşıyıcılar için altyapısal destek gibi (akla tor ve anonim olmayan tcp/ip geliyor) 17:06 <@frosk> zamanla, syndie’nin (yaklaşan ve muhtemelen çok güzel bir yeniden yazımda) feedspace’i sendikasyon yöntemlerinden biri olarak kullanmasına izin vermeyi planlıyoruz 17:06 <@frosk> şimdilik feedspace’i gerçekten herhangi bir şey için “kullanacak” istemci uygulama yok :) ben son derece ilkel bir servlet uygulamasıyla test ediyorum 17:07 <jrandom> (kaba + işlevsel)++ 17:07 <@frosk> yani elbette bir istemci hacker’ı için iş ilanı var ;) 17:08 <@frosk> herkese açık testten önce feedspace’in ihtiyaç duyduğu bazı gerekli şeyler hâlâ var, ama artık çok uzun sürmemeli :) 17:08 <jrandom> güzel 17:08 <jrandom> yardımcı olabileceğimiz bir şey var mı? 17:08 <@frosk> ayrıca eksik olan belgelendirme üzerinde de biraz çalışıyorum 17:09 <spinky> feedspace’i büyük dosyalar için kullanılabilir görüyor musun? 17:10 <@frosk> 1) (hala belgesiz) xmlrpc api’sini kullanan istemci uygulamaları, 2) http://feedspace.i2p/wiki/Tasks, 3) zamanı geldiğinde testlere katılım 17:10 <@frosk> büyük dosya desteği şu an öncelik değil, belki sonra 17:10 <@frosk> “1.0” odağı, blog ve tartışma girdileri gibi daha küçük iletiler ve her tür etkinlik 17:11 <jrandom> yine de .torrent dosyalarını rss/feedspace destekli bir BT istemcisine beslemek sorun olmaz 17:11 <@frosk> büyük dosyalar çalışabilir de çalışmayabilir de :) 17:11 <@frosk> bu süper hoş bir şey olur 17:12 <jrandom> feed2snark ;) 17:12 <@frosk> umarım bu tür her çeşit “adapter” uygulaması görürüz :) 17:12 <+Complication> Şey, insanlar büyük dosyaları bit... şey, yan kanallarla taşımayı bir şekilde bulacaktır :) 17:15 <@frosk> feedspace kodunun her türlü java1.5 özelliğini kullanması nedeniyle biraz suçluluk duyuyorum. şu anda özgür Java üzerinde derlemek/kullanmak zor olabilir, ama eminim yetişecektir :) 17:15 <jrandom> vah 17:16 <jrandom> gcj’nin 1.5-ism’ler için ecj’yi benimseyeceğine dair söylentiler var 17:16 <spinky> Complication: Eyer çantaları dolu HDD’lerle midilliler mi? 17:16 <@frosk> evet 17:17 <+Complication> spinky: tercihen insansız hava araçları :P 17:17 * jrandom hâlâ zorla 1.4-ism’lere yükseliyor 17:17 <+Complication> Ama galiba midilliler de olur :P 17:17 <jrandom> gerçi 1.6 gerçekten hoş ;) 17:17 <@frosk> gcj ile uyumlu kalmak için mi? 17:18 <@frosk> gerçi 1.6 çoğu şey için çok “ism” getirmiyor bence :) 17:18 <+Complication> (ya da hafıza kartı hava indiren uçan kirpiler) 17:18 <jrandom> gcj/classpath/etc için, ama performans için de (1.5’i 1.4’ten biraz daha ağır buldum) 17:19 <jrandom> doğru, 1.6’nın iyileştirmeleri büyük ölçüde vm/bytecode’a özgü 17:19 <@frosk> hm tamam 17:20 * jrandom seni 1.5-ism’leri kullanmamaya ikna etmeye çalışmıyor. eminim nedenlerin vardır; örn. azureus zaten 1.5 gerektiriyor 17:21 <@frosk> artık geri dönüş yok :) umarım çok sarsıntılı olmaz 17:24 <jrandom> evet, eminim gayet iyi sonuçlanır :) 17:25 <jrandom> tamam güzel, 3) feedspace hakkında başka bir şey var mı? 17:25 * frosk generics ve java.util.concurrent’e sarılır ;) 17:25 <jrandom> heheh 17:27 <jrandom> tamam, 3 ile ilgili başka bir şey yoksa, 4) ???’ya geçelim 17:27 <jrandom> toplantı için başka bir şey var mı? 17:27 <+Complication> 2) altında sormam gereken küçük bir soru 17:28 <+Complication> Boşta katılımcı tunnel’lar tipik olarak nasıl oluşur, biliyor musun? 17:28 <+Complication> Çoğu, yalnızca oluşturucunun gerçekten başarısız olduğunu bildiği başarısız tunnel build’lerinin bir işareti mi? 17:28 <+Complication> Yoksa başka nedenleri de var mı? 17:28 <+Complication> (elbette bariz olanın - yani bir uygulamanın boşta oturmasının - yanında) 17:29 <jrandom> boşta bir uygulamanın boşta tunnel’ı olmaz (test edilirler) 17:29 <jrandom> boşta tunnel’lar bir şekilde başarısız olmuş demektir 17:29 <jrandom> (ya tamamen oluşturulamadı ya da çalışırken başarısız oldu) 17:30 <+Complication> Doğru, yani tüm tunnel’lar zaten test ediliyor ve tunnel testleri trafik oluşturur... gerçekten 17:30 <+Complication> Bu beni sorumun ikinci kısmına getiriyor: bir tunnel’ın boşta olduğunu fark edip onu erken hurdaya çıkarmanın faydası olur mu? 17:31 <+Complication> Orada kurtarılacak kıymetli kaynaklar var mı? 17:32 <jrandom> yok - veri itmeyen bir tunnel kaynak tüketmez 17:32 <jrandom> (tamam, biraz RAM kullanır, belki 32 bayt) 17:32 <+Complication> Ya da belki, bir router’ın yükünün ve benzeri parametrelerin daha iyi resmini tutmasına yardımcı olur mu... 17:33 <jrandom> tunnel geçmişine dayalı bant genişliği kullanımı tahminleri kesinlikle açık bir soru 17:33 <+Complication> Yoksa sadece anlamsız bir iş mi olur ve en iyisi doğal olarak süresi dolana kadar beklemek midir? 17:33 <+Complication> (şu an olduğu gibi) 17:34 <jrandom> Eskiden bazı tahminler yapıyorduk ama net fayda sağlamadı, bu yüzden şimdi daha basit bir algoritma kullanıyoruz 17:34 <+Complication> Hıh, yani kazanç yok... 17:34 <+Complication> Teşekkürler, aslında sormak istediğim buydu :) 17:34 <jrandom> sorun değil, anlaşılabilir bir kaygı 17:34 <jrandom> tamam, toplantı için başka bir şey var mı? 17:35 <+Complication> Evet, eğer tahmin yapsaydık, boşta tunnel yüzdesi tahminleri kaydırabilir 17:35 <+Complication> (eğer anlamlı şekilde değişiyorsa) 17:36 <jrandom> evet, tahminin bir parçası olarak boşta %’yi tutmak isteriz 17:36 <jrandom> (eskiden tutuyorduk - bkz. RouterThrottleImpl.allowTunnel yöntemi) 17:37 <+Complication> Oh, bunu bilmiyordum :) 17:37 <jrandom> ve yeni yoruma dikkat edin: 17:38 <jrandom> // ok, ignore any predictions of 'bytesAllocated', since that makes poorly 17:38 <jrandom> // grounded conclusions about future use (or even the bursty use). Instead, 17:38 <jrandom> // simply say "do we have the bw to handle a new request"? 17:39 * Complication hâlâ dosyaya doğru göz atıyor, ama teşekkürler :) 17:39 <jrandom> w3rd 17:40 <jrandom> tamam, toplantı için başka bir şey yoksa... 17:40 * jrandom toparlar 17:41 * jrandom toplantıyı *baf* ederek kapatır