I2P Geliştirici Toplantısı - 28 Aralık 2004

13:06 <@jrandom> 0) merhaba 13:06 <@jrandom> 1) 0.4.2.5 13:06 <@jrandom> 2) 0.5 13:06 <@jrandom> 3) ??? 13:06 <@jrandom> 0) merhaba 13:06 * jrandom el sallar 13:06 <+postman> *el sallar* 13:06 <ant> <jnymo> merhaba 13:06 <@jrandom> kısa durum notları şurada yayınlandı @ http://dev.i2p.net/pipermail/i2p/2004-December/000535.html 13:07 <@jrandom> 1) 0.4.2.5'e geçiyorum 13:07 <@jrandom> belirtildiği gibi, işler büyük ölçüde çalışıyor 13:08 <+postman> evet, oldukça etkileyici 13:08 <+postman> benim sistemlerimde artık hiç lease zaman aşımı yok 13:08 <@jrandom> birçok kişi senin gördüğünü gördü jnymo, 0 katılımcı tunnel ile, büyük ölçüde artan verimlilik ve eş seçimine bağlı olarak (artık postman'ın makinesini sömürmeyi biliyoruz ;) 13:08 <ant> <jnymo> ben de 13:08 <@jrandom> güzel 13:08 <ant> <jnymo> ve eepsite'ler hızlı 13:09 <+postman> :) 13:09 <ant> <jnymo> teşekkürler postman :) 13:09 <+postman> toplam bw 29kb / 30.1kb/s 13:09 <frosk> herkes daha az seviliyormuş gibi hissediyor, ama gerçekte sevgi sadece daha verimli işe koşuluyor 13:10 <ant> <jnymo> vay 13:10 <@jrandom> şahane, postman 13:10 <mule2> bunun tercih edilen ideal olduğunu sanmıyorum. tüm düğümlerden biraz trafik geçmesi daha iyi olur 13:10 <ant> <jnymo> insanlar beni sevse bunu kaldırabilirdim :( 13:10 <+postman> evet 13:10 <mule2> bir tür cover traffic (örtü trafiği) olarak 13:10 <@jrandom> mule2: mesele yükümüzün ağ kapasitemizden çok daha az olması 13:11 <@jrandom> kapasiteyi yükten uzun süre büyük tutabileceğimizi sanmıyorum 13:11 <ant> <jnymo> mule2, postman ayrıca bir karıştırıcı (mix) gibi davranıyor.. bu yüzden paketlerin içeri girdikten sonra nereye gittiğini söylemek zor 13:11 <@jrandom> bu yüzden daha yavaş eşler üzerinden veri itmemekten pek kaygı duymuyorum 13:12 <mule2> muhtemelen daha az kusursuz optimizasyon anonimliğe iyi gelir 13:12 <@jrandom> öte yandan, bu aynı zamanda daha çok kişinin i2pcontent'i (uygulayıp &) kullanması için teşvik sağlar, böylece hem yansılama yapabilirler hem de cover traffic kazanabilirler ;) 13:12 <jdot__> tek bir router'ın tüm(üne yakın) tunnel'ları taşıması bir güvenlik sorunu mu? 13:13 <@jrandom> mule2: önce olabildiğince iyi hale getirelim, sonra proaktif olarak nasıl kötüleştireceğimizi tartışırız 13:13 <@jrandom> jdot__: tek bir router tüm trafiği taşımıyor, ama çok hızlı bağlantılardaki (colo [barındırma merkezi], vb.) router'ların dialup/dsl/kablo kullanıcılarından daha fazla yük taşıdığını görüyoruz 13:14 <@jrandom> ayrıca azalan tunnel arızaları daha az kaydırdığımız ve daha az keşif yaptığımız anlamına geliyor 13:14 <mule2> router'ların sınırlarından uzak olduğumuz sürece biraz trafik dağıtımı mümkün olabilir 13:14 <@jrandom> doğru, olasılıksal tunnel reddi router'da var ve router'ın bant genişliği sınırlarına göre etkinleştirilebilir 13:15 <ant> <jnymo> evet, ama postman'ın düğümündeki bu kadar yüksek throughput düğümünü analiz etmeyi zorlaştırıyor.. bu yüzden tüm düğümlerin 1 KB/s yapmasındansa ona üzerinden göndermek daha güvenli olabilir.. 13:15 <@jrandom> (ama postman herhangi bir sınır koymazsa, bunun %'sine göre reddedemeyiz ;) 13:15 <ant> <jnymo> daha hızlı düğümlerin gruplaşması bir tür mix kademelenme yapısı oluşturur, değil mi? 13:15 <@jrandom> evet, öyle de bakılabilir 13:15 <lektriK> Start I2P penceresini kapatabilir miyim? 13:15 * postman bant genişliğini KISITLAMADIĞI için çok üzgün 13:16 <@jrandom> lektriK: ne yazık ki pek değil, i2p'yi bir servis olarak başlatmadıkça (Bkz. http://localhost:7657/configservice.jsp) 13:16 <@jrandom> heh postman merak etme, router'ının kapasitesine ulaşırsak/ulaştığımızda router'ından çekileceğiz 13:17 <lektriK> Tamam, 'service started' diyor 13:17 <lektriK> şimdi kapatabilir miyim? 13:17 <@jrandom> lektriK: hayır/evet - router'ını kapatıp sonra start->run->"net start i2p" ile tekrar başlatabilirsin 13:18 <mule2> şu haliyle, birkaç çok büyük router tüm tunnel'ları taşıyabilir ve diğer tüm router'lardan cover traffic'i kaldırabilir. ama bunu toplantıdan sonra sürdürelim. 13:18 <mule2> ağın çok iyi davranmasından şikayet etmek istemem :) 13:18 <@jrandom> hehe 13:20 <@jrandom> 0.5 ile biraz daha keşif olacak, ancak fazla yayılmanın anonimliğe dair sorunları var. yine de 0.5 için bununla ilgili üzerinde çalışılacak ayrıntılar olacak (ve belki gelecek hafta ilk taslağı hazır olacak belgede) 13:21 <@jrandom> neyse, 0.4.2.5 için gündeme getirecek başka bir şey var mı? 13:21 <@jrandom> yoksa kısaca 2) 0.5'e geçelim mi? 13:21 <+postman> geç 13:21 <ant> <jnymo> çok kararlı... geçelim 13:21 <@jrandom> geçmiş sayın 13:22 <@jrandom> 2) 0.5 13:22 <@jrandom> evet. hâlâ üzerinde çalışılıyor. hazır olunca daha fazla bilgi. 13:22 <ant> <Quadn-werk> Sir Arthur C. Clarke hayatta :P 13:22 <ant> <Quadn-werk> http://slashdot.org/articles/04/12/28/0120240.shtml?tid=99&tid=1 13:22 <ant> <jnymo> .5 heyecan verici 13:22 <@jrandom> tamam, bu konuda söyleyeceklerim bu kadar - bununla ilgili sorusu / tartışacağı bir şey olan var mı? 13:23 <@jrandom> evet, son 16 ayda öğrendiklerimize dayanarak kesinlikle bazı önemli yenilemeler yapılıyor 13:23 <@jrandom> (ya da lanet olsun, 18) 13:23 <+postman> jrandom: yani 0.5 ağırlıklı olarak yeni bir tunnel yönetim sistemi kullanacak? 13:23 <ant> <Quadn-werk> off, umarım toplantıyı bölmedim :/ 13:23 <+postman> vay 13:23 <ant> <Quadn-werk> üzgünüm heh 13:23 <ant> <jnymo> heh. bir önerim vardı 13:24 <@jrandom> evet postman, yeni yönetim, havuzlama ve kurma 13:24 <+postman> quadn: yaptığın şeye bak - yapıştırman bir netsplit'e yol açtı :) 13:24 <@jrandom> pis herif! 13:24 <ant> <Quadn-werk> ! 13:24 <@jrandom> ne var ne yok jnymo? 13:24 <+postman> jrandom: her tunnel hâlâ ayrı bir yerel Destination (hedef kimlik) mı olacak? 13:25 <@jrandom> huzzawuzzah? 13:25 <@jrandom> 0.5'te i2ptunnel'da herhangi bir değişiklik olmayacak 13:25 <+postman> jrandom: tamam 13:25 <@jrandom> (en azından, hiçbirini planlamıyorum) 13:26 <mule> postman bir intersection attack (kesişim saldırısı) mı başlatıyor? 13:26 <ant> <jnymo> hiç bant genişliği kullanımı alamayanlar için.. router'ların, kendilerini de içine koyarak tunnel kurmasına ne dersiniz.. ABCABCA gibi 13:26 <+postman> mule: hayır, quadn'ın suçuydu :) 13:26 <ant> <jnymo> ve bu bir dummy tunnel olurdu 13:27 <@jrandom> jnymo: bir router'ı “hey fazla bant genişliğim var, beni kullanın” diye ilan etmek tehlikeli bir oyun 13:27 <+postman> jrandom: peki yeniden tasarımla hangi sorunlar ele alınacak (kısaca) 13:27 <ant> <jnymo> bunu kastettiğimden emin değilim, jrandom 13:27 <@jrandom> ama şu anki görünüm, iki tür tunnel olacağı — normal olanlar ve keşif amaçlı olanlar; keşif olanlar rasgele seçilmiş başarısız olmayan eşlerden kurulacak 13:28 <ant> <jnymo> jrandom: bir dummy tunnel oluşturmayı ve sadece biraz trafik simüle etmek için kendimi o tunnel'ın ortasına koymayı kastetmiştim 13:29 <@jrandom> postman: bir tunnel içindeki eşleri ilişkilendirmeyi çok daha zor hale getirmek, istemcilerin çıkış tunnel uzunluğunu etkin biçimde seçmesine izin vermek ve predecessor attack'ı (öncül saldırısı) ele almak için gerekli seçenekleri sağlamak (çeşitli ödünlerle) 13:29 <@jrandom> (ah, bir de çok sayıda modPow çağrısından kurtularak performansı iyileştirmek) 13:29 <+postman> tamam, teşekkürler 13:29 <ant> <jnymo> postman: ve her sıçrama için tunnel id'leri büyük bir konu 13:30 <+postman> modpow? 13:30 <@jrandom> ah jnymo. evet, çeşitli chaff traffic (karıştırıcı dolgu trafiği) üretimi için çok potansiyel var 13:30 <ant> <jnymo> bu şekilde, komşu olmayan iki düğüm aynı tunnel üzerinde olduklarını bilemez, postman 13:30 <@jrandom> postman: modüler üstel hesaplama, ağır CPU kullanımı ve bellek israfı 13:31 <ant> <jnymo> jrandom: k güzel 13:31 <+postman> k 13:31 <scintilla> jrandom, istemcilerin tunnel uzunluğunu seçmesine izin verilmesiyle ilgili olarak: insanların bunu 99'a (ya da her neyse) kadar açmasını engelleyecek bir şey olacak mı? 13:31 <ant> <jnymo> cpu gücü 13:32 <@jrandom> gerektiğinde hashcash ekleyebiliriz, ama aşırı uzun tunnel'lar zaten sonunda başarısız olacak 13:32 <scintilla> ah iyi nokta 13:32 <@jrandom> hatta biraz hile de ekleyebiliriz — bir tunnel'ın 'geçerli' sayılması için, oluşturulduktan sonraki 60 sn içinde içinden geçerli bir tunnel mesajı geçirilmesini zorunlu kılmak 13:33 <@jrandom> (böylece tunnel 20 sıçrama uzunluğundaysa, tüm o sıçramaları kurmaları çok uzun sürer) 13:33 <scintilla> harika fikir — böyle saçmalıkların uzun süre sürüncemede kalmasını engeller 13:33 <@jrandom> ama bunların hepsi hacker'lara karşı. normal kullanıcılar yalnızca sunulan arayüzü kullanacak 13:34 <ant> <jnymo> doğru, bunu bir yerde sınırlayacaksınız değil mi? 13:34 <ant> <jnymo> şu anki en fazla 2'den daha yükseğine ulaşacağız, değil mi? 13:34 <@jrandom> doğru, /configclients.jsp veya /i2ptunnel/edit.jsp üzerindeki # hops açılırında olduğu gibi 13:35 <@jrandom> oh şu an en fazla 3 sanıyordum? tamam, ama evet, 2'den yüksek seçenekler olacak 13:35 <ant> <jnymo> 3 tunnel, 2 sıçrama 13:35 <@jrandom> ah 'k 13:35 <@jrandom> evet, 0.5 bazı önemli yeni ayarlamalar ekleyecek, örneğin bu uzunlukların rastgeleleştirilip rastgeleleştirilmeyeceği ve ne kadar rastgeleleştirileceği vb. 13:36 <frosk> en fazla gerçekten 3 13:36 <ant> <jnymo> hmm 13:37 <@jrandom> ah /configclients üzerinde 3, i2ptunnel üzerinde 2 13:37 <frosk> 0.5 hâlâ ocak için yolunda mı? 13:37 <ant> <jnymo> ah 13:37 <@jrandom> evet frosk 13:37 <frosk> güzel 13:37 <@jrandom> streaming lib üzerinde daha fazla oyalanmayacağım, söz ;) 13:37 <frosk> kulağa çok iş gibi geliyor :) 13:38 <@jrandom> aslında o kadar da kötü değil, zor olan kısım algoritmaları doğru yapmak 13:38 <@jrandom> (ayrıntılar mayrıntılar ;) 13:39 <+postman> frosk: ve hepsi şimdiden kâğıt üzerinde 13:39 <+postman> :) 13:39 <ant> <jnymo> heh 13:39 <frosk> doğru :) 13:39 <@jrandom> çoğunlukla evet ;) 13:39 <@jrandom> tamam, 2) 0.5 için başka bir şeyi olan var mı? 13:39 <ant> <jnymo> yok 13:39 <frosk> hiçbişey 13:40 <@jrandom> 'k, şöyle güzel eski usul 3) ???'ye geçelim 13:40 <@jrandom> merhaba 13:40 <@jrandom> gündeme getirmek istediğiniz başka bir şey var mı? 13:41 <ant> <jnymo> postman: i2pmail.org üzerinde smtp/pop3 inproxy'leri yok, değil mi? 13:41 <cat-a-puss> istemci tarafında hâlâ garip gecikmeler görüyorum... 13:41 <+postman> hmm hayır 13:41 <frosk> işte burada, güzel bir geliştirme yılı için tebrik şişesi şarabı takdim ederdim ;) 13:41 <+postman> jnymo: POP3 yalnızca i2p kullanıcıları için mevcut 13:41 <@jrandom> cat-a-puss: ah, az önce buradayken o mesajları kaçırmışım 13:41 <+postman> jnymo: i2pmail.org alan adı için MX olarak bir SMTP inproxy VAR 13:42 <@jrandom> frosk: şerefe 13:42 <ant> <jnymo> doğru doğru.. bu hoş.. 13:42 <cat-a-puss> örneğin iki yerel Destination'ım olabilir ve biri diğerine bağlanmaya çalıştığında bir gecikme oluyor ve bu CPU kaynaklı değil 13:42 <mule> cat-a-puss: prim çekini de veriyor musun? 13:42 * postman iyi bir viski bağışlar 13:42 <@jrandom> cat-a-puss: doğru, .5-1.0 sn gecikme görmüştün, değil mi? 13:42 <cat-a-puss> mule: ne? 13:42 <cat-a-puss> jrandom: evet 13:43 <@jrandom> cat-a-puss: tamamen normal, ertelenmiş SYN'in bir parçası 13:43 <mule> üzgünüm, yorum frosk'tandı 13:43 <ant> * jnymo o dandik kutu şarabı çıkarır 13:43 <mule> frosk: prim çekini de veriyor musun? 13:43 <@jrandom> (paketlenip birlikte gönderilecek daha fazla veri varsa diye SYN ve ilgili ACK'yi göndermek için biraz bekler) 13:43 <scintilla> bilginize, içinde Fortuna algoritması belirtimi olan kitabı yakında almış olmalıyım... bu arada bir makineyi mahvetmeden Java'da entropi toplamayı deniyorum 13:44 <@jrandom> ah harika 13:44 <ant> <jnymo> mmm, birisi i2p üzerinde bazı saldırılar başlatmak istiyordu 13:44 <ant> <jnymo> kimdi o? 13:44 <@jrandom> connelly 13:44 <cat-a-puss> bunu önlemenin bir yolu var mı, yoksa elimden geldiğince kısa ömürlü bağlantılardan kaçınmaya mı çalışmalıyım? 13:45 <ant> <jnymo> bu konuda bir gelişme var mı, jr? 13:45 <@jrandom> cat-a-puss: evet, I2PSocketManager oluştururken geçebileceğin bazı seçenekler var, onları bir çıkarayım 13:46 <@jrandom> jnymo: bu uzun vadeli bir intersection attack, bu yüzden bir süre sonra belirli eepsite'lerin hangi router'lar üzerinde olduğunu belirlemeye yardımcı olacak veriler elinde olacak. bunu elde eder etmez bizim için özet veriler yazacağından eminim 13:46 <ant> <jnymo> scintalla: Fortuna algoritması nedir? 13:46 <ant> <jnymo> jrandom: âlâ 13:48 <@jrandom> cat-a-puss: i2p.streaming.initialResendDelay=50 i2p.streaming.connectDelay=100 13:48 <scintilla> kriptografik olarak güvenli bir sahte-rastgele sayı üreteci... güvenilir şifreleme için kesinlikle vazgeçilmez bir şey 13:48 <jdot__> o saldırı için gönüllü olan oldu mu? 13:48 <@jrandom> cat-a-puss: o zaman I2PSocket'e write() ettikten sonra mutlaka flush() yap 13:48 <@jrandom> jdot__: evet, 7 gönüllü sitesi var 13:48 <cat-a-puss> jrandom: tamam 13:49 <ant> <jnymo> büyük isimlendirme tartışmasıyla ilgili olarak.. 13:49 <ant> * jnymo kıs kıs güler 13:49 <@jrandom> bu arada i2p.streaming.initialAckDelay=1000 13:49 <@jrandom> hatta =100 13:49 * jrandom jnymo'ya çamur atar 13:50 <ant> <jnymo> aslında x500 ile çalışıyorum ve işim bana ücretsiz Windows sunucuları sağlıyor 13:50 <ant> <jnymo> yani, belki bir iki aya sadece test amaçlı merkezi bir DNS kurarım 13:51 <@jrandom> heh, .mil üzerinde barındırılan merkezi bir adlandırma sunucusu olması kanlı komik olurdu 13:51 <ant> <jnymo> yine de i2p adreslerini winserver'a sokuşturmak çok da kolay olmayabilir.. bilemiyorum 13:51 <ant> <jnymo> heh.. dnsalias çözüm 13:52 <@jrandom> nano gerçekten havalı işler yaptı, dnsjava'yı i2p ile entegre etti 13:52 <ant> <jnymo> ooooh 13:53 <@jrandom> daha fazla ayrıntı için nano.i2p'ye göz atın 13:53 <ant> <jnymo> ve kimse bana söylemeyecekti.. ah, teşekkürler 13:53 <@jrandom> ama, geçen sefer belirtildiği gibi, insanların adlandırma hakkında düşünce ve fikirlerini wiki'ye yazmaları gerek 13:54 <@jrandom> tamam, toplantı için gündeme getirecek başka bir şeyi olan var mı? 13:55 <ant> <jnymo> hayır 13:57 <@jrandom> tamam o halde 13:57 * jrandom hazırlanır 13:57 * jrandom toplantıyı kapatır, *baf*