Reunião de Desenvolvedores do I2P - 31 de janeiro de 2006

15:19 <jrandom> 0) olá 15:19 <jrandom> 1) Status da rede 15:19 <jrandom> 2) Status do 0.6.1.10 15:19 <jrandom> 3) ??? 15:19 * jrandom acena 15:19 <jrandom> anotações de status publicadas em http://dev.i2p.net/pipermail/i2p/2006-January/001257.html 15:20 <jrandom> ok, vamos direto para 1) Status da rede 15:21 <jrandom> como mencionado no e-mail, quem está no 0.6.1.9-0 (o lançamento completo) deve estar com o de sempre 15:21 <jrandom> embora usuários em builds mais novos (aqueles desde 0.6.1.9-5 ou mais novos) possam ter problemas 15:21 <jrandom> (“problemas” talvez seja pouco...) 15:21 <+Complication> O CVS -8 estava meio instável, então estou rodando o -2 instad (funciona bem o suficiente) 15:22 <gloin> :-) 15:22 <+Complication> =instead 15:22 <Pseudonym> as coisas parecem instáveis ultimamente (estou no 0.6.1.9-0) 15:22 <jrandom> legal, eu estava pensando em reverter as mudanças de processo mas incluindo a atualização do ircclient do dust e o patch do i2ptunnel httpserver no head, mas o 0.6.1.10 provavelmente não está tão longe 15:23 <jrandom> hmm Pseudonym, acessando eepsites, IRC ou outros serviços, ou hospedando-os? 15:23 <+Complication> Instável com o -0? Como o problema se manifesta? 15:23 <Pseudonym> Percebo no IRC principalmente (jogando idlerpg) 15:24 <jrandom> (“jogando” ;) ) 15:24 <Pseudonym> além disso, às vezes o router fica doido e precisa ser reiniciado (nenhum peer ativo) 15:24 <Pseudonym> hehe 15:24 <jrandom> hmm, problemas de conectividade com a internet? 15:24 <@frosk> -0 está estável aqui, claro, exceto pelos reinícios duas vezes por dia por “router hung!” 15:24 <jrandom> hrm frosk, “router hung” de verdade, ou “router hung” devido à expiração do leaseSet (conjunto de leases do I2P)? 15:25 <Pseudonym> a conectividade da internet está ok. quando eu reinicio o router do i2p ele volta na hora 15:25 <+Complication> Meu Cel300 também trava depois de um tempo, mas os intervalos têm aumentado, e não estou por dentro do motivo 15:25 <@frosk> jrandom: expiração de lease, tenho quase certeza 15:25 <jrandom> hmm 'k 15:26 <jrandom> quase tudo isso foi reescrito para o novo código de criação e gerenciamento, então vamos ver como fica no 0.6.1.10 15:27 <@frosk> legal 15:27 <@frosk> vou ficar feliz em ajudar a testar 15:28 <Pseudonym> não preciso que você depure o problema agora. só queria acrescentar um ponto de dados sobre estabilidade 15:28 <jrandom> massa, assim que estiver estável localmente vou certamente precisar recrutar alguma ajuda :) 15:28 <jrandom> legal, valeu Pseudonym 15:28 <jrandom> ok, mais alguém tem algo para 1) Status da rede? 15:30 <jrandom> se não, vamos pular para 2) Status do 0.6.1.10 15:30 <jrandom> como mencionado no e-mail, em vez de empilhar ajuste sobre ajuste na rede ao vivo, vamos direto à fonte 15:31 <jrandom> não será retrocompatível, então vai ter um... solavanco, e embora agrupemos algumas outras mudanças também não retrocompatíveis com ela, há a possibilidade de outra depois 15:32 <jrandom> mais especificamente, uma ideia com que estou brincando é migrar para ElGamal de 1024 bits para o código de criação de tunnel, em vez de 2048 bits 15:32 <jrandom> mas isso pode não ser necessário. depende de quão pesado isso nos atinge na rede ao vivo 15:34 <jrandom> se acontecer, isso só significaria uma atualização de rede, mas todos os destinations/etc continuariam os mesmos. 15:34 <jrandom> mas, enfim, isso é algo para explorar depois que sair o 0.6.1.10 15:34 <+Complication> Uma pergunta vagamente relacionada: o comprimento da chave tem alguma relação com o comprimento da estrutura de dados de criação de tunnel? 15:34 <jrandom> sim 15:35 <jrandom> diretamente relacionada: tamanho da chave * 2 * máx. nº de hops == tamanho da estrutura de dados 15:36 <jrandom> (então, 256*2*8 = 4KB, que por acaso também é o tamanho das mensagens completas da streaming lib) 15:37 <jrandom> ((ElGamal tem um fator de expansão de 2x)) 15:38 <+Complication> Aha, valeu. :) 15:38 <jrandom> ah, mais uma coisa sobre a nova especificação. durante a implementação encontrei outro dado de que preciso (um “reply message ID” de 4 bytes), que adicionei à spec localmente, usando alguns dos bits reservados 15:40 <jrandom> espero fazer tudo funcionar nos próximos dias, então talvez haja alguns testes iniciais (não anônimos) até o fim de semana 15:40 <jrandom> mas, claro, mais informações sobre isso à medida que surgirem 15:41 <jrandom> ok, alguém tem perguntas/comentários/preocupações sobre as coisas do 0.6.1.10? 15:41 <bar> outra pergunta vagamente relacionada: durante o rollout do .10, que tal manter i2p.net no .9 por alguns dias para o pessoal que atualiza automaticamente? 15:41 <bar> rollout* 15:41 <jrandom> sim, com certeza 15:42 <jrandom> provavelmente vou ter dois ou três routers nessa máquina durante a migração 15:42 <jrandom> e haverá avisos bem claros pelo menos 5 dias antes do lançamento 15:42 <bar> show 15:42 <+Complication> Assim ficaria mais suave mesmo. 15:43 <+Complication> O fórum parece um bom canal. A caixa de notícias no Router Console também... 15:43 * jrandom lembra-se dos dias em que cada release era incompatível com versões anteriores... tivemos muita prática então ;) 15:43 <jrandom> sim, fórum, caixa de notícias, lista, site 15:43 <+Complication> Assim, quem cuida de suas máquinas ficaria sabendo. 15:43 <tethra> heheh 15:44 <jrandom> e aqueles que ainda estão no 0.6.0.1, bem, estão ferrados de qualquer forma ;) 15:44 <@frosk> cortem-lhes as cabeças 15:44 <+Sugadude> Totalmente sem relação: podemos ter mais mudanças incompatíveis com versões anteriores com mais frequência para forçar esses routers antigos a saírem? 15:44 <+Complication> Acho que eles só esqueceram o I2P rodando :) 15:44 <jrandom> heh Sugadude 15:45 <jrandom> bem, se forem compatíveis, podemos aproveitar seus recursos, mas se houver algum motivo pelo qual não possamos, devemos marcá-los como incompatíveis 15:47 <jrandom> ok, se não há mais nada sobre isso, vamos pular para o nosso tópico geral: 3) ??? 15:47 <jrandom> alguém tem mais alguma coisa que queira levantar para a reunião? 15:48 <tethra> diz em algum lugar na router console que usuários atrás de NATs simétricos não são suportados no momento, isso vai mudar em algum momento em breve? 15:48 <tethra> ou estou mostrando uma imensa ignorância de algo 15:49 <+Complication> Sobre o código de webcache... parece que estou praticamente pronto. 15:49 <jrandom> há algumas técnicas para ajudar usuários atrás de NATs simétricos, que o bar descreveu na lista e no fórum, embora eu não conheça nenhum progresso imediato nisso 15:49 <jrandom> oh, nice1 Complication, me avise quando der para publicar o release :) 15:50 <+Complication> Fiz o watchdog abortar downloads de forma razoável, fazendo alguns testes e limpeza (ele atualmente faz log muito mais do que o decente).. 15:50 <+Complication> Tenho um servidor webcache no ar, o awup tem outro... para alguns testes realistas, talvez queiramos ligar o limiting... 15:51 <+Complication> ...se eu conseguir encontrar o legion, vou perguntar se ele teria interesse em rodar um também. 15:52 <jrandom> legal, mesmo um único webcache já seria um ótimo começo 15:52 <+Complication> E se mais alguém quiser rodar o script (disponível em awup.i2p, script Python usando SAM)... as referências deles podem ser adicionadas, embora no momento adicionar refs a mais “seed webcaches” exija recompilar os sources. 15:53 <+Complication> (não em um arquivo, mas no header do GWebCacheContainer.java) 15:53 * gloin não sabe o que é essa coisa de webcache. 15:53 <jrandom> gloin: permite que você se conecte ao i2phex sem precisar baixar um arquivo i2phex.hosts da primeira vez 15:54 <+Complication> gloin: para facilitar a integração do I2PHex 15:55 * cervantes chega atrasado 15:55 <+Complication> E para quem for se reconectar depois (por exemplo, pessoas que ficaram sem refs de peers ativos) ele pode oferecer refs novas 15:55 <gloin> ok. 15:57 <+Complication> Oh, offline de novo 15:58 <stealth> e quanto a iniciar automaticamente o i2phex depois que o i2p iniciar? 15:58 <+Complication> Parece exagero 15:58 <+Complication> Na fase atual, pelo menos 15:58 <jrandom> stealth: você pode fazer o router do i2p lançar qualquer aplicação Java que quiser adicionando entradas no seu arquivo client.config 15:59 <+Complication> Além disso, acho que o I2Phex pode ser iniciado antes do I2P rodar 15:59 <@frosk> em qualquer fase 15:59 <+Complication> Teoricamente, ele deve continuar tentando conectar até o I2P subir 15:59 <+Complication> (não testei, porém) 15:59 <jrandom> mas lembre-se, se você mandar lançar o i2phex, quando o i2phex fechar, é bem provável que o cliente do i2phex mate a JVM (reiniciando seu router) 16:00 <+Complication> Além disso, dá para fazer um script disso bem facilmente também... 16:00 <+Complication> por ex. "cd /home/i2p; sh i2prouter start; cd /home/i2phex; sleep 100; sh run.sh;" 16:00 <+Complication> (ou seja lá como era) 16:01 <+Complication> Desculpe, /home/user/i2p é mais provável :) 16:01 <cervantes> não se esqueça de iniciar /usr/games/tetris antes do sleep 100 16:02 <jrandom> isso aí 16:02 <jrandom> ok, mais alguém tem algo para a reunião? 16:03 <stealth> bem, eu pensei nisso, apenas iniciar o exe. a solução do i2psnark com always on é melhor porque as pessoas esquecem de compartilhar seus arquivos se não estiverem baixando... 16:04 <jrandom> sim, embora eu ainda não tenha ouvido falar de um cliente gnutella que seja enxuto o suficiente (que pudesse ser integrado) 16:05 <cervantes> não está sendo feito trabalho no Phex atual para abstrair a UI? talvez o cliente eventualmente fique mais enxuto 16:05 <+Complication> Eu não li essa parte do CVS do Phex 16:06 <jrandom> se o phex pudesse rodar como um .war, isso seria realmente demais 16:06 <cervantes> isn't the=isn't there 16:06 <cervantes> provavelmente estou enganado 16:06 <+Complication> O Sirup certamente estava trabalhando em uma interface XML-RPC, mas não sei se o Gregor & cia também 16:07 <+Complication> Então não tenho certeza se o sirup portou isso, ou começou a escrever do zero 16:09 <jrandom> se bem me lembro (iirc), ele estava apenas importando a lib xmlrpc do apache e expondo alguns internos do i2phex, mas não houve nenhum trabalho nisso por provavelmente 6–8 meses, e nunca foi funcional até onde sei (afaik) 16:10 <fox_> <tethra> mutella é um cliente gnutella baseado na web que é bem leve, iirc. não sei se vai ajudar, mas heh, talvez valha alguém (mais talentoso) dar uma olhada. 16:10 <fox_> <tethra> pode não ser o que estão procurando, porém. 16:12 <jrandom> portar um novo dá um bocado de trabalho, especialmente um em C/C++, infelizmente 16:12 <+Complication> Pessoalmente é improvável que eu mexa com XML-RPC. Tentar capturar vários bugs... está nos meus planos de curto prazo, porém. 16:13 * Complication quer que o efeito de rehash suma de vez, já que é uma baita perda de tempo 16:13 <jrandom> ooh, talvez isso seja acionado por mudança de fuso horário? 16:14 <jrandom> quando o I2P SDK se conecta ao router, ele obtém a hora atual do I2P (NTP) e força a JVM do SDK para UTC 16:14 <+Complication> Parece improvável... mas neste estágio, não posso excluir muita coisa 16:15 <jrandom> (e se o rehash dependesse de ordenação e timestamps de arquivos, talvez o deslocamento de algumas horas mudasse isso) 16:15 <jrandom> sim, você já cavou bastante nisso, só mencionando uma possibilidade 16:15 * jrandom não sabe nada sobre isso além dos seus relatórios de bug :) 16:16 <+Complication> Isso ocorre ocasionalmente e *parece* relacionado a algo que acontece quando o arquivo de configuração “sharedlibrary” está sendo carregado/regravado 16:16 <+Complication> Hmm, possibilidade interessante... 16:16 <+Complication> Não cavei o suficiente para excluir isso 16:18 <jrandom> ok, mais alguém tem algo para a reunião? 16:19 <jrandom> se não... 16:19 * jrandom encerra 16:19 * bar deseja boa sorte ao jrandom com o .10 e entrega a ele um baf brilhante 16:19 <jrandom> gracias :) 16:19 * jrandom encerra a reunião com um *baf*