Setkání vývojářů I2P - 18. května 2004

14:07 <jrandom> 0) ahoj 14:07 <jrandom> 1) stav testnetu 14:07 <jrandom> 2) SAM 14:07 <jrandom> 3) aktualizace roadmapy 14:07 <jrandom> 4) MyI2P 14:07 <jrandom> 5) ??? 14:07 <jrandom> 0) ahoj 14:07 * jrandom mává 14:08 <Nightblade> ahoj 14:08 * jteitel mává zpátky 14:08 <jar> ahoj 14:08 <duck> čau 14:08 <Masterboy> :P 14:08 <jrandom> týdenní status poznámky jsou zveřejněny na http://dev.i2p.net/pipermail/i2p/2004-May/000239.html 14:09 <jrandom> omlouvám se, jestli jsem dnes trochu mimo, můj spánkový režim je ještě víc rozhozený než obvykle 14:09 <jrandom> každopádně, přejdeme k 1) testnet status 14:10 <duck> ta diverzifikace by se s větší sítí stala automaticky, že? 14:10 <jrandom> ano, a/nebo méně zkreslené prahy výběru peerů 14:11 <jrandom> například, kdyby práh rychlosti byl medián místo průměru, měli bychom poloviční počet rychlých peerů oproti spolehlivým peerům 14:11 <jrandom> na rozdíl od současné situace, kdy jsou rychlosti silně zkreslené 14:12 <Masterboy> no, síť se zotavila, to není tak špatné 14:12 <jrandom> jo, trvalo to ale déle, než by mělo, a odhalilo to cesty, jak to zlepšit 14:13 <jteitel> síť se zotavila? Pořád se nemohu spolehlivě připojit na i2p irc 14:13 <jrandom> profily peerů neztrácely váhu dost rychle, ani nepovýšily nové kandidáty dost efektivně 14:14 <jrandom> spustilo to i řetězec sekundárních událostí – přetížení routerů (I2P směrovačů), které nebyly schopné unést zátěž (kvůli nedostatečnému profilování), což způsobilo, že některým přetíženým routerům došla paměť a vypnuly se 14:15 <human> ayeee ayeee ayeee! 14:15 <jrandom> je to postupný vývoj, jteitel – některé problémy, které vídáme, souvisejí se selháními netDb 14:15 <jrandom> čau, human 14:15 <jteitel> Aha, OK 14:16 <_cervantes_> nemohl by problémový router přesunout tunnels na jiného peera? 14:16 <ugha_node> Páni, Lifetime rate: 8.87KBps sent 8.35KBps received. 14:16 <Nightblade> jteitel: Právě jsem se připojil po několika pokusech... pořád čekám, až projde moje /join 14:16 * BrianR se rozhlíží. 14:16 <jrandom> ne – router může jednoduše zahodit tunnel (pokud ho neměl vůbec přijmout) 14:16 <ugha_node> (A svůj router jsem restartoval před půl hodinou) 14:16 <BrianR> sakra. Jdu pozdě. 14:17 <BrianR> jrandom: (Díky, žes dal myi2p ke konci agendy) 14:17 <jrandom> ugha> jo, všichni jste museli vzít to za ně za ty tři rychlé 14:17 <jrandom> hehe :) 14:18 <duck> to byl pěkný útok 14:18 <ugha_node> jrandom: Očividně. 14:18 <_cervantes_> nebylo by lepší být nekompromisnější a odmítat tunnels při nižším prahu 14:19 <jrandom> ano, cervantesi – routery teď nikdy neodmítnou tunnel, ledaže nedokážou dosáhnout na next hop 14:19 <jrandom> budeme tam chtít přidat nějaké throttling, třeba podle velikosti jobQueue / avg lag atd. 14:20 <jrandom> navíc budeme chtít zajistit, abychom se nepokoušeli budovat příliš mnoho tunnels najednou, jako se stalo, když velká část z nich selhala 14:20 <_cervantes_> nebo prostě umožnit uživateli nastavit práh podle hardware/bandwidth, o které ví, že ji má k dispozici 14:20 <jrandom> (kvůli tomu, že fast+reliable peery šly offline) 14:20 <_cervantes_> alespoň v této fázi 14:20 <jrandom> to je dobrý point – umožnit lidem explicitně nastavit max počet participating tunnels. 14:21 <jrandom> dáme to do příští revize. dobrý nápad. 14:21 <ugha_node> To zní jako fuzzy logika. 14:21 <jrandom> musíme se vypořádat s přetížením a pouhé frontování zpráv v paměti očividně nefunguje 14:21 <duck> (ahoj fvw) 14:21 <_cervantes_> bylo by dobré mít nějaké agregované statistiky o výkonu tunnels... jakou zátěž by to mohlo klást na referenční procesor(y) 14:22 <_cervantes_> mimochodem vzal jsem server offline.... dostával hromadu tunnels a ještě jsem neskompiloval jbigi ;-) 14:22 <jrandom> viz http://localhost:7655/routerStats.html#Tunnels 14:23 <jrandom> ah! jo, jbigi je něco, co chceme, aby všichni používali 14:23 <BrianR> Nějaké myšlenky na rozpočtování šířky pásma pro tunnels? 14:24 <jrandom> aktuálně plánováno pro 3.0 (s celkovým omezením šířky pásma pro router jako celek v 0.4.1) 14:24 <jrandom> ale mít dřív limity šířky pásma na tunnel by neuškodilo 14:25 <fvw> Je rozumné na tohle tak brzy vynakládat úsilí, když je to mnohem snazší a přesnější udělat v kernelu OSů, které většina aktuálních uživatelů/testerů používá? 14:25 <_cervantes_> něco, co bych rád viděl, je nastavení per-tunnel depth (možná to už jde) 14:25 <_cervantes_> například už vím, že svému serveru mohu věřit... tak nechci muset jít přes _x_ hops, abych se k němu dostal 14:25 <jrandom> fvw> to je dobrý point, zvlášť když momentálně nesežereme moc šířky pásma 14:26 <jrandom> hmm, cervantesi – ano, každý klient může specifikovat délku svých tunnels, ale nejsem si jist, že je to přesně to, co chceš 14:26 <_cervantes_> není 14:26 <jrandom> cervantesi – myslím, že hledáš spíš QoS, kde můžeš zkrátit conn pro konkrétního peera 14:26 <_cervantes_> například... 14:26 <_cervantes_> jo 14:27 <jrandom> (což bylo plánováno pro i2p 4.0, ale to je víc než rok daleko == nekonečno) 14:27 <_cervantes_> v tomhle případě taky vybrat depth pro každý i2p host 14:27 <BrianR> fvw: Ano, ale i2p potřebuje zhruba vědět, kolik šířky pásma mají potenciální členové tunnelu k dispozici, aby dělalo rozumná rozhodnutí při stavbě tunnelů... 14:27 <_cervantes_> aha ok 14:27 <_cervantes_> :) 14:27 <jrandom> ale je to dobrý nápad a technicky proveditelný, patche vítány :) 14:28 <_cervantes_> patch už je na cestě.... spolu s šekem na 5000 prutů e-goldu 14:28 <_cervantes_> ;-) 14:28 <jrandom> BrianR: možná to může jít napůl – sledovat, v kolika tunnels se účastní, stejně jako kolik šířky pásma ty tunnels používají, a použít to jako část rozhodování, zda přijmout nebo odmítnout požadavek na vytvoření tunnelu? 14:28 <jrandom> heh 14:30 <jrandom> ok, má ještě někdo něco ke stavu testnetu? 14:30 <Masterboy> co můj paradox? 14:30 <Masterboy> :) 14:30 <jrandom> plán je dostat 0.3.1.3 s aktualizacemi ven do čtvrtka nebo pátku 14:31 <jrandom> Masterboy: neměl jsem čas projít tvoje logy, ale vyřešíme to 14:31 <_cervantes_> pátek 2005? 14:31 <_cervantes_> cool 14:31 <Masterboy> k 14:31 <jrandom> ok, přecházíme na 2) SAM 14:31 <Masterboy> teď víme, kdo provozuje zastaralý router.. 14:32 * jrandom předává mikrofon našemu neohroženému vývojáři SAM.pm 14:33 <jrandom> (to jsi ty, BrianR :) 14:33 <BrianR> Vteřinku.. :) 14:33 * duck jásá 14:33 <jrandom> zatím, je tady dm nebo firerabbit? 14:33 -!- Irssi: #i2p: Total of 26 nicks [0 ops, 0 halfops, 0 voices, 26 normal] 14:33 * jrandom kontroluje /names, nic. škoda 14:33 <jrandom> (takže žádné .net/C# sam lib novinky) 14:34 <duck> je .py věci stále aktuální? 14:34 <duck> nebo zastaralé kvůli vylepšením SAM 14:34 <jrandom> nevím 14:34 <BrianR> Ok. Jsem zpět. 14:34 <Nightblade> Moje C knihovna zřejmě funguje... ale ještě jsem nenapsal aplikaci, která by ji používala 14:34 <jrandom> super, Nightblade! 14:35 <Nightblade> Dělal tady někdo GTK+/C programování pod Windows? 14:35 <human> duck: klientská knihovna potřebuje malou změnu kvůli podpoře verzování 14:35 <_cervantes_> "hello world"? 14:35 <human> duck: zbytek by měl fungovat bez problémů 14:35 * jrandom navrhuje datagram jako tftp jako ideální test pro SAM :) 14:35 <Nightblade> no, cokoliv... funguje GTK dobře pod Windows.....? 14:35 <jrandom> (nebo klidně SAM streaming místo datagram nebo raw) 14:36 <jrandom> fajn, BrianR – jak to jde s .pm a se samcat? 14:36 <BrianR> Net::SAM je v CVS ve většinou nefunkční podobě. 14:36 <BrianR> Doufám, že do konce týdne vychytám všechny bugy a rozběhám datagram a raw. 14:37 <BrianR> Trochu víc práce bude potřeba, aby se streamům dal pěkný OO kabát. 14:37 <Nightblade> jo, s datagram ani raw jsem se neobtěžoval... jen stream 14:37 <Nightblade> ale to je stejně to jediné, co bych používal 14:37 <fvw> human: Zvážil jsi wxWindows? Je to dost užitečné pro tenhle typ věcí (nemyslím, že existuje windows GTK target ale) 14:37 <jrandom> super, BrianR 14:38 <BrianR> Manželka mě honí na večeři. Možná se nevrátím včas na myi2p diskuzi. Zveřejnil jsem threat model a nějaké hloupé fileserver věci na node 208 14:38 <human> fvw: existuje GTK windows port (GIMP běží i na Windows) 14:38 <jrandom> fajn, Nightblade, nejlepší je nejdřív implementovat to, co je potřeba 14:38 <human> fvw: s/client/port/ 14:38 <jrandom> heh, ok BrianR, díky 14:38 <fvw> human: Myslím gtk windows target pro wxWindows (které jsem ti navrhoval použít) 14:38 * fvw mává na BrianR. Dobrou chuť. 14:38 <human> fvw: ah... no, o vxWidgets (vxWindows' new name :-) nevím :-) 14:39 <human> fvw: ale o GTK+ mluvil Nightblade, ne já :-) 14:40 <fvw> Ups, mám křivé oči, ignorujte mě. 14:40 <Nightblade> Nejsem tak obeznámený s C++ jako s C 14:40 <Nightblade> pokud vím, GTK je jediná multiplatformní C GUI knihovna 14:40 <Nightblade> ne že bych měl GTK zvlášť v lásce 14:40 <fvw> to je jedno, wxWindows je snadno použitelné i z C. 14:40 <Nightblade> hmm 14:40 <Nightblade> no možná se na to taky podívám 14:40 <Nightblade> C++ umím, ale nepsal jsem v něm žádné velké programy 14:41 * fvw také není C++ kodér, ale před časem jsem v tom bez problémů zprovoznil docela velký prohlížeč transakcí pro dopravní firmu. 14:42 <Nightblade> jsem si jistý, že wxwindows má vyzrálejší Windows port 14:42 <Nightblade> než gtk 14:42 <fvw> dost pravděpodobně jo. 14:43 <Nightblade> (ok pokračujte v meetingu) heh 14:43 <jrandom> :) 14:43 <jrandom> ok, skáču na 3) roadmap updates 14:44 * jrandom byl poslední měsíc nedbalý v aktualizacích http://www.i2p.net/roadmap 14:44 <jrandom> ale teď je to zase aktuální 14:44 <jrandom> bohužel je jasné, že 0.4 příští týden nedáme 14:44 <duck> (jsou 1.1, 2.0, 3.0 také aktuální?) 14:45 <jrandom> ano pane 14:45 * Masterboy si to přečetl, líbilo se – není kam spěchat, nehoříme.. 14:46 <duck> někdo by měl aktualizovat i wikipedia/infoanarchy :) 14:46 <jrandom> oh, asi bych měl odstranit z 0.4 "SAM bridge and client libraries implemented and tested" 14:46 <jrandom> heh jo, proto jsem před časem !thwapped iA, když jen zkopírovali wiki stránku 14:46 <jrandom> (měli by jen odkazovat na /roadmap, ne duplikovat obsah) 14:47 <Masterboy> SAM je hotový? 14:47 <jrandom> je funkční, ano, ačkoliv práce na dalších klientských knihovnách pokračuje 14:47 <jrandom> s/are/is/ 14:48 <jrandom> ok, pokud nejsou další otázky/připomínky k roadmapě, přecházíme na 4) MyI2P 14:50 <jrandom> i když jsem sám přestal na myi2p pracovat, otevřeli jsme to jako bounty – http://www.i2p.net/node/view/216 14:50 <jrandom> to mimo jiné znamená, že musíme správně stanovit požadavky, a proběhla debata, jaké by měly být 14:51 <Masterboy> zkoušel do toho jít můj kamarád, říkal moc práce, málo peněz;P no, je to kapitalista;) 14:51 <Masterboy> no, nabídl jsem, že to nakóduju.. 14:52 <jrandom> kódování na tom je vždy vítané :) 14:53 <jrandom> aktuální zásadní architektonická otázka ale je, jak naložit s lidmi, kteří nemohou provozovat svůj i2p router / myi2p node neustále 14:53 <Nightblade> je potřeba mít nějakého důvěryhodného i2p isp 14:53 <jrandom> dva návrhy jsou buď použít hosted service providers, nebo systém rozdělit tak, aby používal distributed backing store 14:54 <_cervantes_> posledně jmenované je dlouhodobě ideální řešení 14:54 <_cervantes_> *latter 14:54 <duck> (a bylo by to na další bounty) 14:55 <_cervantes_> nebo webcache proxy službu... 14:55 <jrandom> správně – pokud bychom šli cestou hosted service provider (nebo lokálně běžícího node), když bude k dispozici DHT atd., mohli bychom víc a víc obsahu tlačit do DHT 14:55 <jrandom> _cervantes_: to je v podstatě distributed backing store – untrusted data caches 14:57 <deer> * Masterboy přemýšlí, kde je bogobot 14:57 <jrandom> těžké je získat potřebnou funkcionalitu řízení přístupu – u untrusted data caches / distributed backing store jsou ACL v podstatě šifrování 14:57 <jrandom> ale „vedlejší kanál“ k této diskusi přichází ze tří bodů, které vznesl anonym @ http://www.i2p.net/node/view/215#comment-105 14:57 <_cervantes_> a podepsaný obsah 14:58 <jrandom> jasně, v obou případech bude potřeba mít podepsaný obsah 15:00 <_cervantes_> tady má hypercubusův model své zásluhy... ale rozhodně to není „rychlé“ řešení 15:00 <jrandom> ze včerejší diskuse na irc jsme se zaměřili na „LiveJournal threat model“ – jaké útoky uživatele LJ zajímají a jaké ne 15:01 <wilde> nejdřív ze všeho, dostat nejdřív základní MyI2P 15:02 <jrandom> správně, a aby se dal implementovat základní myi2p, musíme znát architekturu nasazení 15:03 <jrandom> s LJ threat modelem pro uživatele, kteří nemohou provozovat své vlastní nody, si nemyslím, že musíme jít cestou untrusted data cache 15:03 <jrandom> a proč by někdo používal myi2p, pokud potřebuje jen LJ threat model? protože je anonymní 15:04 <jrandom> mohli bychom pokračovat s nějakým idealizovaným systémem, ale platí zákon klesajících výnosů 15:04 -!- Irssi: #i2p: Total of 24 nicks [0 ops, 0 halfops, 0 voices, 24 normal] 15:05 <jrandom> proto se přikláním k tomu držet bounty v současných mantinelech – alternativy můžeme přidat později, až bude základní systém venku 15:05 -!- duck_ je nyní znám jako duck 15:06 <jrandom> každopádně, myslím, že to je vše, co mám k 4) MyI2P, pokud někdo nemá něco dalšího, co by chtěl otevřít 15:06 <jrandom> pokud ne, jdeme na 5) ??? 15:07 <_cervantes_> hmm potřebuješ velké kladívko :) 15:07 <jrandom> zapomněl jsem zmínit nový morph.i2p eepsite v zápisu ze schůzky a nickster.i2p má teď veřejný fproxy! 15:08 <jrandom> (a sungo.i2p má nahozenou a běžící webkameru :) 15:08 <_cervantes_> heh... 15:08 <_cervantes_> i2pr0n 15:08 <jrandom> má ještě někdo něco, co chce otevřít? 15:10 <jrandom> pokud ne, dostává nás to na 70. minutu 15:10 <deer> <Masterboy> ne 15:10 * jrandom uzavírá 15:10 * jrandom *baf* uzavírá schůzku