Reunião de desenvolvedores do I2P - 16 de maio de 2006

<cervantes> moo: http://dev.i2p.net/pipermail/i2p/2006-May/001289.html <cervantes> 0) oi <cervantes> 1) jrandom não está aqui <cervantes> 2) ??? <cervantes> 0) oi <cervantes> oi <cervantes> passando para o 1) <cervantes> jrandom não está aqui hoje, mas ele nos dará uma atualização de status amanhã <cervantes> 2) ??? <cervantes> alguém tem mais algo para acrescentar à reunião? <bar> eu tenho uma pergunta <cervantes> nesse caso... * cervantes se prepara * cervantes para de se preparar <Complication> Aha, uma pergunta... <bar> a correção no PRNG no cvs, isso vai melhorar o desempenho geral ou está relacionado a outra coisa? <cervantes> é incerto quais consequências isso pode ter em geral <Complication> pessoalmente não conheço o impacto total, mas envolve pelo menos dois comportamentos dos quais tenho conhecimento: <cervantes> mas corrige especificamente um sintoma no i2ptunnel * cervantes deixa o complication descomplicar <Complication> randomização do comprimento do tunnel e escolha do servidor IRC (mais genericamente, seleção aleatória a partir de uma lista de destinos I2PTunnel) <Complication> A randomização do comprimento do tunnel provavelmente tem um efeito significativo na saúde geral da rede, pois permite que clientes autorizados a fazer concessões no comprimento do tunnel realmente o façam <Complication> Assim, eles não ficarão prendendo a respiração e construindo tunnels de 2 saltos, mas também tentarão alguns tunnels de 1 salto <Complication> (que, em tempos difíceis, são muito mais fáceis de conseguir) <cervantes> além disso, a conectividade IRC pode melhorar quando isso for implementado. Basicamente, o freshcoffee nunca recebia conexões de clientes porque estava em segundo na lista — então, com a próxima versão, a carga deve ser distribuída uniformemente entre ambos os servidores <bar> então o bug fazia as pessoas sempre escolherem comprimentos de tunnel maiores quando disponíveis? <Complication> Se eu entendi direito, toda randomização com inteiros pequenos (por exemplo, escolher 0 ou 1) foi afetada <Complication> Eu *acho* que randomizações com inteiros maiores (por exemplo, escolher um inteiro entre 0 e 100) foram menos afetadas <Complication> se estiver interessado, provavelmente deveria perguntar ao jranom pelos detalhes quando ele voltar <Complication> Posso estar errando nos detalhes. <bar> entendi, obrigado. bom achado <Complication> bem, o cervantes veio aqui e começou a reclamar de não estar recebendo nenhuma sobrecarga ;P <cervantes> essa também foi a minha compreensão disso <cervantes> tá vendo... você não consegue nada na vida se não resmungar :) <cervantes> alguém tem outras perguntas ou tópicos para a reunião? <fox> <duck> sim <Pi> uma pergunta sobre a saúde geral da rede: vejo cada vez mais clientes ficando para trás em termos de versão do i2p (2 ainda usando 0.6.1.11 e assim por diante). esses clientes não tornarão cada vez mais difícil monitorar os efeitos das mudanças no núcleo? (já que “menos” parecem querer atualizar) <fox> * duck repete o acima * w423412323 sugere uma mudança de tópico nessa linha. ;) <fox> <duck> Eu estava me perguntando, vi alguns commits de ajustes meio esquisitos na lista de e-mails do cvs. são mais experimentos? baseiam-se em observações? são prematuros? <Complication> Pi: enquanto não estiverem presentes em grandes números, não devem fazer muita diferença <Pi> 70 de 300 clientes usando versão diferente de 0.6.1.18 segundo meu netdb agora <Complication> É um jogo de números e capacidade — se a maioria dos routers, ou adicionalmente os routers de maior capacidade, estiverem razoavelmente atualizados, algumas pessoas esquecerem que instalaram o I2P não deve importar :) <cervantes> Pi: se os routers mais antigos se comportarem mal então a rede _deveria_ se adaptar e reduzir o tráfego roteado por eles <cervantes> *sendo roteado <cervantes> Complication: você viu a pergunta do duck? <Pi> e uma pergunta sobre uma estatística na i2p-console que apareceu algum tempo atrás: o que significa handle backlog? <Complication> duck: você quer dizer os ajustes de limitação de tunnel? São ajustes no sentido de que não trazem muita coisa inerentemente nova, mas devem estar razoavelmente bem testados agora (por exemplo, provavelmente não vão morder) <Complication> Mas podem morder um pouco, se você rodar uma configuração exótica que esteja completamente fora dos parâmetros que consegui imaginar <fox> <duck> Complication: eu estava pensando se '2' em vez de '3' coisinhas realmente importava tanto <fox> <duck> mas parecia que o problema do random poderia ter sido um grande vilão <fox> <duck> (embora o impacto relativo disso na má saúde da rede dependa de quando foi introduzido) <cervantes> Pi: handle backlog é o número de solicitações pendentes de ingresso em tunnel de entrada (citado do changelog) <Complication> Se você quer dizer o problema do random nextInteger(), e o efeito na randomização do comprimento do tunnel, acho que teria um efeito significativo <Complication> A diferença de custo entre construir um tunnel de 1 salto e de 2 saltos é bastante significativa <Pi> valeu, cervantes :) <fox> <duck> quando isso foi introduzido? <Complication> duck: acho que foi introduzido com algumas mudanças para o gerador Fortuna, ou alguma modificação nele <fox> <duck> ok; muito obrigado pela sua contribuição <Complication> Deixe-me verificar o cvsweb para mais detalhes... <cervantes> Pi: acredito que agora há código no lugar que descarta solicitações de tunnel de entrada se a fila encher (para ajudar a reduzir a carga de CPU) <Complication> Pi: sim, isso deve ser o indicador visível de outro parâmetro usado para decidir "temos capacidade suficiente para participar de outro tunnel?" <cervantes> duck: certamente notei uma grande mudança no comportamento do router desde que a correção foi introduzida. - nem tudo é bom, devo dizer :) <Complication> handle backlog grande == congestionamento, não faz sentido tentar entrar nos tunnels de outras pessoas <cervantes> tive um load average de 14 e 12000 tunnels participantes outro dia <Complication> Handle backlog parece importante particularmente em routers de alta capacidade (referindo-se ao que o cervantes viu) <Complication> Routers de baixa capacidade geralmente limitam sua aceitação de tunnel por razões de banda <Complication> (ou por razões de tempo de teste de tunnel, para ser preciso) <Complication> (ou pelo menos, tentam fazer isso) <cervantes> uau, conseguimos meia hora.... <Complication> De fato :D <cervantes> alguém quer trazer mais alguma coisa à mesa? <cervantes> nesse caso... * cervantes se prepara * cervantes *baffs* encerra a reunião <fox> <duck> valeu por cuidar da reunião <cervantes> heh eu esperava bafar e encerrar antes de alguém dizer alguma coisa.... mas o bar arruinou esse plano :)