I2P setkání vývojářů - 6. prosince 2005

15:26 <jrandom> 0) ahoj 15:26 <jrandom> 1) 0.6.1.7 a stav sítě 15:26 <jrandom> 2) Experimentální selhání tunnel 15:26 <jrandom> 3) SSU a NATy 15:26 <jrandom> 4) Syndie 15:26 <jrandom> 5) ??? 15:26 <jrandom> 0) ahoj 15:26 * jrandom mává 15:26 <jrandom> týdenní status poznámky jsou na http://dev.i2p.net/pipermail/i2p/2005-December/001237.html 15:26 * ailouros si přečetl poznámky 15:27 * jrandom má zpoždění, tak vám dám chvilku na pročtení :) 15:29 <jrandom> ok, můžeme rovnou skočit k 1) 0.6.1.7 a stavu sítě 15:29 <@cervantes> *odkašlání* 15:29 <jrandom> K tomuhle bodu nemám moc co dodat nad to, co je v mailu. Má někdo další komentáře/dotazy/nápady? 15:30 <Pseudonym> zdá se, že dělat optimalizaci výkonu před změnou algoritmu vytváření tunnel může být opačně 15:30 <gott> dostávám hodně "No HTTP method found in the request. 15:30 <gott> Software caused connection abort: socket write error 15:30 <gott> " 15:30 <@modulus> zpoždění tunnel je mnohem menší, nevím jestli jsi něco měnil nebo se můj ISP najednou zázračně zlepšil. 15:30 <gott> z I2PTunnel Webmanager 15:31 <jrandom> gott: to naznačuje špatné http požadavky, nebo věci, kterým eepproxy nerozuměl 15:31 <jrandom> modulus: super, dost jsme makali na zlepšeních 15:31 <jrandom> Pseudonym: no, zatím pro nás vytváření tunnel nebylo úzkým hrdlem – úzké hrdlo byly věci o úroveň výš 15:32 <jrandom> na druhou stranu, zlepšení posledních pár revizí odkryla pár problémů tam dole 15:32 <Pseudonym> aha, takže optimalizace se týkaly jiných částí kódu? 15:32 <Pseudonym> cool 15:33 <jrandom> jo, na úrovni SSU i na úrovni provozu tunnel. vytváření tunnel není výkonnostně citlivá operace [kromě těch situací, kdy je ;] 15:34 <jrandom> dělám ale živé testy zatížení sítě, sbírám neanonymní statistiky zátěže různých peerů, abych to víc zúžil 15:34 <ailouros> Zajímá mě, proč někdy vidím víc tunnels než je nakonfigurováno pro destinaci (např. eeProxy, inbound 7 tunnels 4 outbound) 15:34 <jrandom> takže během příštích pár dní, když uvidíte router 7xgV přenášet spoustu dat, tak si toho nevšímejte ;) 15:35 <jrandom> ailouros: když vytváření tunnel trvá déle, staví si je do zásoby, pro jistotu. 15:35 <jrandom> zzz tam popisuje pár zvláštností a pracuje se na patchi, který to trochu zlepší 15:35 <ailouros> Chápu.. ale proč pak všechny vyprší ve stejnou dobu? 15:35 <@cervantes> jrandom: jen ze zvědavosti, kdy jsi ty testy začal? 15:35 <jrandom> cervantes: před pár dny 15:36 <@cervantes> aha super, tak to pak _není_ ono ;-) 15:36 <jrandom> nevím, ailouros, záleží na pár podmínkách. ale jsou tam... *ehm* zvláštnosti v kódu pro vytváření tunnel, do kterého se nehrabu, protože se přepisuje pro 0.6.2 15:38 <ailouros> Chápu. Myslel jsem, že je to otázka politiky... Raději bych viděl, aby tunnels umíraly v různý čas, pokud pro opak není dobrý důvod 15:38 <ailouros> tj. vytváření tunnel je rozhozené 15:39 <jrandom> jo, pro 0.6.2 tam bude lepší randomizace a zzzův patch přidává určitou randomizaci i do aktuální revize 15:40 <+Complication> Přemýšlím, proč by jinak normální instance i2phex... chtěla při každém druhém startu rehashovat soubory? 15:40 <jrandom> nemám tušení 15:40 <+Complication> Zatím to vypadá na poškozenou konfiguraci, ale svůj config jsem ještě nesmazal. 15:40 <jrandom> možná posunuté časové značky? 15:42 <+Complication> Ne, ty vypadají taky správně 15:42 * jrandom neví. Tuhle část kódu phexu jsem nikdy nezkoumal 15:42 <jrandom> tedy, code 15:42 <+Complication> Uvidím, jestli pomůže smazat staré konfigy 15:42 <jrandom> fajn 15:43 <jrandom> ok, ještě něco k 1) stavu sítě / 0.6.1.7? 15:43 <jrandom> pokud ne, jdeme na 2) Experimentální selhání tunnel 15:44 <jrandom> už jsme to trochu naťukli a víc je v poznámkách a na zzz.i2p 15:44 <jrandom> zzz: chceš něco dodat / otevřít? 15:46 <jrandom> pokud ne, pojďme na 3) SSU a NATy 15:46 <jrandom> bar: něco chceš dodat? 15:46 <+bar> ne, nemám nic navíc oproti tomu, co je v mailu 15:47 <jrandom> fajn, ještě musím odpovědět na pár detailů – myslím, že naše retransmise už vyřeší některé problémy, které zmiňuješ 15:48 <jrandom> fígl bude detekovat, o jakou situaci jde, abychom mohli zautomatizovat správný postup (nebo uživateli sdělit, že jsou nahraní) 15:48 <+bar> všeho do času, nespěchá to 15:49 <+bar> jo, navrhoval jsem ruční nastavení, aby se ten problém prozatím obešel, možná to nepůjde, ale můžeme to probrat později 15:50 <jrandom> jo, ruční přepínače pomůžou, ale moje zkušenost s dřívějšími revizemi i2p byla, že to všichni (*všichni*) podělali ;) takže automatizace je lepší 15:50 <jrandom> (všichni včetně mě ;) 15:52 <+bar> souhlas 15:52 <ailouros> lol pokud jsem to zvoral i já, tak bylo něco špatně v dokumentaci, jelikož jsem ji následoval krok za krokem :D 15:53 <+bar> mezitím strávím nějaký čas studiem peer testing 15:53 <jrandom> super, díky, bar! 15:54 <+bar> (možná k tomu vygeneruju i nějaký zbytečný spam :) 15:54 <jrandom> :) 15:55 <jrandom> ok, pokud už nic k 3), pojďme na 4) Syndie 15:56 <jrandom> v poslední době je v tomhle směru spousta pokroku, od vydání 0.6.1.7 doznalo UI dost zásadních změn 15:57 <jrandom> je i nový samostatný install/build, ale protože všichni máme i2p nainstalované, nepotřebujeme zvláštní 15:57 <ailouros> přijde mi, že rozvržení 6.1.7 se používá hůř než 6.1.6 15:58 <jrandom> hmm, jede ti syndie v režimu jednoho uživatele? a/nebo používáš poslední CVS build nebo oficiální build 0.6.1.7? 15:58 <ailouros> oficiální 0.6.1.7, single user 15:58 <jrandom> jsi jeden z těch, kdo prosazují blogové rozhraní místo vláknové navigace? 15:58 <ailouros> nejsem, i když vlastně nevím, co je to blog-like 15:58 <ailouros> osobně bych raději vláknovou navigaci 15:59 <ailouros> (a taky nějaké barevné odlišení nových zpráv ve zobrazení vláken) 15:59 <+Complication> Relativně pozdní CVS, single user 15:59 <+Complication> Našel jsem drobnou zvláštnost (která podle mě asi nebyla zamýšlená) 15:59 <jrandom> aha, v CVS je v tomhle ohledu hodně pokroku, ailouros 15:59 <ailouros> skvělé :) 16:00 <jrandom> máme i nový vláknový přehled, používá cervantesův návrh plného průchodu jen jednou větví místo všech 16:00 <@cervantes> jsou ty změny nasazené na syndiemedia.i2p.net? 16:00 <+bla> Nebylo by dobré ukázat nějaké výchozí příklady pro location v http://localhost:7657/syndie/syndicate.jsp ? 16:00 <jrandom> syndiemedia.i2p.net jede na headu z CVS, jo 16:00 <+Complication> Když si otevřete vlákno a čtete jeho příspěvky... a pak zvolíte filtr, na který žádné příspěvky neodpovídají (např. otevřete vlákno "Syndie threading", aplikujete filtr "i2p.i2phex")... 16:00 <jrandom> jo, možná, bla. nové instalace tam budou mít tři výchozí, ale příklady by byly fajn 16:01 <@cervantes> (strom daného vlákna by se měl taky celý rozbalit) 16:01 <+Complication> ...zdá se, že ty aktuální příspěvky nechá zobrazené, jako by odpovídaly nebo tak něco... 16:01 <+Complication> A to jsem určitě klikl na tlačítko "Go". 16:01 <@cervantes> Complication: jo, to mi taky přišlo matoucí 16:02 <jrandom> hmm, Complication, původně jsme chtěli, aby šlo při čtení příspěvku dál procházet, ale možná bude lepší nechat ty zobrazené příspěvky zmizet 16:02 <jrandom> cervantes: aha, jo, rozbalit až k listu by bylo dobré a mělo by to být triviální 16:02 <+Complication> Právě jsem si všiml, a jak to vyčnívalo, tak říkám 16:02 <@cervantes> (nebo udělat ještě zřetelnější, že nejsou žádné shody) 16:03 <jrandom> no, thread nav říká *no matches* :) 16:03 <ailouros> možná hledá zapalovač 16:03 <jrandom> !thwap 16:03 <@cervantes> (nebo udělat ještě víc zřejmé, že nejsou žádné shody) 16:03 <jrandom> <blink>No matches</blink> 16:03 <+Complication> Ups :) 16:04 <tethra> vypadá to, že tvůj !thwap trefil místo toho spaetz__ , jr! 16:04 <+Complication> Jo, někdy je navigátor vláken pocitově dost daleko :) 16:04 <jrandom> jo, zkoušíme nějaké css, aby to plavalo po straně, jako volitelně 16:05 <@cervantes> s podporou skinning bys mohl mít vlákna nahoře, dole, vlevo, vpravo atd. 16:05 <@cervantes> jak říkal jr 16:05 <+Complication> Odkaz "Threads" tam člověka dovede docela rychle 16:05 <+Complication> ...pokud je zrovna ve viewportu. 16:06 <+Complication> A kdo je zvyklý na klávesnici, může prostě zmáčknout "End" 16:06 <jrandom> samozřejmě, tohle je fakt jednoduché upravovat (jak je vidět z rychlých změn v CVS :), takže pokud má někdo návrhy (nebo mockupy – html / png / atd.), prosím, hoďte je sem kdykoli 16:07 <jrandom> čekám, že v CVS bude během pár dní hlavní přehledová stránka blogu 16:08 <jrandom> ok, kolem syndie se děje spousta dalšího, tak mrkněte na http://localhost:7657/syndie/ pro víc info :) 16:08 <jrandom> má někdo ještě něco k tomu, nebo přejdeme k 5) ??? 16:09 <zzz> čau, právě jsem přišel. k 2), hledám testery pro svůj patch. 16:10 <zzz> Moje výsledky jsou zlepšení zpoždění úloh a spolehlivosti a snížení zatuhnutí router. Tak doufám, že to další zkusí. 16:10 <ailouros> to zní dost dobře. co mám udělat? 16:11 <jrandom> čau zzz, ok super, já to tu taky trochu proklepu. má to hodně různých komponent, takže by stálo za to to rozdělit na kusy, ale vypadá to dobře a míří to do 0.6.1.8 16:11 <ailouros> (průměrná doba běhu je tu asi 10 h :( 16:11 <zzz> Pokud máš zdroják a ant, prostě aplikuj patch – nebo můžu hodit i2pupdate.zip, pokud chceš 16:12 <zzz> jrandom budu pracovat na rozdělení 16:12 <ailouros> vezmu si update, díky 16:13 <zzz> ailouros dám to na zzz.i2p do hodiny – díky 16:13 <jrandom> zzz: neřešil bych to, pokud máš čas nazbyt... diff si projdu :) 16:13 <ailouros> děkuju 16:14 <zzz> jrandom OK. Je tam pár různých věcí, které se dají snadno vytrhnout, ať už tebou nebo mnou. 16:16 <ailouros> Myslím, že jsme teď u 5) ??? ? 16:16 <zzz> jrandom jiné téma byly Router OOMs s i2phex a možné potíže se SAM 16:16 <jrandom> jo, ailouros 16:16 <jrandom> aha jo, zzz, bylo by super zjistit, co se děje se SAM 16:17 <ailouros> j346, měl jsi čas mrknout na moji app? 16:17 <jrandom> bylo by super, kdyby se někdo přihlásil a převzal údržbu SAM bridge, já na tom nic zásadního nedělal a human tu delší dobu nebyl. 16:19 <jrandom> ještě ne, ailouros, bohužel. nebyl jsem si jistý, jak to funguje, takže si musím napřed projít zdroják 16:20 <ailouros> klidně se ptej 16:20 <ailouros> (a hodně štěstí na cestě zdrojákem, je to dobrá definice slova "bordel") 16:20 <jrandom> hehe 16:21 <zzz> upřesnění: moje zkušenost byla s vyčerpáním paměti (OOM) při použití i2p-bt, ne i2phex. Stane se to po asi 24 hodinách při běhu jednoho i2p-bt a během pár hodin při běhu dvou i2p-bt 16:22 <+Complication> Mně se to stalo po nočním zátěžovém testování. 16:22 <+Complication> (během něj, podotýkám, jsem viděl pětiminutové průměry 50 KB/s) 16:22 <bar_> připomněl bys mi, co tvoje app je/dělá, ailouros? mám dobrou, ale krátkou paměť... 16:22 <+Complication> Příchozí, tedy. 16:22 <+Complication> Odchozí bylo omezeno na 35 KB/s 16:22 <@cervantes> Complication: ještě jsem neslyšel, že by se tomu říkalo noční zátěžové testování... 16:22 <jrandom> pěkné, Complication 16:23 <+Complication> cervantes: no, dalo by se tomu říkat i polodenní megaleeching :P 16:23 <ailouros> bar_: je to funkční proof-of-concept pro distribuovanou aplikaci na sdílení souborů, která sdílí společné bloky mezi různými soubory (jak navrhl polecat) 16:23 <bar_> aha, jasně, díky, ailouros 16:24 <tethra> cervantes: heheheh ;) 16:24 <ailouros> nemáš zač (kdo chce zdrojáky, jsou v c/c++) 16:25 <+polecat> ailouros: Opatrně, šance, že budou dva binární bloky stejné, je dost malá, mluvím spíš o čisté teorii, která by v praxi nebyla moc užitečná. 16:25 <ailouros> polecat, souhlasím. Nejvíc se to asi hodí, když máš různé verze týchž souborů 16:25 <ailouros> třeba film, který má poškozený blok 16:25 <+polecat> Mohl bys přenášet bloky nulových bytů bleskově! ("Další blok jsou samé nuly" "aha, ten už mám" "další blok jsou samé nuly" "aha, ten už mám") 16:26 <ailouros> nebo archiv jiných zip souborů 16:26 <jrandom> nebo např. upravené ID3 tagy, atd. 16:26 <ailouros> přesně 16:26 <+polecat> Pravda. Ale jednoduchý způsob, jak "opravit" film s poškozeným blokem, je říct bittorrentu, ať ho stáhne přes něj. Většina klientů zachová bloky, jejichž hashe sedí, a přepíše ty, které se liší. 16:26 <jrandom> archivy souborů ale asi fungovat nebudou, protože by se musely lámat na hranicích souborů 16:27 <ailouros> j636, proto chci implementovat nápad LBFS dělit podle datových značek a ne fixních velikostí bloků 16:27 <@cervantes> komunita DC používala tu metodu, sdílením distribucí souborů v rarsetech 16:27 <+polecat> Co by možná bylo užitečné, je udělat obecný binární algoritmus korekce chyb a pak ho nasadit ve velkém. Všechny bloky by se daly "převést" jeden na druhý a musel bys přenášet jen korekční data, která by mohla být menší než přenos celého bloku. 16:29 <@cervantes> a pak se hledá podle tiger hashů těch rar částí 16:29 <+Complication> Hezká myšlenka... zní to ale složitě :) 16:29 <+polecat> Ale jen hash-za-hash ekvivalent... dva stejné bloky nenajdeš! 16:29 <ailouros> cervantes, co je to "rarset"? :D (kromě "RAR souboru") 16:29 <+polecat> Ledaže by měli oba tu věc už staženou a jeden z nich ji měl poškozenou. 16:29 <ailouros> polecat, eh? 16:29 <@cervantes> ailouros: rozdělený rar archiv, případně s paritními soubory 16:30 <ailouros> cervantes: nechápu výhodu to tak dělat 16:31 <@cervantes> hlavní přínos byl pseudo-multisource stahování v DC 16:32 <ailouros> no, to je součást mechanismu sdílení bloků mezi soubory, ne? 16:34 <ailouros> polecat: ohledně bittorrent přepisování poškozených souborů, to nepomůže, když se snažíš získat více verzí najednou 16:35 <@cervantes> tvůj klient páruje/stahuje jen validní části, pokud máš paritní soubory, umíš zachránit i poškozené 16:35 <ailouros> v mém systému nejsou žádné poškozené části (soubory se skládají až když jsou stažené a znovu ověřené všechny tvořící bloky) 16:36 <@cervantes> věci, které bittorrent dělá defaultně, kromě toho, že nemůžeš vyhledávat konkrétně jednotlivé části 16:36 <+polecat> Více verzí pravděpodobně nebude mít společný jediný bit... proto jsou tak pitomé. Někdo překóduje film do velikosti poštovní známky a dá mu stejné jméno. 16:37 <+polecat> Nebo jiný týpek vezme náhodná data a pojmenuje je podle souboru, který chceš stáhnout. 16:37 <ailouros> lol to sedí 16:37 <@cervantes> přesně a vydání v rarsetech jsou vůči tomu imunní... 16:37 <ailouros> ale měj na paměti, že soubory z jiných sítí (emule, kazaa, atd.) často chodí poškozené 16:38 <+polecat> rarset vydání nejsou imunní... 16:38 <+polecat> Pořád musíš zjistit, který rarset je ten správný. 16:38 <ailouros> cervantes, jak jsou rarsety imunní proti idiotovi, co publikuje náhodný bordel? 16:38 <@cervantes> (pokud máš důvěryhodný zdroj) 16:39 <@cervantes> protože release skupina publikuje hashe/distribuční informace 16:39 <ailouros> hahaha to je snadné :D 16:39 <@cervantes> a věci se značkují jako "nuked", pokud jsou nekvalitní, lidi je odstraní ze sdílení 16:40 <ailouros> cervantes, to moje hračka už dělá 16:40 <@cervantes> cool 16:40 <ailouros> získáš deskriptor souboru z důvěryhodného zdroje, soubor hned stáhneš z více zdrojů 16:41 <@cervantes> zní dobře ;-) 16:41 <ailouros> nemůžeš vyhledávat soubory, ale můžeš procházet sdílený dire každého uživatele, takže můžeš použít web crawler a cachovat výsledky 16:42 <ailouros> i když možná časem přidám vyhledávání, pokud se ukáže jako potřebné 16:44 <ailouros> Věřím, že moje hračka, po řádném dotvoření do aplikace, může nabídnout cache a odolnost, o kterou se snaží lidi z freenetu 16:44 <ailouros> tj. distribuci a cache statického obsahu 16:45 <ailouros> přečteš si můj blog, uložíš ho do cache a nabídneš ho dalším, až budou chtít. nic víc neděláš než že ten obsah necháš být 16:45 <ailouros> nelíbí se ti obsah? smaž ho a hotovo 16:45 <jrandom> hmm, takže to vidíš jako backing store (základní úložiště), které by šlo použít pro syndie? 16:46 <ailouros> POUŽÍT to JAKO backing store se dá 16:46 <ailouros> jak je to teď, můžeš to použít i místo jetty v defaultních instalacích i2p 16:46 <jrandom> např. přílohy / odkazy na [clunk hash="$foo"]my file[/clunk] 16:46 <ailouros> (no s pár drobnými změnami :D ) 16:46 <jrandom> heh 16:47 <jrandom> ok, jo, rozhodně nechápu, jak clunk funguje... nechceš o tom napsat v syndie, nebo postavit eepsite? :) 16:47 <ailouros> hashe souborů se stáhnou při požadavku na soubor a tyto hashe se automagicky stáhnou do plného souboru 16:48 <jrandom> jasně, ale "stažení" je otázka odkud kam, atd. pomohl by popis celkové architektury sítě 16:48 <ailouros> napíšu slušný dokument a pak to někde publikuju 16:48 <jrandom> r0x0r, díky 16:48 <ailouros> stažené odkudkoli, odkud jsi vzal hash 16:48 <ailouros> plus od všech ostatních, kdo ty bloky sdílí 16:49 <ailouros> představ si go!zillu a download accellerator :) 16:49 <jrandom> myslím, že nechápeš, jak moc jsem zmatený 16:49 <ailouros> ale transparentně a v rámci i2p 16:49 <ailouros> lol asi jo :D 16:50 <jrandom> velmi, velmi základní vysvětlení typu: "spustíš clunk klienta, stahuješ z clunk serveru, získáváš info o clunk peers", atd. 16:50 <jrandom> používám webový prohlížeč k dotazování clunk klienta? nebo serveru? nebo peer? 16:51 <jrandom> (tak moc jsem ztracen) 16:51 <ailouros> od znova od nuly :) 16:51 <ailouros> použiješ webový prohlížeč 16:51 <ailouros> připojíš se ke svému klientovi 16:51 <ailouros> procházíš cizí adresáře svým prohlížečem 16:51 <ailouros> vybereš, které soubory stáhnout, svým prohlížečem 16:51 <ailouros> tvůj klient udělá špinavou práci 16:52 <ailouros> soubor máš stažený zpět 16:52 <ailouros> je to lepší? :) 16:52 <jrandom> ok super, díky – takže "browse other's dir" dělá tvůj klient dotazem na jejich klienta a vrací HTML reprezentaci 16:52 <ailouros> přesně 16:52 <jrandom> (nebo se to tahá z nějakého serveru/superpeer/etc) 16:53 <jrandom> cool 16:53 <ailouros> veškerou špinavou práci (hledání duplicit, multidownloady atd.) dělá (lokální) klient transparentně 16:54 <ailouros> co vidíš, je v zásadě strom adresářů a nějaké soubory ke stažení 16:54 <jrandom> super 16:55 <ailouros> pro publikování svých dat sdělíš svou veřejnou (p2p) adresu 16:55 <ailouros> a pro sdílení souborů je zkopíruješ (nebo uděláš symlink) do adresáře pub/ (nebo nějakého podadresáře). Tak jednoduché to je 16:57 * jrandom si ještě víc prohrabe zdroják a těší se na víc informací :) 16:57 <jrandom> ok, má ještě někdo něco k meetingu? 16:57 <bar_> umm.. jaký je rozdíl mezi publishing a sharing, jestli se můžu zeptat? posílá publishing data do nějakého datastore? 16:58 <ailouros> bar_: sharing je, že dáváš bloky ke stažení. publishing je, že světu oznámíš, co sdílíš 16:58 <ailouros> publishing je podmnožina sharing 16:58 <bar_> aha, chápu, díky 16:58 <ailouros> například, když máš polovinu souboru, sdílíš ji, ale nepublikuješ 16:59 <jrandom> jak by lidi věděli, že od tebe ty bloky můžou získat? 16:59 <ailouros> a máš plnou kontrolu nad tím, které soubory publikuješ (na rozdíl od emule, kde se publikuje každý stažený soubor) 16:59 <ailouros> protože každý klient periodicky posílá do sítě informaci o tom, které bloky nabízí 17:00 <jrandom> cool 17:00 <ailouros> posílá do sítě jako na server (tak je to teď) nebo do DHT (v budoucnu) 17:00 <jrandom> takže je to mnet-esque, s trackerem bloků 17:00 <ailouros> err mnet-esque? 17:01 <jrandom> podobné tomu, jak funguje mnet (mnetproject.org) 17:01 * ailouros čte mnetproject.org 17:02 <ailouros> no, máš jen své osobní prostory, žádné sdílené prostory 17:02 <ailouros> a netlačíš bloky ven 17:02 <jrandom> jo, není to úplně stejné jako mnet, ale strukturálně je to podobné 17:03 <jrandom> je to jako mnet, kde jsou všichni tak na mizině, že jim nikdo nehostuje data ;) 17:03 <ailouros> jo 17:03 <ailouros> :D 17:03 <jrandom> ok, má ještě někdo něco dalšího? 17:04 <jrandom> pokud ne... 17:04 * jrandom uzavírá 17:04 * jrandom *baf* uzavírá schůzku