Reunião de Desenvolvimento do I2P - 18 de outubro de 2005

16:10 <jrandom> 0) oi 16:10 <jrandom> 1) 0.6.1.3 16:10 <jrandom> 2) Freenet, I2P e darknets (ó céus) 16:10 <jrandom> 3) Ataques de bootstrap de tunnel 16:10 <jrandom> 4) I2Phex 16:10 <jrandom> 5) Syndie/Sucker 16:10 <jrandom> 6) ??? 16:10 <jrandom> 0) oi 16:10 * jrandom acena 16:10 <jrandom> as notas semanais de status estão no http://dev.i2p.net/pipermail/i2p/2005-October/001017.html 16:10 <dust> eba, funciona agora. obrigado Gregor 16:10 <cervantes> olá 16:11 <+fox> <blx> heloa 16:11 <jrandom> ok, passando para 1) 0.6.1.3 16:11 <jrandom> vocês atualizaram num ritmo bem bom, obrigado! 16:12 <jrandom> as coisas parecem estar em condição razoável, mas não tenho muito a acrescentar além do que está nas notas de status 16:12 <jrandom> alguém tem perguntas/comentários/preocupações sobre 0.6.1.3? 16:13 <jrandom> ok, se não, vamos direto para 2) Freenet, I2P e darknets (ó céus) 16:13 <cervantes> 609 pares conhecidos! 16:14 <cervantes> (w00t) 16:14 <jrandom> sim, a rede tem crescido 16:14 <+fox> <blx> ó céus! 16:14 * cervantes está organizando um bolão de quanto tempo até chegar aos 1000 16:14 <jrandom> hehe 16:14 <tethra> heheh 16:15 <tethra> estamos apostando com dinheiro digital? ;) 16:15 <cervantes> mas isso mostra como o núcleo do i2p ficou sólido ultimamente, já que a adoção pelos usuários tem acelerado 16:16 <cervantes> nah... jrandom já doou sem saber todo o dinheiro da cerveja deste ano 16:16 <jrandom> hehe 16:16 <jrandom> ok, em 2), não sei se tenho algo mais a acrescentar ao assunto (acho que já esgotamos esse assunto). alguém tem perguntas/comentários/preocupações sobre isso? 16:18 <cervantes> como você disse, se nada mais, isso estimulou algumas discussões de segurança semi-relacionadas, isto é 3) 16:18 <jrandom> se não, podemos avançar rapidamente para 3) Ataques de bootstrap de tunnel 16:18 <jrandom> pois é, estimulou mesmo 16:19 <jrandom> o ponto que o Michael levantou quantifica uma visão geral que eu tinha, mas é bom torná-la explícita 16:20 <jrandom> vai haver mais discussão sobre o ataque mais recente mais tarde esta noite (assim que eu conseguir escrever uma resposta), mas o primeiro não parece ser muito problemático 16:21 <jrandom> faz sentido para vocês, ou alguém tem alguma pergunta ou preocupação sobre isso? 16:22 <cervantes> heh... isso ou significa que todo mundo está de boa com isso ou que não entendem patavina de quais são os problemas 16:23 <cervantes> vou me colocar na categoria 'ignorância é uma bênção' 16:23 <jrandom> hehe é basicamente um ataque em que os malvados acabam sendo a extremidade de saída de todo tunnel que você já construiu 16:23 <jrandom> agora, quando você está iniciando, "todo tunnel que você já construiu" é um número muito pequeno (ex.: 0, 1, 2) 16:24 <jrandom> mas depois de alguns segundos, o número cresce o suficiente para transformar (c/n)^t em um número muito, muito pequeno 16:25 <tethra> (c/n)^t é... 16:25 <jrandom> (esta é uma das razões pelas quais não iniciamos o I2CP listener — e, portanto, i2ptunnel/etc — até um tempinho depois da inicialização) 16:25 <jrandom> c == # de pares coniventes (bandidos), n == # de pares na rede, t == # de tunnels que você construiu. 16:25 <cervantes> certo... 16:25 <tethra> ah 16:26 <jrandom> então, conforme t cresce, a probabilidade de ataque bem-sucedido fica bem pequena 16:26 <cervantes> então, para isso ser viável, você teria que começar a usar seu router para tarefas sensíveis dentro de alguns minutos após ele iniciar? 16:26 <jrandom> (ou, em qualquer caso, menor do que a probabilidade de assumir todos os saltos em um tunnel) 16:26 <tethra> ahh, entendi 16:27 <jrandom> cervantes: imediatamente, antes de o 3º tunnel ser construído 16:27 <jrandom> (assumindo que você use tunnels de 3 saltos) 16:27 <cervantes> isso é bem improvável 16:28 <cervantes> só pela perspectiva de caso de uso 16:28 <jrandom> exato. 16:28 <jrandom> e como construímos mais de 3 tunnels na inicialização antes de deixar quaisquer clientes rodarem, não é só uma questão de probabilidade 16:28 <jrandom> mas é bom quantificar o ataque de qualquer forma 16:29 <cervantes> vale a pena deixar o router "esquentar" por um pouco mais para se proteger contra qualquer probabilidade? 16:30 <cervantes> ou "esquentar" mais... 16:30 <jrandom> talvez. se ignorarmos o tempo de estabelecimento de conexão bem como a seleção não aleatória de pares, não há probabilidade 16:31 <tethra> isso é motivo para um "woot!", pelo visto? 16:32 <jrandom> sim, embora do ponto de vista de engenharia não devamos ignorar essas características ;) 16:32 <jrandom> então, para 0.6.2 talvez queiramos olhar isso durante a nova implementação de seleção/ordenação de pares de tunnel, para garantir que esteja se comportando de forma sensata 16:34 <jrandom> ok, se não há mais nada em 3), vamos para 4) I2Phex 16:34 <jrandom> sirup não está aqui, e não vi striker no irc - redzara, você por aí? 16:36 <+redzara> sim 16:36 <+redzara> Primeira passada está quase concluída: portar o mod do Sirup para o CVS mais recente do Phex. 16:36 <jrandom> boa! 16:36 <+redzara> próximo: Segunda passada: diff do código do Sirup para o código base do Phex usado no lançamento inicial, para garantir que eu não esqueça nada :) 16:37 <+redzara> talvez concluído para este fim de semana 16:37 <jrandom> uau, isso seria ótimo 16:37 <+redzara> Terceira passada: refatorar a camada de comunicação com o GregorK 16:37 <+fox> <GregorK> espero que você esteja ciente de que no último CVS do Phex o código de download não está estável e o arquivo de download não é compatível com versões anteriores 16:38 <jrandom> isto é i2p, estamos acostumados à instabilidade :) 16:38 <+fox> <GregorK> :) 16:38 <+redzara> Para a última passada, como atualmente não tenho contato com o GregorK, isso deve ser bem difícil :( 16:38 <jrandom> GregorK: o que você recomendaria para integração? 16:39 <+fox> <GregorK> bem, agora você tem contato comigo ;) 16:39 <jrandom> ah, ok redzara, as duas primeiras já são grandes o suficiente de qualquer forma :) 16:39 <+redzara> GregorK : oi, cara 16:40 <+redzara> GregorK : li cuidadosamente todos os códigos 16:40 <+fox> <GregorK> tenho uma ideia de como construir uma camada... posso tentar preparar o melhor que puder e então podemos ver como isso se encaixa e o que precisa ser alterado 16:40 <+fox> <GregorK> todos?? uau... 16:40 <+redzara> Gregork : sim, todos!! 16:41 <cervantes> ele até sabe o tamanho da sua cueca 16:41 <Rawn> :D 16:41 <+fox> <GregorK> ótimo... da próxima vez que eu for às compras só preciso perguntar a você... 16:43 <+fox> <GregorK> seria legal se talvez pudéssemos ter alguém do time do i2phex no time do phex também.. 16:43 <jrandom> redzara: então, você acha que teremos um lançamento 0.1.2 do I2Phex com os resultados da sua segunda passada antes de juntarmos tudo em uma camada de plugin no ramo principal do Phex? ou isso vai ser tudo de uma vez? 16:43 <+redzara> Desculpe, mas eu não entendo/falo/leio/escrevo inglês bem o suficiente para rir do que você escreveu 16:43 <+fox> <GregorK> isso também ajudaria a resolver bugs que estão dos dois lados 16:44 <jrandom> GregorK: esperamos encontrar uma forma de que o lado do I2P seja apenas um plugin leve no Phex, certo? 16:44 <jrandom> ou você acha que os dois devem ficar separados? 16:44 <+redzara> jrandom : acho que poderíamos ter um Phex 2.6.4 sobre I2P, para mim I2Phex está acabado 16:45 <jrandom> acabado? 16:45 <+fox> <GregorK> não tenho certeza se conseguimos fazer assim logo de início, mas acho que a maior parte poderia ser separada em um plugin. 16:45 <jrandom> legal, sim, é muito trabalho, com certeza 16:46 <jrandom> especialmente quando você olha coisas como java.net.URL (que vaza requisições DNS na instanciação, etc) 16:46 <+redzara> jrandom : acabado, encerrado 16:46 <+Ragnarok> grr 16:47 <jrandom> certo, redzara, uma vez que conseguirmos tudo funcionando no Phex 2.6.4 sobre I2P, concordo, não parece haver muita necessidade de um I2Phex 16:47 <+fox> <GregorK> certo... acho que o Phex usa a apache URI class em alguns lugares para contornar isso... mas só quando necessário 16:48 <jrandom> ah sim, lembro de brincar com essa biblioteca, parece boa 16:49 <jrandom> definitivamente vamos ajudar a auditar as coisas um pouco para anonimato/segurança antes de recomendar para usuários finais sobre i2p 16:49 <jrandom> (não para sugerir que há problemas no Phex, só que há problemas em todo app, e esperamos poder ajudar a resolvê-los) 16:50 <+fox> <GregorK> para algumas coisas como uso de Socket e afins eu tenho uma ideia de como integrar suavemente... mas outros lugares, como diferentes recursos UDP e tal... ainda não tenho certeza de como resolver da melhor forma 16:50 <+fox> <GregorK> ah, tenho certeza de que há muitos problemas no phex. :) 16:50 <jrandom> ah, sim, sockets serão fáceis, mas talvez precisemos desativar outras coisas. para que o UDP é usado — consultas rápidas? 16:51 <+fox> <GregorK> atualmente só bootstrap 16:51 <+fox> <GregorK> UDP Host Cache.. um substituto para o GWebCache 16:52 <jrandom> ahhh, ok. 16:52 <+redzara> Então não precisamos disso se tivermos um GWebCache decente? 16:53 <+fox> <GregorK> sim... mas o GWebCache padrão também tem seus problemas de segurança... 16:53 <+redzara> GregorK : não dentro do I2P, acho 16:54 <jrandom> ah, essa parte dá para superar — I2PSocket é autenticado — você sabe o 'destination' do par do outro lado, então eles não poderiam dizer "Eu sou, er... whitehouse.gov.. é!" 16:54 <jrandom> mas você tem razão, é algo que precisa ser verificado 16:54 <+fox> <GregorK> também transferências firewall-para-firewall seriam um tópico de UDP que gostaríamos de implementar assim que encontrarmos um voluntário :) 16:54 <jrandom> ah, bem, o I2P não precisa de transferências firewall-para-firewall — o I2P expõe um espaço de endereçamento de ponta a ponta totalmente aberto :) 16:55 <jrandom> mas... ooh, isso pode ser útil 16:55 <jrandom> se usuários do Phex tivessem "0 hop tunnels", ganhariam NAT traversal/transferências firewall-para-firewall de graça com velocidade bem decente 16:55 <+fox> <GregorK> outro seria broadcasts na LAN de consultas e afins... para compartilhamento mais fácil de conteúdo em redes privadas 16:56 <jrandom> (0 hop tunnels oferecem um nível de plausível negabilidade sem exigir pares intermediários para carregar o tráfego) 16:57 <jrandom> hmm, broadcast na lan é bom, embora eu não tenha certeza se i2p realmente precisaria disso (já que é um risco de anonimato saber onde o outro par está :), então talvez esse recurso pudesse ser desativado ao usar o plugin de I2P? 16:58 <cervantes> *desativado por padrão 16:58 <+fox> <GregorK> bem, ainda não está disponível... mas nesse caso os usuários geralmente já se conhecem para construir essa rede privada.. 16:58 <jrandom> ah, certo, cervantes 16:58 <jrandom> certo, certo, GregorK 16:59 <+fox> <GregorK> há alguma mudança quanto à interface do usuário?? 17:00 <+bar> bem, não vamos precisar de bandeiras :) 17:00 <jrandom> no mínimo, seria útil poder ter algumas opções de configuração relacionadas ao I2P. 17:01 <jrandom> acho que sirup conseguiu trocar parte da exibição para usar 'destinations' do I2P em vez de mostrar IP + números de porta, então acho que ficou ok 17:01 <+redzara> And what about bitzyNot for the moment, but flags and countries are unused 17:01 <jrandom> bitzy? 17:01 <+redzara> desculpe, copiar/colar errado :( 17:02 <+fox> <GregorK> pode fornecer uma lista de opções de configuração e recursos opcionais de que você precisa? 17:03 <jrandom> Tenho certeza de que podemos te passar isso. um host+porta onde o I2P está rodando e alguns drop-downs sobre ajustes de desempenho/anonimato devem resolver 17:03 <jrandom> vamos te passar os detalhes, porém 17:02 <cervantes> [x] Modo super velocidade de transferência 17:02 <+fox> <GregorK> bem, bitzi é usado para identificar arquivos.. isso é um problema de anonimato? 17:03 <vulpine> <redzara> GregorK : Estou preparando isso, mas basicamente não há mudanças 17:03 <+fox> <GregorK> :) pergunte ao seu provedor, cervantes... 17:03 <redzara> GregorK : talvez, estou trabalhando nisso 17:04 <cervantes> GregorK: heh, residente no Reino Unido.... sem chance ;-) 17:04 <+fox> <GregorK> se você transferir arquivos entre 2 instâncias do Phex no mesmo PC.. as transferências são rapidíssimas ;) 17:05 <cervantes> legal... tenho muitos filmes legais que posso compartilhar comigo mesmo :) 17:05 <cervantes> * riscar isso das atas da reunião * 17:06 <bar> jrandom tocou no assunto antes, mas aqui vai aquela ideia maluca de novo: 17:06 <+bar> que tal integrar i2p no Phex, para que usuários comuns tenham 0-hop tunnels? 17:07 <+fox> <GregorK> acho que a exibição de bandeiras e IP+porta vem do objeto HostAddress.. que ficaria oculto da nova camada.. então você pode exibir outra coisa 17:07 <+bar> (para plausível negabilidade e udp firewall hole punching) 17:08 <+fox> <GregorK> não tenho certeza se entendi mesmo o que isso significa ;) 17:08 <+bar> provavelmente eu também ;) 17:09 <jrandom> GregorK: essencialmente, significa que usuários do Phex falariam diretamente entre si, mas teriam plausível negabilidade, já que poderiam estar falando indiretamente 17:09 <+bar> jrandom, tenho certeza de que você pegou a ideia, pode elaborar? 17:09 <jrandom> eles também ganhariam NAT traversal do I2P de graça, além de segurança de dados e proteção contra sniffing por ISPs/etc 17:09 <+redzara> GregorK : então você tem que remover todo o código relacionado a host+port + IsLocalIP + Is PrivateIP + ... 17:10 <jrandom> por outro lado (um GRANDE outro lado), não conseguiria falar com clientes gnutella que não rodam sobre I2P 17:10 <jrandom> (embora eventualmente todos vão ;) 17:10 <+fox> <GregorK> Bem, acho que o primeiro passo — e esse passo já é grande o suficiente — é aproximar i2p e phex. 17:10 <jrandom> concordo 17:10 <+bar> (droga, não pensei nisso) 17:11 <+bar> é, com certeza. 17:11 <jrandom> isso é coisa de pônei voador. vamos primeiro nas coisas práticas 17:11 <+fox> <GregorK> e depois que virmos como isso funcionou podemos decidir como seguir em frente.. 17:11 <jrandom> exatamente 17:12 <+fox> <GregorK> redzara: gostaria de ter duas implementações de HostAddress: uma para i2p e uma como a atual. 17:14 <+redzara> Gregork : sem problema, comentei todo o código no meu mod, você poderia facilmente construir duas implementações. Só me deixe terminar o trabalho inicial por favor 17:14 <+fox> <GregorK> claro.. sem problema.. 17:14 <jrandom> :) ok, então redzara, você acha que conseguimos um teste alfa da nova versão baseada em Phex-2.4.2 em algum momento da próxima semana? 17:15 <jrandom> (para a parte da fase 2. sua fase 3 vai exigir mais trabalho integrando com o ramo principal) 17:15 <+redzara> jrandom : a próxima semana parece ok para mim 17:16 <jrandom> ok, ótimo 17:16 <+redzara> s/next/next week/ 17:16 <jrandom> ok, isso é bem empolgante, vai ser ótimo fazer isso rodar suavemente 17:17 <jrandom> alguém tem mais algo para trazer em 4) I2Phex, ou passamos rapidamente para 5) Syndie/Sucker? 17:17 <cervantes> I2P certamente vai se beneficiar de tais killer apps 17:18 <+fox> <GregorK> a propósito, há uma lista de e-mails do CVS do Phex para todas as mudanças no CVS do Phex... se isso ajudar 17:18 <jnymo> *ehem*.. com certeza 17:18 <jrandom> ok, ótimo, obrigado GregorK 17:18 <jrandom> com certeza, cervantes 17:19 <jrandom> ok, em 5), realmente não tenho nada a acrescentar além do que está lá 17:19 <jrandom> dust: você está por aí? 17:19 <+redzara> GregorK : Obrigado mas lidar com uma versão já é suficiente para mim :) 17:19 <jrandom> hehe redzara 17:19 <dust> Não tenho tido muito tempo livre ultimamente, mas se tiver estou pensando em tentar entender aquela coisa do addresses.jsp, adicionar 'RSS' no dropdown de protocolo ali e então construir um caminho via Updater, Sucker até o BlogManager. 17:20 <dust> a menos que alguém tenha ideia melhor 17:20 <jrandom> sensacional 17:20 <jrandom> isso parece perfeito. 17:21 <jrandom> embora, hmm, talvez precise de um campo adicional (o "em qual blog postar" e "qual prefixo de tag")... 17:21 <jrandom> talvez um formulário/tabela separado faça sentido, embora talvez não 17:22 <dust> ah, eu achei que addresses.jsp era para um único blog (já que você tem que fazer login para chegar lá?) 17:22 <jrandom> ah, verdade, bom ponto 17:23 <jrandom> a parte do updater é meio nebulosa, mas você tem razão 17:23 <dust> (a gente resolve quando chegar lá) 17:23 <jrandom> sim 17:24 * jnymo acha que www.i2p.net poderia abrir uma espécie de 'loja de merchandising' 17:24 <jnymo> com camisetas da eyetoopie dizendo "I am Jrandom" ;) 17:24 * mrflibble ainda está pondo em dia a "flamewar", que parece estar espiralando para uma flamewar de verdade :) 17:24 <jrandom> heh jnymo 17:25 <jrandom> sim, há muito conteúdo naquele tópico 17:25 <jrandom> ok, talvez isso nos leve a 6) ??? 17:25 <jrandom> alguém tem mais algo para trazer para a reunião? 17:25 <+bar> sim, só uma nota rápida sobre a questão do NAT simétrico (andei dando uma fuçada): 17:25 <+nickless_head> jrandom: eu sei a verdade! 17:25 <+fox> <blx> kaffe? 17:25 <mrflibble> ops, desculpe jr 17:26 <jnymo> mas sério.. todo projeto de código aberto de algum porte tem sua própria seção de merchandising 17:26 <+nickless_head> jrandom: tenho prova definitiva de que você hackeou a página inicial do last.fm! 17:26 <+nickless_head> (a seção do que você ganha ao se cadastrar listava 'um pônei') 17:26 <jrandom> jnymo: acho que você está certo, vamos querer explorar essa avenida, pode ser um bom método de arrecadar fundos também 17:27 <jnymo> jrandom: exatamente 17:27 * mrflibble compraria a camiseta 17:27 <+bar> certo, sobre NATs simétricos, 17:27 <+bar> pelo que vale, acho que diferente dos NATs já suportados, não há truque mágico. a única forma de fazer direito é estudar e examinar o comportamento de cada NAT simétrico e usar introducers para sondagem. 17:28 <jrandom> blx: o último CVS do kaffe está completamente b0rked. os pacotes de crypto não estão no fonte, o prng falha ao inicializar, e os manipuladores de url não lidam com file:// :( 17:28 <jnymo> Você provavelmente não vai querer usá-la em público até o i2p ter alguns milhares de usuários ;) 17:28 <+bar> (acredito que é assim que, por exemplo, Hamachi e Skype fazem udp hole punching (técnica de perfuração de NAT via UDP) a partir de trás de NATs simétricos) 17:28 <+nickless_head> jnymo: canecas seriam demais :) 17:28 <+bar> com base no que li na net até agora, algoritmos de predição para NAT simétrico são bem ruins. 17:28 <jrandom> hmm bar 17:28 <mrflibble> hehe, eu não colocaria meu nick nela. ah, e ainda estou vivo/não preso embora eu tenha uma camiseta do IIP 17:28 <jrandom> sim, foi o que eu li também 17:29 <+bar> vou tentar reunir mais material de leitura bom e relevante sobre isso. 17:29 <+redzara> Perguntinha: qual foi a porcentagem média comum de bytes retransmitidos na 0.6.1.3? 17:29 <jrandom> valeu, bar 17:29 <+fox> <jme___> bar, as predições que eles obtiveram são consistentes? 17:29 <+fox> <jme___> bar, deixe-me reformular :) 17:29 <+fox> <blx> jrandom, fico triste em ouvir 17:30 <jrandom> redzara: infelizmente esqueci de colocar isso no netDb. estou vendo 2.6 e 3.8 agora, porém 17:30 <jrandom> blx: eu também :( 17:30 <+fox> <jme___> bar, quando você analisa o comportamento da caixa NAT e encontra uma fórmula para prever. isso sempre funciona para essa caixa NAT? ou depois, uma vez funciona, outra falha? 17:30 <jrandom> blx: sei que eles estão fazendo alguma fusão com o classpath agora, então com sorte assim que isso se resolver 17:30 <+fox> <blx> provavelmente significa que não vou entrar na festa 17:30 <jrandom> blx: você é específico do kaffe, ou específico de OSS/DFSG? 17:31 <+fox> <blx> software livre 17:31 <+fox> <blx> DFSG, pode-se dizer 17:31 <jnymo> caso um usuário de i2p queira usar um servidor hospedado para i2p, qual seria uma empresa de serviços hospedados liberal e barata para usar? 17:31 <+bar> jme___: dizem que o hamachi consegue intermediar 97% de todas as tentativas de conexão. acho que há NATs por aí que mostram um comportamento quase aleatório ao atribuir portas 17:32 <jrandom> ok, tenho certeza de que vamos fazer algo funcionar, blx. o kaffe funcionava, e não dependemos de nada específico da Sun 17:32 <jrandom> jnymo: eu uso sagonet.net, mas eles aumentaram os preços de 65/mês para 99/mês (mas em um link rápido com 1250GB/mês) 17:32 <jrandom> sei que há algumas baratas na Alemanha também 17:33 <+fox> <jme___> bar, 97% seria excelente 17:33 <jrandom> redzara: o que você está vendo de taxa de retransmissão? 17:33 <+bar> jme___: é, então acho que a maioria dos NATs simétricos é previsível 17:33 <+fox> <blx> jrandom, espero que sim. estou realmente interessado nessa parada :) 17:33 <+fox> <jme___> bar, o que você faria? relay, udp hole punching, reversão de conexão (cnx).. há outras técnicas? 17:33 <jnymo> 99 é caro, em média? 17:34 <+redzara> jrandom entre 3,8 e 4,2 17:34 <jrandom> jme___: somos UDP, sem necessidade de reversão de conexão :) 17:35 <+bar> jme___: não sou especialista, talvez eu tenha mais informações para a reunião da próxima semana (mas isso cheira a profiling + udp hole punching ;) 17:35 <jrandom> jnymo: para 1250GB, não muito. já vi 60-120USD/mês por 50-100GB/mês 17:35 <jrandom> bar: talvez UPnP seja um caminho melhor? 17:35 <+fox> <jme___> jrandom, mesmo com UDP é útil :) 17:35 <+redzara> jrandom : mas apenas alguns nós tiveram impacto maior, talvez alguns mais antigos 17:35 <+fox> <jme___> vulpine: ok 17:35 <jrandom> embora isso só ajude as pessoas que conseguem controlar o seu NAT 17:36 <+fox> <jme___> o UPnP deve ser suportado, mas não é exclusivo de outros meios 17:36 <jrandom> bem, estamos fazendo tudo que fazemos agora sem qualquer UPnP 17:36 <+fox> <jme___> porque UPnP não é suportado por todo NAT, longe disso 17:36 <jrandom> certo, por exemplo, o NAT de um ISP 17:36 <+bar> jrandom: se não houver problemas de segurança com upnp, acho que não faz mal. embora o hamachi não use upnp 17:36 <+fox> <jme___> aqui, por 'deve' = para fornecer a conectividade máxima 17:37 <+fox> <jme___> ok, voltando ao meu C++ :) 17:38 <jrandom> certo, jme___, embora se conseguirmos fazer hole punching simétrico além de hole punching de cone/restrito, estaremos muito bem 17:38 <jrandom> até mais, jme___ 17:38 <jrandom> sim, seria ideal se não precisássemos disso 17:39 <jrandom> ok, alguém tem mais algo para trazer para a reunião? 17:41 <jrandom> se não... 17:41 * jrandom se prepara 17:41 * jrandom *baf* encerra a reunião