Setkání vývojářů I2P - 28. února 2006

15:11 <jrandom> 0) ahoj 15:11 <jrandom> 1) Stav sítě a 0.6.1.12 15:11 <jrandom> 2) Cesta k 0.6.2 15:12 <jrandom> 3) Miniprojekty 15:12 <jrandom> 4) ??? 15:12 <jrandom> 0) ahoj 15:12 * Complication rychle čte poznámky 15:12 * jrandom mává 15:12 <jrandom> týdenní status poznámky zveřejněny na http://dev.i2p.net/pipermail/i2p/2006-February/001266.html 15:12 <jrandom> (a já ty poznámky posílal víc než 15 minut před schůzkou! ;) 15:13 <jrandom> ok, zatímco si vy všichni čtete ty tak strašně napínavé body, pojďme rovnou na 1) Stav sítě a 0.6.1.12 15:14 <jrandom> jak bylo zmíněno, hlavní cíle vydání 0.6.1.10-0.6.1.12 se zdají být splněny, řeší změnu kryptografie při vytváření tunnelů a výrazně zlepšují spolehlivost vytváření 15:16 <jrandom> výkyvy, které jsme viděli u 0.6.1.10, zmizely a stabilita IRC se opět zdá být dost dobrá 15:16 <jrandom> má někdo ještě něco k 1) Stavu sítě a 0.6.1.12, nebo se přesuneme k 2) Cesta k 0.6.2? 15:17 <+Complication> Stav sítě tady: už žádné padání pod 20 KB/s :) 15:18 <jrandom> super, jo, 0.6.1.12 opravila docela velký bug v 0.6.1.11, kdy to nedokázalo využít dostupnou šířku pásma. teď by to mělo lépe využívat dostupné zdroje 15:20 <jrandom> ok, přejděme na 2) 15:20 <jrandom> jak bylo řečeno, je pár věcí, které je potřeba vyřešit, než se nasadí poslední funkční změna pro 0.6.2, ale v tomhle směru postupujeme 15:20 <nymisis> stav sítě je v pohodě :) 15:22 <jrandom> jasně. než vyjdou, bude k dispozici víc informací o detailech nových strategií řazení peerů, ale podstata by měla být jasná z jejich stručné zmínky v poznámkách 15:23 <jrandom> má někdo nějaké dotazy/komentáře/obavy ohledně 2) Cesta k 0.6.2? 15:23 <postman> jrandom: budou tentokrát nějaké testnety? 15:24 <postman> (potřebujete nějaké routers, účastníky na testování věcí) 15:24 <postman> ? 15:24 <+Complication> Podstata věci se zdála dost přímočará – omezit možnost, aby protivník sbíral různorodá statistická data 15:25 <+Complication> Zní to jako dost žádoucí vlastnost 15:25 <jrandom> postman: nové věci by měly fungovat transparentně na živé síti s využitím pouze lokálních informací, takže by neměl být potřeba samostatný net na testování 15:25 <jrandom> jo, přesně tak, Complication 15:26 <postman> ok 15:26 <postman> jrandom: jsi dost odvážný prozradit odhad termínu (ETA) pro 0.6.2 ? :) 15:27 <blubb> 1. dubna 15:27 <jrandom> no, jelikož je dnes konec února, tipnul bych březen nebo duben 15:27 <postman> hehe 15:27 <jrandom> blubb: na ten termín už máme naplánovaná mi6 backdoor ;) 15:29 <@cervantes> spíš mi6 catflap 15:29 <@cervantes> (škrty v rozpočtu) 15:29 <postman> v pavilonu slonů 15:30 <nymisis> To je SIS, ne MI6, pokud máme být přesní. :) 15:30 <jrandom> no, říkejme jim prostě Oni ;) 15:31 <jrandom> ok, ještě něco k 2)? 15:31 <jrandom> pokud ne, pojďme se přesunout k 3) miniprojekty 15:31 <@cervantes> sorry „firma“ 15:34 <jrandom> ok, chtěl jsem jen upozornit na pár šikovných věcí, které by byly 1) jednoduché na udělání a 2) opravdu užitečné 15:34 <+Complication> K miniprojektům: nejsem si jistý, jestli moje odpověď ohledně Syndie dorazila nebo ne, ale přemýšlím, jestli bych si mohl jeden urvat. 15:34 <+Complication> Ještě nevím který. Momentálně si víc procvičuji Javu (dělám micro-projekt :D), abych měl větší jistotu, že až to zkusím, zvládnu nějaký 15:35 <DeltaQ> hmm, když na konzoli navýším šířku pásma, projeví se změny hned, nebo je potřeba restart? 15:35 <+Complication> Až budu hotov s tím „micro-projektem“ (samozřejmě za předpokladu, že ten stůl ještě nebude prázdný), zkusím si nějaký vybrat 15:35 <jrandom> w3wt, skvělé, Complication 15:36 <jrandom> DeltaQ: okamžitě 15:36 <@cervantes> není 1) Syndie scheduler propojený s 4) Download Manager / eepget scheduler 15:36 <+Complication> DeltaQ: projeví se skoro okamžitě (v rámci období, přes která se průměruje šířka pásma) 15:37 <@cervantes> mně se zdá, že obecněji funkční správce uploadu a downloadu by obsloužil obě potřeby 15:37 <jrandom> cervantes: hmm, ne nutně. 1) je dost zaměřené a zahrnuje i push, zatímco 4) je dost obecné 15:37 <+Complication> cervantes: zní, že by mohl 15:37 <jrandom> ale jo, engine za obojím je EepGet 15:37 <jrandom> (eepget dělá Syndie http přenosy, programově) 15:38 <DeltaQ> průměr se nezdá jít nad 13 kb/s 15:38 <DeltaQ> nastavil jsem 64 kb/s se 192 burst down 15:38 <DeltaQ> 32/64 up 15:38 <@cervantes> takže generické pushing a pulling v eepget s API pro plánování a správu... 15:39 <@cervantes> i tak se to v tom bodě nejspíš přestává kvalifikovat jako mini-projekt 15:39 <+Complication> DeltaQ: průměr také závisí na tom, jakou zátěž generují tvoje klientské tunnels (a participating tunnels ostatních peerů) 15:39 <+Complication> sorry, s/average/actual bandwidth 15:39 <jrandom> cervantes: jo, v těch věcech kolem Syndie je ale zapojená podstatná logika. 15:40 <DeltaQ> heh, konečně to šlo nahoru 15:40 <DeltaQ> 1s: 30.82/29.33KBps 15:40 <DeltaQ> asi jsem potřeboval zvednout ul šířku pásma 15:40 <jrandom> DeltaQ: průměr bude také ovlivněn tím, jak tě vnímají ostatní, což závisí na tvém chování, ne na nějaké inzerované rychlosti, takže to chvíli potrvá 15:40 <+Complication> DeltaQ: u průchozího provozu (participating tunnels) musí to, co přijde, také odejít 15:41 <+Complication> DeltaQ: takže velmi rozdílné ul/dl rychlosti by škrtily participating traffic na tu nižší z nich 15:42 <+Complication> DeltaQ: participating traffic také závisí na tom, jak ostatní uzly „vnímají“ směrovací kapacitu tvého uzlu 15:42 <DeltaQ> oki 15:43 <+Complication> Když si budou myslet, že umí dobře routovat, budou žádat častěji 15:43 <jrandom> ok, pokud už nic není k 3) miniprojekty, přeskočme na 4) ??? 15:43 <jrandom> má někdo ještě něco k projednání na schůzku? 15:43 <DeltaQ> no, jsem za routerem, ale namapoval jsem port 8887 na tenhle PC 15:43 <+Complication> Pokud je nový nebo nedávno zvýšil kapacitu, jsou trochu ostýchaví 15:44 <DeltaQ> oh, promiňte, nechtěl jsem rušit schůzku ^^ 15:44 <+Complication> Někdo se nedávno ptal na možné útoky založené na odchylce hodin (clock skew). Myslím, že jsem viděl tvoji odpověď ohledně tunelovací části (zpráva o vytvoření obsahuje jen dobu platnosti tunnelu, ne čas z pohledu jeho tvůrce)... 15:44 <@cervantes> (díky za zmínku ve status poznámkách) ;-)_ 15:46 <+Complication> Tak jsem vlastně přemýšlel, že se zeptám... které body, pokud vůbec nějaké, v I2P messagingu by mohly obsahovat čas z pohledu odesílatele? 15:47 <+Complication> Nepodařilo se mi to dohnat do aktuálního stavu, takže v tom mám trochu hokej 15:47 <jrandom> Complication: nic výslovně neříká „myslím, že je teď $time“, ale s dostatkem provozu a časové analýzy by to pravděpodobně šlo podstatně zúžit 15:48 <jrandom> časy kvantujeme na dlouhá období, i když ne tak dlouhá jako naše maximální odchylka hodin, takže tam je určitý prostor 15:49 <+Complication> Myslíš, že by se nakonec dalo něco získat z více „odlehčeného“ NTP klienta? 15:49 <+Complication> Takového, který by snáz udržoval menší odchylky? 15:50 <jrandom> no, od doby, kdy byl do i2p přidán sntp klient, se pořád zlepšuje, takže teď už nevidíme takové výkyvy jako dřív 15:51 <jrandom> možná bychom mohli snížit limit minimální odchylky z 10s na 2 nebo 3s, případně méně 15:51 <jrandom> případně mu můžeme dovolit dívat se i na ssu odchylky hodin, abychom se vyhnuli zbytečným odchylkám 15:52 <+Complication> Nebo by šlo ještě víc omezit možnosti hádání možné hodnoty hodin jiného peeru? 15:53 * Complication neví, která cesta by byla praktičtější, jen navrhuje náhodné možnosti :D 15:53 <jrandom> ne, známe odchylku hodin přímo připojených peerů 15:55 <Magii> dá se nějak poznat, že se update povedl? 15:55 <+Complication> Aha, takže session protokol na té informaci opravdu závisí.. 15:55 <tethra> podívej se na číslo verze 15:55 <+Complication> Magii: do logů by měl zapsat CRIT ve stylu "update verified, restarting to install" 15:55 <tethra> :/ 15:55 <+Complication> Pak by měl odpočítat minuty do řízeného restartu 15:56 <+Complication> A nakonec restartovat 15:57 <+Complication> Oh, mimochodem: zná interní NTP klient koncept jako "clock drift rate" (rychlost driftu hodin)? 15:58 <jrandom> jo, číslo verze v levém horním rohu na http://localhost:7657/index.jsp by mělo být jasné vodítko :) 15:58 <jrandom> Complication: ne, nezaručuje sekvenční tiky hodin 15:59 <jrandom> s/sequential/ordered/ 15:59 <+Complication> Ani si nevytváří znalost typu "naše systémové hodiny jsou 0.00345× rychlejší, než by měly být"? 16:00 <jrandom> aha, ne, ačkoliv přidat to do net.i2p.util.Clock by nebylo tak těžké (chceš miniprojekt? :) 16:00 <+Complication> Nad něčím takovým jsem přemýšlel 16:01 <+Complication> Asi o tom teď přemýšlím o něco víc :) 16:01 <+Complication> Ale nejdřív jiné miniprojekty :) 16:02 <jrandom> ok, má ještě někdo něco k této schůzce? 16:03 <nymisis> Muffiny? 16:04 <jrandom> ne, palačinky 16:04 <jrandom> (mmMMmm palačinky) 16:04 <jrandom> když už jsme u toho 16:04 * jrandom se rozmachuje 16:04 <nymisis> Aha, sakra, dobrý point. 16:04 * jrandom *baf* uzavírá schůzi