Reunião de desenvolvedores do I2P - 16 de novembro de 2004

13:05 <jrandom> 0) oi 13:05 <jrandom> 1) Congestionamento 13:05 <+dinoman> a chave do pgforge mudou :/ desculpa 13:05 <jrandom> 3) BT 13:05 <jrandom> 4) ??? 13:05 <jrandom> ah legal, podemos fazer um pouco de mágica para isso 13:05 <jrandom> 0) oi 13:05 * jrandom acena 13:05 <ant> <lucky> oi 13:05 <jrandom> notas semanais de status no ar em @ http://dev.i2p.net/pipermail/i2p/2004-November/000489.html 13:05 <wiht> Olá. 13:06 <jrandom> (e postamos as notas *antes* da reunião. w00t) 13:06 <jrandom> vamos entrar logo em 1) Congestionamento 13:07 <jrandom> para quem tem ficado no canal nos últimos dias, vocês ouviram muitas discussões sobre que diabos tem acontecido, e tanto este email quanto o post do duck mais cedo devem cobrir isso em geral 13:07 <jrandom> dito isso, alguém tem perguntas / comentários / preocupações que gostaria de levantar/discutir? 13:09 <wiht> O que você quer dizer com "seleção de pares selvagem"? 13:10 <jrandom> a maneira como a nossa construção de tunnel atual funciona infelizmente faz as coisas se estabilizarem em torno dos pares rápidos 13:10 <jrandom> se esses pares rápidos não falham ocasionalmente, simplesmente os usamos, ponto, em vez de explorar além deles na nossa construção de tunnel 13:11 <jrandom> isso significa que, quando eles *de fato* falham mais tarde, praticamente não fazemos ideia de quanta capacidade o resto da rede tem e, assim, escolhemos pares de forma bastante arbitrária 13:11 <+DrWoo> jrandom: o que está no pipeline para usar melhor a capacidade? 13:12 <jrandom> DrWoo: a versão 0.4.3 incluirá uma nova forma de agrupar tunnels para que possamos ter mais tunnels de backup 'experimentais' (permitindo aprender mais sobre a rede sem sacrificar o desempenho) 13:13 <jrandom> um balanceamento de carga mais agressivo por meio de reservas no estilo ATM também está no pipeline, mas ainda não está planejado para uma versão específica (vulgo faremos quando for preciso) 13:14 <ant> <Connelly> bleh 13:14 <ant> <Connelly> a reunião ainda não começou? 13:14 <jrandom> (reservas no estilo ATM, ou seja, acompanhar quanta largura de banda os tunnels usam, em média, multiplicar isso pelo número de tunnels dos quais participamos e comparar com nossos limites/capacidade de largura de banda, usando essa comparação para aceitar/rejeitar novos pedidos de tunnel) 13:15 <jrandom> Connelly: começou há 10 min, notas de status postadas na lista ;) 13:15 <+DrWoo> jrandom: que impacto isso terá no desempenho? 13:15 <+DrWoo> desempenho do PC local 13:15 * wiht se pergunta quantos protocolos diferentes estão sendo usados na rede I2P além de HTTP, IRC e BT. 13:16 <jrandom> DrWoo: o pooling da 0.4.3 vai nos dar maior resiliência (menos falhas), e as reservas permitirão mais compartilhamento de carga baseado em capacidade (vulgo reduzir a contenção) 13:16 <jrandom> nenhuma dessas coisas é particularmente baseada em latência, porém 13:17 <jrandom> wiht: esses três são os principais usados, até onde sei, embora algumas coisas feias sejam feitas sobre HTTP 13:17 <jrandom> isso na verdade é uma questão interessante, com relação a irc e congestionamento 13:18 <jrandom> o que realmente estava matando o irc.duck.i2p outro dia foi o fato de que, durante o congestionamento, o servidor de irc do duck ainda tinha que bombear 20x o número de mensagens que recebia 13:19 <jrandom> some a isso o reenvio automático de mensagens a.cada.10.segundos.sem.recuo, e isso cresce para 120 mensagens para cada linha de texto ;) 13:19 <jrandom> basicamente, o que estou dizendo é que um protocolo de chat descentralizado seria Bom ;) 13:19 <+DrWoo> existe tal bicho? 13:20 <jrandom> (embora a nova streaming lib vá se livrar desse overhead de 6x) 13:20 <+dinoman> há algum bom 13:20 <jrandom> não sei se alguém avaliou algo à la SILC para i2p no último ano 13:20 <susi23> pop3 e smtp são _terrivelmente_ lentos no i2p 13:21 <ant> <duck> silc == irc+alguma cripto 13:21 <susi23> (como resposta à pergunta, quais protocolos também são usados) 13:21 <jrandom> ah, eu achava que o silc tinha se afastado do conceito de ircd 13:21 <jrandom> ah, merda, verdade, esqueci desses dois :) 13:21 <wiht> susi23: Sim, eu esqueci que temos correio no I2P agora. 13:21 <ant> <duck> não muito, pelo menos 13:21 <jrandom> 'k 13:21 <ant> <protok0l> reunião? 13:22 <ant> <lucky> agora mesmo, protok0l 13:22 <ant> <protok0l> k 13:22 <jrandom> ok, temos mais algo para 1) congestionamento? 13:23 <jrandom> se não, seguindo para 2) streaming 13:23 <jrandom> [vejam o email] 13:24 <jrandom> mantive todas as atualizações da streaming lib fora do history.txt, mas você pode acompanhar o que está acontecendo pela lista do cvs 13:24 <jrandom> (se você for maluco) 13:24 <jrandom> não tenho realmente mais nada a acrescentar. então, alguma pergunta/comentário/preocupação? 13:25 <+postman> só uma 13:25 <+postman> obrigado :) 13:25 <ant> <protok0l> que aumento de velocidade haverá 13:25 <jrandom> hehe era para você esperar até receber o software, postman ;) 13:25 <jrandom> protokol: algum. varia. 13:25 <+postman> jrandom: eu apostaria em você de olhos vendados 13:26 <+DrWoo> jrandom: Vou perguntar o que você odeia: há um ETA para a nova streaming lib? A situação atual obviamente é um ponto de vulnerabilidade? 13:27 <jrandom> se os testes desta semana forem bem, podemos marcar para a próxima 13:27 <jrandom> haverá serviços no ar e rodando na nova streaming lib antes disso, para que possamos testá-la sob carga 13:28 <wiht> Pelo que me lembro, você está usando uma rede simulada para os testes. Ainda é verdade? 13:29 <jrandom> para alguns deles, sim 13:29 <jrandom> quando não uso a simulação, simplesmente rodo na rede real 13:30 <jrandom> (porque eu gosto de abusar da sua largura de banda ;) 13:30 <susi23> de nada ;) 13:30 <+dinoman> hehe ligar e ver se explode? 13:31 -!- x agora é conhecido como fidd 13:31 <jrandom> basicamente - eu tenho algum código de logging que essencialmente despeja os cabeçalhos dos pacotes de streaming, permitindo que eu garanta que tudo é enviado corretamente e que várias situações são tratadas como deveriam 13:32 <jrandom> os testes simulados são mais elaborados, com talvez meia dúzia de testes unitários com vários parâmetros de execução 13:33 <wiht> Quão bem os testes de simulação refletem o uso observado da rede? 13:33 <jrandom> muito bem, já que o código da simulação é o mesmo do código da rede real 13:34 <jrandom> eu não tenho a injeção de latência e perdas perfeita na simulação, porém está na média 13:35 <ant> <cat-a-puss> a nova streaming lib usará a mesma interface? Ou apps Java terão que fazer algo novo? 13:35 <wiht> Obrigado por esclarecer. 13:36 <jrandom> cat-a-puss: mesma interface. há algumas opções de config adicionais que você pode querer acrescentar ao construir um I2PSocketManager, mas isso é um bom e velho mapa de propriedades 13:36 <ant> <cat-a-puss> k 13:37 <jrandom> k, mais alguma coisa, ou vamos pular para 3) BT? 13:38 <jrandom> duck: ping 13:38 <@duck> *quack 13:38 <@duck> Na semana passada eu relatei que tínhamos BitTorrent funcionando no I2P. Houve alguma 13:38 <@duck> confusão, mas é anônimo tanto para os trackers quanto para os clientes (seeders e leechers). 13:38 <@duck> Atualizações desde a semana passada: 13:38 <@duck> Trabalho na GUI (wxPython), tracker incluído, correções de bugs. 13:39 <@duck> lista completa em http://dev.i2p/cgi-bin/cvsweb.cgi/~checkout~/i2p-bt/CHANGES.txt?rev=HEAD 13:39 <@duck> o código também está no CVS em cvs.i2p 13:39 <@duck> e ganhou um eepsite dedicado: http://duck.i2p/i2p-bt/ 13:39 <@duck> O tracker incluído é bem espartano e você ainda precisa disponibilizar os 13:39 <@duck> próprios torrents em algum lugar; então o DrWoo, o thetower e eu temos analisado 13:39 <@duck> várias alternativas que oferecem recursos como o suprnova, até eu ficar maluco. 13:39 <@duck> *flierp* 13:40 <jrandom> w00t 13:40 <@duck> Finalmente o bytemonsoon foi selecionado, o original é feio, mas o DrWoo tem consertado isso, 13:40 <@duck> A ideia é melhorá-lo mais um pouco e lançá-lo como uma solução de tracker pronta para I2P, 13:40 <@duck> veja: http://brittanyworld.i2p/bittorrent/ 13:40 <@duck> atendendo aos requisitos em: http://duck.i2p/i2p-bt/txt/bytemonsoon.txt 13:40 <@duck> . 13:40 <jrandom> foda 13:40 <+DrWoo> vocês podem conferir alguns arquivos pequenos de teste no bom tracker que o duck arrumou 13:41 <+DrWoo> não tem nada grande para emperrar a rede heh 13:41 <jrandom> quê, você não quer que a gente baixe mais episódios de Lost? :) 13:41 <@duck> se o do thetower estiver no ar.. 13:42 <jrandom> a port do bytemonsoon está ficando muito boa. 13:42 <+DrWoo> não consigo acessar o thetower agora aqui 13:42 <+DrWoo> jrandom: parece realmente fornecer quase tudo de que você precisa 13:42 <+dinoman> que tipo de velocidade o pessoal está vendo? 13:43 <@duck> ~5kb/s por par 13:43 <+DrWoo> dino: daqui parece 4-10K por par 13:43 <@duck> (otimista, claro que tem aquela galera de adsl porcaria) 13:44 <+dinoman> uau, melhor do que eu pensei 13:44 <@duck> até o i2p cair; veja 1) 13:44 <jrandom> heh 13:44 <+DrWoo> dinoman: em outras palavras, deve ficar bem impressionante com um enxame 13:44 <@duck> houve vários pedidos para melhorar a GUI 13:45 <+DrWoo> dinoman: e alguns pares de 0 hop ;) 13:45 <@duck> mas não muitos se ofereceram para isso 13:45 <jrandom> duck (& gang): o que podemos fazer para ajudar? 13:45 <@duck> você: deixe a nova streaming lib pronta 13:46 <@duck> galera: olhem o todo: http://duck.i2p/i2p-bt/txt/todo.txt 13:46 <@duck> lucky está trabalhando em um howto 13:47 <@duck> DrWoo: mais alguma coisa? 13:47 <jrandom> nice 13:47 <+DrWoo> jrandom: você pode falar um pouco sobre como você vê a importância (ou não) do compartilhamento de arquivos (e outros serviços populares atualmente executados na internet) e o que isso significa para as perspectivas de anonimato do I2P. 13:47 <ant> <lucky> eu estou? 13:48 <ant> <lucky> ah 13:48 <ant> <lucky> eu estou 13:48 <ant> <lucky> :) 13:48 <+DrWoo> duck: sempre tem mais alguma coisa heh 13:48 <jrandom> o compartilhamento de arquivos é crítico para o sucesso do I2P, pois é, realisticamente, o maior conjunto potencial de usuários para se misturarem ao nosso conjunto de anonimato 13:49 <ant> <lucky> vish. 13:49 <ant> <lucky> Então isso significa que eu deveria mesmo, mesmo, trabalhar naquele howto. 13:49 <jrandom> sem um sistema viável de transferência de arquivos grandes, teremos que fazer alguns milagres para engajar apps de usuário 13:50 <jrandom> o que estamos fazendo - o trabalho da susi e do postman é bastante promissor 13:50 <jrandom> mas o mercado para email anônimo é muito menor do que o mercado para transferência segura de arquivos 13:51 <jrandom> embora o próprio I2P escale para qualquer tamanho (se as coisas forem como esperamos ;), precisamos de um grande conjunto de anonimato para sustentar qualquer coisa que valha a pena 13:51 <jrandom> </my $0.02> 13:52 <@duck> o que você acha das configurações padrão para esses apps de compartilhamento de arquivos? 13:52 <jrandom> isso eu não sei 13:53 <@duck> ou isso ainda não é realmente relevante dadas as possibilidades atuais 13:54 <+DrWoo> duck: pode ser necessário um pouco de 'pensar fora da caixa' para superar alguns obstáculos pelo caminho? 13:54 <jrandom> tunnels de 1 hop podem ser relevantes para o pessoal do BT, antes da 0.4.3 13:57 <jrandom> ok, temos mais algo para 3) BT? 13:57 <@duck> não eu 13:57 <+DrWoo> obrigado ao duck e à galera 13:58 <+DrWoo> foi um trabalho bem foda 13:58 <jrandom> pois é, vocês estão fazendo um trabalho foda 13:58 <+dinoman> eu não fiz isso 13:58 <jrandom> (eu adoro ver o --spew 1 no btdownloadheadless :) 13:58 <@duck> dinoman: você começou 13:58 <+Ragnarok> spew sem cabeça... parece sujo 13:59 <+DrWoo> dino: impulsionar o esforço é uma contribuição real 13:59 * Ragnarok vai preparar um patch para as opções de linha de comando da lista de todo 13:59 <jrandom> w00t 14:00 <ant> <dm> Não esqueça o WWW anônimo, isso também é grande. 14:00 <jrandom> dm: sim, talvez milhares ou dezenas de milhares, mas não atrai milhões 14:01 <jrandom> (para coisas de outproxy, imho) 14:01 <jrandom> ok, se não há mais nada, passando para o bom e velho 4) ??? 14:01 <jrandom> algo que ainda não foi levantado e deveria ser? 14:02 <wiht> postman: Qual é o status do sistema de correio? Quão bem está funcionando, especialmente com relação às comunicações fora da rede I2P? 14:02 <+DrWoo> dm: isso tudo faz parte do rico espetáculo da vida :) 14:03 <ant> <dm> muita gente usa a web 14:03 <ant> <dm> (acabaram de instalar surfcontrol no meu trabalho) ;) 14:03 <jrandom> sim, a hospedagem www anônima será crítica para quem realmente precisa de i2p, embora provavelmente não serão o conjunto de anonimato necessário 14:03 <jrandom> ah, que chato 14:04 <jrandom> wiht: se ele não estiver por aqui, posso dizer que in e outproxy têm funcionado muito bem para mim - nenhum perdido até agora 14:04 <jrandom> (e verificar meu correio leva alguns segundos, mas o biff me avisa quando eu preciso de qualquer forma) 14:05 <jrandom> ok, mais alguma coisa? 14:06 <ant> <dm> você está 'bafando' a reunião? 14:07 <jrandom> parece que sim 14:07 * jrandom se prepara 14:07 * jrandom *baf* encerra a reunião