Reunião de Desenvolvimento do I2P - 28 de fevereiro de 2006

15:11 <jrandom> 0) olá 15:11 <jrandom> 1) Status da rede e 0.6.1.12 15:11 <jrandom> 2) Caminho para 0.6.2 15:12 <jrandom> 3) Miniprojetos 15:12 <jrandom> 4) ??? 15:12 <jrandom> 0) olá 15:12 * Complication lê rapidamente as notas 15:12 * jrandom acena 15:12 <jrandom> notas semanais de status publicadas em http://dev.i2p.net/pipermail/i2p/2006-February/001266.html 15:12 <jrandom> (e aqui estou eu publicando as notas mais de 15 minutos antes da reunião! ;) 15:13 <jrandom> ok, enquanto vocês leem aqueles trechos tão empolgantes, vamos pular direto para 1) Status da rede e 0.6.1.12 15:14 <jrandom> como mencionado, os objetivos principais dos lançamentos 0.6.1.10-0.6.1.12 parecem ter sido alcançados, abordando a mudança na criptografia de criação de tunnel e melhorando substancialmente a confiabilidade da criação 15:16 <jrandom> os problemas que vimos na 0.6.1.10 sumiram, e a estabilidade do IRC parece estar bem boa novamente 15:16 <jrandom> alguém tem mais algo para trazer em 1) Status da rede e 0.6.1.12, ou vamos seguir para 2) Caminho para 0.6.2? 15:17 <+Complication> Status da rede por aqui: nada de cair abaixo de 20 KB/s :) 15:18 <jrandom> legal, sim, a 0.6.1.12 corrigiu um bug bem grande na 0.6.1.11 onde ela não aproveitava a largura de banda disponível. agora deve fazer melhor uso dos recursos disponíveis 15:20 <jrandom> ok, vamos passar para 2) 15:20 <jrandom> como mencionado, há algumas coisas que precisam ser resolvidas antes de a última mudança funcional ser colocada em prática para a 0.6.2, mas estamos fazendo progresso nesse sentido 15:20 <nymisis> status da rede está ok :) 15:22 <jrandom> certo. haverá mais informações disponíveis sobre os detalhes das novas estratégias de ordenação de pares antes de saírem, mas a essência delas deve estar clara a partir da breve menção nas notas 15:23 <jrandom> alguém tem dúvidas/comentários/preocupações sobre 2) caminho para a 0.6.2? 15:23 <postman> jrandom: alguma rede de teste desta vez? 15:24 <postman> (precisam de algum routers, participantes para testar coisas) 15:24 <postman> ? 15:24 <+Complication> A essência da questão pareceu bastante direta — limitar a oportunidade de um adversário coletar dados estatísticos diversos 15:25 <+Complication> Parece um recurso bastante desejável 15:25 <jrandom> postman: as novidades devem funcionar de forma transparente na rede ao vivo usando apenas informações locais, então não deve ser necessário uma rede separada para testar 15:25 <jrandom> sim, exatamente, Complication 15:26 <postman> ok 15:26 <postman> jrandom: você é ousado o bastante para divulgar uma previsão para a 0.6.2 ? :) 15:27 <blubb> 1º de abril 15:27 <jrandom> bem, visto que hoje é o fim de fevereiro, eu diria março ou abril 15:27 <postman> hehe 15:27 <jrandom> blubb: já temos um backdoor do MI6 agendado para então ;) 15:29 <@cervantes> mais como uma portinhola de gato do MI6 15:29 <@cervantes> (cortes no orçamento) 15:29 <postman> num recinto de elefantes 15:30 <nymisis> Isso é SIS, não MI6, se quiser ser preciso. :) 15:30 <jrandom> bem, vamos apenas chamá-los de Eles ;) 15:31 <jrandom> ok, mais algo para 2)? 15:31 <jrandom> se não, vamos passar para 3) miniprojetos 15:31 <@cervantes> desculpe, "the firm" 15:34 <jrandom> ok, eu só queria destacar algumas coisas legais que seriam 1) simples de fazer e 2) realmente úteis 15:34 <+Complication> Do lado dos miniprojetos, não tenho certeza se minha resposta sobre o Syndie chegou ou não, mas estou pensando se poderia pegar um. 15:34 <+Complication> Ainda não sei qual. Atualmente estou praticando um pouco mais de Java (fazendo um microprojeto :D) só para ter mais certeza de que, quando eu tentar, vou conseguir dar conta de um 15:35 <DeltaQ> hmm, se eu aumentar a largura de banda no console, as mudanças são imediatas ou precisa reiniciar? 15:35 <+Complication> Quando eu terminar o "microprojeto" (assumindo, claro, que a lista ainda não tenha sido esvaziada), vou tentar escolher um 15:35 <jrandom> w3wt, ótimo, Complication 15:36 <jrandom> DeltaQ: imediatamente 15:36 <@cervantes> não é que 1) syndie scheduler se integra com 4) Download Manager / eepget scheduler 15:36 <+Complication> DeltaQ: entra em vigor quase instantaneamente (dentro dos períodos nos quais a largura de banda é calculada como média) 15:37 <@cervantes> parece-me que um gerenciador de upload e download mais geral atenderia a ambas as necessidades 15:37 <jrandom> cervantes: hmm, não necessariamente. 1) é bem focado e também inclui pushes, enquanto 4) é bem genérico 15:37 <+Complication> cervantes: parece que poderia 15:37 <jrandom> mas sim, o motor por trás de ambos é o EepGet 15:37 <jrandom> (eepget faz as transferências HTTP do Syndie, programaticamente) 15:38 <DeltaQ> a média não parece ir acima de 13kb/s 15:38 <DeltaQ> eu defini 64kb/s com burst de 192 no download 15:38 <DeltaQ> 32/64 up 15:38 <@cervantes> então um eepget genérico de push e pull com uma API de agendamento e gerenciamento... 15:39 <@cervantes> ainda assim, provavelmente deixa de ser um mini-projeto nesse ponto 15:39 <+Complication> DeltaQ: a média também depende de quanta carga seus client tunnels (e os tunnels participantes de outros pares) geram 15:39 <+Complication> desculpa, s/média/largura de banda real 15:39 <jrandom> cervantes: sim, há uma lógica considerável envolvida nas coisas do Syndie, no entanto. 15:40 <DeltaQ> hehe, finalmente subiu 15:40 <DeltaQ> 1s: 30.82/29.33KBps 15:40 <DeltaQ> acho que eu precisava aumentar a largura de banda de upload 15:40 <jrandom> DeltaQ: a média também será afetada por como as outras pessoas o veem, o que depende das suas ações, e não de qualquer taxa anunciada, então vai levar um pouco 15:40 <+Complication> DeltaQ: para tráfego de passagem (tunnels participantes), o que entra também precisa sair 15:41 <+Complication> DeltaQ: então taxas UL/DL muito diferentes iriam estrangular o tráfego participante para a menor das duas 15:42 <+Complication> DeltaQ: além disso, o tráfego participante depende de como outros nós "percebem" a capacidade de roteamento do seu nó 15:42 <DeltaQ> oki 15:43 <+Complication> Se acharem que ele consegue rotear bem, vão pedir com mais frequência 15:43 <jrandom> ok, se não houver mais nada em 3) miniprojetos, vamos passar para 4) ??? 15:43 <jrandom> alguém tem mais algo para trazer para a reunião? 15:43 <DeltaQ> bem, estou atrás de um router mas eu fiz o mapeamento da porta 8887 para este pc 15:43 <+Complication> Se for novo, ou se só recentemente aumentou a capacidade, eles ficam um pouco tímidos 15:44 <DeltaQ> ah, desculpa, eu não quis atrapalhar a reunião ^^ 15:44 <+Complication> Alguém perguntou outro dia sobre possíveis ataques baseados em clock skew (desvio do relógio). Acho que vi sua resposta sobre a parte de tunneling (a mensagem de criação contém apenas o período de validade do tunnel, não o horário do ponto de vista de quem a criou)... 15:44 <@cervantes> (obrigado pela menção nas notas de status) ;-)_ 15:46 <+Complication> Então pensei, na verdade, em perguntar... quais pontos, se é que há algum, nas mensagens do I2P, poderiam conter o horário do ponto de vista do remetente? 15:47 <+Complication> Não consegui me atualizar sobre isso, então estou um pouco perdido 15:47 <jrandom> Complication: nada diz explicitamente "I think it is now $time", mas, com tráfego suficiente e análise temporal, provavelmente daria para restringir substancialmente 15:48 <jrandom> nós quantizamos os tempos em um período grande, embora não tão grande quanto o nosso desvio máximo de relógio, então há margem aí 15:49 <+Complication> Você acha que haveria, no fim das contas, algum benefício em um cliente NTP mais "enxuto"? 15:49 <+Complication> Um que pudesse manter os desvios menores com mais facilidade? 15:50 <jrandom> bem, desde que o cliente SNTP foi introduzido no i2p, ele vem melhorando cada vez mais, de modo que agora não vemos a variação que víamos antes 15:51 <jrandom> talvez pudéssemos reduzir o limite de desvio mínimo de 10s para talvez 2 ou 3s, ou até menos 15:51 <jrandom> alternativamente, poderíamos permitir que ele considerasse também os desvios de relógio do ssu para evitar desvios desnecessários 15:52 <+Complication> Ou, alternativamente, seria possível limitar ainda mais qualquer oportunidade de adivinhar o possível valor do relógio de outro par? 15:53 * Complication não sabe qual caminho seria mais prático, só sugerindo possibilidades aleatórias :D 15:53 <jrandom> não, nós sabemos o desvio do relógio dos pares diretamente conectados 15:55 <Magii> há alguma maneira de saber se a atualização foi feita com sucesso? 15:55 <+Complication> Aha, então o protocolo de sessão realmente depende dessa informação.. 15:55 <tethra> olhe o seu número de versão 15:55 <+Complication> Magii: deve registrar um CRIT como "update verified, restarting to install" nos logs 15:55 <tethra> :/ 15:55 <+Complication> Depois, deve fazer uma contagem regressiva de minutos para um reinício suave 15:56 <+Complication> E por fim reiniciar 15:57 <+Complication> Ah, observação: o cliente NTP interno conhece um conceito como "taxa de deriva do relógio"? 15:58 <jrandom> sim, o número de versão no canto superior esquerdo de http://localhost:7657/index.jsp deve entregar :) 15:58 <jrandom> Complication: não, ele não garante tique-taques do relógio sequenciais 15:59 <jrandom> s/sequenciais/ordenados/ 15:59 <+Complication> Nem desenvolve conhecimento do tipo "nosso relógio do sistema é 0,00345 vezes mais rápido do que o necessário"? 16:00 <jrandom> ah, não, embora adicionar isso a net.i2p.util.Clock não fosse tão difícil (quer um miniprojeto? :) 16:00 <+Complication> Eu estava pensando em algo nessa linha 16:01 <+Complication> Acho que agora estou pensando um pouco mais sobre isso :) 16:01 <+Complication> Mas, primeiro, outros miniprojetos :) 16:02 <jrandom> ok, alguém tem mais algo para a reunião? 16:03 <nymisis> Muffins? 16:04 <jrandom> não, panquecas 16:04 <jrandom> (mmMMmm panquecas) 16:04 <jrandom> por falar nisso 16:04 * jrandom se prepara 16:04 <nymisis> Ah, puxa, bem lembrado. 16:04 * jrandom *baf* encerra a reunião