Stručné shrnutí
Přítomni: b0unc3, cat-a-puss, cervantes, Complication, DoubtfulSalmon, dust, jme\___, jrandom, lordalbert, Pseudonym, tethra, wmpq, zzz
Zápis ze schůzky
15:40 <jrandom> 0) ahoj 15:40 <jrandom> 1) Stav sítě a 0.6.1.9 15:40 <jrandom> 2) Kryptografie vytváření tunnelů 15:40 <jrandom> 3) Syndie blogy 15:40 <jrandom> 4) ??? 15:40 <jrandom> 0) ahoj 15:40 * jrandom mává 15:40 <jrandom> týdenní poznámky o stavu zveřejněny @ http://dev.i2p.net/pipermail/i2p/2006-January/001251.html 15:41 <@cervantes> pfff, ještě že I2P je spolehlivější než NASA 15:41 <jrandom> heh 15:41 <tethra> haha 15:41 <jrandom> (i když mám 20 minut zpoždění... ;) 15:41 <jrandom> každopádně, pojďme na 1) Stav sítě a 0.6.1.9 15:42 <wmpq> NSA nebo NASA, to není takový rozdíl, že? 15:42 <@cervantes> Říkal jsem I2P, ne jrandom ;-) 15:42 <jrandom> dobrá poznámka, cervantes ;) 15:42 <tethra> neblázni, jrandom JE i2p! ;D 15:42 <@cervantes> aha, myslel jsem, že to je způsob myšlení 15:42 <wmpq> [redact] 15:43 <jrandom> heh no, každopádně, 0.6.1.9 je venku a v oběhu, 70 % sítě už aktualizováno (díky všem) 15:43 <Pseudonym> mmmm, chutné nové vydání 15:44 <+zzz> úspěšnost sestavení klientských tunnelů zůstává <30 % 15:44 <jrandom> Nezaznamenal jsem mnoho hlášení o výrazně zvýšené end-to-end propustnosti, i když některé routery více než saturovaly T1 linky 15:44 <+zzz> dolů z ~40 % 15:44 <+Complication> Šířka pásma se zdá normální, o něco vyšší než u posledního CVS před vydáním. Počty peerů vypadají trochu vyšší. 15:45 <jrandom> hmm, jo, tím se moc netrápím, zzz, protože se to celé kompletně předělává pro 0.6.2 15:45 <+zzz> průměrná šířka pásma z ~12K na ~20K 15:45 <jrandom> 0.6.1.9 by neměl vybírat peery spíše náchylné souhlasit (tj. s vysokou kapacitou), ale místo toho by se měl zaměřit na ty s vyšší propustností 15:46 <+Complication> Procento retransmisí (poznal jsem 7 % v noci vydání) kleslo na 6 a něco 15:46 <jrandom> jo, s routery, které tlačí 1–300 KB/s, tam bude zkreslení 15:46 <jrandom> hmm, to je docela šílená míra, Complication, já viděl jen 2–3 % 15:46 <jrandom> (ale nepochybuju o tom, co vidíš) 15:47 <+Complication> V podstatě jedu na maximum směrem ven 15:47 <+Complication> (myslím tím vyčerpání kapacity linky) 15:47 <jrandom> aha, to by vysvětlovalo 15:47 <+zzz> pořád dostávám NULLy před GETy, což vede k 405 bad method, míra možná klesá, těžko říct jistě 15:48 <jrandom> jo, zzz, ve streaming knihovně je pár věcí k dopracování, ale nejspíš se k tomu nedostanu dřív než po přepracování tunnelů pro 0.6.2 15:48 <jrandom> (ale kdyby se do toho někdo chtěl ponořit dřív, to by samozřejmě bylo super) 15:49 <jrandom> Complication: když snížíš svůj omezovač šířky pásma na cca 70 % kapacity linky, vrátí se míra selhání na rozumnou hodnotu? 15:49 <+zzz> Pořád si myslím, že to je něco, co šlo do kódu těsně před Novým rokem, takže bude lepší se na to podívat dřív, než se na ty nedávné změny zapomene :) 15:50 <+zzz> Poprvé zaznamenáno 29. prosince 15:50 <jrandom> jo, zzz, určitě to tak bylo. pravděpodobně to souvisí s tím, jak teď respektujeme timeouty. 15:51 <+Complication> jrandom: to vlastně právě zkouším :) 15:51 <+Complication> Upravil jsem to pár vteřin předtím, než ses zeptal, ale hned to asi vědět nebudu 15:51 <jrandom> ale je tam potřeba dost práce, aby se to vyčistilo, a je důležitější nasadit nový kód pro vytváření tunnelů (což výrazně zlepší úspěšnost stavby tunnelů a přidá i celou sadu vylepšení anonymity) 15:51 <jrandom> super, Complication, jo, dej tomu 3–6 hodin 15:51 <jrandom> (aby se vyčistily staré hodnoty / spojení) 15:52 <+zzz> ~1–3 % GETů je momentálně poškozených 15:54 <jrandom> takže navrhuješ vrátit změny ve streaming knihovně (aby i2psnark shodil všechny své uživatele na OOM během 12–48 hodin) a odložit další přepracování streaming knihovny až po práci na 0.6.2 tunnelu, nebo o týden dva odsunout práci na 0.6.2 tunnelu a mezitím předělat streaming knihovnu? 15:55 <+zzz> rozhodně nevracet 15:56 <+zzz> je to na tobě 15:56 <+Complication> Je to poměrně záludný bug, to můžu říct 15:58 <jrandom> jsou tam i další bugy ve streaming knihovně, takže když si vyhrnu rukávy, chtěl bych je vzít všechny dohromady (protože žádný z těch zbývajících bugů není zjevný). 15:59 <jrandom> na druhou stranu, když půjdeme napřed do práce na tunnelu, dosáhneme výrazného snížení využití šířky pásma, vyšší úspěšnosti stavby, lepší anonymity a lepší schopnosti monitorovat vyvažování zátěže na živé síti 15:59 <Pseudonym> jestli je to u surfování jen 1–3 % chyb, řekl bych, že to může počkat, ale to je jen můj názor. 16:00 <jrandom> Přikláním se k tomu udělat nejdřív práci na tunnelu, protože po jeho nasazení můžeme pasivně monitorovat síť, zatímco budeme aktivně předělávat streaming knihovnu 16:01 <jrandom> (rád bych taky udělal GUI pro editaci/posílání do Syndie, ale to může počkat, až budou obě ty věci vyřešené ;) 16:01 <+Complication> Taková je míra i tady 16:02 <+Complication> (na mém eepsite) 16:04 <jrandom> Ok, bylo by fajn, kdybyste na to dohlédli, jestli se ty míry mění, ale mezitím budu pokračovat v přepracování tunnelů, po kterém přijde přepracování streaming knihovny (obojí bude hotové před 0.6.2) 16:05 <jrandom> (nebo pokud se chce někdo ponořit do streaming knihovny [nebo zjistit, jestli tam není nějaká podivná interakce s i2ptunnel], dejte vědět!) 16:06 <+Complication> jrandom: ze zvědavosti, šel by v testovací aplikaci vyloučit i2ptunnel? 16:07 <+Complication> např. kdyby něco jako ukázková appka od jnymo *také* dostávalo nully, očistilo by to i2ptunnel ze seznamu podezřelých příčin? 16:07 <jrandom> šlo by připojit tenkou (v rámci VM) implementaci I2PSocket, rozhodně 16:07 <+Complication> Protože, pokud si dobře pamatuju, ta ukázka používala streaming knihovnu přímo... 16:08 <+Complication> (nebo docela přímo) 16:08 <jrandom> jo, samozřejmě, když něco používající streaming knihovnu dokáže chybu reprodukovat, očistilo by to i2ptunnel 16:10 <+Complication> Hmm, pokud mě někdo nepředběhne (zkusím nejdřív dodělat tu věc s webcache), mohl bych zkusit emulovat HTTP něčím takovým... 16:10 <jrandom> boží, díky, Complication 16:10 <jrandom> ok, ještě něco k 1) Stavu sítě a 0.6.1.9? 16:11 <jrandom> pokud ne, přesuneme se k 2) Kryptografie vytváření tunnelů 16:11 <+Complication> Nevím, může to nevyústit v nic užitečného, nebo zakopnu v půlce... ale je to možnost, která mě láká 16:11 <jrandom> jo, určitě stojí za prozkoumání, Complication 16:12 <jrandom> (a zkoumání nemusí mít pozitivní výsledky, aby stálo za to :) 16:12 * cervantes zahlédne výjimku „moo“ ve změnách zdroje vedoucích k novému roku....možná je to ono? :) 16:13 <jrandom> ok, v e‑mailu je odkaz na novou specifikaci kryptografie vytváření tunnelů, založenou na diskusi, kterou jsme vedli s toadem a Michaelem na mailing listu loni v říjnu 16:14 <jrandom> mrkněte na to a dejte mi vědět své dojmy – na živé síti to nebude nasazeno ještě nějakou dobu, protože jsou předtím jiné věci k implementaci, ale blíží se to 16:14 <+Complication> Je „moo“ rezervované slovo v Javě? ;P 16:14 <+zzz> k 2) pomohu zrevidovat odkazy ve status mailu 16:14 <+Complication> K tématu krypta tunnelů, nevadilo by zkontrolovat, jestli je následující přeformulování v pořádku – chci si jen ověřit, že jsem to pochopil správně... 16:14 <jrandom> díky, zzz 16:15 <+Complication> „Každý hop zašifruje všechny záznamy svým reply klíčem, který si dešifroval ze svého záznamu pomocí svého ElGamal privátního klíče, a tímto šifrováním zvrátí jednu vrstvu dešifrování (nebo spíš by se mělo říct, šifrování) provedeného vlastníkem tunnelu, takže záznam dalšího účastníka se stane čitelným s použitím ElGamal privátního klíče dalšího účastníka?“ 16:15 <jrandom> Complication: ano 16:15 <+Complication> Nebo je moje přeformulování úplně špatně? 16:16 <+fox> <jme___> a příliš komplikované, jestli smím 16:16 <jrandom> je to správně, myslím, ale jo, příliš mnoho vedlejších vět :) 16:16 <+Complication> Nenapadl mě lepší způsob, jak si to představit. I tak to bylo dost těžké. :P 16:16 <jrandom> (nebo jme___ říkáš, že ten algoritmus je příliš komplikovaný?) 16:17 <+fox> <jme___> ne, zkusil jsem narychlo přečíst dokument a vzdal jsem to, protože příliš mnoho věcí vyžaduje předchozí znalosti 16:17 <+fox> <jme___> na druhou stranu jsem se moc nesnažil :) jiné věci na práci 16:17 <jrandom> Complication: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/java/src/net/i2p/router/tunnel/BuildMessageProcessor.java?rev=HEAD 16:18 <+fox> <jme___> je ten peer review formalita, nebo z toho máš opravdu obavy/nejistotu ? 16:19 <+Complication> No, je vždycky dobré vědět, co ten podkladový mechanismus dělá... 16:19 <jrandom> Jsem si jistý, že to dělá, co má, ale upřímně mě zajímá, jestli v tom někdo uvidí problém 16:19 <+fox> <jme___> pokud to druhé, mohl bych tomu věnovat čas, ale moje znalosti jsou staré a nemám je v hlavě čerstvé 16:20 <+fox> <jme___> pokud ne, věřím :) 16:20 <jrandom> Sekce poznámek má pár otázek - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.notes 16:22 <jrandom> nespěchá to, potrvá asi týden či dva, než se tahle nová kryptografie začne v routeru opravdu používat 16:22 <@cervantes> jrandom: k tomu, byl by velký dopad na výkon při vložení náhodného zpoždění mezi hop-y? 16:22 <@cervantes> protože to vypadá jako nejrozumnější možnost, jak bránit timing útokům 16:23 <jrandom> jde o vytváření tunnelu, takže zpoždění by nevadilo, i když by při katastrofálních selháních mohlo způsobit předčasné vypršení lease set 16:25 <jrandom> no, nejsem si jistý, jak účinná ta zpoždění budou. Mohou výrazně pomoct, ale taky nemusí. Živé tunnely však stejně mohou jednoduše použít blending (mísení provozu) k detekci spolupracujících peerů na daném tunnelu, takže si nejsem jist, zda na tom záleží 16:25 <+fox> <jme___> ok, čtu to znovu 16:27 <jrandom> díky. ok, nespěchá to, ale až/když bude mít někdo nějaké postřehy, pošlete je ke mně (nebo na list, nebo na svůj blog, atd.) 16:27 <jrandom> ok, ještě něco k 2, nebo přejdeme k 3) Syndie blogy? 16:29 <jrandom> (považujte nás za přesunuté) 16:29 <jrandom> ok, nové pěkné blogové věci v Syndie, směle do toho ;) 16:29 <@cervantes> v.cool 16:30 <jrandom> skupiny vlevo mohou obsahovat odkazy na libovolné URL, stejně jako odkazy na blogy, příspěvky v blozích nebo přílohy k příspěvkům v blozích 16:30 <jrandom> je možné i spousta dalších vylepšení, třeba přidání stylování příspěvků podle blogu nebo tagu, ikony atd. kdyby se do toho někdo ponořil, bylo by to super (a mělo by to hodně viditelný dopad :) 16:31 <@cervantes> mimochodem externí odkazy definované v komentářích by měly mít také atribut title nastavený na cílové URL (tak jako to máš na levém panelu) 16:31 <@cervantes> komentáře/příspěvky 16:32 <jrandom> ah, dobrý nápad 16:33 <jrandom> (net.i2p.syndie.sml.BlogPostInfoRenderer, metoda renderLinks(...) :) 16:34 <@cervantes> *čmárá si* 16:35 <jrandom> co ještě Syndie blogům chybí, aby představovaly funkční alternativu k informačním eepsite? samozřejmě, Syndie je statický obsah, takže některé věci nejdou, ale můžeš publikovat obsah a nechat lidi komentovat 16:36 <jrandom> jsou nějaké konkrétní úpravy, které bys chtěl umět? pokud ano, dej vědět 16:37 <DoubtfulSalmon> jrandom: aktualizovat existující obsah skriptem? 16:37 <@cervantes> archiv podle data 16:37 <jrandom> DoubtfulSalmon: skriptem? 16:37 <jrandom> cervantes: aha, jako malý kalendářový widget, místo odkazů „5 starších záznamů“? 16:38 <@cervantes> jo 16:38 <DoubtfulSalmon> jrandom: řekněme, že chci tímto souborem/textem nahradit tamten soubor/text. Jak to udělám? 16:38 <jrandom> ok, super, jo, to by mělo být opravdu snadné (když někdo spíchne ten HTML :) 16:38 <@cervantes> nebo jednoduše „zobrazit příspěvky z minulého měsíce“ 16:39 <@cervantes> jrandom: potřebuješ jen tabulku 7×6 s pár čísly ;-) 16:40 <jrandom> DoubtfulSalmon: měnit už publikovaný obsah je zajímavý směr. Obecně by to nefungovalo vždy, protože by to muselo fungovat jako řídicí zprávy Usenetu (zrušení starého příspěvku atd) 16:40 <jrandom> DoubtfulSalmon: na druhou stranu můžeš prostě zveřejnit nový soubor/záznam a změnit odkazy na levé straně, aby mířily na nový soubor/záznam 16:40 <jrandom> (tím zůstane starý obsah zachován, ale lidé jsou směrováni na nový) 16:41 <DoubtfulSalmon> jrandom: jo, nevadilo by, kdyby starý obsah zůstal, pokud by všechny odkazy ukazovaly na nový, aniž by museli měnit svůj obsah. 16:41 <jrandom> vybudovat z toho plnohodnotnou wiki, v podstatě posílat diffy a nechat Syndie vykreslovat výsledek, je možné, ale asi by to bylo overkill 16:41 <jrandom> hmm, OK, chápu, co myslíš 16:42 <jrandom> takže chceš možnost mít přesměrovatelné odkazy, místo stávajících odkazů na přesné verze obsahu 16:43 <jrandom> možná by to šlo tak, že by se odkazovalo na záložku blogu a přesná verze by se našla načtením aktuálních záložek toho blogu a zjištěním, kam ukazuje 16:44 <jrandom> na druhou stranu, nová verze by mohla být označena jako odpověď na starý příspěvek, takže když lidé následují odkaz, můžou se prokliknout na odpověď, která obsah nahrazuje 16:44 <jrandom> (i když to asi není tak hladké) 16:44 <DoubtfulSalmon> jo: řekněme, že chci mít odkaz třeba na aktuální radarový snímek, nebo něco takového, co se bude aktualizovat každých 10 minut. Nevadí, když se obsah nerozšíří po celé síti, ale když na mou stránku odkáže někdo jiný, uživatel by měl vidět aktuální obrázek. 16:45 <jrandom> no, to záleží na tom, co chtějí – chtějí odkazovat na obrázek tak, jak byl v době, kdy na něj odkazovali, nebo chtějí odkazovat na službu, která obrázek vyrenderuje při zobrazení čtenářem 16:45 <+Complication> cervantes: podivnost dne :D Poslední příspěvek v: http://forum.i2p/viewtopic.php?t=1199&start=15 16:46 <+Complication> Přišlo mi, že by to mohl být další z našich robotických vládců :P 16:46 <jrandom> ale je dobrý nápad podporovat oba koncepty a nemyslím, že by to byl velký problém 16:46 <@cervantes> díky 16:46 <jrandom> i když by to vyžadovalo malou rozšíření SML (např. [blog bloghash="ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=" bookmark="radar.webp"]) 16:47 * cervantes vylepší obranu fóra, pokud jich začne chodit hodně 16:47 <@cervantes> (tohle už vím, jak zastavit) 16:47 <DoubtfulSalmon> jrandom: měli by umět odkazovat jak na statickou verzi, pokud syndikátor obsah nesmazal, tak i na generické URL, které míří na poslední verzi 16:47 <jrandom> (které by se podívalo na aktuální meta post ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c= pro záložky a přesný URI by vytáhlo z té s názvem „radar.webp“) 16:48 <DoubtfulSalmon> jrandom: šlo by to teď udělat něčím jako: „Zobrazit nejnovější jeden příspěvek v tagu <divný řetězec>“ 16:48 <jrandom> aha, dobrý point – ano, šlo by to 16:49 <jrandom> to by se dalo dokonce omezit na „Zobrazit nejnovější příspěvek od $author s tagem $tag“ 16:49 <jrandom> (aby to druzí nemohli spoofnout) 16:49 <DoubtfulSalmon> tak možná jen dát nějaké UI, aby uživatel nemusel vidět divné tagy a podobně 16:50 <jrandom> nahoře je příklad, jak to vypadá, i když po ruce nemám URI... ale jo, je to odkaz kolem odkazovaného textu 16:50 <DoubtfulSalmon> Předpokládám, že všechny ty informace mohou přijít ve formě URL. 16:51 <jrandom> ale psát tohle ručně v SML je určitě komplikované, proto by se hodilo GUI na tvorbu SML 16:51 <jrandom> jsou to atributy na SML tagách, ne URL 16:52 <@cervantes> a SML GUI bude bez JavaScriptu ošemetné 16:52 <DoubtfulSalmon> ale můžeš si uložit záložku na výsledek hledání, že? 16:52 <jrandom> co je výsledek hledání? 16:52 <jrandom> a co myslíš záložkou? 16:52 <@cervantes> (nebo rozšíření pro prohlížeč ;-) ) 16:52 <jrandom> aha, záložky v prohlížeči, ano 16:52 <+Complication> Výsledek filtru? 16:53 <jrandom> ale tyhle záložky nejsou obecně sdíletelné 16:53 <DoubtfulSalmon> ehm: „získat nejnovější 1 příspěvek od X s tagem Y“ 16:53 <jrandom> (vlastně většina ano, ale není to univerzální, protože jsou to URL, ne URI)) 16:53 <DoubtfulSalmon> jo, bylo by dobré, kdyby na to mohly odkazovat i jiné blogy 16:54 <jrandom> DoubtfulSalmon: mohou, pomocí SML 16:54 <jrandom> [blog tag="Y" bloghash="X"] 16:54 <DoubtfulSalmon> no paráda 16:55 <jrandom> cervantes: JavaScript, nebo XUL, nebo Java, nebo nějaká jiná klientská aplikace specifická pro OS 16:57 <@cervantes> aha, super, takže ti nevadí závislost na skriptování nebo pluginu 16:57 <jrandom> (až se náš web předělá pro 0.6.2, Syndie určitě dostane web, který vysvětlí, co je sakra Syndie zač a jak umí všechno kromě mytí nádobí ;) 16:57 <@cervantes> (pokud to degraduje elegantně) 16:57 <jrandom> cervantes: Syndie by měla být funkční i s lynx, ale je spousta prostoru pro bohaté klienty 16:58 <jrandom> (s/function/functional/) 16:58 <@cervantes> správně... takže uživatelé lynxu by dostali referenční tahák SML, ale nic víc 16:58 <jrandom> ano, jako máme teď 16:58 <jrandom> i když možná zjednodušené SML, nevím. 17:01 <+Complication> jrandom: myslíš, že by byť vzdáleně bylo možné... že ten null bug souvisí s gzip kódováním? 17:01 <+Complication> Přemýšlel jsem, jak vypnout gzipping pro svůj eepsite tunnel... 17:01 <+Complication> Nebo je to úplně nepravděpodobné? 17:01 <@cervantes> těsně před Novým rokem se do i2ptunnel přidalo něco kolem http kompresoru 17:03 <jrandom> jo, může – můžeš to vypnout na klientské straně pomocí i2ptunnel.gzip=false (na /configadvanced.jsp). momentálně si ale nemyslím, že to můžeš vypnout v i2ptunnelhttpserver 17:03 <+zzz> je to na straně requestu, kde žádná komprese není 17:03 <+zzz> server nebude komprimovat, pokud to klient nastaví na false 17:03 <+Complication> zzz: aha, jasně, to jsem zapomněl 17:04 <jrandom> (ale bez velké námahy bys to mohl přidat do I2PTunnelHTTPServer [řádek 310, atd) 17:04 * Complication je hlupák a omlouvá se za to 17:04 <@cervantes> (nebo bys mohl použít normální tunnel) 17:04 <+Complication> Aha, díky... 17:05 <jrandom> hmm, ale ve chvíli, kdy i2ptunnelhttpserver dostane GET, ten null už tam je 17:05 <+zzz> jo, přesunul jsem oriona zpět na HTTP tunnel, což výrazně pomáhá s dobou načítání jeho stránek, protože se znovu komprimují 17:05 <+Complication> Nějak jsem úplně zapomněl, že gzipping začíná, když se na něm klient a server dohodnou 17:05 <jrandom> takže to může být na klientské straně, ale rozhodně ne na serverové 17:05 <jrandom> jo, zzz, teď je to šíleně rychlé :) 17:05 <+zzz> je to na straně _requestu_ ne na straně _response_ – může to být na straně klienta i serveru 17:06 <jrandom> pravda 17:09 <jrandom> ok, má ještě někdo něco k 3) Syndie blogům? 17:09 <jrandom> pokud ne, přejděme k 4) ??? 17:09 <jrandom> má ještě někdo něco, co by chtěl na schůzce probrat? 17:10 <cat-a-puss> Complication: Java gzip stream + I2P tunnely. NEfunguje a je to bug od Sunu 17:10 <jrandom> hmm, cat-a-puss? vážně? 17:10 <+zzz> Aktualizace HTTP persistent connections: klientská strana většinou hotová, serverová strana dobře postupuje, je třeba hodně zodolňování a testování, odhad dokončení 2–4 týdny 17:10 <jrandom> pěkné, zzz! 17:11 <cat-a-puss> jrandom: jo, mluvil jsem s tebou o tom už dávno, asi bych našel dlouhé vysvětlení proč, ale asi bude nejlepší to někde zdokumentovat, protože není důvod to dělat. 17:12 <jrandom> hmm, jsem mimo kontext, co přesně nefunguje? jaký je to bug od Sunu? 17:14 <dust> mám divné logy jako tohle: 21:21:59.816 WARN [%d0%a2%d1%4f] net.i2p.util.EepGet : ERR: status <html> 17:14 <jrandom> hmm, zajímavé 17:15 <jrandom> jaký tracker? 17:15 <cat-a-puss> jrandom: Jak si vzpomínám, Sun používá zipy bez hlaviček a nějaké magické číslo k rozpoznání, že je to zip stream. Ale to číslo zrovna vychází záporné, takže když z nějakého důvodu vytvoříš zip stream uvnitř zip streamu, čte data ze streamu jako sekvenci neoznačených bajtů a to magické číslo se tak převede na nějaké jiné kladné číslo. (nejspíš mi nějaký detail uniká, ale to je podstata) 17:16 <dust> například ten OSDevWithCVS_3E.pdf.torrent 17:17 <dust> d8:announce540:http://YRgrgTLGnbTq2aZOZDJQ... 17:17 <jrandom> hmm, o tom nic nevím a nejsem si jistý, jak by to ovlivnilo gzip stream přes i2ptunnel (kdyby to /tak bylo/, selhávaly by všechny, protože gzipujeme všechno) 17:19 <jrandom> ok super, duste, takže postmanův tracker. hmm, jedeš na 0.6.1.9, duste? 17:20 <cat-a-puss> jrandom: jo, je to skoro rok, co jsem měl ten problém, takže si to moc nepamatuju, a nevím, jestli je to opravené v 1.5, ale opravdu jsem se natrápil při zjišťování, proč každý normální typ streamu fungoval, ale jakmile jsem je obalil komprimovaným streamem, všechny selhaly. 17:20 <dust> ano 17:20 <jrandom> cat-a-puss: za poslední rok jsme dramaticky změnili věci kolem komprese přes I2P ;) 17:21 <jrandom> (a já osobně 1.5 nepoužívám) 17:21 <jrandom> ale děláme vlastní zip encoding explicitně, místo použití jejich zabaleného streamu (kvůli anonymitě/efektivitě, ne kompatibilitě) 17:22 <@cervantes> zzz: kde přesně v requestu ten null nastane? hned po GET? 17:22 <+Complication> Předtím, pokud si dobře pamatuju 17:23 <+fox> <lordalbert> hi 17:23 <+Complication> Pozn.: Celeron 300 ukazuje dvakrát nižší procento retransmisí než Sempron 17:23 <jrandom> čau, lordalberte 17:23 <jrandom> fajn, Complication, 2–3 % je rozumné (i když bych samozřejmě preferoval méně) 17:23 <@cervantes> bylo by zajímavé pustit spoustu HEAD requestů nebo tak něco... 17:24 <jrandom> jo, sada lokálních testů by byla skvělá, i když, pokud si dobře pamatuju (IIRC), to Complication zkoušel už dřív bez chyb 17:24 <+fox> <lordalbert> může někdo udělat anonymní tracker? Zkouším to, ale nerozumím, jak použít tunnel 17:24 <+Complication> cervantes: Jednou jsem se to snažil vyprovokovat, s rekurzivním wget mezi mými 2 uzly 17:24 <+Complication> Znudil jsem se dřív, než se to stalo 17:25 <@cervantes> heh 17:26 <+fox> <lordalbert> čau, b0unc3 ;) 17:26 <+fox> <b0unc3> lordalbert, :D 17:26 <+Complication> lordalbert: s kterou částí bys potřeboval poradit? 17:27 <+Complication> S nastavováním trackerů bohužel nepomohu. 17:27 <+Complication> S I2PTunnel bych se to pokusil vysvětlit... 17:27 <+fox> <lordalbert> Nainstaloval jsem BTtracker, a funguje perfektně 17:28 <+Complication> Je třeba poznamenat, že aby tracker zůstal anonymní, měl by běžet s dost opatrnou konfigurací 17:28 <+fox> <lordalbert> teď bych ho chtěl zanonimizovat 17:28 <+fox> <lordalbert> takže 17:28 <jrandom> Jsem si jist, že to po schůzce můžeme pomoci projít. neměl bys používat generické trackery, potřebuješ takový, který je postavený pro anonymitu 17:28 <+fox> <lordalbert> právě jsem udělal i2ptunnel 17:29 <jrandom> (např. úpravu bytemonsoon, kterou najdeš na kterémkoli I2P trackeru, nebo v CVS) 17:29 <+fox> <lordalbert> teď bych chtěl vědět, jak ten tunnel použít. Tunnel už jsem udělal 17:29 <jrandom> ok, má někdo ještě něco na schůzku? 17:30 <jrandom> lordalbert: http://localhost:7657/i2ptunnel/ by ti měl umožnit vytvořit „http server tunnel“ ukazující na tvůj webserver/tracker, ale tvůj tracker nebude fungovat, pokud nebude upraven pro anonymní použití 17:30 <+fox> <lordalbert> jrandom, jaký tracker mám použít? 17:31 <+Complication> postman používá upravenou verzi ByteMonsoon, myslím 17:32 <jrandom> i2p-bytemonsoon byl upraven pro anonymní použití - je tam zip @ http://i2p-bt.postman.i2p/, a je v CVS na http://dev.i2p.net/cgi-bin/cvsweb.cgi/bytemonsoon/ ale opravdu o tom moc nevím 17:32 <+fox> <lordalbert> není bytemonsoon zastaralý? 17:32 <jrandom> když to funguje, není to zastaralé. funguje to 17:33 <+fox> <lordalbert> ok XD 17:33 <jrandom> je spousta trackerů a kdyby je chtěl nějaký vývojář upravit, aby fungovaly bezpečně a anonymně, bylo by to skvělé 17:33 <+Complication> Může být klidně stařejší... ale rozhodně funguje s destkeys místo IP... 17:33 <+Complication> O bezpečnosti a těsnosti nic říct nemůžu 17:34 <jrandom> (bylo to upraveno duckem a spol. kvůli anonymitě a bezpečnosti) 17:34 <+Complication> Ale běží už nějakou dobu, a zdá se, že to zvládá... 17:35 <jrandom> ok, pokud už pro schůzku nic není... 17:36 * jrandom se balí 17:36 * jrandom *baf* uzavírá schůzku