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

16:12 <jrandom> 0) merhaba 16:12 <jrandom> 1) Ağ durumu ve 0.6.1.17 16:12 <jrandom> 2) I2Phex 16:13 <jrandom> 3) ??? 16:13 <jrandom> 0) merhaba 16:13 * jrandom el sallar 16:13 <@cervantes> selam 16:13 <jrandom> haftalık durum notları @ http://dev.i2p.net/pipermail/i2p/2006-April/001283.html adresine eklendi 16:14 <jrandom> siz onu hızlıca gözden geçirirken, 1) Ağ durumu'na geçelim 16:14 <jrandom> çoğunuzun gördüğü gibi, yeni bir sürüm yayımladık ve şu ana kadar sonuçlar oldukça olumlu 16:15 <@cervantes> (yaşasın!) 16:15 <jrandom> hâlâ olmamız gereken yerde değiliz, ama gördüğümüz başlıca sorunları büyük ölçüde çözüyor 16:15 <jrandom> evet, 2+ hop tunnel'larda yeniden fena sayılmayacak tunnel kurulum oranlarına sahip olmak güzel :) 16:16 * jrandom başka bir router üzerinde 1hop tunnel'larda %50+'lik başarı oranlarına sahip 16:17 <jrandom> Bence 0.6.1.17'deki son birkaç değişiklik, gelecekte bu tür bir yoğunluk çökmesini önlemeye de yardımcı olacak 16:17 <jrandom> Kullanıcının göreceği sonuç ise ara sıra lease'lerin süresinin dolduğunu görecek olmamız; ancak bu durum kendi kendini büyütmek yerine backoff (geri çekilme) yapacak 16:17 * cervantes azureus'u çalıştırır 16:18 <+Complication> Bu sabah, istemci tunnel (uzunluk 2 +/- 1) başarı oranlarını %35 civarında kaydettim 16:18 <+Complication> Şu anda daha düşük, çünkü bazı değişiklikler denedim ve sonuncusu pek iyi değildi :D 16:18 <@cervantes> jrandom: onu bulup çıkardığın için iyi iş - bir ara freenet'e benzemeye başlamıştık :) 16:19 <jrandom> *öksürür* ;) 16:20 <+fox> <inkeystring> jrandom: backoff mekanizmasını kısaca anlatır mısın? Şu anda freenet 0.7 için buna benzer bir şey üzerinde çalışıyorum 16:21 <jrandom> inkeystring: taşıma katmanında, taşıma katmanı aşırı yüklendiğinde bir peer'a iletimleri azaltmak için bir backoff mekanizmamız vardı, ancak bu yeterli değildi 16:21 <@cervantes> *öksürür* freenet mi dedim, tor demek istedim 16:21 <+fox> <inkeystring> :-) 16:22 <jrandom> inkeystring: yeni değişiklik, bunu daha üst bir seviyeye yaymaktı; böylece iletişim katmanımız doygunluğa ulaştığında tunnel kurmaya çalışmayı bırakıyoruz 16:22 <jrandom> (daha fazla tunnel kurma girişimi göndermek yerine) 16:22 <+fox> <inkeystring> teşekkürler - taşıma katmanı yalnızca paketler kaybolduğunda mı backoff yapıyor, yoksa alıcının akışı kontrol etmesinin bir yolu var mı? 16:23 * jrandom toad ile birkaç kez (irc'de ve eski flog'umda) yoğunluğun yönlendirmeye göre etkisini tartıştığını hatırlıyor gibi, ama olumlu net bir çözüm hatırlamıyorum :/ 16:23 <jrandom> alıcı NACK gönderebilir ve ECN için kancalarımız var, ama gerekli olmadılar 16:23 <+fox> <inkeystring> evet tartışma freenet-dev'de yeniden gündeme geldi :-) hâlâ sihirli bir çözüm yok 16:24 <+fox> <inkeystring> harika, bilgi için teşekkürler 16:24 <+Complication> Bu aralar onlar da UDP kullanıyor, değil mi? 16:24 <jrandom> şu anda, aşırı tıkanmış peer'lar sorunlarını her-peer hız sınırlamasında değil, peer iletişiminin genişliğinde yaşıyorlar 16:24 <+Complication> (taşıma protokolü olarak) 16:24 <+fox> <inkeystring> genişlik = peer sayısı mı? 16:24 <jrandom> evet 16:25 <jrandom> artmış tunnel başarı oranlarıyla, peer'ların bir tunnel kurmak için yüzlerce peer ile konuşmasına artık gerek yok 16:25 <jrandom> bu yüzden yalnızca 20-30 peer ile idare edebilirler 16:25 <jrandom> (yani doğrudan bağlı peer'lar) 16:26 <+fox> <inkeystring> sanırım bu NAT hole punching, keepalive'lar vb. için iyi haber? 16:26 <jrandom> diğer yandan, 2-300 aktif SSU bağlantısı ile, 6KBps'lik bir hat zorlanacak 16:26 <jrandom> evet 16:26 <+fox> <inkeystring> Complication: evet 16:27 <+fox> <inkeystring> (0.7 alpha'da) 16:27 <+Complication> Aha, o halde muhtemelen benzer şeylerle karşılaşıyorlar 16:27 <+Complication> Umarım biri sihirli çözümü bulur :D 16:27 <jrandom> Yine de farklı bir şekilde. Taşıma katmanı nispeten kolay bir mesele 16:27 <+fox> <inkeystring> sanırım SSU kodunun bir kısmını yeniden kullanmış olabilirler... ya da en azından bundan bahsettiler 16:27 <jrandom> (yani 30+ yıldır iyi çalışılmış) 16:28 <jrandom> ama i2p (ve freenet) yük dengelemesi uçtan uca bağlantılardan daha üst bir seviyede çalışır ve farklı gereksinimlere sahiptir 16:28 <+fox> <inkeystring> evet, zorluk yönlendirme ile etkileşimde 16:29 <jrandom> evet, gerçi i2p'nin işi daha kolay (söz konusu veriye sahip belirli peer'ları bulmamız gerekmiyor, sadece tunnel'larımıza katılacak kapasiteye sahip herhangi biri yeterli) 16:30 <+fox> <inkeystring> yani aşırı yüklü bir peer'dan kaçınırsanız verim kaybı yok... 16:30 <+fox> <inkeystring> oysa freenet'te, aşırı yüklü bir peer'ı dolaşarak yönlendirmek yol uzunluğunu artırabilir 16:30 <+fox> <inkeystring> neyse, bu konu dışı, kusura bakmayın 16:31 <jrandom> sorun değil, 0.6.1.17'deki değişikliklerin neden yoğunluk çökmesini etkilediğini açıklamak yerindeydi :) 16:31 <jrandom> tamam, 1) Ağ durumu için başka ekleyecek bir şeyi olan var mı? 16:32 <+Complication> Şey, daha önce de belirtildiği gibi, saf .17 çalıştırırken bant genişliği ve aktif peer'larda fark edilir bir periyodiklik gözlemledim 16:32 <+Complication> Birkaç kişinin daha bunu yaşadığı görünüyor, ancak ne kadar yaygın olduğuna dair bir fikrim yok 16:33 <+Complication> Birincil nedenlerini merak ediyordum, çoğunlukla tunnel hız sınırlaması açısından, ama henüz bir çözüm yok 16:33 <+Complication> Kendi grafikleri daha düz görünür hale getirmeyi başardım, ama bunu genel bir bozulma pahasına yaptım 16:33 <+Complication> Şu tür değişiklikler denedim: 16:34 <+Complication>> _log.error("Allowed was " + allowed + ", but we were overloaded, so ended up allowing " + Math.min(allowed,1)); 16:34 <+Complication> (bu, kendi tunnel'ları için kurma girişimlerinden tamamen kaçınmasını önlemek içindi) 16:35 <jrandom> ah doğru 16:35 <+Complication> (ah, ve doğal olarak loglevel garip, çünkü test için onları değiştirdim) 16:35 <jrandom> orada periyodikliği biraz kaydırmaya çalışan bazı kodlarımız var, ama pek doğru çalışmıyor (belli ki) 16:36 * perv sistemini mahvetti :( 16:36 <+Complication> Ama bunun gibi bazı şeyler denedim ve tunnel sayıları için büyüme faktörünü azaltmayı denedim 16:36 <perv> reiser4 için bir undelete var mı? 16:36 <jrandom> temelde, tunnel'lar gerçekte olduğundan (rastgele) daha erken sona eriyormuş gibi davranırsak bu yardımcı olmalı 16:36 <+Complication> Şu anda TunnelPool.java içindeki büyük "countHowManyToBuild" fonksiyonunu okuyorum :D 16:36 <+Complication> Ama henüz baştan sona okumadım 16:37 <jrandom> (gerçi bu, tunnel kurma sıklığını bariz şekilde artırırdı ki 0.6.1.17'den önce makul olmazdı) 16:37 <+Complication> perv: bir şey var 16:37 <jrandom> hmm, oraya bir rastgelelik koymak zor olur Complication, çünkü o fonksiyonu oldukça sık çağırıyoruz 16:38 * perv kurtarmayı ve gentoo'ya geçmeyi düşünüyor 16:38 <jrandom> önereceğim şey, başarıyla kurulmuş tunnel'ların sona erme zamanını rastgeleleştirmeye bakmanız olurdu 16:38 <+Complication> perv: reiser ile ext3'ten daha iyi durumdasın, kesinlikle 16:38 <+Complication> perv: ama ezbere bilmiyorum 16:38 <+Complication> jrandom: doğru, bazen bu şekilde fazla kurulum yapabilir 16:38 <jrandom> (böylece mevcut countHowManyToBuild, gerçekte ihtiyaç duyulmadan önce onlara ihtiyaç olduğunu sanır) 16:38 <+Complication> (ve bazen tunnel'lar koptuğunda acele edip kaçınılmaz olarak fazla kurar) 16:40 <+Complication> Hmm, düşünmediğim bir olasılık... 16:41 <+Complication> Her halükârda, bununla da oynuyorum, ama henüz işe yarar gözlemler yok 16:42 <jrandom> harika, bunun üzerinde benim de oynadığım bazı ince ayarlar var, belki bir sonraki build'e birlikte koyup makul şekilde işler bir ağda nasıl çalıştığını görürüz ;) 16:43 <spinky> i2p ağının uygulama verisine ne kadar overhead eklediğini görebileceğiniz bir istatistik var mı? 16:43 <jrandom> "overhead" çok yüklü bir terim... ;) 16:43 <jrandom> biz ona anonimliğin bedeli diyoruz ;) 16:43 <spinky> hehe 16:45 <jrandom> (yani pek değil. mükemmel bir ağda 0 tıkanıklık ve 1+1hop ile uygulama katmanı yükü uç noktalar için yaklaşık %70-80 verim elde eder) 16:45 <jrandom> ((en son ölçtüğümde)) 16:45 <jrandom> ama bunlar gerçekten laboratuvar koşulları 16:45 <jrandom> canlı ağ çok daha karmaşık 16:47 <spinky> Doğru, sadece tunnel kurma, anahtarlar, padding vb. için kullanılan ekstra veri miktarını kastettim 16:47 <spinky> ...aktarılan uygulama verisiyle karşılaştırıldığında 16:47 <jrandom> mesaj çerçevelemesine, tıkanıklığa, tunnel kurma başarı oranlarına vb. bağlıdır 16:48 <jrandom> 2 hop bir tunnel, ağın 20KB taşımasıyla kurulabilir 16:48 <+Complication> Bunu ara sıra test etmek istedim, öncelikle BitTorrent ve I2Phex gibi toplu aktarım uygulamalarının "israfçılık" düzeyini tahmin etmek amacıyla 16:48 <+Complication> Ama iki düğümüm arasında temiz bir ölçüm yapmaya fırsat bulamadım 16:48 <+Complication> Bir gün buna geri döneceğim yine de 16:49 <jrandom> Complication: konuşkan uygulamalarla bu oldukça zor, wget'i ölçmek çok daha basit :) 16:49 <+Complication> Ne kadar da doğru 16:50 <+Complication> Deneyebildiklerimde, kesinliğe benzer bir şey bile yoktu 16:54 <jrandom> tamam, 1) ile ilgili başka bir şey yoksa, 2) I2Phex'e geçelim 16:55 <jrandom> Complication: neyle uğraşıyorsun? :) 16:55 <+Complication> Dünkü commit, benim aptal ilk-çalıştırma algılayıcım nedeniyle bazı kişilerin yaşadığı belirli sorunlara bir düzeltmeydi 16:56 <+Complication> İlk-çalıştırma algılayıcısı artık daha az aptal ve bar normal davranmaya başladığını bildirdi 16:56 <+Complication> Bununla birlikte, I2Phex mevcut ağ koşullarında zaten çalışabilir göründüğünden, 16:56 <+Complication> rehash hatasını da bulmayı deneyeceğim. 16:57 <+Complication> Yapabilirsem tabii 16:57 <jrandom> harika, bunun seni aylardır rahatsız ettiğini biliyorum 16:57 <+Complication> İlginç olan, ana Phex'te de olabilir; onların gözlemlerini bulup okumayı da deneyeceğim 16:58 <jrandom> ama başlangıç düzeltmesinin içinde olduğunu duymak güzel 16:58 <jrandom> ah aynen 16:58 <+Complication> =is that 16:58 <+Complication> Ancak şu anda ana Phex'te olup olmadığını doğrulayamıyorum - şahsen orada hiç görmedim 16:59 <jrandom> (aralıklı hatalar)-- 16:59 <+Complication> Kontrollü biçimde tetiklemek zor, dolayısıyla bulmak da zor 17:00 <+Complication> Benim tarafımdan şimdilik aşağı yukarı bu kadar 17:00 <+Complication> İleride, I2Phex'in aynı anda başlattığı paralel peer iletişim girişimlerinin sayısını sınırlamanın faydalı olup olmayacağını merak ediyordum 17:01 <jrandom> evet, muhtemelen 17:01 <+Complication> Çünkü kısa sürede bir sürü NetDB sorgusu oluştururlar ve bu, bir I2P router açısından potansiyel olarak pek hoş olmayabilir 17:02 <jrandom> ayrıca yeni hedef bağlantıları aes yerine elG gerektirir 17:02 <+Complication> Ama bu hedefe yönelik gerçek bir kod okumadım ya da yazmadım henüz 17:04 <jrandom> k sorun yok. belki efsanevi i2phex/phex birleşmesi bir çözüm de getirir :) 17:04 <+Complication> Ve benim açımdan, I2Phex cephesinden haberler aşağı yukarı bu kadar... 17:04 <jrandom> harika, güncelleme ve konuları inceleme çaban için teşekkürler! 17:05 <jrandom> tamam, 3) ???'a geçelim 17:05 <jrandom> toplantıda gündeme getirecek başka bir şey olan var mı? 17:05 <lsmith> merhaba! son sürümdeki harika iyileştirmeler için geliştiricileri tebrik etmek istiyorum, toplam bw değerim 0.9/1.4 KBps ve irc'ye bağlı kalıyorum... bu... akıl almaz derecede havalı :) 17:05 <+Complication> :D 17:06 <jrandom> yol boyunca sabrınız için teşekkürler - düşük bw kullanıcılarını desteklemek kritik 17:06 <@cervantes> lsmith: bu gerçekten iyi 17:06 <@cervantes> * Bağlantı Sıfırlandı 17:06 <jrandom> heh 17:07 <lsmith> :) 17:09 <jrandom> ah, dikkat çekici bir başka şey de zzz'nin geri dönmüş olması ve onunla birlikte stats.i2p'nin gelmesi :) 17:09 <jrandom> [wewt] 17:11 <+Complication> Karşılaştırma verisi için epey yararlı bir kaynak :) 17:11 <jrandom> kesinlikle 17:11 <jrandom> tamam, toplantı için başka bir şey olan var mı? 17:13 <jrandom> yoksa... 17:13 <jdot> bende baf sonrası bir iki soru var 17:13 <jrandom> heh tamam, o zaman baffer'ı başlatalım :) 17:13 * jrandom hazırlanır... 17:13 * jrandom *baf*s toplantıyı kapatır