Reunião de Desenvolvimento do I2P - 04 de abril de 2006

16:21 <jrandom> 0) oi 16:21 <jrandom> 1) Status da rede e 0.6.1.14 16:21 <jrandom> 2) Planejamento do Syndie 16:21 <jrandom> 3) Otimizações locais do jbigi 16:21 <jrandom> 4) ??? 16:21 <jrandom> 0) oi 16:21 * jrandom acena 16:21 <jrandom> notas de status semanais publicadas em http://dev.i2p.net/pipermail/i2p/2006-April/001275.html 16:21 * Complication lê 16:22 <jrandom> enquanto vocês leem aquele post (montado rapidamente), vamos direto para 1) Status da rede 16:23 <@cervantes> (fórum de volta) 16:23 <jrandom> há alguns problemas por aí afetando o uso na 0.6.1.13, e a maioria deles foi localizada e resolvida 16:24 <Complication> Aqui, com a "quarta" build do CVS, notei uma mudança nos meus gráficos 16:24 <jrandom> ainda há alguns detalhes sendo testados e retrabalhados, mas um release deve sair nos próximos dias 16:24 <Complication> Em geral, as coisas caminharam para mais estabilidade e menos oscilação 16:24 <jrandom> ah droga, esqueci de incrementar para -4, não foi? 16:24 <jrandom> (ok, -5 sai mais tarde esta noite) 16:24 <jrandom> legal Complication 16:25 <Complication> Mas minhas percepções podem estar influenciadas pelo jbigi também, já que não tomei medidas para excluir isso 16:25 <Complication> Agora, depois de um tempo, a retransmissão também caiu para 15% 16:28 <jrandom> hmm, estou vendo minha média de RTO do SSU se aproximar do teto de 3s também 16:28 <jrandom> (embora retransmissão ainda muito baixa, abaixo de 5%) 16:29 * Complication dá uma segunda olhada nisso 16:29 <Complication> Digamos que a média bruta está um pouco acima de 1500 16:29 <Complication> (por aqui) 16:30 <+fox> <BrianR___> jrandom: Existe uma "MTU" de facto para pacotes do I2P? 16:30 <jrandom> ah ok, talvez à medida que isso sobe, a taxa de retransmissão diminua 16:30 <Complication> Notei que os meus começaram com MTUs menores, agora subiu para 1350 16:30 <jrandom> BrianR___: sim, ou 1350 ou 608 (como mostrado em `http://localhost:7657/peers.js)` 16:31 <jrandom> se a taxa de falhas for muito alta com a MTU maior, recua para a MTU menor (e se for muito baixa com a MTU menor, salta para a MTU maior) 16:31 <+fox> <BrianR___> jrandom: E isso é para o payload interno ou para os pacotes IP visíveis? 16:31 <+fox> <BrianR___> Ou seja, se eu fosse enviar um bloco de dados por um stream do I2P, qual seria o tamanho ideal dos fragmentos para minimizar overhead? 16:31 <jrandom> isso é para o payload UDP 16:32 <jrandom> streams estão duas camadas acima 16:32 <jrandom> (há fragmentação para tunnels, e depois fragmentação no nível stream/i2cp) 16:32 <+fox> <BrianR___> Sim... Há um tamanho ideal para minimizar a fragmentação? 16:32 <jrandom> o tamanho de bloco ideal de um app usando a streaming lib é "grande", para que a streaming lib possa usar o tamanho apropriado. 16:33 <jrandom> (vulgo ignore o homem por trás da cortina) 16:33 <+fox> <BrianR___> Aah.. Talvez eu deva pensar em pipelining ou algo assim então.. 16:34 <+fox> <BrianR___> Estou planejando um app com muito tráfego de requisição/resposta... 16:34 <jrandom> eu recomendaria agrupar então para reduzir o tráfego verboso 16:34 <Complication> Talvez manter o tráfego focado ajude até certo ponto 16:37 <jrandom> ok, mais alguma coisa em 1) Status da rede, ou devemos deslizar para 2) Planejamento do Syndie 16:38 * jrandom desliza 16:39 <jrandom> isso é em grande parte um placeholder e um cfp (chamada para propostas) - vai haver uma reformulação substancial no Syndie, tanto na operação quanto na UI, então se você tem alguns recursos-chave ou casos de uso que acha que precisam ser tratados, entre em contato 16:40 <jrandom> (mais informações virão, é claro, conforme as coisas forem sendo detalhadas) 16:42 <jrandom> isso é tudo que tenho a dizer sobre isso por enquanto, então, passando para 3) otimizações do jbigi 16:42 <@frosk> e eu tinha presumido que "plotting" se referia a alguma coisa do jrobin no Syndie :) 16:43 <jrandom> hehe 16:43 <jrandom> seria interessante plotar posts/dia, posts/autor, novos autores/dia, etc ;) 16:44 <Complication> Ah, um ponto sobre o Syndie (desculpe, só lembrei agora) 16:44 <Complication> =um bit 16:44 <@frosk> qual você quer, 0 ou 1? :) 16:44 <Complication> Você acha que seria prático, ou fácil/difícil separar autores favoritos e autores em blacklist (spam) em duas listas diferentes? 16:45 <Complication> No addresses.jsp 16:45 <jrandom> ah, sim, sem muita dificuldade 16:46 <jrandom> essa é uma boa ideia para a reformulação também, mas talvez possamos colocar isso no build 0.6.1.14 16:47 <Complication> Nah, isso não está me incomodando, eu só lembrei de algo que notei naquela época 16:47 <Complication> De qualquer forma, o jbigi fica mais rápido em Linux/AMD64 quando você compila localmente e usa GMP 4.2 16:48 <jrandom> legal 16:48 <jrandom> você comparou isso com -O3 -m64 no GMP 4.1.2? 16:48 <Complication> E eu fui um grande tolo por usar flags de compilação bem erradas :O 16:48 <@cervantes> o link relevante era `http://forum.i2p/viewtopic.php?t=1523&start=30` btw 16:48 <jrandom> ah valeu cervantes 16:48 <Complication> jrandom: Ainda não comparei, mas vou 16:49 <Complication> Durante o próximo reboot agendado 16:50 <jrandom> o processo de build do jbigi é essencialmente "compilar o GMP, depois compilar o jbigi.o, e vincular os dois", então qualquer tipo de otimização que as pessoas queiram fazer no GMP pode ser feita como primeiro passo 16:50 <@cervantes> Não vi muita diferença entre -O3 e -O2 em quaisquer testes anteriores que fiz, se isso é diferente em x86_64 ... *shrug* 16:50 <jrandom> sim, pode depender também da revisão do compilador 16:50 <jrandom> (especialmente com todos esses problemas 3.3/3.4/4.0/4.1) 16:51 <@cervantes> só para reiterar o que mencionei naquele tópico... provavelmente não veremos jbigi otimizado para windows64 tão cedo 16:51 <+fox> <BrianR___> A biblioteca de stream do I2P faz compressão do payload? 16:52 <Complication> BrianR: sim 16:52 <@cervantes> a menos que alguém tenha M$ VC 2005 com SDK de 64 bits e tope um trabalho pesado para conseguir compilar o gmp 16:52 <Complication> Pelo menos pelo que eu sei 16:53 <@cervantes> (havia um projeto para portar o gmp para um projeto vc em algum lugar, porém) 16:53 <jrandom> cervantes: bem, temos um que /funciona/ para amd64/win, mas não aproveita ao máximo o hardware ;) 16:53 <jrandom> (quando meu novo box chegar talvez eu consiga ajustar isso, já que é um amd64) 16:53 <+fox> <BrianR___> tentando descobrir se devo usar um protocolo binário para economizar bits ou se zlib ou algo assim vai esmagar um protocolo ASCII deixando-o bem pequeno.. 16:54 <@cervantes> legal - infelizmente Mingw64 ou cygwin64 não parecem estar no horizonte próximo... 16:54 <jrandom> BrianR___: otimização prematura sendo a raiz de todo mal, e aquela coisa toda... 16:55 <Complication> protocolos pelo menos parcialmente legíveis por humanos são geralmente mais fáceis de depurar, mas acho que depende do que se está fazendo 16:56 <Complication> (porque algumas coisas como criptografia não gostam de ser legíveis por humanos, de jeito nenhum :) ) 16:57 <Complication> Mas se o I2P faz a criptografia e também comprime, há boas chances de que muitas coisas que ocorrem em cima dele possam ser feitas com protocolos legíveis por humanos 16:58 <jrandom> sim 16:58 <jrandom> ok, mais alguma coisa em 3) coisas do jbigi? 16:58 <jrandom> se não, vamos para 4) ??? 16:59 <jrandom> alguém tem mais alguma coisa para a reunião? 17:01 <+tethra> lembro de ter ouvido algo sobre ferramentas de colaboração anônimas recentemente 17:01 <+tethra> quer detalhar de que tipo, e se serão ao estilo do Syndie ou não? 17:02 <@cervantes> irc e Syndie são uma ferramenta de colaboração anônima :) 17:02 <jrandom> hmm, não tenho certeza do que você se refere - ou talvez você queira dizer as reformulações do Syndie já planejadas? :) 17:02 <+tethra> verdade. 17:02 * tethra também não tem certeza, por isso perguntou 17:02 <+tethra> houve conversa sobre isso nos fóruns - razões para anonimato e tal 17:03 <+tethra> vou encontrar o tópico para pegar a citação 17:03 <jrandom> ah certo 17:03 <+tethra> http://forum.i2p.net/viewtopic.php?t=1618 17:03 <jrandom> o tópico de casos de uso 17:03 <+tethra> - fóruns/boards/wikis hospedados anonimamente e acessíveis publicamente 17:03 <+tethra> sim 17:04 <+tethra> vai haver um projeto tipo i2wiki baseado em algo como o Syndie ou isso fica a cargo dos usuários? 17:04 <jrandom> tem havido algumas boas ideias lá e bons feedbacks 17:05 <jrandom> a capacidade de editar posts do Syndie é um recurso frequentemente solicitado, e com isso você poderia montar um wiki com um editor rico 17:05 <jrandom> mas, claro, nada vai existir no vácuo - se alguém acredita que isso é necessário, alguém deveria dizer "ei, um wiki é essencial, e eis o porquê" 17:06 <jrandom> há um número infinito de apps que /podem/ ser construídos, mas como estamos mirando forte anonimato e forte segurança, é preciso ter cuidado com o que é construído 17:07 <+tethra> certo 17:07 <+tethra> dito isso, algumas das coisas mais difíceis de manter anônimas e seguras talvez seja melhor serem feitas por alguém que seja bom em manter as coisas anônimas e seguras, certo? 17:08 <jrandom> provavelmente sim, embora não haja nenhum "cabal" - qualquer um pode aprender 17:08 <+tethra> (coisas-chave, basicamente. não que eu esteja nomeando alguma, mas enfim.) 17:08 <+tethra> verdade 17:09 <+tethra> mas aprender às custas da sua própria anonimidade e da de outras pessoas não é a melhor maneira de fazer isso 17:10 <jrandom> todo mundo tem que começar em algum lugar, claro 17:10 <+tethra> (talvez se alguém fizesse algo tipo um sandbox que permitisse às pessoas rodar $software e ter gente atacando e tal, isso seria bom para quem é novo/inexperiente?) 17:10 <+tethra> é 17:14 <jrandom> ok, mais alguém tem algo para a reunião? 17:15 <jrandom> se não 17:15 * jrandom vai encerrando 17:15 <@cervantes> *ahem* 17:15 * jrandom pausa 17:16 <jrandom> o que tá pegando, cerv? 17:16 <Complication> Legal, encontrei um baf ;P 17:17 <jrandom> baf-bloqueado ;) 17:17 <@cervantes> ops foi mal, continue baffando 17:17 * jrandom retoma o encerramento 17:18 * jrandom *baf*a a reunião encerrada