I2P Geliştirici Toplantısı - 28 Şubat 2006

15:11 <jrandom> 0) merhaba 15:11 <jrandom> 1) Ağ durumu ve 0.6.1.12 15:11 <jrandom> 2) 0.6.2'ye giden yol 15:12 <jrandom> 3) Mini projeler 15:12 <jrandom> 4) ??? 15:12 <jrandom> 0) merhaba 15:12 * Complication hızlıca notları okur 15:12 * jrandom el sallar 15:12 <jrandom> haftalık durum notları http://dev.i2p.net/pipermail/i2p/2006-February/001266.html adresine konuldu 15:12 <jrandom> (ve notları toplantıdan 15 dakikadan fazla önce paylaşıyordum ben! ;) 15:13 <jrandom> tamam, siz o pek heyecan verici kısımları okurken, 1) Ağ durumu ve 0.6.1.12'ye dalalım 15:14 <jrandom> belirtildiği gibi, 0.6.1.10-0.6.1.12 sürümlerinin temel hedefleri karşılanmış görünüyor; tunnel oluşturma kriptosundaki değişikliği ele alıp oluşturma güvenilirliğini ciddi ölçüde iyileştiriyor 15:16 <jrandom> 0.6.1.10'da gördüğümüz tökezlemeler gitti ve irc kararlılığı yine oldukça iyi görünüyor 15:16 <jrandom> 1) Ağ durumu ve 0.6.1.12 için başka eklemek istediğiniz bir şey var mı, yoksa 2) 0.6.2'ye giden yol'a doğru ağır ağır geçelim mi? 15:17 <+Complication> Burada ağ durumu: artık 20 KB/s altına geri düşmek yok :) 15:18 <jrandom> güzel, evet 0.6.1.12, 0.6.1.11'deki, mevcut bant genişliğini kullanamamasına yol açan epey büyük bir hatayı düzeltti. artık mevcut kaynakları daha iyi kullanmalı 15:20 <jrandom> tamam, 2)'ye geçelim 15:20 <jrandom> belirtildiği gibi, 0.6.2 için son işlevsel değişiklik devreye alınmadan önce çözülmesi gereken birkaç şey var, ama o konuda ilerleme kaydediyoruz 15:20 <nymisis> ağ durumu iyi :) 15:22 <jrandom> aynen. yeni eş sıralama stratejilerinin ayrıntıları çıkmadan önce daha fazla bilgi olacak, ama notlarda kısaca bahsedilmesinden fikir edinilmiş olmalı 15:23 <jrandom> 2) 0.6.2'ye giden yol ile ilgili soru/yorum/endişe olan? 15:23 <postman> jrandom: bu sefer testnet var mı? 15:24 <postman> (bir şeyleri test etmek için router veya katılımcılara ihtiyaç var mı) 15:24 <postman> ? 15:24 <+Complication> Mesele özü itibarıyla oldukça net görünüyordu - bir düşmanın çeşitli istatistiksel veriler toplama fırsatını sınırlamak 15:25 <+Complication> Oldukça arzu edilir bir özellik gibi geliyor 15:25 <jrandom> postman: yeni şeyler canlı ağda yalnızca yerel bilgiyi kullanarak şeffaf şekilde çalışmalı, bu yüzden test için ayrı bir ağa gerek olmamalı 15:25 <jrandom> evet, aynen Complication 15:26 <postman> tamam 15:26 <postman> jrandom: 0.6.2 için bir ETA açıklayacak kadar cesur musun? :) 15:27 <blubb> 1 nisan 15:27 <jrandom> şey, bugün şubatın sonu olduğuna göre, mart ya da nisan derim 15:27 <postman> hehe 15:27 <jrandom> blubb: o zamana bir MI6 arka kapısı zaten planladık ;) 15:29 <@cervantes> daha çok bir MI6 kedi kapısı gibi 15:29 <@cervantes> (bütçe kesintileri) 15:29 <postman> bir fil barınağında 15:30 <nymisis> Bu SIS, MI6 değil, eğer doğru olmak istiyorsan. :) 15:30 <jrandom> neyse, onlara kısaca Onlar diyelim ;) 15:31 <jrandom> tamam, 2) için başka bir şey var mı? 15:31 <jrandom> yoksa, kıvrılıp 3) mini projeler'e geçelim 15:31 <@cervantes> pardon “the firm” 15:34 <jrandom> tamam, 1) yapması basit ve 2) gerçekten faydalı olacak birkaç hoş şeye işaret etmek istedim 15:34 <+Complication> Mini projeler tarafında, Syndie yanıtım ulaştı mı emin değilim, ama birini kapabilir miyim diye merak ediyorum. 15:34 <+Complication> Hangisi olduğundan henüz emin değilim. Şu anda biraz daha Java pratik yapıyorum (mini bir proje yapıyorum :D) ki denediğimde birini kaldırabileceğimden daha emin olayım 15:35 <DeltaQ> hmm konsolda bw’yi artırırsam değişiklikler anında mı olur yoksa yeniden başlatmak gerekir mi? 15:35 <+Complication> “mini proje” ile hazır olduğumda (tabii liste henüz boşaltılmadıysa), birini seçmeyi deneyeceğim 15:35 <jrandom> w3wt, harika Complication 15:36 <jrandom> DeltaQ: hemen 15:36 <@cervantes> 1) syndie zamanlayıcısı 4) Download Manager / eepget scheduler ile bağlantılı değil mi 15:36 <+Complication> DeltaQ: neredeyse anında etkisini gösterir (bant genişliğinin ortalandığı periyotlar içinde) 15:37 <@cervantes> bana daha genel işlevli bir yükleme ve indirme yöneticisinin her iki ihtiyacı da karşılayacağı gibi geliyor 15:37 <jrandom> cervantes: hmm, şart değil. 1) oldukça odaklı ve push'ları da içeriyor, 4) ise epey genel 15:37 <+Complication> cervantes: olabilir gibi geliyor 15:37 <jrandom> ama evet, ikisinin arkasındaki motor EepGet 15:37 <jrandom> (eepget, syndie'nin http transferlerini programatik olarak yapar) 15:38 <DeltaQ> ortalama 13kb/s’nin üzerine çıkmıyor gibi görünüyor 15:38 <DeltaQ> 64kb/s indirme, 192 burst olarak ayarladım 15:38 <DeltaQ> 32/64 yükleme 15:38 <@cervantes> yani zamanlama ve yönetim API’si olan, genel amaçlı itme ve çekme yapan bir eepget... 15:39 <@cervantes> yine de, o noktada muhtemelen mini proje olmaktan çıkar 15:39 <+Complication> DeltaQ: ortalama ayrıca istemci tunnel'larının (ve diğer eşlerin katılımcı tunnel'larının) ne kadar yük ürettiğine de bağlı 15:39 <+Complication> pardon, s/average/actual bandwidth 15:39 <jrandom> cervantes: evet, yine de syndie işlerinde hatırı sayılır mantık var. 15:40 <DeltaQ> heh sonunda yükseldi 15:40 <DeltaQ> 1s: 30.82/29.33KBps 15:40 <DeltaQ> sanırım ul bw’yi daha da artırmam gerekiyordu 15:40 <jrandom> DeltaQ: ortalama, başkalarının sizi nasıl gördüğünden de etkilenecektir; bu da ilan edilen bir hızdan değil, sizin davranışlarınızdan etkilenir, bu yüzden biraz zaman alır 15:40 <+Complication> DeltaQ: geçiş trafiği (participating tunnel'lar) için, içeri giren dışarı da çıkmak zorunda 15:41 <+Complication> DeltaQ: dolayısıyla çok farklı ul/dl oranları, katılımcı trafiği iki değerden düşük olana boğar 15:42 <+Complication> DeltaQ: ayrıca katılımcı trafik, diğer düğümlerin düğümünüzün yönlendirme kapasitesini nasıl “algıladıklarına” bağlıdır 15:42 <DeltaQ> oki 15:43 <+Complication> İyi yönlendirebildiğini düşünürlerse, daha sık istekte bulunurlar 15:43 <jrandom> tamam, 3) mini projeler üzerinde başka bir şey yoksa, 4) ???'a geçelim 15:43 <jrandom> toplantı için gündeme getirmek istediğiniz başka bir şey var mı? 15:43 <DeltaQ> şey, bir router arkasındayım ama 8887 portunu bu PC’ye yönlendirdim 15:43 <+Complication> Eğer yeniyse ya da kapasitesi daha yeni artırıldıysa, biraz çekingen olurlar 15:44 <DeltaQ> ah özür dilerim, bir toplantıya müdahale etmek istememiştim ^^ 15:44 <+Complication> Geçen gün biri saat kaymasına dayalı olası saldırıları sordu. Tunneling kısmıyla ilgili cevabını gördüm sanırım (oluşturma mesajı yalnızca tunnel geçerlilik süresini tutuyor, oluşturucunun bakış açısından zamanı değil)... 15:44 <@cervantes> (durum notlarında bahsettiğin için teşekkürler) ;-)_ 15:46 <+Complication> Ben de aslında şunu sormayı düşündüm... I2P mesajlaşmasında hangi noktalar, varsa, göndericinin bakış açısından zamanı içerebilir? 15:47 <+Complication> Bu konuda kendimi güncelleme fırsatım olmadı, o yüzden biraz bihaberim 15:47 <jrandom> Complication: hiçbir şey açıkça “bence şu an $time” demiyor, fakat yeterli trafik ve zamanlama analiziyle bunu muhtemelen epey daraltabilirler 15:48 <jrandom> zamanları geniş bir periyoda kuantalıyoruz, ancak en büyük saat kaymamız kadar büyük değil, bu yüzden orada bir pay var 15:49 <+Complication> Daha “sadeleştirilmiş” bir NTP istemcisinden nihayetinde fayda sağlanacağını düşünüyor musun? 15:49 <+Complication> Kaymaları daha kolay küçük tutan/tutabilecek bir şey? 15:50 <jrandom> şey, i2p’ye sntp istemcisi eklendiğinden beri giderek daha iyi hale geldi, artık eskiden gördüğümüz dalgalanmaları görmüyoruz 15:51 <jrandom> belki minimum kayma limitini 10 saniyeden 2 veya 3 saniyeye, hatta belki daha aza indirebiliriz 15:51 <jrandom> alternatif olarak, gereksiz kaymaları önlemek için ssu saat kaymalarına da bakmasına izin verebiliriz 15:52 <+Complication> Ya da alternatif olarak, başka bir eşin olası saat değerini tahmin etme fırsatlarını daha da sınırlamak mümkün olabilir mi? 15:53 * Complication hangi yolun daha pratik olacağını bilmiyor, sadece rastgele olasılıklar öneriyor :D 15:53 <jrandom> hayır, doğrudan bağlı eşlerin saat kaymasını biliyoruz 15:55 <Magii> güncellemenin başarıyla yapılıp yapılmadığını anlamanın bir yolu var mı? 15:55 <+Complication> Aha, yani oturum protokolü gerçekten o bilgiye bağlı.. 15:55 <tethra> sürüm numarana bak 15:55 <+Complication> Magii: günlüklerde “update verified, restarting to install” gibi bir CRIT kaydı düşmesi gerekir 15:55 <tethra> :/ 15:55 <+Complication> Sonra, düzgün bir yeniden başlatmaya doğru dakika sayımı yapmalı 15:56 <+Complication> Ve en sonunda yeniden başlatmalı 15:57 <+Complication> Ah, küçük not: dahili NTP istemcisi “clock drift rate” gibi bir kavramı biliyor mu? 15:58 <jrandom> evet, http://localhost:7657/index.jsp sayfasının sol üst köşesindeki sürüm numarası ipucu olmalı :) 15:58 <jrandom> Complication: hayır, ardışık saat tiklerini garanti etmez 15:59 <jrandom> s/sequential/ordered/ 15:59 <+Complication> Ya da “bizim sistem saatimiz gereğinden 0.00345 kat daha hızlı” gibi bir bilgi geliştirmez mi? 16:00 <jrandom> ah, hayır, gerçi bunu net.i2p.util.Clock içine eklemek o kadar zor olmaz (mini proje yapmak ister misin? :) 16:00 <+Complication> Bu minvalde bir şey düşünüyordum 16:01 <+Complication> Sanırım şimdi biraz daha üzerine düşünüyorum :) 16:01 <+Complication> Ama önce diğer mini projeler :) 16:02 <jrandom> tamam, toplantı için başka bir şey var mı? 16:03 <nymisis> Muffinler? 16:04 <jrandom> hayır, pankek 16:04 <jrandom> (mmMMmm pankek) 16:04 <jrandom> hazır yeri gelmişken 16:04 * jrandom toparlanır 16:04 <nymisis> Ah, tüh, iyi nokta. 16:04 * jrandom toplantıyı *baf* kapatır