Reunião de Desenvolvedores do I2P - 09 de agosto de 2005

13:11 <jrandom2p> 0) oi 13:11 <jrandom2p> 1) 0.6.0.2 13:11 <jrandom2p> 2) atualização do roadmap 13:11 <jrandom2p> 3) ??? 13:11 <jrandom2p> 0) oi 13:11 * jrandom2p acena 13:11 <+detonate> oi 13:11 <jrandom2p> notas semanais de status no ar @ http://dev.i2p.net/pipermail/i2p/2005-August/000839.html 13:12 <jrandom2p> ok, entrando rapidamente em [1-2] antes da bagunça geral.. 13:12 <jrandom2p> 1) 0.6.0.2 13:12 <jrandom2p> saiu. e tal 13:12 <jrandom2p> alguém tem perguntas/comentários/preocupações com a 0.6.0.2? 13:13 <jrandom2p> se não, passando para 2) atualização do roadmap 13:13 <jrandom2p> o, er, roadmap foi atualizado. e tal ;) 13:14 <duck> seu australiano 13:14 <+bla> jrandom: Ainda há problemas intermitentes ao contatar um destino, mesmo quando ele normalmente está no ar 13:14 * postman pode confirmar isso 13:14 * detonate também confirma 13:14 <+bla> jrandom: Por exemplo, forum.i2p funciona bem, então depois de alguns minutos não funciona, e exige alguns recarregamentos 13:15 * bla foi o primeiro ;) 13:15 <jrandom2p> hmm, sim, já ouvi relatos disso. com a 0.6.0.2 também, certo? 13:16 <+postman> de fato, senhor 13:16 <+bla> Sim, 0.6.0.2 13:16 <+bla> Pode ser problema no netDb, ou uma seleção ruim de pares para colocar nos tunnels (ou outra coisa) 13:16 <jrandom2p> 'k 13:17 <jrandom2p> a seleção de pares para tunnel tem estado bem ruim ultimamente, assim como o flooding de armazenamento no netDb 13:17 <jrandom2p> (veja seu /oldstats.jsp para contagens de falhas de solicitação de tunnel) 13:18 <+bla> Agora que usamos UDP/SSU, a classificação de pares parece estar melhor do que antes: vários pares que eu _sei_ que são rápidos geralmente aparecem na seção "fast" na profile pafe 13:19 <jrandom2p> legal 13:19 <jrandom2p> 0.6.0.2 adicionou algum código de rejeição de tunnel baseado no netDb que já deveria estar fazendo antes (recusando entrar se não conseguirmos encontrar o próximo salto), então o aumento nas rejeições é esperado 13:19 <+bla> Embora eu realmente devesse voltar aos algoritmos de classificação... ;) 13:20 <jrandom2p> tenho feito análise de perfil/estatísticas, mas ainda sem resultados sólidos 13:21 <jrandom> isso seria legal, bla :) 13:25 <jrandom2p> ok, mais alguma coisa em 2) atualização do roadmpa? :) 13:26 <jrandom2p> se não, passando para 3) ??? 13:26 <+detonate> você acha que seria útil colocar na lista negra pares com altas taxas de failure/duprecv em comparação à moda? 13:27 <jrandom> hmm, não tenho certeza disso — se as taxas de failure/dup forem altas demais para ser útil, devemos simplesmente transferir lentamente e com cuidado 13:27 <jrandom> enquanto as mensagens estiverem chegando, as mensagens estão chegando 13:28 <jrandom> há um motivo pelo qual não usamos estatísticas sobre comunicação direta entre pares como parte do nosso perfilamento — depender delas nos deixaria vulneráveis a alguns ataques fáceis e poderosos (agir de forma diferente com pares diferentes e ver quem usa você, etc.) 13:29 <+detonate> hmm 13:29 <+detonate> ok 13:29 <jrandom> mas talvez precisemos encerrar sessões para pares que estejam em conexões tão congestionadas 13:29 <+detonate> boa observação 13:34 <jrandom> ok, mais alguém tem algo para levantar em 3) ??? 13:34 <luckypunk> o,oh, talvez você devesse esperar até todo mundo voltar 13:34 <luckypunk> antes de fazer perguntas críticas :P 13:35 <jrandom2p> bah, eles têm a lista de e-mails ;) 13:35 <luckypunk> bem 13:35 <luckypunk> acho que este é o lugar certo para reclamar 13:36 <luckypunk> I2P ainda usa um pouco de CPU 13:36 <luckypunk> mas não tanto quanto antes 13:36 <luckypunk> é verdade, eu não rodo desde os tempos da 5.0 13:36 <luckypunk> mas é 13:36 <luckypunk> er 13:36 <luckypunk> 0.5.0 13:36 <jrandom2p> legal, qual das suas máquinas funciona com ele? 13:36 <luckypunk> er 13:36 <luckypunk> ffs 13:36 <luckypunk> eu não uso desde a 0.6.0.0 13:36 <luckypunk> funciona bem com o Pentium 2 13:37 <luckypunk> o valor de nice padrão faz com que ele tenda a travar se eu fizer qualquer coisa muito intensiva de CPU por muito tempo, pois o I2P fica sem CPU 13:38 <+detonate> hmm, acho que poderia haver um espaço na configuração de rede do console do router para fixar manualmente os introducers (nós introdutores), uma vez que haja introducers, se o usuário preferir 13:39 <jrandom2p> você está na 0.6.0.2 agora, luckypunk? 13:39 <@smeghead> detonate: isso é coisa de rota confiável... mais adiante no roadmap :) 13:39 <luckypunk> não 13:39 <luckypunk> não rodo desde a 0.6.0.0 13:39 <@smeghead> *rota restrita 13:40 <luckypunk> mas o uso de CPU pareceu muito menor. 13:40 <+detonate> heh, isso deveria estar lá assim que houver introducers :) 13:40 <jrandom2p> ah sim, detonate, a seleção de introducer certamente poderia ser configurável, mas provavelmente será uma opção de configuração avançada oculta ;) 13:41 <jrandom2p> luckypunk: a 0.6.0.1 tirou um bocado de criptografia, e a 0.6.0.2 deve ajudar mais ainda. experimente quando puder, pode lidar melhor 13:41 <luckypunk> ok 13:41 <@smeghead> e se um introducer não quiser que você o selecione o tempo todo? 13:41 <luckypunk> tenho a impressão de que o I2P rodaria agora em um Pentium intermediário dedicado. 13:41 <jrandom> smeghead: então ele diz "cai fora, não vou servir como introducer para você" 13:42 <jrandom> e os pares terão múltiplos introducers, então ficará balanceado 13:42 <jrandom> (e são apenas 2 pacotes para conectar um novo par, não todos os pacotes comunicados) 13:44 <+detonate> se os introducers funcionassem de forma diferente você poderia fazer uma votação por maioria entre eles para decidir quais estão funcionando, mas como está isso não faz sentido 13:45 <ant> <jme___> perg.: onde posso encontrar uma descrição desse sistema de votação ? 13:45 <jrandom> maioria não faz sentido algum 13:45 * jrandom não confia em votação nem um pouco 13:45 <jrandom> (especialmente à luz de Sybil) 13:45 <jrandom> um introducer está funcionando se um novo par consegue contatá-lo através dele 13:47 <+detonate> qual é o status do vanguard, isso é de certa forma relacionado 13:47 <+detonate> enquanto o smeghead está por aqui 13:51 <jrandom> ok, se não houver mais nada... 13:51 * jrandom vai encerrando 13:51 * jrandom *baf* fecha a reunião