Reunión de desarrollo de I2P - 18 de octubre de 2005

16:10 <jrandom> 0) hola 16:10 <jrandom> 1) 0.6.1.3 16:10 <jrandom> 2) Freenet, I2P y darknets (oh cielos) 16:10 <jrandom> 3) Ataques de arranque de tunnel 16:10 <jrandom> 4) I2Phex 16:10 <jrandom> 5) Syndie/Sucker 16:10 <jrandom> 6) ??? 16:10 <jrandom> 0) hola 16:10 * jrandom saluda 16:10 <jrandom> las notas de estado semanales están en http://dev.i2p.net/pipermail/i2p/2005-October/001017.html 16:10 <dust> ¡bien, ahora funciona. gracias Gregor 16:10 <cervantes> hola 16:11 <+fox> <blx> heloa 16:11 <jrandom> ok, pasando a 1) 0.6.1.3 16:11 <jrandom> han actualizado a muy buen ritmo, ¡gracias! 16:12 <jrandom> las cosas parecen estar en buen estado, pero no tengo mucho que añadir más allá de lo que está en las notas de estado 16:12 <jrandom> ¿alguien tiene preguntas/comentarios/preocupaciones sobre: 0.6.1.3? 16:13 <jrandom> ok, si no, pasemos a 2) Freenet, I2P y darknets (oh cielos) 16:13 <cervantes> ¡609 pares conocidos! 16:14 <cervantes> (w00t) 16:14 <jrandom> sí, la red ha estado creciendo 16:14 <+fox> <blx> ¡oh cielos! 16:14 * cervantes está organizando una porra sobre cuánto falta hasta llegar a los 1000 16:14 <jrandom> jeje 16:14 <tethra> jejeje 16:15 <tethra> ¿estamos apostando con dinero digital? ;) 16:15 <cervantes> pero muestra lo sólido que se ha vuelto el núcleo de I2P últimamente que la adopción de usuarios se ha acelerado 16:16 <cervantes> nah... jrandom ya ha donado sin saberlo todo su dinero de cerveza de este año 16:16 <jrandom> jeje 16:16 <jrandom> ok, sobre el punto 2), no estoy seguro de tener algo más que añadir al tema (creo que ya lo exprimimos). ¿alguien tiene preguntas/comentarios/preocupaciones al respecto? 16:18 <cervantes> como dijiste, si nada más, ha estimulado algunas discusiones de seguridad semi-relacionadas, es decir, 3) 16:18 <jrandom> si no, podemos pasar rápidamente a 3) Ataques de arranque de tunnel 16:18 <jrandom> sí, así ha sido 16:19 <jrandom> el tema que planteó Michael cuantifica una opinión general que tenía, pero es bueno hacerlo explícito 16:20 <jrandom> habrá más discusión sobre el ataque más reciente esta noche (una vez que pueda redactar una respuesta), pero el primero no parece ser un gran problema 16:21 <jrandom> ¿tiene sentido para ustedes, o tienen preguntas o preocupaciones al respecto? 16:22 <cervantes> jeje... eso significa que o todos están de acuerdo o no entienden ni jota de cuáles son los problemas 16:23 <cervantes> me apunto a la categoría de 'la ignorancia es felicidad' 16:23 <jrandom> jeje básicamente es un ataque donde los malos resultan ser el extremo de salida de cada tunnel que hayas construido 16:23 <jrandom> ahora, cuando acabas de iniciar, "cada tunnel que hayas construido" es un número muy pequeño (p. ej., 0, 1, 2) 16:24 <jrandom> pero después de unos segundos, el número crece lo suficiente como para convertir (c/n)^t en un número realmente muy pequeño 16:25 <tethra> (c/n)^t es... 16:25 <jrandom> (esta es una de las razones por las que no arrancamos el listener de i2cp - y por tanto, i2ptunnel/etc - hasta un rato después del inicio) 16:25 <jrandom> c == n.º de pares confabulados (los malos), n == n.º de pares en la red, t == n.º de tunnels que has construido. 16:25 <cervantes> bien... 16:25 <tethra> ah 16:26 <jrandom> así que a medida que t crece, la probabilidad de éxito del ataque se vuelve muy pequeña 16:26 <cervantes> entonces, para que fuera siquiera viable tendrías que empezar a usar tu router para tareas sensibles a los pocos minutos de iniciarlo? 16:26 <jrandom> (o, en cualquier caso, menor que la probabilidad de controlar todos los saltos en un tunnel) 16:26 <tethra> ahh, ya veo 16:27 <jrandom> cervantes: inmediatamente, antes de que se construya el 3er tunnel 16:27 <jrandom> (asumiendo que usas tunnels de 3 saltos) 16:27 <cervantes> eso es bastante improbable 16:28 <cervantes> solo desde una perspectiva de casos de uso 16:28 <jrandom> exacto. 16:28 <jrandom> y como construimos más de 3 tunnels al iniciar antes de permitir que corran los clientes, no es solo un tema de probabilidad 16:28 <jrandom> pero es bueno cuantificar el ataque de todos modos 16:29 <cervantes> ¿vale la pena dejar que el router dé más vueltas durante un poco más para protegerse contra cualquier probabilidad? 16:30 <cervantes> o agitarlo más... 16:30 <jrandom> quizá. si ignoramos el tiempo de establecimiento de conexión así como la selección no aleatoria de pares, no tiene probabilidad 16:31 <tethra> ¿eso amerita un "w00t!" supongo? 16:32 <jrandom> sí, aunque desde una perspectiva de ingeniería no deberíamos ignorar esas características ;) 16:32 <jrandom> así que, para 0.6.2 quizá queramos revisarlo durante la implementación renovada de selección/ordenación de pares de tunnel, para asegurarnos de que se comporte de forma sensata 16:34 <jrandom> ok, si no hay nada más sobre el 3), pasemos al 4) I2Phex 16:34 <jrandom> sirup no está aquí, y no he visto a striker en irc - redzara, ¿andas por ahí? 16:36 <+redzara> sí 16:36 <+redzara> La primera pasada está casi completa: portar el mod de Sirup al CVS más reciente de Phex. 16:36 <jrandom> ¡bien ahí! 16:36 <+redzara> siguiente: segunda pasada: diff del código de Sirup al código base de Phex usado en la versión inicial, para asegurarme de no olvidar nada :) 16:37 <+redzara> quizá terminado para este fin de semana 16:37 <jrandom> wow, eso sería genial 16:37 <+redzara> Tercera pasada: refactorizar la capa de comunicaciones con GregorK 16:37 <+fox> <GregorK> espero que tengan claro que en el último CVS de Phex el código de descarga no es estable y el archivo de descarga no es compatible con versiones anteriores 16:38 <jrandom> esto es i2p, estamos acostumbrados a la inestabilidad :) 16:38 <+fox> <GregorK> :) 16:38 <+redzara> Para la última pasada, como actualmente no tengo contacto con GregorK, esto será bastante difícil :( 16:38 <jrandom> GregorK: ¿qué recomendarías para la integración? 16:39 <+fox> <GregorK> bueno, ahora ya tienes contacto conmigo ;) 16:39 <jrandom> ah 'k redzara, las dos primeras ya son bastante grandes en cualquier caso :) 16:39 <+redzara> GregorK: hola 16:40 <+redzara> GregorK: He leído cuidadosamente todos los códigos 16:40 <+fox> <GregorK> Tengo una idea de cómo construir una capa... puedo intentar prepararla lo mejor que pueda y luego vemos qué tan bien encaja y qué hay que cambiar 16:40 <+fox> <GregorK> ¿todos?? wow... 16:40 <+redzara> Gregork: sí, ¡todos! 16:41 <cervantes> hasta sabe la talla de tu ropa interior 16:41 <Rawn> :D 16:41 <+fox> <GregorK> genial... la próxima vez que vaya de compras solo necesito preguntarte... 16:43 <+fox> <GregorK> sería bueno si pudiéramos tener a alguien del equipo de I2Phex también en el equipo de Phex.. 16:43 <jrandom> redzara: entonces, ¿crees que tendremos una versión 0.1.2 de I2Phex con los resultados de tu segunda pasada antes de que lo integremos todo en una capa de plugin en el Phex principal? ¿o será todo de una? 16:43 <+redzara> Perdón, pero no entiendo/hablo/leo/escribo inglés lo suficientemente bien como para reírme con lo que has escrito 16:43 <+fox> <GregorK> esto también ayudaría a resolver errores que están en ambos lados 16:44 <jrandom> GregorK: con suerte encontraremos una forma de que la parte de I2P sea solo un plugin ligero en Phex, ¿no? 16:44 <jrandom> ¿o crees que deberían permanecer separados? 16:44 <+redzara> jrandom: creo que podríamos tener un Phex 2.6.4 sobre I2P; para mí, I2Phex está terminado 16:45 <jrandom> ¿terminado? 16:45 <+fox> <GregorK> no estoy seguro de que podamos hacerlo así desde el principio, pero creo que la mayor parte se podría separar en un plugin. 16:45 <jrandom> genial, sí, es mucho trabajo, seguro 16:46 <jrandom> especialmente cuando miras cosas como java.net.URL (que filtra solicitudes DNS al instanciarse, etc.) 16:46 <+redzara> jrandom: terminado, finiquitado 16:46 <+Ragnarok> grr 16:47 <jrandom> ok, correcto, redzara, una vez que podamos hacer que todo funcione en Phex 2.6.4 sobre I2P, de acuerdo, no parecería haber mucha necesidad de un I2Phex 16:47 <+fox> <GregorK> correcto... creo que Phex usa la clase URI de Apache en algunos lugares para sortear esto... pero solo cuando es necesario 16:48 <jrandom> ah, cierto, recuerdo haber trasteado con esa librería, se ve bien 16:49 <jrandom> definitivamente ayudaremos a auditar un poco las cosas en cuanto a anonimato/seguridad antes de recomendarlo a usuarios finales sobre I2P 16:49 <jrandom> (no es que sugiramos que haya problemas en Phex; es que hay problemas en toda app, y con suerte podemos ayudar a resolverlos) 16:50 <+fox> <GregorK> para algunas cosas como el uso de Socket y similares, tengo una idea de cómo integrarlo suavemente... pero en otros sitios como diferentes características UDP y eso... aún no estoy seguro de cuál es la mejor manera de resolverlas 16:50 <+fox> <GregorK> oh, estoy seguro de que hay muchos problemas en Phex. :) 16:50 <jrandom> ah, sí, los sockets serán fáciles, pero quizá necesitemos desactivar otras cosas. ¿para qué se usa UDP? ¿consultas rápidas? 16:51 <+fox> <GregorK> actualmente solo el arranque 16:51 <+fox> <GregorK> UDP Host Cache... un reemplazo de GWebCache 16:52 <jrandom> ahhh, ok. 16:52 <+redzara> ¿Entonces no lo necesitamos si tenemos un GWebCache decente? 16:53 <+fox> <GregorK> sí... pero el GWebCache estándar también tiene sus problemas de seguridad... 16:53 <+redzara> GregorK: no dentro de I2P, creo 16:54 <jrandom> oh, esa parte se podría superar - I2PSocket está autenticado - conoces el 'destination' del par al otro lado, así que no podrían decir "Soy, eh... whitehouse.gov.. ¡sí!" 16:54 <jrandom> pero tienes razón, es algo que hay que verificar 16:54 <+fox> <GregorK> también las transferencias firewall a firewall serían un tema de UDP que nos gustaría implementar una vez que encontremos un voluntario :) 16:54 <jrandom> ah, bueno, I2P no necesita transferencias firewall a firewall: I2P expone un espacio de direcciones de extremo a extremo completamente abierto :) 16:55 <jrandom> pero... ooh, eso podría ser útil 16:55 <jrandom> si los usuarios de Phex tuvieran "tunnels de 0 saltos", obtendrían NAT traversal/transfers firewall a firewall gratis con una velocidad bastante decente 16:55 <+fox> <GregorK> otro sería difusiones por LAN de consultas y similares... para compartir contenidos más fácilmente en redes privadas 16:56 <jrandom> (los tunnels de 0 saltos ofrecen un nivel de negación plausible sin requerir pares intermediarios para transportar el tráfico) 16:57 <jrandom> hmm, la difusión por LAN es buena, aunque no estoy seguro de que I2P realmente lo necesite (ya que es un riesgo para el anonimato saber dónde está el otro par :), así que quizá esa función se pueda desactivar al usar el plugin de I2P? 16:58 <cervantes> *desactivado por defecto 16:58 <+fox> <GregorK> bueno, aún no está disponible... pero en este caso los usuarios suelen conocerse de todos modos para montar esa red privada.. 16:58 <jrandom> oh, cierto, cervantes 16:58 <jrandom> cierto, cierto, GregorK 16:59 <+fox> <GregorK> ¿hay algún cambio respecto a la interfaz de usuario?? 17:00 <+bar> bueno, no necesitaremos banderas :) 17:00 <jrandom> como mínimo, sería útil poder tener algunas opciones de configuración relacionadas con I2P. 17:01 <jrandom> creo que sirup fue capaz de cambiar parte de la visualización para usar 'destinations' de I2P en lugar de mostrar IP + números de puerto, así que creo que estaba bien 17:01 <+redzara> ¿Y qué hay de bitzy? De momento no, pero las banderas y países no se usan 17:01 <jrandom> ¿bitzy? 17:01 <+redzara> perdón, mal copy/paste :( 17:02 <+fox> <GregorK> ¿pueden proporcionar una lista de opciones de configuración y funciones opcionales que necesitan? 17:03 <jrandom> Seguro que podemos dártelas. un host+puerto donde esté corriendo I2P y algunos desplegables sobre ajustes de rendimiento/anonimato deberían bastar 17:03 <jrandom> te pasaremos los detalles, eso sí 17:02 <cervantes> [x] Modo de super velocidad de transferencia 17:02 <+fox> <GregorK> bueno, Bitzi se usa para identificar archivos... ¿es eso un problema para el anonimato? 17:03 <vulpine> <redzara> GregorK: lo estoy preparando, pero básicamente no hay cambios 17:03 <+fox> <GregorK> :) pregúntale a tu proveedor, cervantes... 17:03 <redzara> GregorK: quizá, estoy trabajando en ello 17:04 <cervantes> GregorK: je, residente en el Reino Unido... ni de broma ;-) 17:04 <+fox> <GregorK> si transfieres archivos entre 2 instancias de Phex en el mismo PC... las transferencias son rapidísimas ;) 17:05 <cervantes> genial... tengo muchas pelis chulas que puedo compartir conmigo mismo :) 17:05 <cervantes> * borren eso del acta de la reunión * 17:06 <bar> jrandom tocó el tema antes, pero, aquí va de nuevo esa idea loca: 17:06 <+bar> ¿qué tal integrar I2P en Phex, para que los usuarios normales tengan tunnels de 0 saltos? 17:07 <+fox> <GregorK> creo que la visualización de banderas e IP+puerto viene del objeto HostAddress... que quedaría oculto desde la nueva capa... así que puedes mostrar otra cosa 17:07 <+bar> (por la negación plausible y el hole punching de firewall por UDP) 17:08 <+fox> <GregorK> no estoy seguro de entender realmente qué significa ;) 17:08 <+bar> probablemente yo tampoco ;) 17:09 <jrandom> GregorK: básicamente, significa que los usuarios de Phex hablarían entre sí directamente, pero obtendrían negación plausible, ya que podrían estar hablando indirectamente 17:09 <+bar> jrandom, estoy seguro de que captas mi idea aquí, ¿podrías elaborar? 17:09 <jrandom> también obtendrían el NAT traversal de I2P gratis, así como seguridad de datos y protección contra sniffing por parte de ISPs/etc 17:09 <+redzara> GregorK: así que tienes que quitar todo el código relacionado con host+puerto + IsLocalIP + Is PrivateIP + ... 17:10 <jrandom> por otro lado (un GRAN por otro lado), no podría hablar con clientes de Gnutella que no corran sobre I2P 17:10 <jrandom> (aunque eventualmente, todos lo harán ;) 17:10 <+fox> <GregorK> Bueno, creo que el primer paso —y ese paso ya es bastante grande— es acercar I2P y Phex. 17:10 <jrandom> de acuerdo 17:10 <+bar> (maldita sea, no pensé en eso) 17:11 <+bar> sí, definitivamente. 17:11 <jrandom> esto es material de ponis voladores. vamos primero con lo práctico 17:11 <+fox> <GregorK> y después, cuando veamos qué tan bien funcionó, podremos decidir cómo seguimos.. 17:11 <jrandom> exacto 17:12 <+fox> <GregorK> redzara: me gustaría tener dos implementaciones de HostAddress, una para I2P y otra como la actual. 17:14 <+redzara> Gregork: sin problema, he comentado todo el código en mi mod; podrías construir fácilmente dos implementaciones. Solo déjame terminar el trabajo inicial, por favor 17:14 <+fox> <GregorK> claro... sin problema... 17:14 <jrandom> :) ok, entonces redzara, ¿crees que podremos hacer una prueba alfa de la nueva versión basada en Phex-2.4.2 en algún momento de la próxima semana? 17:15 <jrandom> (para la parte de la fase 2. tu fase 3 llevará más trabajo al integrarla con la rama principal) 17:15 <+redzara> jrandom: la próxima parece estar bien para mí 17:16 <jrandom> ok, genial 17:16 <+redzara> s/next/next week/ 17:16 <jrandom> ok, esto es bastante emocionante, será maravilloso ponerlo a funcionar sin problemas 17:17 <jrandom> ¿alguien tiene algo más que plantear para 4) I2Phex, o pasamos brevemente a 5) Syndie/Sucker? 17:17 <cervantes> I2P seguramente se beneficiará de apps tan potentes 17:18 <+fox> <GregorK> por cierto, hay una lista de correo de Phex CVS para todos los cambios de CVS en Phex... por si sirve de ayuda 17:18 <jnymo> *ejem*... y tanto 17:18 <jrandom> ok, genial, gracias GregorK 17:18 <jrandom> definitivamente, cervantes 17:19 <jrandom> ok, sobre el punto 5), realmente no tengo nada que añadir más allá de lo que hay 17:19 <jrandom> dust: ¿andas por aquí? 17:19 <+redzara> GregorK: Gracias, pero manejar una sola versión ya es suficiente para mí :) 17:19 <jrandom> jeje, redzara 17:19 <dust> No he tenido mucho tiempo libre últimamente, pero si lo tengo, creo que intentaré encargarme de esto de addresses.jsp, añadir 'RSS' en el desplegable de protocolo ahí y luego construir un camino a través de Updater, Sucker hasta BlogManager. 17:20 <dust> a menos que alguien tenga una idea mejor 17:20 <jrandom> de lujo 17:20 <jrandom> suena perfecto. 17:21 <jrandom> aunque, hmm, quizá necesite un campo adicional (el "en qué blog publicarlo" y "qué prefijo de etiqueta")... 17:21 <jrandom> quizá tenga sentido un formulario/tabla separado, aunque quizá no 17:22 <dust> oh, pensaba que addresses.jsp era solo para un blog (¿ya que tienes que iniciar sesión para llegar ahí?) 17:22 <jrandom> ah, cierto, buen punto 17:23 <jrandom> la parte del updater es un poco difusa, pero tienes razón 17:23 <dust> (lo resolveremos cuando lleguemos ahí) 17:23 <jrandom> sí 17:24 * jnymo piensa que www.i2p.net podría montar algo tipo "merchandise café" 17:24 <jnymo> con camisetas de eyetoopie que digan "I am Jrandom" ;) 17:24 * mrflibble todavía está poniéndose al día con la "flamewar", que parece estar convirtiéndose en una flamewar de verdad :) 17:24 <jrandom> jeje, jnymo 17:25 <jrandom> sí, hay mucho contenido en ese hilo 17:25 <jrandom> ok, quizá esto nos lleva a 6) ??? 17:25 <jrandom> ¿alguien tiene algo más que plantear para la reunión? 17:25 <+bar> sí, solo una nota rápida sobre el tema de NAT simétrico (he estado husmeando un poco): 17:25 <+nickless_head> jrandom: ¡sé la verdad! 17:25 <+fox> <blx> kaffe? 17:25 <mrflibble> ups, perdón jr 17:26 <jnymo> pero en serio... todo proyecto de código abierto de cierto tamaño tiene su propia sección de merchandising 17:26 <+nickless_head> jrandom: ¡tengo pruebas definitivas de que hackeaste la página principal de last.fm! 17:26 <+nickless_head> (la sección de "lo que obtienes al registrarte" listaba "a pony") 17:26 <jrandom> jnymo: creo que tienes razón, querremos explorar esa vía; también podría ser un buen método de recaudación 17:27 <jnymo> jrandom: exactamente 17:27 * mrflibble compraría la camiseta 17:27 <+bar> bien, respecto a los NAT simétricos, 17:27 <+bar> por lo que vale, creo que a diferencia de los NAT ya soportados, no hay truco mágico. la única manera de hacerlo bien es estudiar y examinar el comportamiento de cada NAT simétrico y usar introducers para sondear. 17:28 <jrandom> blx: el último CVS de kaffe está completamente b0rked. los paquetes de criptografía no están en el código fuente, el PRNG falla al inicializar y los manejadores de URL no pueden con file:// :( 17:28 <jnymo> Probablemente no querrías llevarla en público hasta que I2P tenga unos cuantos miles de usuarios ;) 17:28 <+bar> (creo que así es como, por ejemplo, Hamachi y Skype hacen UDP hole punching desde detrás de NAT simétricos) 17:28 <+nickless_head> jnymo: las tazas molarían :) 17:28 <+bar> basado en lo que he leído en la red hasta ahora, los algos de predicción de NAT simétrico apestan bastante. 17:28 <jrandom> hmm, bar 17:28 <mrflibble> jeje, yo no pondría mi nick en ella. oh, y sigo vivo/no arrestado aunque tengo una camiseta de IIP 17:28 <jrandom> sí, eso es lo que yo leí también 17:29 <+bar> intentaré recopilar más material de lectura bueno y relevante sobre esto. 17:29 <+redzara> Pequeña pregunta: ¿cuál fue el porcentaje promedio común de bytes retransmitidos en 0.6.1.3? 17:29 <jrandom> gracias, bar 17:29 <+fox> <jme___> bar, ¿las predicciones que obtuvieron son consistentes? 17:29 <+fox> <jme___> bar, déjame reformular :) 17:29 <+fox> <blx> jrandom, me entristece oírlo 17:30 <jrandom> redzara: lamentablemente olvidé poner eso en el netDb. aunque ahora mismo veo 2.6 y 3.8 17:30 <jrandom> blx: yo también :( 17:30 <+fox> <jme___> bar, cuando analizas el comportamiento de la caja NAT y encuentras una fórmula para predecirlo, ¿esto siempre funciona para esa caja NAT? ¿o luego a veces funciona y a veces falla? 17:30 <jrandom> blx: sé que están haciendo algo de fusión con classpath ahora, así que con suerte, una vez que se arregle 17:30 <+fox> <blx> probablemente significa que no me uniré a la fiesta 17:30 <jrandom> blx: ¿eres específico de kaffe o específico de OSS/DFSG? 17:31 <+fox> <blx> software libre 17:31 <+fox> <blx> DFSG, podrías decir 17:31 <jnymo> en caso de que un usuario de I2P quiera usar un servidor alojado para I2P, ¿qué empresa de servicios alojados sería liberal y barata para elegir? 17:31 <+bar> jme___: se dice que Hamachi puede mediar el 97% de todos los intentos de conexión. supongo que hay algunos NAT por ahí que muestran un comportamiento casi aleatorio al asignar puertos 17:32 <jrandom> ok, seguro que lograremos algo, blx. kaffe solía funcionar, y no dependemos de nada específico de Sun 17:32 <jrandom> jnymo: yo uso sagonet.net, pero han subido sus precios de 65/mes a 99/mes (pero en un enlace rápido con 1250GB/mes) 17:32 <jrandom> sé que hay algunos baratos en Alemania también 17:33 <+fox> <jme___> bar, 97% sería magnífico 17:33 <jrandom> redzara: ¿qué estás viendo de tasa de retransmisión? 17:33 <+bar> jme___: sí, así que supongo que la mayoría de los NAT simétricos son predecibles 17:33 <+fox> <blx> jrandom, eso espero. estoy realmente interesado en esta mierda :) 17:33 <+fox> <jme___> bar, ¿qué harías? relay, UDP hole punching, inversión de conexión... ¿hay otras técnicas? 17:33 <jnymo> ¿99 es caro, en promedio? 17:34 <+redzara> jrandom: entre 3,8 y 4,2 17:34 <jrandom> jme___: somos UDP, no hace falta inversión de conexión :) 17:35 <+bar> no soy experto; quizá tenga más info para la reunión de la próxima semana (pero esto huele a perfilado + UDP hole punching ;) 17:35 <jrandom> jnymo: para 1250GB, no realmente. he visto 60-120 USD/mes por 50-100GB/mes 17:35 <jrandom> bar: ¿quizá UPnP sería una mejor vía? 17:35 <+fox> <jme___> jrandom, incluso con UDP es útil :) 17:35 <+redzara> jrandom: pero solo algunos nodos tuvieron un impacto mayor, quizá algunos más antiguos 17:35 <+fox> <jme___> vulpine: ok 17:35 <jrandom> aunque eso solo ayuda a quienes podrían controlar su NAT 17:36 <+fox> <jme___> aquí por 'must' = para proporcionar la máxima conectividad 17:36 <jrandom> bueno, todo lo que hacemos ahora lo hacemos sin ningún UPnP 17:36 <+fox> <jme___> porque UPnP no está soportado por todos los NAT, ni de lejos 17:36 <jrandom> cierto, p. ej., un NAT de un ISP 17:36 <+bar> jrandom: si no hay problemas de seguridad con UPnP, supongo que no puede hacer daño. aunque Hamachi no usa UPnP 17:36 <+fox> <jme___> aquí > volver a mi C++ :) 17:38 <jrandom> cierto, jme___, aunque si podemos hacer hole punching simétrico además de hole punching de tipo cono/restringido, estamos en muy buena forma 17:38 <jrandom> l8s, jme___ 17:38 <jrandom> sí, sería ideal si no lo necesitáramos 17:39 <jrandom> ok, ¿alguien tiene algo más que plantear para la reunión? 17:41 <jrandom> si no... 17:41 * jrandom se prepara 17:41 * jrandom *baf* cierra la reunión