Setkání vývojářů I2P - 18. dubna 2005

16:09 <jrandom> 0) ahoj 16:09 <jrandom> 1) Stav sítě a 0.6.1.16 16:09 <jrandom> 2) Vytváření tunnelů a přetížení 16:10 <jrandom> 3) Feedspace 16:10 <jrandom> 4) ??? 16:10 <jrandom> 0) ahoj 16:10 * jrandom mává 16:10 <jrandom> týdenní statusové poznámky zveřejněny na http://dev.i2p.net/pipermail/i2p/2006-April/001281.html 16:10 * frosk taky 16:10 <jrandom> (taky skoro dvě hodiny *před* schůzkou :) 16:11 <jrandom> ok, protože jsem si jistý, že jste si poznámky už prolítli, pojďme na 1) Stav sítě 16:12 <+Complication> Ahoj :) 16:12 * Complication rychle bere poznámky 16:12 <jrandom> vydání 0.6.1.16 opravilo velmi dlouho přetrvávající bug v našem PRNG (pseudonáhodný generátor), který způsobil značné množství libovolných odmítnutí tunnelů 16:13 <jrandom> (kořenová příčina byla zanesena loni v říjnu, ale teď je opravená) 16:13 <+Complication> Stav tady: funguje snesitelně s tunnely o 1 + 0..1 hopu, s 2 + 0..1 nebo 2 +/- 0..1 se nechová dobře 16:14 <jrandom> jo, to je pochopitelné, zvlášť na pomalejších linkách 16:14 <jrandom> (bohužel „pomalejší“ zas není nijak zvlášť pomalé) 16:15 <jrandom> pořád je spousta práce, a 0.6.1.16 ještě není tam, kde potřebujeme být, ale je to pokrok 16:17 <+Complication> Něco, o čem jsem přemýšlel, ohledně toho, čemu jsi říkal „kolaps z přetížení“ 16:18 <+Complication> Jedním ze způsobů, jak omezit jeho dopad, by mohlo být skutečně vyžadovat, aby router přijímal určitou kvótu požadavků na participaci 16:19 <+Complication> (něco určeného uživatelem přímo nebo nepřímo?) 16:19 <jrandom> určené kterým uživatelem? 16:19 <+Complication> (např. nějaká část share percentage (procento sdílení) nebo další parametr) 16:19 <jrandom> místním uživatelem, nebo námi jako vzdálenými uživateli? 16:19 <+Complication> Určené každým sám pro sebe 16:19 <@frosk> přejdeme tedy k 2) pak? :) 16:20 <jrandom> jo, můžeme se klidně považovat za u 2) :) 16:20 <+Complication> Abych mohl svému routeru například říct „i když jsi přetížený, dál směruj minimálně 4 KB/s“ 16:21 <jrandom> Complication: to není moc možné – když je router příliš přetížený, ostatní lidé (doufejme ;) přestanou žádat, aby se účastnil tunnelů. 16:21 <+Complication> (to by samozřejmě znamenalo, že nějaký místní cíl může být o něco déle offline) 16:21 <jrandom> a když nejsou požádáni, /nemůžou/ tlačit data ostatních 16:22 <+Complication> Aha, asi jsem to měl formulovat podstatně jasněji 16:24 <+Complication> Představoval jsem si, že by to při určité kvótě participujícího provozu omezovalo své vlastní zprávy pro vytváření tunnelů místo participujících tunnelů 16:24 <+Complication> např. „Nikdy neomezím své participující tunnely pod 4 KB/s. Kdyby to bylo potřeba, omezím raději vlastní provoz.“ 16:26 <jrandom> hmm, jsou v tom rizika pro anonymitu (i když je to pořád v rovině selektivního DoS, proti kterému se stejně nebráníme) 16:27 <jrandom> ale omezování našich vlastních lokálních buildů tunnelů při přetížení teď testuju – přidat podporu pro volitelné ignorování 4KBps spodního limitu by mělo být dost jednoduché 16:28 <spinky> V současnosti nedostaneš žádný cover traffic (krycí provoz) při přenosu velkého množství dat. 16:29 <spinky> Mít spodní hranici pro šířku pásma pro participaci zní dobře. 16:30 <jrandom> no, spodní hranici máme (jak jako procento sdílení, tak vnitřních 4KBps rezervovaných po přidělení veškeré šířky pásma) 16:30 <+Complication> Ach jo, odpojení... Doufám, že se z toho, co jsem říkal, moc neztratilo, ale odpovědi si budu muset přečíst z logu :) 16:32 <@frosk> je na 4KBps něco významného? 16:33 <jrandom> pár věcí – 4KB ~= sizeof(tunnel create message), a podle heuristiky jsem nikdy neslyšel o routeru, který by úspěšně běžel na méně 16:33 <spinky> Možná jsou to bugy, které brání tomu, aby procento sdílení fungovalo? 16:34 <jrandom> co tě vede k tomu říct, že procento sdílení nefunguje? 16:34 <@frosk> chápu 16:34 <+Complication> frosk: ne, je to jen číslo v aktuálním kódu a odkazoval jsem se na něj, když jsem se snažil vysvětlit, co jsem si představoval 16:35 <+Complication> (ne z nějakých hlubokých důvodů, jen protože to, co jsem si představoval, bylo v jistém smyslu jeho přesným opakem) 16:35 <spinky> Je nastaveno na 80 % a participace jde na 0, když lokálně generuju data. Možná tomu nerozumím správně. 16:36 <jrandom> aha, ano, to není to, co dělá procento sdílení 16:36 <+Complication> spinky: je to maximální limit toho, co se může sdílet, podmíněný šířkou pásma skutečně dostupnou pro sdílení 16:37 <+Complication> Pokud místní provoz zabere 70 %, zbývá ti jen 10 % na sdílení 16:37 <+Complication> Když je místní provoz velký, zbude ti 0 % a horní limit 80 % se nikdy nedotkne 16:37 <spinky> Ok. Vidím, že to říká ‚až‘... 16:38 <+Complication> A je tu taky rezerva 4 KB/s 16:38 <jrandom> aha, je to procento sdílení z toho, co máš k dispozici 16:38 <spinky> Možná další nastavení pro spodní hranici šířky pásma pro participaci, pod kterou router přijme víc tunnelů? 16:38 <jrandom> pokud používáš 95 % své šířky pásma, bude sdílet až 80 % ze zbývajících 5 % 16:39 <+Complication> Aha, tak jsem to taky částečně nepochopil 16:40 <fox> <zorglu1> jak i2p měří množství šířky pásma používané jinými místními aplikacemi ? 16:40 <spinky> (Jen říkám, pokud považujete cover traffic (krycí provoz) za dobrou věc, možná je dobré mít ho konfigurovatelný i při silném místním využití šířky pásma) 16:40 <+Complication> Myslel jsem, že se to uplatňuje proti trvalému limitu 16:40 <jrandom> zorglu1: měří využití šířky pásma i2p a zná limity šířky pásma i2p 16:41 <jrandom> oh, hmm, když se podívám zpět do kódu, int availBps = (int)(((maxKBps*1024)*share) - used); 16:41 <jrandom> takže máš pravdu, Complication 16:42 <jrandom> spinky: cover traffic (krycí provoz) je jen do určité míry užitečný na low-latency mixnetu 16:42 <jrandom> dává to určitý stimul pro routery s vyšší šířkou pásma, ale ti bez volné šířky pásma mají jen málo možností 16:49 <jrandom> každopádně, problém s přetížením tunnelů tu je už nějakou dobu, ale teprve nedávno ho zhoršily šílené míry odmítání tunnelů 16:49 <jrandom> doufejme, že příští revize to pro nás vyčistí 16:49 <jrandom> ok, má někdo ještě něco k 2) vytváření tunnelů a přetížení? 16:50 <@frosk> zní to, že by to vyžadovalo pár změn v schématu stavby tunnelů 16:50 <+Complication> Doufám, že to pomůže věci zlepšit :) 16:51 <+Complication> Mimochodem... 16:52 <jrandom> no, máme pár levných oprav, jako snížení maximální souběžnosti, škrcení našich pokusů o build při přetížení, snížení frekvence dropů (na rozdíl od explicitního odmítnutí) a úpravu profilování tak, aby motivovalo k explicitním odmítnutím místo dropů 16:52 <+Complication> ...našel jsi náhodou něco, co by vysvětlilo velký rozdíl mezi ukazateli syrové šířky pásma a ukazateli užitečného zatížení tunnelu? 16:52 <+Complication> (např. celková šířka pásma 1 GB, součet payloadu tunnelu 300 MB) 16:52 <jrandom> ale je pravda, že to ovlivňuje jen rozsah 16:52 <+Complication> (protože jsem v poslední době nebyl na IRC, nejsem si jistý, jestli ses na to nedávno díval) 16:54 <jrandom> moc jsem to nezkoumal, ale pamatuj, že požadavky na build tunnelu pro odchozí tunnely nejsou tunnelové zprávy (a je jich hodně, když uspěje jen 0,1 %. a při 4 KB za kus...) 16:54 * Complication si není jistý, jestli jsou to ukazatele, nebo skutečný efekt 16:55 <+Complication> Oh... odchozí požadavky na build... jasně 16:55 <jrandom> nadcházející build -1 přidává spoustu statistik pro monitorování paketů podle typu zprávy 16:55 <+Complication> To by mohlo být přesně ono 16:55 <jrandom> (jsou tam také požadavky na účast při buildu – přeposílání odpovědi) 16:56 <jrandom> ((takže to není jen lokální věc)) 17:00 <+Complication>> Díky, to toho hodně vysvětluje :) 17:00 <+Complication>> Takže to není žádné voodoo, ale docela reálný provoz, na který jsem jen zapomněl, protože se na místech, která jsem kontroloval, zvlášť nepočítal 17:00 <+Complication> Skutečně by musel nastávat a opravdu by stál hodně bajtů 17:00 <+Complication> Zvlášť při nízké úspěšnosti 17:01 <jrandom> jo, i když by to nemělo stát tolik, kolik to stojí, protože bychom měli mít vyšší úspěšnost, než máme :) 17:01 <jrandom> ok, ještě něco k 2)? 17:02 <jrandom> pokud ne, přejděme k 3) Feedspace 17:02 <jrandom> frosk: chceš nám dát aktualizaci? 17:03 <jrandom> (nebo nám řekni, ať jdeme fsck off a přečteme si eepsite? ;) 17:04 <@frosk> tak pro ty, kdo nevěnovali pozornost frosk.i2p nebo feedspace.i2p, feedspace teď v zásadě funguje (podle mé vlastní definice „v zásadě“) 17:04 <jrandom> (w00t) 17:05 <@frosk> poslední dobou přibylo pár pěkných věcí, jako infrastrukturní podpora pro transporty jiné než i2p (napadá mě tor a neanonymní tcp/ip) 17:06 <@frosk> takže časem plánujeme umožnit, aby syndie (v chystaném a pravděpodobně velmi pěkném přepisu) používal feedspace jako jednu ze svých metod syndikace 17:06 <@frosk> teď zatím nejsou žádné klientské aplikace, které by feedspace k něčemu skutečně používaly :) testoval jsem s extrémně hrubou servletovou aplikací 17:07 <jrandom> (crude + functional)++ 17:07 <@frosk> takže je tu samozřejmě volné místo pro klientského hackera ;) 17:08 <@frosk> pořád je ještě pár nezbytností, které feedspace potřebuje před jakýmkoli veřejným testováním, ale už by to nemělo trvat dlouho :) 17:08 <jrandom> pěkné 17:08 <jrandom> můžeme nějak pomoct? 17:08 <@frosk> taky jsem trochu pracoval na dokumentaci, která chyběla 17:09 <spinky> Vidíš feedspace jako použitelné pro velké soubory? 17:10 <@frosk> 1) klientské aplikace používající (pořád nezdokumentované) xmlrpc api, 2) http://feedspace.i2p/wiki/Tasks, 3) zapojit se do testování, až přijde čas 17:10 <@frosk> podpora velkých souborů teď není prioritou, ale možná později 17:10 <@frosk> fokus pro „1.0“ jsou menší zprávy jako blogové a diskusní příspěvky a libovolné události 17:11 <jrandom> i když posílání .torrent souborů do bt klienta s podporou rss/feedspace by nebyl problém 17:11 <@frosk> velké soubory mohou a nemusí fungovat :) 17:11 <@frosk> to by byla super věc 17:12 <jrandom> feed2snark ;) 17:12 <@frosk> doufám, že uvidíme všelijaké takové „adapter“ aplikace :) 17:12 <+Complication> No, jsem si jistý, že lidi najdou způsoby, jak přesouvat velké soubory pomocí bit... ehm, postranních kanálů :) 17:15 <@frosk> cítím se trochu provinile, že kód feedspace používá všelijaké funkce java1.5. teď by se to asi těžko kompilovalo/používalo na free java, ale dožene to, jsem si jistý :) 17:15 <jrandom> jejda 17:16 <jrandom> no, šušká se, že gcj převezme ecj pro 1.5-ismy 17:16 <spinky> Complication: Poníci se sedlovými brašnami plnými hdd? 17:16 <@frosk> jo 17:17 <+Complication> spinky: droni, v mém preferovaném případě :P 17:17 * jrandom se pořád jen stěží posouvá k 1.4-ismům 17:17 <+Complication> Ale hádám, že poníci taky fungují :P 17:17 <jrandom> i když 1.6 je fakt fajn ;) 17:17 <@frosk> aby to zůstalo kompatibilní s gcj? 17:18 <@frosk> no 1.6 stejně pro většinu věcí nemá moc „ismů“, myslím :) 17:18 <+Complication> (nebo létající ježci shazující paměťové karty) 17:18 <jrandom> gcj/classpath/etc, ale také kvůli výkonu (1.5 mi přišla trochu těžkopádnější než 1.4) 17:19 <jrandom> pravda, zlepšení v 1.6 jsou z velké části specifická pro vm/bytecode 17:19 <@frosk> hm ok 17:20 * jrandom nesnažím se tě přesvědčovat, abys nepoužíval 1.5ismy. jsem si jistý, že máš své důvody, a např. azureus už 1.5 vyžaduje 17:21 <@frosk> no, zpátky už nejde :) doufejme, že to nebude moc hrbolaté 17:24 <jrandom> jo, jsem si jistej, že to dopadne fajn :) 17:25 <jrandom> ok, super, má někdo ještě něco k 3) feedspace? 17:25 * frosk objímá své generics a java.util.concurrent ;) 17:25 <jrandom> heheh 17:27 <jrandom> ok, pokud není nic dalšího k 3, přesuňme se k 4) ??? 17:27 <jrandom> má někdo ještě něco na schůzku? 17:27 <+Complication> Malá otázka, kterou jsem se měl zeptat u 2) 17:28 <+Complication> Víte, jak typicky vznikají nečinné participující tunnely? 17:28 <+Complication> Jsou většinou známkou neúspěšných buildů tunnelů, kde o neúspěchu ve skutečnosti ví jen tvůrce? 17:28 <+Complication> Nebo mají další důvody? 17:28 <+Complication> (kromě, samozřejmě, zjevného – totiž aplikace, která sedí nečinně) 17:29 <jrandom> nečinná aplikace by neměla nečinné tunnely (testovaly by se) 17:29 <jrandom> nečinné tunnely selhaly z toho či onoho důvodu 17:29 <jrandom> (buď se nepodařilo je úplně vytvořit, nebo selhaly během provozu) 17:30 <+Complication> Správně, takže všechny tunnely se stejně testují a testování tunnelů by mělo způsobovat provoz... přesně tak 17:30 <+Complication> To mě vlastně přivádí k druhé části otázky: přineslo by nějaký užitek zjistit, že tunnel je nečinný, a zrušit ho dřív? 17:31 <+Complication> Daly by se tím ušetřit nějaké vzácné zdroje? 17:32 <jrandom> žádné – tunnel, který netlačí data, nevyužívá zdroje 17:32 <jrandom> (ok, používá trochu ram, možná 32 bajtů) 17:32 <+Complication> Nebo by to třeba mohlo routeru pomoct mít lepší představu o svém zatížení a podobných parametrech... 17:33 <jrandom> predikce využití šířky pásma založené na historii tunnelů jsou určitě otevřená otázka 17:33 <+Complication> Nebo by to byla jen zbytečná práce a je nejlepší počkat, až to přirozeně vyprší? 17:33 <+Complication> (jako teď) 17:34 <jrandom> dřív jsme dělali nějaké predikce, ale nepřineslo nám to jasné přínosy, takže teď používáme jednodušší algoritmus 17:34 <+Complication> Aha, takže žádný zisk... 17:34 <+Complication> Díky, to bylo v zásadě vše, na co jsem se k tomu chtěl zeptat :) 17:34 <jrandom> není zač, pochopitelná obava 17:34 <jrandom> ok, má někdo ještě něco na schůzku? 17:35 <+Complication> Jo, kdyby se dělaly predikce, procento nečinných tunnelů by mohlo zkreslovat odhady 17:35 <+Complication> (pokud by se výrazně měnilo) 17:36 <jrandom> jo, chtěli bychom udržovat idle % jako součást odhadu 17:36 <jrandom> (dělali jsme to – viz metoda RouterThrottleImpl.allowTunnel) 17:37 <+Complication> Oh, to jsem nevěděl :) 17:37 <jrandom> a povšimni si nového komentáře: 17:38 <jrandom> // ok, ignore any predictions of 'bytesAllocated', since that makes poorly 17:38 <jrandom> // grounded conclusions about future use (or even the bursty use). Instead, 17:38 <jrandom> // simply say "do we have the bw to handle a new request"? 17:39 * Complication si k tomu souboru teprve proklikává cestu, ale díky :) 17:39 <jrandom> w3rd 17:40 <jrandom> ok, pokud už nic dalšího na schůzku... 17:40 * jrandom ukončuje 17:41 * jrandom *baf* zavírá schůzku