Reunião de desenvolvimento do I2P - 25 de abril de 2005

16:12 <jrandom> 0) oi 16:12 <jrandom> 1) Status da rede e 0.6.1.17 16:12 <jrandom> 2) I2Phex 16:13 <jrandom> 3) ??? 16:13 <jrandom> 0) oi 16:13 * jrandom acena 16:13 <@cervantes> olá 16:13 <jrandom> notas semanais de status publicadas em @ http://dev.i2p.net/pipermail/i2p/2006-April/001283.html 16:14 <jrandom> enquanto vocês dão uma olhada por alto, vamos entrar em 1) Status da rede 16:14 <jrandom> então, como a maioria de vocês viu, temos um novo lançamento disponível e, até agora, os resultados têm sido bem positivos 16:15 <@cervantes> (oba!) 16:15 <jrandom> ainda não estamos onde precisamos estar, mas isso basicamente resolve os principais problemas que vínhamos vendo 16:15 <jrandom> sim, é bom ter novamente taxas de construção de tunnel razoáveis, em tunnels de 2+ hops :) 16:16 * jrandom tem taxas de sucesso de 50%+ em outro router com tunnels de 1 hop 16:17 <jrandom> acho que as últimas mudanças na 0.6.1.17 devem ajudar a evitar esse tipo de colapso por congestionamento no futuro também 16:17 <jrandom> o resultado visível para o usuário, porém, é que ocasionalmente veremos expirações de lease, mas, em vez de se agravar, ele fará backoff (redução gradual da taxa) 16:17 * cervantes abre o Azureus 16:18 <+Complication> Hoje de manhã, registrei taxas de sucesso de client tunnel (comprimento 2 +/- 1) perto de 35% 16:18 <+Complication> No momento está mais baixa, já que tentei fazer algumas modificações, e a última não foi lá essas coisas :D 16:18 <@cervantes> jrandom: bom trabalho em rastrear isso — estávamos começando a parecer o freenet por um momento :) 16:19 <jrandom> *cof* ;) 16:20 <+fox> <inkeystring> jrandom: você se importaria de descrever brevemente o mecanismo de backoff? estou trabalhando em algo assim para o freenet 0.7 no momento 16:21 <jrandom> inkeystring: temos um mecanismo de backoff na camada de transporte para reduzir transmissões a um peer (par) quando a camada de transporte está sobrecarregada, mas isso não foi suficiente 16:21 <@cervantes> *cof* eu disse freenet, quis dizer tor 16:21 <+fox> <inkeystring> :-) 16:22 <jrandom> inkeystring: a nova mudança foi propagar isso para um nível mais alto, de modo que parássemos de tentar construir tunnels quando nossa camada de comunicação estivesse saturada 16:22 <jrandom> (em vez de enviar mais tentativas de construção de tunnel) 16:22 <+fox> <inkeystring> obrigado — a camada de transporte só faz backoff quando pacotes se perdem, ou há alguma forma do receptor controlar o fluxo? 16:23 * jrandom lembra de discutir o impacto do congestionamento vs roteamento com o toad algumas vezes (no IRC e no meu antigo flog), embora eu não me lembre de nenhuma solução com resultado líquido positivo :/ 16:23 <jrandom> o receptor pode enviar NACK, e temos ganchos para ECN, mas não têm sido necessários 16:23 <+fox> <inkeystring> sim, o debate ressurgiu no freenet-dev :-) ainda sem bala de prata 16:24 <+fox> <inkeystring> legal, obrigado pela informação 16:24 <+Complication> Eles também estão usando UDP hoje em dia, não estão? 16:24 <jrandom> atualmente, os peers altamente congestionados têm problema não com limitação por peer, mas com a abrangência da comunicação com peers 16:24 <+Complication> (como protocolo de transporte) 16:24 <+fox> <inkeystring> abrangência = número de peers? 16:24 <jrandom> sim 16:25 <jrandom> com o aumento das taxas de sucesso de construção de tunnel, os peers não precisam mais falar com centenas de peers só para conseguir construir um tunnel 16:25 <jrandom> então eles conseguem se virar com apenas 20–30 peers 16:25 <jrandom> (peers conectados diretamente, isto é) 16:26 <+fox> <inkeystring> imagino que isso seja uma boa notícia para hole punching em NAT (técnica para atravessar NAT), keepalives (mensagens de manutenção) etc? 16:26 <jrandom> por outro lado, com 200–300 conexões SSU ativas, um link de 6 KBps vai ter problemas 16:26 <jrandom> sim 16:26 <+fox> <inkeystring> Complication: sim 16:27 <+fox> <inkeystring> (no alpha 0.7) 16:27 <+Complication> Aha, então provavelmente estão enfrentando coisas similares 16:27 <+Complication> Espero que alguém encontre a bala mágica :D 16:27 <jrandom> de um jeito diferente, porém. a camada de transporte é um problema relativamente fácil 16:27 <+fox> <inkeystring> acho que eles podem ter reutilizado algum código do SSU... ou ao menos falaram sobre isso 16:27 <jrandom> (ou seja, bem estudada há mais de 30 anos) 16:28 <jrandom> mas o balanceamento de carga do i2p (e do freenet) funciona em um nível mais alto do que os links ponto a ponto e tem requisitos diferentes 16:28 <+fox> <inkeystring> sim, é a interação com o roteamento que é complicada 16:29 <jrandom> sim, embora o i2p tenha isso mais fácil (não precisamos encontrar peers específicos com os dados em questão, apenas qualquer um com capacidade para participar dos nossos tunnels) 16:30 <+fox> <inkeystring> então não há perda de eficiência se você evitar um peer sobrecarregado... 16:30 <+fox> <inkeystring> enquanto no freenet, rotear em torno de um peer sobrecarregado pode aumentar o comprimento do caminho 16:30 <+fox> <inkeystring> enfim, desculpe o OT 16:31 <jrandom> sem problema, embora explicar por que as mudanças em 0.6.1.17 afetam nosso colapso por congestionamento fosse relevante :) 16:31 <jrandom> ok, mais alguém tem algo para 1) Status da rede? 16:32 <+Complication> Bem, como mencionei antes, rodando puro .17, observei uma periodicidade perceptível na largura de banda e nos peers ativos 16:32 <+Complication> E mais algumas pessoas parecem experimentar isso também, embora eu não faça ideia de quão comum isso é 16:33 <+Complication> Tenho pensado sobre suas causas primárias, principalmente da perspectiva da limitação de tunnel, mas ainda sem solução 16:33 <+Complication> Consegui deixar meus próprios gráficos mais planos, mas apenas ao custo de alguma deterioração geral 16:33 <+Complication> Tentei modificações como: 16:34 <+Complication>> _log.error("Allowed was " + allowed + ", but we were overloaded, so ended up allowing " + Math.min(allowed,1)); 16:34 <+Complication> (isso foi para evitar que ele se abstivesse totalmente de tentativas de construção para seus próprios tunnels) 16:35 <jrandom> ah certo 16:35 <+Complication> (ah, e naturalmente o nível de log está bagunçado, já que eu mudei isso para testes) 16:35 <jrandom> temos algum código ali que tenta enviesar a periodicidade um pouco, mas não está funcionando muito bem (obviamente) 16:36 * perv acabou de detonar o sistema :( 16:36 <+Complication> Mas tentei coisas assim e tentei reduzir o fator de crescimento para contagem de tunnels 16:36 <perv> existe um undelete para reiser4? 16:36 <jrandom> basicamente, se simplesmente agirmos como se os tunnels expirassem (aleatoriamente) mais cedo do que realmente expiram, isso deve ajudar 16:36 <+Complication> Atualmente lendo a grande função "countHowManyToBuild" no TunnelPool.java :D 16:36 <+Complication> Mas ainda não a li toda 16:37 <jrandom> (embora isso obviamente aumente a frequência de construção de tunnel, o que, antes da 0.6.1.17, não teria sido razoável) 16:37 <+Complication> perv: existe algo 16:37 <jrandom> hmm, colocar uma aleatorização ali seria difícil, Complication, já que chamamos essa função com bastante frequência 16:38 * perv considera salvar e mudar para gentoo 16:38 <jrandom> o que eu recomendaria seria olhar para aleatorizar o tempo de expiração de tunnels construídos com sucesso 16:38 <+Complication> perv: você está melhor com reiser do que com ext3, com certeza 16:38 <+Complication> perv: mas eu não sei de cor 16:38 <+Complication> jrandom: verdade, às vezes isso pode construir demais desse jeito 16:38 <jrandom> (para que o countHowManyToBuild existente ache que precisa deles antes de realmente precisar) 16:38 <+Complication> (e às vezes inevitavelmente constrói demais, quando os tunnels quebram e ele fica apressado) 16:40 <+Complication> Hmm, uma possibilidade que eu não tinha considerado... 16:41 <+Complication> De todo modo, também estou brincando com isso, mas ainda sem observações úteis 16:42 <jrandom> legal, tenho alguns ajustes com que venho brincando nisso, talvez possamos juntar isso para o próximo build e ver como funciona na rede razoavelmente viável ;) 16:43 <spinky> Existe alguma estatística em que se possa ver a quantidade de overhead que a rede i2p adiciona aos dados da aplicação? 16:43 <jrandom> "overhead" é um termo tão carregado... ;) 16:43 <jrandom> nós chamamos isso de custo do anonimato ;) 16:43 <spinky> hehe 16:45 <jrandom> (ou seja, não muito. a carga útil da camada de aplicação em uma rede perfeita com 0 congestionamento e 1+1 saltos consegue algo como 70–80% de eficiência para os endpoints) 16:45 <jrandom> ((da última vez que medi)) 16:45 <jrandom> mas isso são condições de laboratório 16:45 <jrandom> a rede real é muito mais complicada 16:47 <spinky> Certo, eu quis dizer apenas a quantidade de dados extras usados para configurar tunnels, chaves, padding etc 16:47 <spinky> ...comparado aos dados da aplicação transferidos 16:47 <jrandom> depende do framing da mensagem, congestionamento, taxas de sucesso de construção de tunnel, etc. 16:48 <jrandom> um tunnel de 2 hops pode ser construído com a rede arcando com 20KB 16:48 <+Complication> Eu quis testar isso às vezes, principalmente com o objetivo de estimar o "desperdício" de aplicativos de transferência em massa como BitTorrent e I2Phex 16:48 <+Complication> Mas nunca cheguei a fazer uma medição limpa entre meus dois nós 16:48 <+Complication> Algum dia, vou voltar a isso, porém 16:49 <jrandom> Complication: é bem difícil com apps tagarelas, muito mais simples medir wget :) 16:49 <+Complication> Muito verdade 16:50 <+Complication> No que consegui tentar, nenhuma semelhança com precisão esteve envolvida 16:54 <jrandom> ok, se não há mais nada no 1), vamos passar para 2) I2Phex 16:55 <jrandom> Complication: o que você anda fazendo? :) 16:55 <+Complication> Bem, o commit de ontem foi uma correção para certos problemas que algumas pessoas experimentaram com meu detector de primeira execução bobo 16:56 <+Complication> O detector de primeira execução agora está menos bobo, e o bar relatou que pareceu começar a se comportar normalmente 16:56 <+Complication> No entanto, como o I2Phex parece executável já nas condições atuais da rede, 16:56 <+Complication> Vou tentar encontrar o bug do rehash também. 16:57 <+Complication> Se eu conseguir 16:57 <jrandom> legal, sei que isso tem te assombrado há meses 16:57 <+Complication> O interessante é que o Phex principal também pode tê-lo, e localizar + ler as observações deles é algo que vou tentar fazer também 16:58 <jrandom> mas é bom saber que a correção de inicialização está lá 16:58 <jrandom> ah sim 16:58 <+Complication> =é isso 16:58 <+Complication> Não posso confirmar no momento se o Phex principal tem isso ou não — nunca vi pessoalmente lá 16:59 <jrandom> (bugs intermitentes)-- 16:59 <+Complication> É difícil causar de forma controlada e, portanto, difícil de encontrar 17:00 <+Complication> E da minha parte, é basicamente isso por enquanto 17:00 <+Complication> Mais adiante, eu estava pensando se valeria a pena limitar o número de tentativas paralelas de contato a peers que o I2Phex dispara de uma vez 17:01 <jrandom> sim, provavelmente 17:01 <+Complication> Como criariam um monte de consultas ao NetDB em um curto período de tempo, e isso poderia ser potencialmente não muito legal sob a perspectiva de um I2P router 17:02 <jrandom> e novos contatos de destination exigem elG em vez de aes 17:02 <+Complication> Mas ainda não li nem escrevi qualquer código real com esse objetivo 17:04 <jrandom> blz, sem problema. talvez a mítica fusão i2phex/phex traga uma solução :) 17:04 <+Complication> E da minha parte, são basicamente essas as notícias da frente do I2Phex... 17:04 <jrandom> legal, obrigado pela atualização e pelo esforço de investigar as coisas! 17:05 <jrandom> ok, vamos pular para 3) ??? 17:05 <jrandom> alguém tem mais alguma coisa para trazer para a reunião? 17:05 <lsmith> olá! só quero parabenizar os devs pelas melhorias fantásticas na última versão, meu bw total indica 0,9/1,4 KBps e continuo conectado ao IRC... é... insanamente legal :) 17:05 <+Complication> :D 17:06 <jrandom> obrigado pela paciência ao longo do caminho — dar suporte a usuários com bw baixo é fundamental 17:06 <@cervantes> lsmith: isso é muito bom pra 17:06 <@cervantes> * Connection Reset 17:06 <jrandom> heh 17:07 <lsmith> :) 17:09 <jrandom> ah, outra coisa digna de nota é que o zzz está de volta e, com ele, vem o stats.i2p :) 17:09 <jrandom> [wewt] 17:11 <+Complication> Uma fonte de dados de comparação bastante útil :) 17:11 <jrandom> com certeza 17:11 <jrandom> ok, alguém tem mais algo para a reunião? 17:13 <jrandom> se não... 17:13 <jdot> tenho uma ou duas perguntas pós-baf 17:13 <jrandom> heh ok, então vamos pôr o baffer pra rodar :) 17:13 * jrandom se prepara... 17:13 * jrandom encerra a reunião com um *baf*