I2P Geliştirici Toplantısı - 22 Mart 2005

13:01 <@jrandom> 0) selam 13:01 <@jrandom> 1) 0.5.0.3 13:01 <@jrandom> 2) toplu paketleme (batching) 13:01 <@jrandom> 3) güncelleme 13:01 <@jrandom> 4) ??? 13:01 <@jrandom> 0) selam 13:01 * jrandom el sallar 13:01 <@jrandom> az önce gönderilen haftalık durum notları şu adreste: http://dev.i2p.net/pipermail/i2p/2005-March/000654.html 13:02 <+detonate> merhaba 13:02 <+cervantes> selam 13:02 <@jrandom> 1) 0.5.0.3’e doğrudan dalıyoruz 13:02 <@jrandom> sürüm birkaç gün önce çıktı ve geri bildirimler olumlu 13:02 <+cervantes> jrandom: mavi dans eden cüceler ekranına tırmanmaya başladığında haber ver, toplantıyı erken bitirelim 13:03 <@jrandom> heh cervantes 13:03 <@jrandom> (düzenlenebilir toplantı günlükleri için Bob’a şükür ;) 13:04 <@jrandom> 0.5.0.3 ile ilgili, o mesajda yazanın ötesine ekleyecek çok bir şeyim yok 13:04 <@jrandom> bunun hakkında yorum/soru/endişesi olan var mı? 13:04 <bla> jrandom: fast-peers-selection kodu üzerine yeni ölçümler var mı? 13:05 <@jrandom> ah, 0.5.0.3’te ihmal ettiğim başka bir şey daha olduğunu biliyordum ;) 13:06 <@jrandom> henüz katı metriklerim yok, ama anekdotsal olarak hızlı eş seçiminde bildiğim ‘hızlı’ eşleri buldu (ör. aynı kutudaki router’lar, vb.) 13:07 <bla> jrandom: Bazen eepsite’lar hâlâ kullanılacak iyi bir tunnel bulmak için birkaç yeniden deneme gerektiriyor 13:07 <@jrandom> ara sıra makul aktarım hızlarına dair raporlar da geldi (10-20KBps aralığında), ama bu hâlâ sık değil (parametreler hâlâ kısık ayarlı) 13:08 <+ant> <Connelly> oops toplantı varmış 13:09 <@jrandom> hmm, evet, güvenilirliğin hâlâ olması gereken yerde olmadığını gördüm. Bir kereden fazla yeniden denemek gerçekten bir çözüm değil — bir site 1 yeniden denemeden sonra açılmıyorsa, tekrar denemeden önce 5-10 dk verin 13:09 <@jrandom> ağda gördüğüm şey ise yeterince seyrek olmayan taşıma katmanı gecikme sıçramaları 13:10 <@jrandom> örn. bir soketten 1-2KB’lık bir mesajı boşaltmak için 5-20+ saniye sürmesi 13:10 <@jrandom> bunu 5 hop’luk bir yol (2 hop’luk tunnels) ile birleştirince sorun yaşayabilirsiniz 13:11 <@jrandom> bu aslında toplu paketleme kodunu tetikleyen şeyin bir parçası — gönderilecek mesaj sayısını azaltmak 13:13 <@jrandom> peki, 0.5.0.3 hakkında başka soru/yorum/endişe var mı? 13:13 <bla> jrandom: İyi görünüyor. Bir sonraki “bölümde” bununla ilgili daha fazla soracağım 13:14 <@jrandom> aynen, peki, o zaman 2) toplu paketleme’ye geçebiliriz 13:15 <@jrandom> e-posta ve blogum (jrandom.dev.i2p</spam>) planlananların temelini anlatıyor olmalı 13:15 <@jrandom> ve, şey, aslında oldukça temel şeyler 13:15 <@jrandom> mevcut preprocessor, uygulanabilecek en basitiydi (sınıf adı: TrivialPreprocessor) ;) 13:16 <@jrandom> yenisinde toplu paketleme sıklığı için bazı ayarlanabilir parametreler ve tek tek tunnel havuzları içinde bir miktar giden tunnel yakınlığı var (örneğin 500 ms’ye kadar ardışık istekler için aynı giden tunnel’ı seçmeye çalışıyoruz ki toplu paketlemeyi optimize edebilelim) 13:17 <@jrandom> bunun hakkında ekleyeceklerim bu kadar — soru/yorum/endişe? 13:18 <bla> Bunun için tüm katılımcı düğümlerin yeni preprocessor’ı çalıştırması mı gerekiyor, yoksa Trivial/Yeni karışık çalışabilir mi? 13:18 <+Ragnarok> bu, gecikmeye .5 sn ekleyecek, değil mi? 13:19 <@jrandom> bla: hayır, bu preprocessor sadece tunnel ağ geçidinde kullanılıyor ve toplu paketleme yapıp yapmamaya nasıl karar verileceği o ağ geçidine kalmış 13:20 <@jrandom> Ragnarok: genelde değil — mesaj 1 en fazla .5 sn gecikebilir, ama mesaj 2-15, aksi halde olduğundan çok daha hızlı aktarılır. Ayrıca bu basit bir eşik — tam bir tunnel mesajı kadar veri hazır olunca boşaltılır 13:20 <+Ragnarok> güzel 13:20 <+Ragnarok> ne kadar ek yük tasarrufu sağlıyor? 13:21 <@jrandom> kayda değer ;) 13:21 <+Ragnarok> kayda değer iyidir, biraz muğlak da olsa :P 13:21 <@jrandom> şu sayfaya bakın: http://localhost:7657/oldstats.jsp#tunnel.smallFragments 13:21 <@jrandom> bunu #tunnel.fullFragments ile karşılaştırın 13:22 <bla> jrandom: Bu sadece endpoint->IB-gateway iletişimini mi ilgilendiriyor? 13:22 <@jrandom> toplu paketleme ile, dolu/ küçük oranı artacak ve küçüklerdeki pad baytlarının sayısı düşecek 13:23 <@jrandom> bla: hmm, bu tüm tunnel ağ geçitlerini ilgilendiriyor, ister inbound ister outbound 13:24 <mihi> full fragments: lifetime average value: 1,00 over 1.621,00 events 13:24 <bla> jrandom: tamam 13:24 <mihi> parçaların kesirli sayıda olması mümkün mü? 13:24 <@jrandom> full: 1.00 over 807,077.00 events small: 746.80 over 692,682.00 events 13:25 <@jrandom> heh mihi 13:25 <@jrandom> (o small: 746 demek 692 bin mesajın her birinde 996 baytın 746’sı boşa giden dolgu baytıydı!) 13:26 <@jrandom> pek de boşa değil — amaçlarına hizmet ettiler 13:26 <+detonate> yine de gereksiz ek yük 13:27 <@jrandom> evet, bunun çoğunu toplu paketleme preprocessor’ı ile atabilmeliyiz 13:28 <@jrandom> ne yazık ki, bu bir sonraki sürüme dahil edilmeyecek 13:28 <@jrandom> ama 0.5.0.6 rev’de (belki 0.5.1’de) dahil edilecek 13:28 <@jrandom> pardon, 0.5.0.5 ya da 0.5.1 13:28 * jrandom #’lerle kafası karışır 13:29 <bla> jrandom: Neden değil? 13:29 <+cervantes> esrar ve haplar... lanet olsun 13:30 <@jrandom> !thwap cervantes 13:30 <@jrandom> bla: 0.5.0.3’te (ve öncesinde) bir hata var; parçalanmış mesaj işleyicisi, aynı tunnel mesajı içindeki sonraki parçaların atılmasına neden oluyor 13:31 <@jrandom> toplu paketleme preprocessor’ını doğrudan dağıtırsak, ciddi sayıda mesaj kaybımız olur 13:31 <@jrandom> dert değil, kolumuzun altında başka hoş şeylerimiz var, bu yüzden gelecek 0.5.0.4 tamamen sıkıcı olmayacak ;) 13:31 <bla> jrandom: Ah, demek öyle 13:32 <bla> jrandom: Yani bu yüzden 0.5.0.4 yaygınlaştıktan sonra yapmamız gerekiyor.. Anladım. Sağ ol. 13:33 <@jrandom> evet, keşke parça işleyicisi bununla başa çıkabilseydi, ve genel olarak başa çıkıyor, sadece bayt tamponunu fazla erken salıyor, ardından gelen parçaları sıfırlıyor (oops) 13:33 <@jrandom> peki, 2) ile ilgili başka bir şey var mı, yoksa 3) güncellemeye geçelim mi? 13:35 <@jrandom> peki, durum notlarında belirtildiği gibi (ve çeşitli ortamlarda bir süre tartışıldığı üzere), son kullanıcıyı web sitesine gitmeye, posta listesini okumaya ya da kanaldaki başlığı okumaya zorlamadan, basit ve güvenli güncelleme için biraz işlevsellik ekleyeceğiz :) 13:36 <+detonate> güzel 13:36 <@jrandom> smeghead süreci otomatikleştirmeye ve güvenceye almaya yardımcı olacak biraz kod bir araya getirdi; cervantes ile birlikte hem fire2pe’ye hem normal routerconsole’a bağlamak için çalışıyor 13:37 <@jrandom> e-postada hangi özelliklerin sunulacağına dair genel bir açıklama var ve bunların çoğu işlevsel olsa da hâlâ tam netleşmemiş birkaç parça var 13:37 <@jrandom> toplu paketlemenin aksine, bu bir sonraki rev’de /olacak/, gerçi insanlar 0.5.0.5’e kadar (güncelleme zamanı geldiğinde) bundan pek faydalanamayacak 13:39 <+Ragnarok> peki... 5.0.4 için havalı şeyler neler? 13:42 <@jrandom> güncelleme koduyla birlikte duyuru verilerini çekme yeteneği geliyor; örn. router konsolunun üstünde bir haber kırpıntısı göstermek. Buna ek olarak, güncelleme kodunun bir parçası olarak, doğrudan ya da eepproxy üzerinden çalışan, yolda yeniden deneyip devam eden yeni bir güvenilir indirme bileşenimiz var. Belki bunun üzerine ilgili özellikler de gelir, ama söz yok 13:42 <+Ragnarok> hoş 13:43 <@jrandom> peki, 3) güncelleme hakkında başka soru/yorum/endişe var mı? 13:45 <@jrandom> yoksa 4) ???’ye geçiyorum 13:45 <@jrandom> başka değinmek istediğiniz bir şey var mı? Eminim bazı şeyleri atladım 13:45 <+detonate> i2p, OpenBSD 3.7’de sun jvm ile çalıştığı biliniyor :) 13:45 <@jrandom> güzel! 13:47 <bla> UDP transport’un durumu nedir? 13:48 <+detonate> udp dağınık olacak, bence bt’den pipelining kodunu çalıp uyarlamak daha iyi ;) 13:48 <@jrandom> *öksürür* 13:49 <@jrandom> çok sorun olmasını beklemiyorum, ama kesinlikle yapılacak işler var 13:49 <@jrandom> kuyruklama politikasının nasıl işleyeceği ve kuyruğa kabul için bant genişliği kısıtlaması da ilginç olacak 13:50 <bla> O ön çalışmayı kim yapıyordu? 13:50 <@jrandom> bla: detonate ve mule 13:50 <+detonate> evet.. gerçi son bir aydır biraz sallıyorum 13:50 <bla> detonate: BT yorumun şakaydı herhalde? 13:51 <+detonate> yarı ciddi 13:51 <+detonate> bunu yaparsan transport için thread sayısını en azından yarıya indirebilirsin 13:51 * jrandom detonate’a bir kova çamur fırlatır 13:51 <jdot> yaşasın. router’ım artık POS kablo bağlantım yerine adanmış sunucumda çalışıyor. 13:51 <@jrandom> iyi iş, jdot 13:52 <@jrandom> tüm eşlerle tüm iletişim için taşıma katmanında 3-5 iş parçacığı ile idare edebileceğiz 13:52 <bla> detonate: Ama ağ büyüdüğünde (> birkaç yüz düğüm) yarıya indirmek yetmeyecek 13:52 <jdot> emrinde 1000GB b/w ile 13:53 <jdot> ne yazık ki j.i2p ve chat.i2p birkaç saat daha kapalı olacak, taşırken 13:53 <duck> detonate: addressbook da durdu mu? 13:53 <+detonate> evet, o da durdu 13:54 <+detonate> durmayan tek şey monolithic profile storage, onu bugün ilerleyen saatlerde çalıştırmayı düşünüyordum 13:54 <@jrandom> aynen 13:54 <+detonate> böylece i2p diski çok feci parçalamayacak 13:54 <jdot> jrandom: BW limitleri ortalama mı? 13:54 <+frosk> modern dosya sistemleri parçalanmaz, aptal 13:55 <+detonate> ntfs parçalar 13:55 <@jrandom> jdot: bant genişliği limitleri katı token bucket (jeton kovası algoritması) 13:55 <@jrandom> jdot: patlama süresini (burst) ayarlarsan, ortalamasını aldığı dönem o kadar uzun olur 13:56 <@jrandom> (şey, 2x burst == dönem) 13:56 <@jrandom> ((gibi)) 13:56 <jdot> hmmm... benim 1000GB’ım var ve i2p’nin ayda 800GB’a kadar kullanabilmesini istiyorum.... 13:56 <+ant> <mihi> detonate: ntfs çok küçük dosyaları mft’de saklar; bu da neredeyse hiç parçalanma olmaz demek 13:57 <jdot> ve neye sıçradığı umurunda değil 13:57 <+detonate> şey, birleştiriciyi çalıştırdığında, tüm 6000 profili 10 dakika taşıyor.. demek ki parçalanıyorlar 13:58 <@jrandom> jdot: hmm, şey, 800GB muhtemelen zaten göndermek isteyeceğinden fazladır, o yüzden limitsiz bırakabilirsin ;) 13:58 <@jrandom> diğer yandan, uygulanmasını istediğin bir politika tanımlayabilirsen, belki onu da karşılayabiliriz 13:58 <jdot> jrandom: şimdilik öyle yapacağım, nasıl çalıştığına bakarız 13:58 <bla> detonate: NTFS, yanlış hatırlamıyorsam, journalling bir FS. Yani tek parça dosya bile küçük parçalar yazarsan parçalanır 13:58 <+detonate> her şey bir seferde yazılıyor 13:59 <+detonate> ve bir seferde okunuyor 13:59 <bla> detonate: Tamam. Anladım. 13:59 <jdot> jrandom: peki, bunun gerçekten bir sorun olup olmayacağını anlayana kadar bekleyelim. 13:59 <bla> detonate: O durumda iyi iş! 13:59 <+detonate> iyi bir bağlantıda sınırsız bırakırsan gerçekte ne kadar kullanım olduğunu bilmek ilgimi çeker 14:00 <+detonate> iyi bir bağlantıda 14:00 <jdot> ben de merak ediyorum! 14:00 <@jrandom> benim colo router’larım sınırsız çalışıyor, ama cpu kısıtlı 14:00 <+Ragnarok> bir ay boyunca ortalama almak için bitbucket kullanabilir misin? 14:00 <jdot> jrandom: cpu kısıtlı mı? ne tür bir cpu? 14:01 <@jrandom> 4g transfer 3.04GB/2.73GB 14:01 <+detonate> hmm, daha az bekliyordum 14:01 <@jrandom> jdot: cpu kısıtlı çünkü üzerinde 3 router çalıştırıyorum, artı birkaç başka jvm, bazen profil çıkarıyorum 14:01 <+detonate> kesin bt tayfasıdır 14:01 <+detonate> toplu paketleme işleri devreye girince bunun nasıl değiştiğini görmek ilginç olur 14:02 <@jrandom> detonate: bu aktarımın bir kısmı da 50MB’lık dosyaları kendi içinde itmem ;) 14:02 <+detonate> heh 14:02 <jdot> ahh. tamam. bakalım bu sistem nasıl yapacak. AMD XP 2400, 512MB ve 10Mbit bağlantı 14:02 <@jrandom> Ragnarok: token bucket’lar öyle çalışmıyor 14:02 <@jrandom> jdot: aynen, bu da p4 1.6 idi sanırım 14:03 <@jrandom> Ragnarok: bir token bucket’ta, her (örn.) saniye, orana göre kovaya token eklersin. Kova doluysa (boyut = ani artış dönemi), token’lar atılır 14:04 <@jrandom> ne zaman veri aktarmak istesen, yeterli miktarda token alman gerekir 14:04 <@jrandom> (1 token = 1 bayt) 14:04 <+Ragnarok> nasıl çalıştıklarını biliyorum... kovayı sadece çok büyük yaparsan ne olur? 14:05 <+detonate> o zaman asla veri göndermeyi bırakmazsın 14:05 <+detonate> eğer boyutu sonsuzsa 14:05 <+detonate> şey, ve token’larla doluysa 14:05 <@jrandom> çok büyükse, düşük kullanımdan sonra sınırsız hızlara sıçrayabilir 14:06 <@jrandom> gerçi bazı durumlarda bu istenebilir 14:07 <@jrandom> mesele şu ki, token bucket’ı 800GB olarak ayarlayamazsın, bu toplam aktarımı sınırlamaz 14:08 <+detonate> orada saniye başına token sayısını ayarlayabileceğin bir alan gerekir; sonra aylık bant genişliği kullanımını saniye sayısına bölersin 14:08 <+detonate> :) 14:10 <@jrandom> bu, oranı ay boyunca ortalamaya ayarlamakla aynı, ki bu dengesiz olur. Ama, neyse, pek çok senaryo var — mevcutla karşılanamayan ihtiyaçlarınızı adresleyen senaryolar varsa lütfen iletişime geçin 14:10 <+Ragnarok> ama istediğin ortalamaya oranı ayarlarsan... Burada 308 kB/s, sonra bitbucket’ı çok büyük yaparsan... neden olmaz? 14:11 <+Ragnarok> s/larger/large/ 14:12 <+detonate> şey, 60 saniyelik bir patlama döneminde 800GB/44000’den fazla göndermeyecek şekilde ayarlayabilirsin 14:12 <+detonate> 44000 kabaca bir aydaki dakika sayısı 14:13 <@jrandom> kova boyutu / ani artış süresi, kısıtsız olarak ne kadar göndereceğimizi tanımlar ve çoğu insan kısıt ister, böylece router, kovayı boşaltırken (veya her neyse) 5 dakika boyunca 10mbps’i yutmaz 14:14 <@jrandom> kovadan çıkan token’lara ek bir kısıt da mümkün (ve o kısıtın kendi token bucket’ı olsun mu, ve o kovada kendi kısıtı olsun mu, vs.) 14:16 <+Ragnarok> Kovaya yalnızca kullanılmayan bant genişliği varken eklendiğini sanıyordum 14:16 <@jrandom> token’lar kovaya sabit bir hızda eklenir (örn. saniyede 64k token) 14:17 <@jrandom> bant genişliği isteyen her şey her zaman kovadan ister 14:18 <+Ragnarok> ah.. tamam 14:19 <@jrandom> peki güzel, toplantıda gündeme getirmek istediğiniz başka bir şey var mı? 14:21 <@jrandom> yoksa 14:21 * jrandom toparlanır 14:21 * jrandom toplantıyı kapatır