Setkání vývojářů I2P - 5. září 2017

20:00:00 <zzz> 0) Ahoj 20:00:00 <zzz> 1) aktualizace 0.9.32 (zzz) 20:00:00 <zzz> 2) připomenutí e-mailu k financování 34C3 (zzz/echelon) 20:00:03 <zzz> 0) Ahoj 20:00:05 <zzz> Ahoj 20:00:44 <zzz> 1) aktualizace 0.9.32 (zzz) 20:00:58 <R4SAS> Ahoj 20:01:09 <zzz> ok, str4d udělal pár aktualizací UI a já jsem začal s implementací prop 141, ale zatím jsem nic nepřidal 20:01:37 <zzz> jsme na dobré cestě k vydání na začátku října 20:01:49 <i2pr> [Slack/str4d] Ahoj 20:02:03 <zzz> Myslím, že str4d chce udělat prop své benchmark větve, měl by to udělat brzy? Komentoval jsem to v jeho ticketu 20:02:20 <psi_> jo 20:02:36 <i2pr> [Slack/str4d] Zatím jsem pushnul jen drobnou úpravu UI; mám lokálně víc, co řeší řadu dalších problémů, ale musím projít svým procesem git -> mtn 20:03:09 <i2pr> [Slack/str4d] Podívám se na komentáře k benchmarku a dodělám / pushnu to koncem tohoto týdne 20:03:57 <zzz> ok, někdy s tebou potřebuji probrat náš proces vydání. U .31 jsme měli blocker tickety, které nebyly uzavřené, asi bychom měli trvat na tom, aby se uzavřely před vydáním 20:04:08 <zzz> jinak co potom vůbec znamená 'blocker' 20:04:23 <i2pr> [Slack/str4d] Správně 20:04:36 <zzz> ještě něco k 1) ? 20:06:01 <zzz> 2) připomenutí e-mailu k financování 34C3 (zzz/echelon) 20:06:11 <psi> vyžaduje toto vydání odstranění hostnames? 20:06:15 <psi> v RI 20:06:25 <psi> ach, lag 20:06:33 <zzz> podívej se na text návrhu kvůli diskusi o migraci 20:06:45 <psi> kk 20:07:07 <i2pr> [Slack/str4d] -1 k tomu, aby to bylo v tomto vydání bez diskuse o mitigacích zombie 20:07:08 <zzz> ok, co se týče 34C3: pokud chcete financování nebo volnou vstupenku, MUSÍTE do 30. září poslat e-mail echelonovi 20:07:43 <zzz> mimochodem měl echelon nějaké problémy se serverem, takže pokud jste od něj nedostali ACK, že váš e-mail dostal, pošlete ho znovu 20:08:46 <zzz> máme k dispozici spoustu prostředků pro zájemce, ale musíte si o ně říct. Nebudeme financovat lidi, kteří požádají po konci měsíce 20:09:48 <zzz> takže znovu: ujistěte se, že echelon potvrdil přijetí vaší žádosti 20:10:03 <zzz> rozpočet stanovíme na příští měsíční schůzce 20:10:19 <zzz> ještě něco k 2) ? 20:10:36 <i2pr> [Slack/str4d] Za mě ne. 20:11:26 <zzz> něco dalšího k této schůzce? 20:11:54 <psi> něco mám 20:12:02 <zzz> psi, povídej 20:12:03 <psi> ale je to dlouhé a úmorné 20:12:09 <psi> je to ten nápad na zarovnané odchozí tunnels 20:12:36 <psi> původně jsem ti to prezentoval jako techniku na snížení zátěže OBEP 20:12:45 <psi> to je pěkný vedlejší efekt 20:12:53 <psi> ale to nebyl původní záměr 20:13:10 <psi> původní záměr byl snížit ztrátovost paketů 20:13:59 <zzz> ok, co bys o tom chtěl probrat? 20:14:08 <psi> moje otázka je: implementovalo by java i2p aligned outbound tunels ? 20:14:22 <psi> nebo je to pro vás příliš experimentální? 20:14:53 <psi> nejsem s kódem java i2p tak obeznámen jako s kódem i2pd 20:14:57 <zzz> teď nemůžu odpovědět, protože jsem zapomněl detaily. Pokud to sepíšeš a někam to dáš, rád ti dám odpověď 20:15:09 <psi> dobře 20:15:15 <psi> myslím, že můžeš schůzku ukončit 20:15:26 <psi> nápad je OBEP == IBGW 20:15:35 <psi> s jedním extra hopem na OB tunnel 20:15:38 <eche|offf> zatím ode mě nic 20:15:43 <psi> takže OBEP == IBGW 20:16:14 <psi> aby se snížila ztrátovost paketů a tlak na OBEP 20:16:30 <psi> (za cenu více tunnels) 20:16:51 <zzz> ok, když už jsi to implementoval, jakákoli data o přínosech by byla velmi užitečná 20:17:10 <zzz> ještě něco k zarovnaným odchozím tunnels? 20:17:31 <psi> moje počáteční pozorování jsou, že počáteční RTT je stejné jako později 20:17:44 <psi> resp. není tam počáteční špička RTT 20:17:57 <psi> možná kvůli uvolnění tlaku na OBEP 20:18:03 <psi> ale to je jen domněnka 20:18:15 <psi> chci to otestovat na testnetu, který máme s Dockerem. 20:18:25 <i2pr> [Slack/str4d] Pokud z toho můžeme udělat performance benchmark, dej mi vědět 20:18:25 <psi> abychom nasbírali tvrdá čísla atd 20:19:01 <psi> jo, stejně i já, nemám dobrý perf benchmark 20:19:18 <psi> používal jsem icmp ping přes openvpn 20:19:23 <i2pr> [Slack/str4d] Vlastně by to bylo spíš metrika, protože by to záviselo i na výkonu sítě a pravděpodobně by se to lišilo podle umístění endpointů 20:19:27 <psi> asi to není nejlepší způsob 20:19:48 <i2pr> [Slack/str4d] Ale pokud z toho *můžeme* udělat opakovatelný benchmark, chtěl bych ho přidat do sady, kterou plánuji začít sbírat 20:20:18 <psi> co teď používám, je čas připojení přes dtls a pak následné měření latence přes ping 20:20:31 <psi> to podle mě není přenositelné pro java i2p 20:20:45 <psi> ledaže by fungovalo socks5 udp 20:20:49 <psi> nebo udělám nějaké SAM věci 20:21:23 <zzz> ještě něco k zarovnaným odchozím tunnels? 20:21:31 <psi> aligned outbound tunnels jsou zatím experimentální a nevím, jestli zvýšený počet tunnels za to stojí, nebo ne 20:21:49 <psi> takže je potřeba víc výzkumu a právě se to zkoumá u i2pd 20:21:56 <psi> dám vědět 20:22:12 <i2pr> [Slack/str4d] Skvělé, průběžně mě informuj o vědě v #i2p-science :slightly_smiling_face: 20:22:20 <psi> kk 20:22:21 <zzz> skvělé, díky za update, psi 20:22:25 <zzz> ještě něco k zarovnaným odchozím tunnels? 20:22:53 <psi> ještě poslední věc: možná by stálo za to udělat něco navíc k zarovnávání tunnels, tj. něco jako tor's rend spec 20:23:17 <psi> co to je, nevím, a budu o tom nahlas přemýšlet v #i2p-science 20:23:20 <psi> (přidejte se prosím) 20:23:29 <psi> to je vše 20:23:41 <i2pr> [Slack/str4d] Za mě vše 20:23:49 <zzz> něco dalšího k této schůzce? 20:24:28 <psi> já jsem v pohodě 20:25:15 <zzz> díky všem, uvidíme se za 4 týdny, což bude čas vydání .32 20:26:10 * zzz ***bafffs*** dokončuje schůzku