I2P Geliştirici Toplantısı - 04 Nisan 2006

16:21 <jrandom> 0) selam 16:21 <jrandom> 1) Ağ durumu ve 0.6.1.14 16:21 <jrandom> 2) Syndie planlaması 16:21 <jrandom> 3) Yerel jbigi optimizasyonları 16:21 <jrandom> 4) ??? 16:21 <jrandom> 0) selam 16:21 * jrandom el sallar 16:21 <jrandom> haftalık durum notları şu adreste yayınlandı: http://dev.i2p.net/pipermail/i2p/2006-April/001275.html 16:21 * Complication okur 16:22 <jrandom> siz o (kısaca hazırlanmış) gönderiyi okurken, 1) Ağ durumu ile başlayalım 16:23 <@cervantes> (forum geri geldi) 16:23 <jrandom> 0.6.1.13 üzerinde kullanımı etkileyen birkaç sorun var ve bunların çoğu izlenip çözüldü 16:24 <Complication> Burada, "dördüncü" CVS derlemesiyle, grafiklerimde bir değişiklik fark ettim 16:24 <jrandom> yine de hâlâ test edilip elden geçirilen birkaç pürüz var, fakat bir sürüm önümüzdeki birkaç gün içinde çıkmalı 16:24 <Complication> Genel olarak her şey daha fazla kararlılığa ve daha az oynaklığa doğru gitti 16:24 <jrandom> ah kahretsin, onu -4'e yükseltmeyi unuttum değil mi? 16:24 <jrandom> (tamam, -5 bu akşam ilerleyen saatlerde çıkacak) 16:24 <jrandom> harika Complication 16:25 <Complication> Ama algılarım jbigi tarafından da etkilenmiş olabilir, onu dışlamak için bir şey yapmadım 16:25 <Complication> Şimdi, bir süre sonra yeniden iletim de %15'e kadar düştü 16:28 <jrandom> hmm, ben de ortalama SSU RTO değerimin 3 sn tavanına yaklaştığını görüyorum 16:28 <jrandom> (ancak yeniden iletim hâlâ çok düşük, %5'in altında) 16:29 * Complication tekrar bir göz atar 16:29 <Complication> Diyelim ki ham ortalama 1500'ün biraz üzerinde 16:29 <Complication> (burada) 16:30 <+fox> <BrianR___> jrandom: I2P paketleri için fiilî bir "MTU" var mı? 16:30 <jrandom> ah tamam, belki o yavaşça yükseldikçe, yeniden iletim oranı düşer 16:30 <Complication> Bendekinin daha küçük MTU'larla başladığını fark ettim, şimdi biraz artıp 1350 oldu 16:30 <jrandom> BrianR___: evet, ya 1350 ya da 608 (`http://localhost:7657/peers.js` üzerinde gösterildiği gibi) 16:31 <jrandom> daha büyük MTU'da hata oranı çok yüksekse daha küçük MTU'ya geri düşer (ve daha küçük MTU'da çok düşükse daha yüksek MTU'ya zıplar) 16:31 <+fox> <BrianR___> Peki bu içteki veri yükü için mi, yoksa görünen IP paketleri için mi? 16:31 <+fox> <BrianR___> Şöyle ki, bir I2P stream üzerinden bir veri bloğu gönderecek olsam, ek yükü en aza indirmek için parçaların ideal boyutu ne olurdu? 16:31 <jrandom> bu UDP veri yükü içindir 16:32 <jrandom> streams iki katman yukarıdadır 16:32 <jrandom> (tunnels için parçalama var ve sonra stream/I2CP düzeyinde parçalama var) 16:32 <+fox> <BrianR___> Evet... Parçalamayı en aza indirmek için ideal bir boyut var mı? 16:32 <jrandom> streaming lib (akış kitaplığı) kullanan bir uygulamanın ideal blok boyutu "büyük"tür; böylece streaming lib uygun boyutu kullanabilir. 16:33 <jrandom> (yani perdenin arkasındaki adamı görmezden gelin) 16:33 <+fox> <BrianR___> Aaah... O hâlde belki pipelining ya da buna benzer bir şey düşünmeliyim.. 16:34 <+fox> <BrianR___> Çok sayıda istek/yanıt trafiği olan bir uygulama planlıyorum... 16:34 <jrandom> o zaman gevezeliği azaltmak için toplu işlemeyi öneririm 16:34 <Complication> Belki trafiği odaklı tutmak bir nebze yardımcı olur 16:37 <jrandom> tamam, 1) Ağ durumu hakkında başka bir şey var mı, yoksa 2) Syndie planlamasına doğru kayalım mı 16:38 * jrandom salınır 16:39 <jrandom> bu büyük ölçüde bir yer tutucu ve cfp - Syndie'de hem işleyişte hem de UI'da ciddi bir yenileme olacak, bu yüzden ele alınması gerektiğini düşündüğünüz bazı kritik özellikler veya kullanım senaryoları varsa, iletişime geçin 16:40 <jrandom> (konular daha da somutlaştıkça elbette daha fazla bilgi gelecek) 16:42 <jrandom> şimdilik bu konuda söyleyeceklerim bu kadar, o hâlde 3) jbigi optimizasyonlarına geçelim 16:42 <@frosk> ve ben de "plotting"in Syndie'deki bazı jrobin işlerine atıf yaptığını sanmıştım :) 16:43 <jrandom> hehe 16:43 <jrandom> günlük gönderiler, yazar başına gönderiler, günlük yeni yazarlar vb. şeyleri çizmek ilginç olur ;) 16:44 <Complication> Ah, Syndie hakkında bir not (üzgünüm, şimdi hatırladım) 16:44 <Complication> =bir not 16:44 <@frosk> hangisini istiyorsun, 0 mı 1 mi? :) 16:44 <Complication> Favori yazarları ve kara listeye alınmış (spam) yazarları iki ayrı listeye ayırmak pratik olur mu, kolay/zor mudur? 16:45 <Complication> addresses.jsp üzerinde 16:45 <jrandom> ah, evet pek zahmetsizce 16:46 <jrandom> bu yenileme için de iyi bir fikir, ama belki bunu 0.6.1.14 derlemesine de koyabiliriz 16:47 <Complication> Yok, bu beni rahatsız etmiyor, sadece o zaman fark ettiğim bir şeyi hatırladım 16:47 <Complication> Her neyse, yerelde derleyip GMP 4.2 kullandığınızda Linux/AMD64 üzerinde jbigi hızlanıyor 16:48 <jrandom> güzel 16:48 <jrandom> bunu GMP 4.1.2 üzerinde -O3 -m64 ile karşılaştırdın mı? 16:48 <Complication> Ve yanlış derleme bayraklarının peşinden gittiğim için tam bir aptalım :O 16:48 <@cervantes> ilgili bağlantı bu arada `http://forum.i2p/viewtopic.php?t=1523&start=30` idi 16:48 <jrandom> ah teşekkürler cervantes 16:48 <Complication> jrandom: Henüz karşılaştırmadım, ama yapacağım 16:49 <Complication> Bir sonraki planlı yeniden başlatmada 16:50 <jrandom> jbigi derleme süreci esasen "GMP'yi derle, sonra jbigi.o'yu derle ve ikisini birbirine bağla" şeklindedir, dolayısıyla insanların GMP üzerinde yapmak istediği her tür optimizasyon ilk adımda yapılabilir 16:50 <@cervantes> Yaptığım önceki testlerin hiçbirinde -O3 ile -O2 arasında fazla fark görmedim, x86_64 altında farklı mıdır ... *omuz silker* 16:50 <jrandom> evet, derleyicinin sürümüne de bağlı olabilir 16:50 <jrandom> (özellikle tüm şu 3.3/3.4/4.0/4.1 meseleleriyle) 16:51 <@cervantes> o başlıkta belirttiğimi yinelemek gerekirse... yakın zamanda Windows64 için optimize edilmiş jbigi görmeyeceğiz muhtemelen 16:51 <+fox> <BrianR___> i2p stream lib veri yükünü sıkıştırıyor mu? 16:52 <Complication> BrianR: evet 16:52 <@cervantes> tabii birinin M$ VC 2005 + 64-bit SDK'sı olup GMP'yi derletmek için ciddi emek harcamak istememesi hâlinde 16:52 <Complication> En azından bildiğim kadarıyla 16:53 <@cervantes> (yine de GMP'yi bir VC projesine taşımak için bir proje bir yerlerde vardı) 16:53 <jrandom> cervantes: şey, amd64/win için /çalışan/ bir tane var ama donanımdan azamî faydalanmıyor ;) 16:53 <jrandom> (yeni kutum geldiğinde bunu kurcalayabilirim, çünkü o bir amd64) 16:53 <+fox> <BrianR___> bitlerden tasarruf için ikili bir protokol mü kullanmalıyım, yoksa zlib ya da benzeri bir şey ASCII protokolünü güzelce küçültecek mi, bunu anlamaya çalışıyorum.. 16:54 <@cervantes> harika - ne yazık ki Mingw64 veya cygwin64 yakın ufukta görünmüyor... 16:54 <jrandom> BrianR___: erken optimizasyon tüm kötülüklerin anasıdır, falan filan... 16:55 <Complication> en azından kısmen insan tarafından okunabilir protokollerin hata ayıklaması genelde daha kolaydır, ama sanırım ne yapıldığına bağlı 16:56 <Complication> (çünkü şifreleme gibi bazı şeyler, ne olursa olsun, insan tarafından okunur olmayı sevmez :) ) 16:57 <Complication> Ama I2P şifrelemeyi yapıyor ve ayrıca sıkıştırıyorsa, üzerinde gerçekleşen pek çok şeyin insan tarafından okunabilir protokollerle yapılabilme ihtimali yüksektir 16:58 <jrandom> evet 16:58 <jrandom> tamam, 3) jbigi işleri hakkında başka bir şey? 16:58 <jrandom> yoksa, 4) ???'a geçelim 16:59 <jrandom> toplantı için başka bir şey olan var mı? 17:01 <+tethra> yakın zamanda anonim işbirliği araçları hakkında bir şeyler duyduğumu hatırlıyorum 17:01 <+tethra> ne tür olduklarını ve Syndie tarzında olup olmayacaklarını açar mısın? 17:02 <@cervantes> irc ve syndie anonim işbirliği aracıdır :) 17:02 <jrandom> hmm, neye atıfta bulunduğundan emin değilim - ya da belki planlanan asıl Syndie yenilemelerini mi kastediyorsun? :) 17:02 <+tethra> doğru. 17:02 * tethra da emin değil, bu yüzden sordu 17:02 <+tethra> forumlarda bununla ilgili konuşmalar vardı - anonimliğin nedenleri falan 17:03 <+tethra> alıntı yapabilmek için başlığı bulacağım 17:03 <jrandom> ah doğru 17:03 <+tethra> http://forum.i2p.net/viewtopic.php?t=1618 17:03 <jrandom> kullanım senaryosu başlığı 17:03 <+tethra> - anonim barındırılan & herkese açık erişilebilen forumlar/panolar/wikiler 17:03 <+tethra> evet 17:04 <+tethra> Syndie gibi bir şey etrafında temellenen bir i2wiki türü proje olacak mı, yoksa bu kullanıcılara mı kalmış? 17:04 <jrandom> orada bazı iyi fikirler ve iyi geri bildirimler oldu 17:05 <jrandom> Syndie gönderilerini düzenleme olanağı sıkça istenen bir özellik ve bununla, zengin bir editörle bir wiki çıkarabilirsiniz 17:05 <jrandom> ama tabii hiçbir şey bir vakumda var olmaz - birisi bunun gerekli olduğuna inanıyorsa, birisi "hey, bir wiki vazgeçilmez ve işte nedeni" demeli 17:06 <jrandom> yapılabilecek /sonsuz/ sayıda uygulama var, ancak güçlü anonimlik ve güçlü güvenliği hedeflediğimiz için, neyin inşa edildiği konusunda dikkatli olunmalı 17:07 <+tethra> doğru 17:07 <+tethra> öyle olmakla birlikte, anonim ve güvenli tutulması daha zor bazı şeylerin, bu konuda iyi olan biri tarafından yapılması daha iyi olabilir, değil mi? 17:08 <jrandom> muhtemelen öyle, ancak herhangi bir gizli klik yok - herkes öğrenebilir 17:08 <+tethra> (temel şeyler, esasen. Tek tek saymıyorum ama neyse.) 17:08 <+tethra> doğru 17:09 <+tethra> ama kendi ve başkalarının anonimliğinin pahasına öğrenmek pek iyi bir yol değil 17:10 <jrandom> elbet herkes bir yerden başlamak zorunda 17:10 <+tethra> (belki biri insanların $software çalıştırmasına ve başkalarının ona saldırmasına vb. izin veren bir sandbox (kum havuzu) benzeri bir şey yaparsa, bu yeni/deneyimsiz biri için iyi olur?) 17:10 <+tethra> evet 17:14 <jrandom> tamam, toplantı için başka bir şeyi olan var mı? 17:15 <jrandom> yoksa 17:15 * jrandom toparlar 17:15 <@cervantes> *öhm* 17:15 * jrandom duraklar 17:16 <jrandom> n'aber cerv? 17:16 <Complication> Harika, bir baf buldum ;P 17:17 <jrandom> baf-engellendi ;) 17:17 <@cervantes> hups üzgünüm, baf'lamaya devam 17:17 * jrandom toparlamaya devam eder 17:18 * jrandom toplantıyı *baf*'layarak kapatır