Reunião de Desenvolvedores do I2P - 29 de novembro de 2005

15:25 <jrandom> 0) oi 15:25 <jrandom> 1) Estado da rede e 0.6.1.6 15:25 <jrandom> 2) Syndie 15:25 <jrandom> 3) I2P Rufus 0.0.4 15:25 <jrandom> 4) ??? 15:25 <jrandom> 0) oi 15:25 * jrandom acena 15:25 <jrandom> notas de status semanais no ar em http://dev.i2p.net/pipermail/i2p/2005-November/001234.html 15:26 * bar entrega a jrandom um baf 15:26 <c3rvantes> ainda não! 15:26 * jrandom se prepara 15:26 <jrandom> er... 15:26 <jrandom> vamos lidar com os primeiros itens da pauta primeiro :) 1) Estado da rede e 0.6.1.6 15:27 <jrandom> muitas coisas foram atualizadas nas últimas versões, mas a rede ainda parece razoavelmente estável. 15:28 <jrandom> tivemos alguns picos sérios na participação em alguns routers, embora isso seja praticamente inofensivo 15:28 <+legion> legal, concordo que o estado da rede está melhorando. Também, sim, por que não remover tcp para 0.6.1.7 15:28 <jrandom> (er, picos na participação de tunnel, isto é) 15:29 <@cervantes> não está brincando 15:29 <jrandom> não tenho certeza, legion. pode haver alguns usuários por aí limitados apenas a tcp, mas me parece lembrar que havia só um ou talvez dois desses 15:29 <+legion> bem, notei que com 0.6.1.5 o router às vezes reiniciava sozinho. 15:29 <+Complication> O meu tem oscilado dentro de limites razoáveis, de 100 a 250 tunnels participantes 15:29 <jrandom> Não consigo pensar em nenhum grande motivo para mantê-lo, e consigo pensar em alguns para removê-lo 15:30 <jrandom> legal, Complication 15:30 <jrandom> (esses números são bastante médios, de acordo com stats.i2p/, mas lembrem-se, números assim podem prejudicar o anonimato, então realmente não deveriam ser divulgados, especialmente não em reuniões registradas ;) 15:30 <+Complication> Meu velho Celeron ainda está reiniciando automaticamente a cada cerca de 10 horas 15:30 <+Complication> Fora isso, está mais bem conectado do que nunca 15:30 <Pseudonym> quais são as razões para removê-lo? 15:31 <+Complication> TCP é caro 15:31 <@cervantes> meu router está acabado 15:31 <+Complication> Em termos de threads por conexão 15:31 <@cervantes> Complication: multiplique isso por 10 e você tem a faixa atual do meu router ;-) 15:31 <+legion> O meu tem oscilado entre 200-400 tunnels participantes, então parece melhor do que nunca. 15:32 <+Complication> cervantes: ai ai 15:32 <+Complication> Já vi um acidente estranho que causou 2000 tunnels participantes, mas isso foi no verão 15:32 <jrandom> Pseudonym: desempenho (cpu/memória, melhor escalonamento devido aos nossos requisitos semi-confiáveis), manutenibilidade, blacklist mais eficaz 15:32 <+Complication> Um único pico que nunca se repetiu novamente 15:32 <+legion> sim, com algumas versões anteriores houve tais picos 15:32 <jrandom> Complication: tivemos> 2000 picos de tunnel com esta última revisão 15:33 <jrandom> mas, com sorte, 0.6.1.7 vai cuidar disso 15:33 <+legion> Bem, esses são bons motivos para remover tcp :) 15:33 <jrandom> mas, de novo, os picos na participação de tunnel não são um problema, já que a maioria deles não é usada 15:34 <@cervantes> Pseudonym: parece haver apenas um ou dois routers ainda usando tcp na rede 15:34 <jrandom> também pode ser uma boa ideia remover tcp nesta revisão, já que ela não tem outras mudanças importantes. assim podemos ver com bastante clareza como isso afeta as coisas 15:34 <jrandom> (e podemos reativá-lo se necessário) 15:35 <Pseudonym> se só houver dois routers usando, não imagino que vá ter muito efeito de qualquer forma 15:35 <Pseudonym> (exceto por haver dois routers a menos na rede) 15:35 <@cervantes> 2 clientes descontentes 15:35 <jrandom> bem, o transport aparece em algumas situações estranhas, o que é um dos motivos pelos quais quero desativá-lo :) 15:35 <+Complication> Espero que eles não levem muito para o lado pessoal 15:36 <+Complication> É realmente perverso da parte de certos ISPs filtrar UDP. 15:36 <+Complication> Perverso e completamente sem sentido. 15:36 <jrandom> (p.ex., quando um router está danificado, as pessoas marcam seu transport SSU como com falha e, assim, recorrem ao transport tcp) 15:36 * Pseudonym ama o ISP dele. sem restrições 15:37 <+Complication> Então, sem TCP, veríamos como o UDP lida com isso sozinho? 15:37 <+Complication> "sem rodinhas auxiliares" :P 15:37 <+legion> hã, então como contornamos essa filtragem perversa sem tcp? 15:38 <jrandom> exatamente, Complication :) 15:38 <jrandom> legion: não contornamos 15:38 <jrandom> (restricted routes) 15:38 <+Complication> Bem, não há vários apps úteis além de programas de compartilhamento de arquivos que também usam pacotes UDP com tamanho acima dos pacotes de DNS? 15:39 <+legion> :( não parece bom 15:39 <+Complication> Com tamanho semelhante ao menor tamanho de pacote que o I2P usa? 15:39 <jrandom> eh, legion, não é um problema 15:39 <jrandom> Complication: protocolos de streaming 15:39 <+Complication> Não se pode bloquear UDP diretamente, jamais, sem aleijar o DNS. 15:39 <+Complication> Pode-se limitar o tamanho dos pacotes. 15:40 <+legion> ok, parecia que poderia ser 15:40 <+Complication> VoIP? 15:40 <jrandom> seria um problema se fosse generalizado — se a comunidade da internet em geral banisse udp 15:40 <+Complication> Hmm, VoIP usa pacotes grandes ou pequenos? 15:40 <jrandom> mas se forem apenas alguns isps, podemos tratá-los como restricted routes 15:40 <+Complication> Ou você quis dizer mais como... video streaming? 15:40 <+legion> Eu acharia que usaria uma mistura de ambos 15:41 <jrandom> ambos, Complication, RTSP roda sobre UDP, e o Real roda sobre RTSP, se bem me lembro 15:41 <+Complication> s/p/s 15:42 <+legion> Então vamos para o próximo item? 15:42 <+Complication> cat /etc/services | grep -c udp 15:42 <+Complication> 227 15:43 <jrandom> Ainda não tenho certeza se vamos remover tcp na 0.6.1.7, mas provavelmente. 15:43 <jrandom> sim, alguém tem mais algo sobre 1)? se não, vamos pular para 2) Syndie 15:43 <+Complication> Ou seja, há pelo menos 227 apps (alguns possivelmente obsoletos ou apps de LAN) que usam UDP 15:44 <jrandom> bah, isto é a intarweb. tudo que você precisa é acesso HTTP via proxy 15:44 <jrandom> Não tenho muito a acrescentar ao 2) além do que está no e-mail (e do que está no Syndie) 15:44 <+legion> Estou convencido, sim, remova. :) 15:44 <jrandom> alguém tem algo sobre o Syndie que queira levantar? 15:45 <+legion> Também não tenho nada a dizer sobre o 2). 15:45 * Complication está lendo "como o Syndie funciona" 15:46 <+Complication> Um pequeno efeito de UI vive me surpreendendo. :D 15:46 <+Complication> Quando eu expando um thread de mensagens, sempre me pega de surpresa que a mensagem ativa se mova para se tornar a de cima na lista. :P 15:47 <+Complication> Mas você provavelmente pode ignorar isso sem problemas. Eu só sou muito exigente e criatura de hábito. :P 15:47 <@cervantes> o modelo de threading é algo que está sendo discutido longamente 15:47 <@cervantes> ;-) 15:47 <+Complication> Vou me acostumar. :) 15:48 <+Complication> cervantes: no Syndie? Tenho que encontrar esse thread. :) 15:48 <@cervantes> também não gosto disso — mas pode muito bem mudar 15:48 <jrandom> sim, isso é meio esquisito, suponho 15:48 <+legion> sim 15:48 <@cervantes> "assunto: syndie threading" 15:49 <+Complication> Além disso, se a mensagem expandida fosse a de baixo, ela *teria* que se mover de qualquer forma. 15:49 <+Complication> Porque, caso contrário, ela ficaria presa lá. 15:50 <jrandom> bem, a navegação no rodapé mostra 10 *threads* por vez, não 10 mensagens. então poderia expandir o thread de baixo 15:50 * cervantes está testando algumas implementações de estilo de UI de threading diferentes no momento 15:51 <jrandom> massa 15:51 <jrandom> sim, idealmente poderemos alterná-los em CSS, ou, se não, no lado do servidor 15:52 <@cervantes> ou melhor "estilos de navegação de threading" 15:53 <@cervantes> hmm, meus testes usam listas não ordenadas HTML aninhadas puras por padrão 15:53 <@cervantes> você pode adicionar tanto CSS e JavaScript quanto precisar ou quiser 15:53 <jrandom> alguma previsão de quando poderemos ver alguns mockups? 15:53 <@cervantes> (contudo é apenas uma prova de conceito, não uma implementação de UI real) 15:54 <@cervantes> Eu faço a maior parte da minha codificação durante as reuniões do I2P ;-) 15:54 <jrandom> heh 15:54 <@cervantes> talvez o primeiro mockup esteja pronto esta noite 15:54 * jrandom agenda reuniões diárias 15:54 <jrandom> massa 15:54 <@cervantes> maldição :) 15:55 <jrandom> ok, alguém tem mais algo para 2) syndie? 15:55 <jrandom> se não, vamos para 3) I2P Rufus 0.0.4 15:56 <jrandom> Não tenho muito a acrescentar além do que está no e-mail — Rawn/defnax, vocês estão por aí? 15:56 <+legion> então quão boa é a 0.0.4? Que problemas restam, se é que há? 15:57 * jrandom não tem a menor ideia 15:58 <+legion> Talvez um de seus usuários possa responder. Parece boa e estável? 15:58 <jrandom> ok, parece que Rawn e defnax estão ausentes no momento. se alguém tiver perguntas/comentários/preocupações sobre o I2P Rufus, passe no fórum e publique lá 15:58 <+legion> puxa, acho que teremos que fazer isso. 15:59 <+legion> vamos para 4)? 15:59 <jrandom> sim, parece que sim. ok, 4) ??? 15:59 <+Complication> Eu não testei o I2P Rufus, infelizmente. 16:00 <jrandom> alguém tem mais alguma coisa que queira trazer? 16:00 <jrandom> (vamos lá, temos que esticar isso para o cervantes poder fazer mais algum trabalho!) 16:00 <+legion> sim, que tipo de coisas interessantes estão vindo por aí? 16:00 <+bar> há algum lugar onde eu poderia ler mais sobre "restricted routes"? 16:00 <+bar> (eu *procurei*, sim) 16:01 <+legion> Talvez possamos até discutir i2phex? 16:01 <jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD 16:01 * cervantes posiciona o mouse sobre o botão fechar 16:01 <jrandom> er, #future.restricted 16:02 <jrandom> além das páginas how_* e a todo 16:02 <jrandom> (na web) 16:02 <+Complication> Heh, o I2P parece ter pulado um build :D 16:02 <+Complication> :D 16:02 <+bar> obrigado 16:02 <+Complication> - public final static long BUILD = 1; 16:02 <+Complication> + public final static long BUILD = 3; 16:03 <jrandom> legion: alguns hacks no netDb, modificações de desempenho, restricted routes, melhorias no streaming, melhorias no eepproxy, melhorias de tunnel, etc. muita coisa, mas nada pronto ainda 16:03 <+legion> hã, estranho 16:03 <jrandom> algo a levantar sobre i2phex, legion? 16:03 <jrandom> Complication: sim, intencional. Eu esqueci de aumentar para BUILD = 2 16:03 <+Complication> (não que isso importe para alguma coisa, só me pergunto se já vi essa ocasião rara antes :) 16:04 <+legion> ótimo, parece excelente, obrigado! 16:04 <jrandom> ah, isso me lembra... seria legal se alguém quisesse se aprofundar em revisar nossa página web 16:05 * jrandom não quer pensar nisso, mas isso tem que ser feito mais cedo ou mais tarde 16:05 <+legion> sim, tem 16:05 <+legion> valeria a pena atualizar o i2phex neste ponto para o último código cvs do phex? 16:06 <+Complication> Não sei, não ouvi nada do Redzara recentemente 16:06 <jrandom> pelo que me lembro, o redzara estava esperando as atualizações do gregorz no phex 16:06 <jrandom> (para que pudéssemos ter uma atualização/extensão relativamente limpa) 16:08 <+legion> hã, então por que ter i2phex? 16:08 <+Complication> Só por via das dúvidas? 16:08 <jrandom> hmm? 16:08 <jrandom> i2phex é uma extensão do phex 16:08 <+legion> Parece que eles queriam que houvesse apenas o phex com uma extensão i2p 16:09 <jrandom> extensão, ou seja, modificação em um número muito pequeno de bits 16:09 <jrandom> er, s/bits/components/. assim podemos atualizar o código facilmente sempre que os devs do phex corrigirem coisas 16:10 <+legion> se for assim, então não deveria dar muito trabalho para eu atualizá-lo para o último código cvs, embora eu saiba que vai dar. 16:10 <jrandom> a última coisa que ouvi no fórum foi que o plano é que I2Phex e Phex sejam aplicativos separados, mas compartilhem a maior parte do código 16:10 <jrandom> sim, legion, isso seria ótimo, mas pelo que ouvi, o Gregor ainda não havia terminado as modificações no Phex 16:11 <jrandom> (que era o que o redzara estava esperando) 16:11 <+legion> ah, entendi 16:11 <jrandom> então, a alternativa é ou ajudar o Gregor ou continuar modificando a base de código existente do I2Phex 16:12 <+legion> bom, então se eu não esperar e apenas atualizar o i2phex com código novo, não haveria necessidade de o redzara continuar 16:12 <jrandom> bem, não exatamente. 16:12 <jrandom> atualizar o I2Phex para o código atual do Phex seria ótimo, sim 16:13 <jrandom> mas assim que os desenvolvedores do Phex atualizarem o código do Phex, ficaremos fora de sincronia de novo 16:13 <+legion> ok, provavelmente vou mexer nisso hoje à noite ou dentro de alguns dias. 16:13 <jrandom> massa 16:13 <+legion> Tudo bem. 16:14 <+legion> Na verdade, não estou buscando manter o i2phex sincronizado com o código do phex; é só que parece que o cvs contém correções das quais o i2phex certamente poderia se beneficiar. 16:15 <+legion> Também estou querendo retirar qualquer código e recursos do phex que o i2phex não precise. 16:15 <jrandom> legal 16:16 <+legion> Quanto a novos recursos e a corrigir o que ainda não está funcionando, como as filas de upload... Bem, já dei uma olhada em fazer os webcaches funcionarem, mas ainda há muito o que fazer. 16:17 <jrandom> isso aí. sim, o phex costumava ter suporte a gwebcache funcionando, mas o sirup desabilitou, pois não era necessário no começo 16:17 <+legion> Eu planejo adicionar jeti ao i2phex eventualmente. 16:17 <jrandom> legal 16:18 * jrandom nunca usou jeti, e espero que continue sendo um componente opcional, mas suportar mais coisas é legal 16:18 <+legion> Sim, pode ser opcionalmente; os usuários poderão baixar um jeti2phex ;) 16:19 <jrandom> isso aí 16:19 <+legion> Ainda há muito que podemos fazer com o i2phex, embora ele esteja funcionando muito bem como está. 16:20 <+legion> Até agora manter um cliente conectado, no ar e rodando 24/7 é possível e fácil. 16:21 <jrandom> sim, tive algum sucesso com ele... "fazendo backup das minhas gravações licenciadas" 16:21 <+legion> heh :) 16:22 <jrandom> ok, mais alguém tem algo para a reunião? 16:23 * cervantes traz o gongo chinês 16:23 <+legion> Parece que estou esquecendo algo... hmm 16:24 <+legion> Ah, sim, alguma ideia de como podemos reduzir a quantidade de memória que o i2p e o i2phex consomem? 16:25 <+Complication> Bem, o transport TCP consome um pouco 16:25 <jrandom> poder-se-ia rodar ambos na mesma jvm 16:25 <+Complication> Se isso for embora, vai liberar um pouco 16:26 <@cervantes> tire alguns pentes de RAM da sua máquina 16:26 <cat-a-puss> alguém com alguma experiência com javolution sabe se isso ajudaria? http://javolution.org/ 16:26 <jrandom> (clients.config no diretório de instalação do i2p define a classe principal e os argumentos para iniciar os clientes) 16:26 <+legion> Então, se executássemos ambos na mesma jvm e quando o tcp for embora, poderíamos reduzir para menos de 50mb? 16:27 <jrandom> sem ideia, legion. depende também do que você quer dizer por 50MB. RSS/VSS/etc 16:27 <jrandom> Eu realmente não recomendaria rodar ambos em uma JVM, a menos que você mantenha os dois rodando o tempo todo, já que encerrar um mataria o outro 16:27 <@cervantes> legion: limitar a largura de banda e impor um teto de participantes também pode ajudar 16:27 <jrandom> sim, como o cervantes disse 16:28 <cat-a-puss> parece-me que, se soubermos exatamente quantos de um certo tipo de objeto provavelmente usaremos, isso ajudaria a evitar alocação excessivamente zelosa da jvm 16:28 <+Complication> Certo, ela faz aquelas diferentes alocações, das quais eu nunca consegui realmente fazer sentido 16:28 <jrandom> sim, fazemos um pouco disso, cat-a-puss (veja net.i2p.util.ByteCache) 16:29 <+Complication> (mas, como disse, Java é algo muito novo para mim) 16:29 <jrandom> Já dei uma olhada no javolution antes, mas parece que progrediu bastante. vou dar outra olhada 16:30 <cat-a-puss> jrandom: sei que algumas pessoas no meu trabalho usam e estão satisfeitas, embora não se importem com alocação de memória 16:31 <jrandom> bem, realmente não economizaria memória, mas ajudaria a reduzir a agitação do GC 16:31 <+legion> Bem, pessoalmente não me importo muito com alocação de memória; porém, muitas pessoas se importam. 16:31 <jrandom> ooh, e também é licenciado BSD 16:31 <cat-a-puss> certo 16:31 <jrandom> legion: alocação de memória significa desempenho 16:32 <+legion> er, ah, então consumo de memória 16:33 <+legion> Muita gente fica muito feliz com o utorrent por causa do seu consumo de memória muito pequeno. 16:33 <jrandom> ah, sim. podemos ajustar isso mais adiante, mas como o i2p roda dentro dos tamanhos padrão da jvm, não estou muito preocupado (pois temos bastante margem para ajustes) 16:34 <jrandom> ok, mais alguém tem algo para a reunião? 16:35 <+legion> não, estou de boa... 16:37 * jrandom se prepara 16:37 * jrandom encerra a reunião com um *baf*