Reunião de Desenvolvedores do I2P - 18 de abril de 2005

16:09 <jrandom> 0) oi 16:09 <jrandom> 1) Status da rede e 0.6.1.16 16:09 <jrandom> 2) Criação de tunnel e congestionamento 16:10 <jrandom> 3) Feedspace 16:10 <jrandom> 4) ??? 16:10 <jrandom> 0) oi 16:10 * jrandom acena 16:10 <jrandom> notas semanais de status publicadas em http://dev.i2p.net/pipermail/i2p/2006-April/001281.html 16:10 * frosk também 16:10 <jrandom> (quase duas horas *antes* da reunião, também :) 16:11 <jrandom> ok, como tenho certeza de que vocês já esmiuçaram as notas, vamos passar para 1) Status da rede 16:12 <+Complication> Oi :) 16:12 * Complication pega as notas rapidamente 16:12 <jrandom> a versão 0.6.1.16 corrigiu um bug muito antigo no nosso PRNG (gerador de números pseudoaleatórios), que havia causado um número substancial de rejeições arbitrárias de tunnel 16:13 <jrandom> (a causa raiz foi introduzida em outubro passado, mas agora está corrigida) 16:13 <+Complication> Status por aqui: funciona toleravelmente com tunnels de 1 + 0..1 saltos, não se comporta com 2 + 0..1 ou 2 +/- 0..1 16:14 <jrandom> sim, isso é compreensível também, especialmente em links mais lentos 16:14 <jrandom> (infelizmente, “mais lentos” nem são tão lentos assim) 16:15 <jrandom> ainda há muito trabalho a fazer, e 0.6.1.16 não é onde precisamos estar, mas é um avanço 16:17 <+Complication> Algo em que venho pensando, em relação ao que você chamou de “colapso por congestionamento” 16:18 <+Complication> Uma forma de limitar o impacto poderia ser realmente *exigir* que um router aceite uma certa cota de pedidos de participação 16:19 <+Complication> (algo especificado pelo usuário, direta ou indiretamente?) 16:19 <jrandom> especificado por qual usuário? 16:19 <+Complication> (por exemplo, alguma parte do percentual de compartilhamento ou um parâmetro adicional) 16:19 <jrandom> o usuário local, ou por nós como usuários remotos? 16:19 <+Complication> Especificado por cada um para si 16:19 <@frosk> devemos passar para 2) então? :) 16:20 <jrandom> sim, podemos considerar que estamos no 2) :) 16:20 <+Complication> Para que eu pudesse, por exemplo, dizer ao meu router: “mesmo que você esteja congestionado, continue roteando no mínimo 4 KB/s” 16:21 <jrandom> Complication: isso não é realmente possível — se um router estiver muito congestionado, outras pessoas (com sorte ;) vão parar de pedir para ele participar em tunnels. 16:21 <+Complication> (isso, é claro, significaria que algum destino local poderia ficar offline por mais tempo) 16:21 <jrandom> e se não forem solicitados, eles /não podem/ enviar os dados de outras pessoas 16:22 <+Complication> Ah, talvez eu devesse ter formulado de forma significativamente mais clara 16:24 <+Complication> Eu imaginei que, sob uma certa cota de tráfego de participação, ele poderia limitar suas próprias mensagens de criação de tunnel em vez de limitar os tunnels de participação 16:24 <+Complication> por exemplo: “Nunca vou limitar meus tunnels de participação a menos de 4 KB/s. Se isso for necessário, vou limitar o meu próprio tráfego.” 16:26 <jrandom> hmm, há riscos para o anonimato nisso (ainda que na mesma linha de um DoS seletivo, contra o qual não nos defendemos de qualquer forma) 16:27 <jrandom> mas limitar nossas próprias construções de tunnel locais diante de congestionamento é algo que estou testando agora — adicionar suporte para, opcionalmente, ignorar o piso de 4KBps deve ser simples o suficiente 16:28 <spinky> Ativamente, você não obtém tráfego de cobertura ao transferir muitos dados. 16:29 <spinky> Ter um piso para a banda de participação parece bom. 16:30 <jrandom> bem, nós temos um piso (tanto como o percentual de compartilhamento quanto uma reserva interna de 4KBps depois que toda a banda é atribuída) 16:30 <+Complication> Bah, desconexões... Espero que não tenha se perdido muito do que eu disse, mas terei que ler as respostas no log :) 16:32 <@frosk> há algo significativo sobre 4KBps? 16:33 <jrandom> algumas coisas — 4KB ~= sizeof(mensagem de criação de tunnel), e, heurística­mente, eu nunca ouvi falar de um router funcionando com sucesso com menos 16:33 <spinky> Talvez sejam bugs que impedem o percentual de compartilhamento de funcionar então? 16:34 <jrandom> o que faz você dizer que o percentual de compartilhamento não funciona? 16:34 <@frosk> entendi 16:34 <+Complication> frosk: não, é só um número no código atual, e eu me referi a ele enquanto tentava explicar o que eu imaginei também 16:35 <+Complication> (não por motivos significativos, apenas porque o que eu imaginei era, de certo modo, o oposto equivalente) 16:35 <spinky> Está definido para 80% e a participação vai a 0 quando estou gerando dados localmente. Talvez eu esteja entendendo mal. 16:36 <jrandom> ah, sim, isso não é o que o percentual de compartilhamento faz 16:36 <+Complication> spinky: é um limite máximo do que pode ser compartilhado, sujeito à largura de banda realmente disponível para compartilhar 16:37 <+Complication> Se o tráfego local ocupa 70%, você só tem 10% restante para compartilhar 16:37 <+Complication> Se o tráfego local for pesado, você terá 0% restante, e o limite superior de 80% nunca será atingido 16:37 <spinky> Ok. Vejo que diz “até”... 16:38 <+Complication> E também há a reserva de 4 KB/s 16:38 <jrandom> ah, é o percentual de compartilhamento do que você tem disponível 16:38 <spinky> Talvez outra configuração para o piso de banda de participação, abaixo do qual o router aceitará mais tunnels? 16:38 <jrandom> se você estiver usando 95% da sua banda, ele vai compartilhar até 80% dos 5% restantes 16:39 <+Complication> Ah, então eu também entendi parcialmente errado 16:40 <fox> <zorglu1> como o i2p mede a quantidade de banda usada por outras aplicações locais? 16:40 <spinky> (Só dizendo, se você considera tráfego de cobertura uma coisa boa, talvez tê-lo configurável mesmo sob uso pesado de banda local seja algo bom) 16:40 <+Complication> Eu achava que era aplicado contra o limite sustentado 16:40 <jrandom> zorglu1: ele mede o uso de banda do i2p e conhece os limites de banda do i2p 16:41 <jrandom> oh, hmm, olhando de volta para o código, int availBps = (int)(((maxKBps*1024)*share) - used); 16:41 <jrandom> então você está certo, Complication 16:42 <jrandom> spinky: tráfego de cobertura só é tão útil assim em uma mixnet (rede de mistura) de baixa latência 16:42 <jrandom> isso adiciona algum incentivo para routers com banda mais alta, mas aqueles sem banda de sobra têm pouca alternativa 16:49 <jrandom> de qualquer forma, a questão do congestionamento de tunnel existe há um tempo, mas só recentemente foi exacerbada pelas taxas insanas de rejeição de tunnel 16:49 <jrandom> esperançosamente, a próxima revisão vai resolver isso para nós 16:49 <jrandom> ok, alguém tem mais alguma coisa sobre 2) criação de tunnel e congestionamento? 16:50 <@frosk> parece que seriam necessárias algumas mudanças no esquema de construção de tunnel 16:50 <+Complication> Espero que isso ajude a melhorar as coisas :) 16:51 <+Complication> Ah, a propósito... 16:52 <jrandom> bem, temos algumas correções simples, como reduzir a concorrência máxima, limitar nossas tentativas de construção quando congestionados, reduzir a frequência de descarte (em vez de rejeição explícita) e ajustar o perfil para incentivar rejeições explícitas em vez de descartes 16:52 <+Complication> ...por acaso vocês encontraram algo que pudesse explicar a grande disparidade entre os indicadores de largura de banda bruta e os indicadores de carga útil de tunnel? 16:52 <+Complication> (por exemplo, largura de banda total 1 GB, carga útil de tunnel somada 300 MB) 16:52 <jrandom> mas é verdade, isso só afeta a magnitude 16:52 <+Complication> (como eu não tenho aparecido no IRC ultimamente, não sei se vocês têm olhado isso recentemente) 16:54 <jrandom> não aprofundei muito nisso, mas lembrem-se, pedidos de construção de tunnel para tunnels de saída não são mensagens de tunnel (e há muitos deles se apenas 0,1% têm sucesso. e com 4KB cada...) 16:54 * Complication não tem certeza se são os indicadores ou um efeito real 16:55 <+Complication> Ah... pedidos de construção de saída... de fato 16:55 <jrandom> a próxima build -1 adiciona uma porção de estatísticas para monitoramento de pacotes por tipo de mensagem 16:55 <+Complication> Isso pode ser exatamente isso 16:55 <jrandom> (nesses pedidos de construção de saída também estão incluídos pedidos de participação na construção — encaminhando uma resposta) 16:56 <jrandom> ((então não é só coisa local)) 17:00 <+Complication>> Obrigado, isso explica bastante :) 17:00 <+Complication>> Então não é vodu, mas um tráfego bem real, que eu apenas esqueci, já que não estava especificamente contado nos lugares que verifiquei 17:00 <+Complication> De fato teria que ocorrer, e realmente custaria muitos bytes 17:00 <+Complication> Especialmente com taxas de sucesso baixas 17:01 <jrandom> sim, embora não devesse custar tanto quanto custa, já que deveríamos ter taxas de sucesso mais altas do que temos :) 17:01 <jrandom> ok, mais alguma coisa sobre o 2)? 17:02 <jrandom> se não, vamos passar para 3) Feedspace 17:02 <jrandom> frosk: quer nos dar uma atualização? 17:03 <jrandom> (ou mandar a gente ‘fsck off’ e ler o eepsite? ;) 17:04 <@frosk> bem, para quem não tem prestado atenção a frosk.i2p ou feedspace.i2p, o feedspace agora está basicamente funcionando (pela minha própria definição de “basicamente”) 17:04 <jrandom> (w00t) 17:05 <@frosk> houve algumas adições legais recentemente, como suporte infraestrutural para transports além do i2p (tor e tcp/ip não anônimo vêm à mente) 17:06 <@frosk> então, com o tempo, planejamos permitir que o syndie (em uma reescrita futura e provavelmente muito legal) use o feedspace como um de seus métodos de distribuição 17:06 <@frosk> por ora, não há aplicativos cliente para realmente *usar* o feedspace para nada :) tenho testado com um aplicativo servlet extremamente rudimentar 17:07 <jrandom> (rudimentar + funcional)++ 17:07 <@frosk> então há, claro, uma vaga para um hacker de cliente ;) 17:08 <@frosk> ainda há algumas coisas necessárias de que o feedspace precisa antes de qualquer teste público, mas não deve demorar :) 17:08 <jrandom> legal1 17:08 <jrandom> algo que possamos fazer para ajudar? 17:08 <@frosk> também tenho trabalhado um pouco na documentação, que estava em falta 17:09 <spinky> Você vê o feedspace sendo utilizável para arquivos grandes? 17:10 <@frosk> 1) aplicativos cliente usando a (ainda não documentada) API XML-RPC, 2) http://feedspace.i2p/wiki/Tasks, 3) participar dos testes quando chegar a hora 17:10 <@frosk> suporte a arquivos grandes não é prioridade agora, mas talvez depois 17:10 <@frosk> o foco para a “1.0” são mensagens menores, como entradas de blog e discussões, e eventos de qualquer tipo 17:11 <jrandom> embora alimentar arquivos .torrent em um cliente BT com suporte a RSS/feedspace não seria um problema 17:11 <@frosk> arquivos grandes podem ou não funcionar :) 17:11 <@frosk> isso seria muito bacana 17:12 <jrandom> feed2snark ;) 17:12 <@frosk> espero que vejamos todos os tipos desses apps “adaptadores” :) 17:12 <+Complication> Bem, tenho certeza de que as pessoas vão encontrar formas de mover arquivos grandes usando bit... hã, canais laterais :) 17:15 <@frosk> eu me sinto um pouco culpado pelo código do feedspace usar todo tipo de recursos do java1.5. provavelmente seria difícil compilar/usar em Java livre agora, mas vai alcançar, tenho certeza :) 17:15 <jrandom> caramba 17:16 <jrandom> bem, há rumores de que o gcj adote o ecj por causa dos 1.5-ismos 17:16 <spinky> Complication: Pôneis com alforjes cheios de HDDs? 17:16 <@frosk> sim 17:17 <+Complication> spinky: drones, no meu caso preferido :P 17:17 * jrandom ainda mal está avançando para os 1.4-ismos 17:17 <+Complication> Mas acho que pôneis também funcionam :P 17:17 <jrandom> embora 1.6 seja bem legal ;) 17:17 <@frosk> para permanecer compatível com gcj? 17:18 <@frosk> bem, 1.6 não tem muitos “-ismos” para a maioria das coisas de qualquer forma, acho :) 17:18 <+Complication> (ou ouriços voadores lançando cartões de memória do ar) 17:18 <jrandom> gcj/classpath/etc, mas também por desempenho (achei o 1.5 um pouco mais pesado que o 1.4) 17:19 <jrandom> verdade, as melhorias do 1.6 são em grande parte específicas de VM/bytecode 17:19 <@frosk> hm ok 17:20 * jrandom não está tentando te convencer a não usar 1.5-ismos. tenho certeza de que você tem seus motivos e, por exemplo, o azureus já exige 1.5 17:21 <@frosk> bem, não tem como voltar :) espero que não seja muito acidentado 17:24 <jrandom> sim, tenho certeza de que vai dar tudo certo :) 17:25 <jrandom> ok, legal, alguém tem mais algo sobre 3) feedspace? 17:25 * frosk abraça seus generics e java.util.concurrent ;) 17:25 <jrandom> heheh 17:27 <jrandom> ok, se não há mais nada no 3, vamos passar para 4) ??? 17:27 <jrandom> alguém tem mais alguma coisa para a reunião? 17:27 <+Complication> Uma perguntinha que eu deveria ter feito no 2) 17:28 <+Complication> Vocês sabem como os tunnels participantes ociosos normalmente se formam? 17:28 <+Complication> Eles são principalmente um sinal de construções de tunnel fracassadas, em que só o criador realmente sabe que fracassou? 17:28 <+Complication> Ou têm razões adicionais? 17:28 <+Complication> (além, é claro, do óbvio — um aplicativo parado) 17:29 <jrandom> um aplicativo ocioso não teria tunnels ociosos (eles seriam testados) 17:29 <jrandom> tunnels ociosos falharam por um motivo ou outro 17:29 <jrandom> (ou falharam em ser criados completamente, ou falharam durante a operação) 17:30 <+Complication> Certo, então todos os tunnels são testados de qualquer forma, e testes de tunnel devem causar tráfego... de fato 17:30 <+Complication> Isso na verdade me leva à segunda parte da minha pergunta: haveria algum benefício em notar que um tunnel está ocioso e descartá-lo cedo? 17:31 <+Complication> Há algum recurso valioso a ser economizado aí? 17:32 <jrandom> nenhum — um tunnel que não está enviando dados não está consumindo recursos 17:32 <jrandom> (ok, está usando um pouco de RAM, talvez 32 bytes) 17:32 <+Complication> Ou talvez isso poderia ajudar um router a manter uma noção melhor da sua carga e parâmetros semelhantes... 17:33 <jrandom> previsões sobre o uso de banda com base no histórico de tunnel são certamente uma questão em aberto 17:33 <+Complication> Ou seria apenas trabalho inútil, e o melhor é esperar até que expire naturalmente? 17:33 <+Complication> (como acontece agora) 17:34 <jrandom> costumávamos fazer algumas previsões, mas isso não nos deu benefícios claros, então estamos usando um algoritmo mais simples agora 17:34 <+Complication> Aha, então sem ganho... 17:34 <+Complication> Obrigado, isso era basicamente tudo o que eu queria perguntar sobre isso :) 17:34 <jrandom> de nada, preocupação compreensível 17:34 <jrandom> ok, alguém tem mais alguma coisa para a reunião? 17:35 <+Complication> É, se alguém fizesse previsões, o percentual de tunnels ociosos poderia enviesar as estimativas 17:35 <+Complication> (se variasse significativamente) 17:36 <jrandom> sim, gostaríamos de manter a % de ociosidade como parte da estimativa 17:36 <jrandom> (nós costumávamos — veja o método RouterThrottleImpl.allowTunnel) 17:37 <+Complication> Oh, não sabia disso :) 17:37 <jrandom> e observe o novo comentário: 17:38 <jrandom> // ok, ignore any predictions of 'bytesAllocated', since that makes poorly 17:38 <jrandom> // grounded conclusions about future use (or even the bursty use). Instead, 17:38 <jrandom> // simply say "do we have the bw to handle a new request"? 17:39 * Complication ainda está navegando até o arquivo, mas obrigado :) 17:39 <jrandom> w3rd 17:40 <jrandom> ok, se não há mais nada para a reunião... 17:40 * jrandom se apronta 17:41 * jrandom encerra a reunião com um *baf*