Reunião de desenvolvimento do I2P - 22 de fevereiro de 2005

13:04 <jrandom> 0) oi 13:04 <jrandom> 1) 0.5 13:04 <jrandom> 2) Próximos passos 13:04 <jrandom> 3) azneti2p 13:04 <jrandom> 4) ??? 13:04 <jrandom> 0) oi 13:04 * jrandom acena 13:05 <jrandom> notas semanais de status publicadas em @ http://dev.i2p.net/pipermail/i2p/2005-February/000595.html 13:05 <jrandom> (é, só um ou dois minutos antes da reunião, então vamos testar sua leitura dinâmica) 13:05 <+detonate> acho que vou esperar até estar um pouco menos bugado antes de colocar boondock saints no ar, nesse caso 13:06 <jrandom> por que... isso é... isso é... isso é uma violação de direitos autorais! 13:06 <+detonate> adições estranhas na beta do Azureus 13:06 <+detonate> categorias 13:06 <+detonate> haha 13:06 <+detonate> um tracker DHT 13:06 <+detonate> legal 13:07 <jrandom> sim, parece muito legal, mas vamos tratar dos itens 1 e 2 antes do 3, ok? ;) 13:07 <+detonate> oi 13:07 <+detonate> de fato 13:07 <jrandom> pulando para 1) 0.5 13:07 <jrandom> tipo, saiu, e tal 13:08 <cervantes> oba! 13:08 <jrandom> vai sair uma nova revisão mais tarde hoje com um monte de atualizações (o head atual do CVS é 0.5-5, com um -6 em teste em alguns routers) 13:09 <jrandom> tem ido muito bem, mas encontramos alguns bugs esquisitos no caminho. mas é a vida 13:09 <frosk> posso relatar que o 0.5-5 se comporta _bem_ mais amigavelmente do que o -4 (que frequentemente me dava contagens de tunnels participantes na casa dos milhares) 13:09 <bla> jrandom: A versão 0.5.0.1 vai corrigir o problema de não conseguir encontrar destinos? 13:09 <jrandom> ah, bem, isso na verdade é mais função de outras pessoas, porém o build -0 realmente constrói centenas de tunnels 13:09 <bla> s/nor/not 13:10 <jrandom> bla: sim, isso é um bug na netDb 13:10 <bla> jrandom: Ótimo! 13:10 <jrandom> (especificamente na publicação do leaseSet) 13:11 <jrandom> e sim, a revisão 0.5.0.1 vai eliminar aquele bug do proxy que some ocasionalmente 13:12 <jrandom> ainda há um vazamento de memória estranho que eu não rastreei, afetando alguns usuários 13:12 <bla> Então, no geral, parece que tirando esses bugs, a rede 0.5 está indo muito bem. Oba! 13:12 <jrandom> até onde sei, isso só está afetando duas ou três instâncias de I2PTunnel 13:12 <Meomia> é sinal de progresso quando você passou de 0 para 130 tunnels participantes desde o 0.5 ? 13:13 <jrandom> w3wt 13:13 <jrandom> Meomia: bah, eu já tive mais de 5000 tunnels ;) 13:13 <jrandom> mas o dm na verdade ajudou a encontrar um bug no código do pool exploratório, então vamos construir tunnels com mais frequência em pares 'aleatórios' 13:14 <jrandom> (oba) 13:14 <Meomia> ok 13:14 <bla> jrandom: Isso também significa que agora, ao contrário do 0.4, qualquer par pode, em algum momento, se tornar seu gateway de entrada? 13:14 <jrandom> sim, para tunnels exploratórios 13:15 <jrandom> tunnels de cliente só vão usar pares no nível 'fast' 13:15 <bla> bla: Ok. O fato de os tunnels de cliente usarem apenas os pares rápidos é bom: caso contrário, temos o problema de anonimato que discutimos antes 13:16 <jrandom> e a performance ficaria péssima do contrário ;) 13:17 <jrandom> na verdade, isso nos leva a 2) Próximos passos 13:18 <jrandom> o grande item que resta para a série 0.5 é um conjunto de estratégias para ordenar e/ou filtrar os pares usados nos tunnels 13:18 <godmode0> jrandom pode usar NNTP com i2p ? 13:18 <jrandom> godmode0: há dois servidores NNTP no i2p, sim. veja o fórum 13:19 <godmode0> jrandom ok, estou testando 13:19 <godmode0> posso montar meu servidor também ? 13:20 <jrandom> godmode0: estamos em uma reunião agora, mas sim, você pode rodar um servidor 13:20 <godmode0> jrandom ok desculpa 13:20 <jrandom> sem problema 13:20 <jrandom> as estratégias publicadas são basicamente voltadas a melhorar o anonimato, mas há alguns outros objetivos que podemos equilibrar ali 13:21 <jrandom> talvez possamos encontrar uma forma de integrar alguns dos caminhos AS (Sistema Autônomo) na seleção, como o bla sugeriu 13:22 <jrandom> isso pode tanto melhorar o anonimato (jurisdicional) quanto, se tentarmos permanecer dentro de um AS (ou dois), melhorar a performance 13:22 <bla> jrandom: Isso basicamente está relacionado a um artigo dos criadores do Tor: http://theland.i2p/files/routing-zones.pdf 13:22 <jrandom> sim 13:23 <jrandom> há uma porção de estratégias diferentes que as pessoas podem usar, e experimentar novas deve ser bem fácil 13:24 <jrandom> não vamos passar meses implementando tudo que pudermos imaginar, mas sim fornecer o básico do que a maioria vai precisar. quem quiser adicionar novas estratégias é mais do que encorajado a ajudar a integrá-las 13:25 <jrandom> de qualquer forma, quando o básico estiver no lugar, vamos passar a focar no transporte UDP para o 0.6 13:26 <jrandom> é basicamente isso que eu tenho para 2) próximos passos, alguém tem comentários/perguntas/preocupações? 13:26 <bla> Quem eram as pessoas que começaram a olhar o I2P, mesmo? 13:26 <bla> Parece que não temos ouvido muito deles ultimamente. 13:27 <bla> s/into I2P/into UDP/ 13:27 <bla> desculpa 13:27 <jrandom> ah, o mule esteve doente, embora eu ache que o detonate esteja progredindo 13:28 <jrandom> detonate: alguma novidade? 13:29 <jrandom> ou talvez não ;) 13:30 <jrandom> ok, passando para 3) azneti2p 13:30 <+detonate> foi mal 13:30 <+detonate> estou progredindo 13:30 <+detonate> ainda preciso terminar a parte de remontagem das coisas 13:31 <+detonate> quanto a dividir os dados em pacotes e enviá-los de forma ordenada, isso funciona 13:31 <+detonate> indo para o 3) 13:31 <jrandom> da hora 13:31 <godmode0> desculpa passo 2) o i2p tem algum problema com ataques ? 13:31 <bla> detonate: Legal! Pode manter todos nós informados no fórum? 13:32 <+detonate> bla: claro 13:32 <tracker> Sobre o azneti2p, veja aqui: http://sourceforge.net/forum/forum.php?thread_id=1233727&forum_id=377614 parece que o download funciona, fazer seed não. 13:32 <jrandom> godmode0: as diferentes estratégias de ordenação devem permitir que o usuário escolha o impacto de ataques de predecessor 13:33 <microsoft> quem quer que administre o i2p.net deveria adicionar mais buzzwords de Soluções Classe Enterprise na página. 13:33 <+detonate> alguém precisa verificar se aquele novo tracker DHT não está se comportando mal também, em relação ao plugin do Azureus 13:33 <tracker> Meus testes locais parecem confirmar isso, consigo fazer download com o Azureus mas não fazer seed. 13:34 <jrandom> hmm ok legal, tracker, valeu — eu sei que eles atualizaram algumas coisas e lançaram o b34 ontem à noite, mas parece que ainda há mais a fazer 13:34 <jrandom> detonate: bem lembrado 13:35 <tracker> Bem lembrado, detonate, eu deixo o DHT desativado porque o Azureus trava depois de algumas horas com 100% de uso de CPU quando está ativo. 13:35 * jrandom gostaria de reiterar que o plugin azneti2p ainda está em beta bem inicial, e as implicações de anonimato do Azureus não foram totalmente auditadas 13:36 <jrandom> embora eu tenha certeza de que eles adoram que as pessoas testem, quem precisa de anonimato talvez deva ter cautela 13:36 <tracker> Por outro lado, o i2p-bt funciona muito bem. Exceto que ele não fecha os tunnels, mas isso não é tão ruim na minha opinião. 13:37 <jrandom> oh, isso ainda está acontecendo com você, tracker? eu não consegui reproduzir 13:37 <jrandom> você está na revisão 0.1.7, certo? 13:37 <tracker> Sim, estou. 13:38 <jrandom> ok, legal, se isso acontece sempre com você eu gostaria muito de pedir sua ajuda depois da reunião para ajudar a rastrear a causa 13:39 <tracker> Talvez esteja relacionado a rodar no XP em vez de linux ou unix. Fechar o tunnel funciona com o Azureus, então acho que é algo relacionado ao I2P-BT. 13:39 <jrandom> hmm certo, o i2p-bt usa o SAM, enquanto o Azureus usa o i2p SDK diretamente 13:40 <tracker> A propósito. Te enviei um relatório de bug no fórum. O timestamper está quebrando nos últimos builds do CVS do I2P. 13:40 <jrandom> ah legal, obrigado, não chequei minhas PMs lá hoje 13:41 <jrandom> no -5 ou -4? ou antes? 13:42 <jrandom> ah, -4. ok, legal 13:42 <jrandom> valeu, vou corrigir isso para o 0.5.0.1 13:42 <jrandom> ok, alguém tem mais alguma coisa para 3) azneti2p? 13:43 <tracker> Também está acontecendo no -5 13:43 <jrandom> você tem servidor sntp definido explicitamente, certo? 13:44 <tracker> Sim. Os 2 do nosso país. 13:44 <jrandom> acabei de verificar o source e a exceção ocorre se o # de servidores concorrentes (padrão = 3) for maior que o # de servidores especificados (o novo padrão tem 3) 13:44 <jrandom> ok, legal, é uma correção trivial de fazer % # servers 13:45 <jrandom> ok, se não há mais nada sobre azneti2p, passando para o bom e velho 4) ??? 13:46 <jrandom> mais alguém tem algo para trazer para a reunião? 13:46 <tracker> Legal. Acabei de te enviar os erros de log do router ao fechar o i2p-bt no fórum. 13:47 <jrandom> 'k legal, valeu 13:47 <cervantes> nada a mencionar além de: bom trabalho com o rollout do 0.5, parece que vai arrebentar quando os bugs forem resolvidos 13:48 <tracker> Sim, os builds mais recentes do CVS estão tendo um desempenho muito bom por aqui. 13:48 <jrandom> valeu, com a ajuda de vocês e do resto dos testadores do 0.5-pre conseguimos limpar um monte de problemas 13:49 <jrandom> a performance tem sido melhor do que eu esperava, embora ainda não com tanta vazão quanto antes. ainda há muito a otimizar 13:49 <cervantes> estranhamente as versões pré eram mais estáveis... para mim, mas aí, eu estava rodando em uma máquina diferente ;-) 13:49 <jrandom> (e esses malditos bugs até a confiabilidade ficar onde deve) 13:50 <jrandom> heh bem, é, mas a rede -pre tinha 5-7 routers, todos absurdamente confiáveis em conexões muito, muito rápidas 13:50 <cervantes> :) 13:51 <cervantes> me inscreva para o teste pré do 0.6 então :) 13:51 <jrandom> heh 13:51 <tracker> Talvez eu devesse participar da próxima rede pré então. Fornecendo uma conexão bem instável e lenta ;). 13:51 <jrandom> a migração para o 0.6 provavelmente será ainda mais fácil, espero, já que poderemos apenas adicionar novos endereços do router ao routerInfo (endereços UDP) 13:51 <jrandom> heh isso aí 13:51 <cervantes> posso colocar meu compartilhamento de 1TB online... 13:52 <jrandom> vamos definitivamente precisar de muita ajuda com os testes do 0.6, cobrindo uma grande variedade de configurações de rede 13:52 <hobbs> o comando ssh '~C' é bacana 13:52 <laberhorst> isso vai ser outro passo não compatível? 13:53 <Myo9> Alguém sabe quais servidores NNTP estão no ar? 13:53 <jrandom> laberhorst: não, o 0.6 será compatível com versões anteriores 13:53 <jrandom> Myo9: não sei, podem estar no ar e só terem sido mordidos pelos bugs do 0.5-0 13:54 <jrandom> a revisão 0.5.0.1 deve corrigir muitos problemas e, quando sair, atualizar será altamente recomendado 13:54 <laberhorst> então é só construir um 0.6 de teste e passar para os testadores 13:54 <cervantes> podemos fazer o tráfego de BT usar apenas routers desatualizados... isso vai incentivar o pessoal a atualizar ;-) 13:54 <laberhorst> então grande festa de upgrade amanhã 13:54 <jrandom> haverá um anúncio no fórum e na lista quando estiver pronto 13:54 <jrandom> isso mesmo, laberhorst 13:54 <jrandom> heh cervantes ;) 13:55 <laberhorst> *ansioso para testar para vocês* 13:55 <jrandom> a performance do BT tem sido bem boa no 0.5, tenho visto muitas transferências de arquivos grandes com sucesso nos trackers 13:55 <laberhorst> pload rate: 8.85 kB/s 13:55 <jrandom> (e o irc não foi afetado como antes, além dos problemas que temos tido com o tunnel do duck) 13:55 <tracker> Depende do que você chama de grande ;) 13:56 <jrandom> tracker: estou pensando de um arquivo específico de 874MB que teve um monte de downloads bem-sucedidos ;) 13:56 <jrandom> mas é verdade, isso é pequeno para alguns 13:56 <laberhorst> apenas o bom e velho pornô 13:56 <laberhorst> eu suponho ;-) 13:57 <laberhorst> vamos torcer para que a partir de amanhã meu router não participe em>3000 tunnels 13:57 <tracker> Ok, isso é grande. 13:57 <laberhorst> ou, se for o caso, a rede É grande 13:57 <jrandom> heh laberhorst 13:58 <jrandom> ok, mais alguém tem algo para a reunião? 13:58 <laberhorst> a propósito, participar em>3000 é sinônimo de um bom router confiável no i2p com conexão rápida? 13:58 <+detonate> vou colocar boondock saints no ar depois que eu pegar House hoje à noite :) 13:59 <+detonate> vai ser uns bons 4,1 GB :) 13:59 * laberhorst só quer agradecer aos desenvolvedores pela correção rápida de bugs 13:59 <+detonate> parece haver muita demanda 13:59 <laberhorst> oh, algumas imagens de DVD estão aqui, também 13:59 <hobbs> detonate: ooh, verdade. House. :) 13:59 <tracker> cervantes, você já atualizou para o phpBB 2.0.12 13:59 <laberhorst> mas espere até o 0.5.0.1 sair 13:59 <+detonate> deve dar um bom shake-down no 0.5.0.1 também 14:00 <+detonate> sim 14:00 <+detonate> pretendo 14:00 <jrandom> somente pessoas que já possuem cópias legais desses arquivos devem baixá-los, claro. isso é só para testes 14:00 <jrandom> *cof* 14:00 <tracker> rofl 14:01 * jrandom observa mpaa.i2p 14:01 <+detonate> heh 14:01 <laberhorst> oh, posso criar imagens iso de debian, fedora, suse, fotos que eu fiz,... 14:01 <laberhorst> então muito material legal 14:01 <laberhorst> se você só quer testar, /dev/random é MUITO grande 14:01 <Ragnarok> nem sempre 14:02 <laberhorst> a propósito, para fins de semana solitários: cat /dev/random | grep linux :-) 14:02 <jrandom> heh 14:02 <frosk> /dev/random esvazia o tempo todo, eu prefiro /dev/urandom :) 14:02 <frosk> ou o novo e melhorado /dev/jrandom 14:02 <jrandom> nah, isso dá core dump o tempo todo 14:03 <jrandom> e precisa do seu descanso noturno 14:03 <Ragnarok> qual é a melhor forma de gerar entropia para o /dev/random? 14:03 <laberhorst> a gente devia mesmo criar o fundo "arranjar umas cervejas para o jrandom" 14:03 <frosk> chame de descanso ou coleta de entropia :) 14:03 <hobbs> Ragnarok: Depende do que você realmente quer dizer. Conseguir um RNG de hardware seria mais ou menos a forma "ideal" :) 14:03 <jrandom> Ragnarok: depende do seu SO (e se você tem hardware ;) 14:04 <tracker> dd if=/dev/urandom of=/dev/hda bs=1M count=4 Sempre bom ;) 14:04 <jrandom> na verdade vamos incluir uma implementação do Fortuna em um desses builds, e vamos precisar garimpar várias fontes de entropia 14:04 <Ragnarok> sem hardware :P 14:04 <susi23> . o O ( Achei que alguém usando i2p sabe por que não deveria usar /dev/urandom ) 14:05 <cervantes> tracker: as falhas de segurança cobertas no 2.0.12 o meu mod_rocinante corrige inadvertidamente, então não me preocupei em atualizar ainda 14:05 <hobbs> susi23: quando é só por travessura, acho que tudo bem ;) 14:05 <ant> <Nolar> quem aqui faz o porte de BT em Python? 14:05 <jrandom> Nolar: seria o duck 14:06 * duck assobia 14:06 <ant> <Nolar> duck: por que vocês mudaram o tamanho do bloco de requisição para 128k ? 14:06 <susi23> . o O ( o próximo sugere: while true; do echo $RANDOM>> largefile; done ) 14:06 <ant> <Nolar> é por isso que o az não consegue fazer seed para você 14:06 <tracker> cervantes: Ok 14:06 <ant> <Nolar> nós bloqueamos requisições> 64k 14:06 <laberhorst> poxa, preciso de mais mp3 14:06 <frosk> susi23: para grepar por linux numa noite ociosa, /dev/urandom está ótimo :) 14:07 <jrandom> ah, sempre foi? se bem me lembro, o i2p-bt tem usado 128k há um tempo 14:08 <ant> <Nolar> sim, está assim desde o começo :) 14:08 <ant> <Nolar> algum motivo para usar 128? 14:08 <ant> * duck procura no log do cvs 14:08 <jrandom> mantém o pipeline cheio, o i2p tem uma certa latência ;) 14:08 <jrandom> com 32KB, isso é essencialmente um tamanho de janela fixo de 1 14:09 <jrandom> então cada mensagem fica bloqueada esperando um ACK, enquanto 128KB permite que 4 mensagens voem no RTT 14:09 <@duck> certo, tamanho máximo de fatia permitido de acordo com as especificações do BT 14:09 <ant> <Nolar> bem, há duas formas de lidar com isso: 1) aumentamos o limite para 128k do nosso lado, ou 2) vocês simplesmente fazem pipeline de mais requisições 14:09 <cervantes> i2pbt está um pouco mais esperto do que costumava ser... talvez dê para reduzir... 14:10 <@duck> schni, schna, schnappi 14:10 <ant> <Nolar> então, em vez de fazer um único pedido de 128k, mande, por exemplo, dois de 64k 14:10 <hobbs> duck: haha... essa coisa rodou o mundo. 14:10 <@duck> por que vocês bloqueiam 128k? 14:11 <cervantes> *arrepio* europop 14:11 <laberhorst> duck: por favor, fique quieto OU eu derrubo você! 14:11 <tracker> Às vezes me arrependo de ter aprendido alemão alguns anos atrás... 14:11 <laberhorst> sem europop, realmente não POP 14:11 * cervantes ordena ao Reino Unido que repila as fronteiras antes que uma música dessas entre nas paradas 14:11 <laberhorst> tracker: não ligue, está ok 14:12 <ant> <duck> agora é (2^17)-13 14:12 <ant> <Nolar> duck: bem, o limite está aí há um tempo, mas uma boa razão é que blocos de 128K demoram para enviar.....16KB (nosso padrão) permite um controle mais fino dos pedidos 14:12 <ant> <duck> 13 bytes é o comprimento do comando do bittorrent 14:12 <ant> <duck> não teria problema em (2^16)-13 14:12 <laberhorst> algumas músicas são realmente ridículas, mas música industrial de verdade, bah, não 14:13 <ant> <duck> ou voltar ao padrão? 14:13 <jrandom> reduzir para 64KB parece o mais simples (isso é um parâmetro de CLI no momento?) 14:13 <ant> <duck> --download_slice_size 14:14 <ant> <Nolar> bem, minha pergunta é: vocês têm uma razão convincente para manter blocos de 128K, o que me parece um pouco grande, especialmente para i2p 14:14 <ant> <Nolar> ao invés de apenas fazer pipeline de múltiplos pedidos menores? 14:14 <ant> <duck> Não tenho motivo. 14:14 <tracker> laberhorst: Às vezes eu pego alguns canais alemães via satélite. Especialmente a viva e aquele "Theater Kanal" são realmente horríveis... 14:15 <ant> <Nolar> um problema com blocos grandes é que, uma vez que eu dê choke em você, ainda tenho que terminar de enviar aquele pedaço de 128k 14:15 <jrandom> não lembro se o bt vanilla sabe fazer pipeline, mas deveria ser simples o suficiente (especialmente porque não sou eu que estou fazendo ;) 14:15 <ant> <Nolar> o que pode demorar 14:15 <laberhorst> tracker: a viva só é interessante no horário de "hard rock", o resto do tempo "por favor ignore", e o theater, não sei 14:15 <jrandom> com i2p, 128KB não é tão grande assim, já que há uma latência inerente na ordem de segundos 14:15 <ant> <Nolar> o que pode bagunçar o chunk/unchoke 14:16 <@duck> jrandom: ainda faz sentido subtrair a sobrecarga de 13 bytes do bittorrent para caber numa mensagem sam? 14:16 <jrandom> duck: nah, já que a streaming lib já reduz mais para mensagens de 16KB, então deixe em 64KB 14:17 <@duck> ok, 2**16 então 14:17 <jrandom> (e então os tunnels quebram essas mensagens de 16KB em fragmentos de 996 bytes..) 14:17 <ant> <Nolar> o problema com 128k é que, se eu estiver enviando a, digamos, 12 k/s, então vai levar mais de 10 segundos para terminar aquele bloco 14:18 <cervantes> uau, isso é quase tanto quanto a latência no irc... 14:18 <jrandom> o que dá de 1 a 10 RTTs (enquanto na rede normal, 10-500) 14:18 <+detonate> eu estava pronto para usar blocos de 512K 14:18 <ant> <Nolar> vocês também podem experimentar fazer pipeline de blocos de 16kb 14:18 <jrandom> heh 14:18 <+detonate> então 64 é preferido? 14:19 <ant> <Nolar> todos os clientes bt, que eu saiba, usam blocos de 16KB 14:19 <ant> <duck> corrigido no CVS; 14:19 <jrandom> massa, valeu duck! (e Nolar!) 14:19 <ant> <duck> espere que isso apareça no release 0.1.8 junto com alguns ajustes de sam i2cp 14:19 <tracker> laberhorst: O nome completo é "ZDF Theater" ou algo assim. E bem, eles dizem que transmitem um programa de alto nível cultural. Eu realmente espero que o que eles transmitem não seja o melhor que a cultura alemã pode oferecer ;) 14:19 <jrandom> ok, heh, acabei de lembrar que ainda estamos numa reunião 14:19 <jrandom> mais alguém tem algo para a reunião? 14:20 <ant> <Nolar> então, se quisermos um chunk de 128k, só fazemos 8 pedidos simultâneos 14:20 <susi23> . o O ( e descartar os 448 bytes restantes? ) 14:20 <jrandom> isso, isso 14:20 <laberhorst> tracker: oh, esse é um canal secundário pequeno... arte ou 3sat são realmente mais interessantes 14:20 <laberhorst> e arte é alemão/francês :-) 14:20 <ant> <Nolar> se o uploader puder atender tal pedido, todos os 128k devem ser empurrados para o stream de pipe do i2p 14:20 <jrandom> legal 14:21 <cervantes> . o O ( se pergunta por que consegue ouvir tudo que a susi está pensando ) 14:21 <ant> <Nolar> então pode valer a pena experimentar tamanhos de blocos de 16KB vs 32KB vs 64KB 14:21 <jrandom> sim 14:21 <jrandom> contanto que seja pipelined, o i2p não liga 14:21 <ant> <Nolar> ótimo 14:22 <jrandom> a velocidade com 16KB sem pipelines é bem ruim, ou pelo menos costumava ser 14:22 <tracker> laberhorst: Ok, vou tentar ver se consigo pegar a arte nos próximos dias... 14:22 <ant> <duck> sugiro deixar esse ajuste para o 0.2 14:22 <ant> <duck> já que vai incluir as melhorias do bittorrent 3.9.1 14:22 <jrandom> sim, DTSTTCPW 14:22 <susi23> . o O ( ah isso é fácil... as pessoas são tão previsíveis... ) 14:23 <ant> <duck> o que pode reestruturar completamente o código de rede 14:23 <cervantes> http://www.gavelstore.com 14:24 <jrandom> ok, acho que é isso por enquanto, o pessoal deve checar a lista e o site em algumas horas, pois a revisão 0.5.0.1 vai sair em breve 14:24 <ant> <Nolar> sim, dá para ver como pedidos únicos de 16kb seriam lentos 14:24 * jrandom faz download de um martelo (de juiz) 14:24 * jrandom *baf* encerra a reunião