Reunión de desarrolladores de I2P - 22 de febrero de 2005

13:04 <jrandom> 0) hola 13:04 <jrandom> 1) 0.5 13:04 <jrandom> 2) Próximos pasos 13:04 <jrandom> 3) azneti2p 13:04 <jrandom> 4) ??? 13:04 <jrandom> 0) hola 13:04 * jrandom saluda 13:05 <jrandom> notas de estado semanales publicadas @ http://dev.i2p.net/pipermail/i2p/2005-February/000595.html 13:05 <jrandom> (sí, solo un minuto o dos antes de la reunión, así que vamos a probar tu lectura rápida) 13:05 <+detonate> creo que esperaré hasta que esté un poco menos con errores antes de poner boondock saints, en ese caso 13:06 <jrandom> ¡por qué... eso es... eso es... eso es una violación de copyright! 13:06 <+detonate> nuevas y raras incorporaciones a la beta de Azureus 13:06 <+detonate> categorías 13:06 <+detonate> jaja 13:06 <+detonate> un rastreador DHT 13:06 <+detonate> genial 13:07 <jrandom> sí, se ve muy bien, pero abordemos los puntos 1 y 2 antes del 3, ¿eh? ;) 13:07 <+detonate> hola 13:07 <+detonate> en efecto 13:07 <jrandom> entrando en 1) 0.5 13:07 <jrandom> está, ya sabes, publicado y todo eso 13:08 <cervantes> ¡bien! 13:08 <jrandom> habrá una revisión nueva esta noche con un montón de actualizaciones (la cabeza de CVS actual es 0.5-5, con una -6 en pruebas en algunos routers) 13:09 <jrandom> ha ido bastante bien, pero nos hemos topado con algunos bugs extraños por el camino. pero c'est la vie 13:09 <frosk> puedo informar que 0.5-5 se comporta un _mucho_ más amigable que -4 (que a menudo me daba recuentos de tunnels participantes por miles) 13:09 <bla> jrandom: ¿La versión 0.5.0.1 corregirá el problema de no poder encontrar destinos? 13:09 <jrandom> ah, bueno, eso realmente es solo una función de otra gente, aunque la build -0 de hecho construye cientos de tunnels 13:09 <bla> s/nor/not 13:10 <jrandom> bla: sí, ese es un bug en la netDb 13:10 <bla> jrandom: ¡Genial! 13:10 <jrandom> (específicamente en la publicación del leaseSet) 13:11 <jrandom> y sí, la revisión 0.5.0.1 eliminará ese bug ocasional del proxy que desaparece 13:12 <jrandom> todavía hay una pérdida de memoria rara que no he localizado y que afecta a algunos usuarios 13:12 <bla> Entonces, en general, parece que aparte de esos bugs, la red 0.5 va muy bien. ¡Bien! 13:12 <jrandom> que yo sepa, realmente solo está afectando a dos o tres instancias de I2PTunnel 13:12 <Meomia> ¿es señal de progreso cuando has pasado de 0 a 130 tunnels participantes desde 0.5 ? 13:13 <jrandom> w3wt 13:13 <jrandom> Meomia: bah, yo he tenido más de 5000 tunnels ;) 13:13 <jrandom> pero dm de hecho ha ayudado a encontrar un bug en el código del pool exploratorio, así que construiremos tunnels más a menudo en peers 'aleatorios' 13:14 <jrandom> (bien) 13:14 <Meomia> ok 13:14 <bla> jrandom: ¿Eso también significa que ahora, a diferencia de 0.4, cualquier peer puede en algún momento convertirse en tu inbound gateway? 13:14 <jrandom> sí, para tunnels exploratorios 13:15 <jrandom> los tunnels de cliente solo usarán peers en el nivel 'rápido' 13:15 <bla> bla: De acuerdo. El hecho de que los tunnels de cliente usen solo los peers rápidos es bueno: de lo contrario, obtenemos el problema de anonimato del que hablamos antes 13:16 <jrandom> y el rendimiento sería pésimo de otro modo ;) 13:17 <jrandom> de hecho, eso nos lleva a 2) Próximos pasos 13:18 <jrandom> lo principal que queda para la serie 0.5 es un conjunto de estrategias para ordenar y/o filtrar los peers usados en los tunnels 13:18 <godmode0> jrandom ¿se puede usar NNTP con i2p ? 13:18 <jrandom> godmode0: hay dos servidores NNTP en i2p, sí. mira el foro 13:19 <godmode0> jrandom ok estoy probando 13:19 <godmode0> ¿puedo montar mi servidor también? 13:20 <jrandom> godmode0: estamos en una reunión ahora mismo, pero sí, puedes ejecutar un servidor 13:20 <godmode0> jrandom ok perdón 13:20 <jrandom> no hay problema 13:20 <jrandom> las estrategias propuestas están básicamente orientadas a mejorar el anonimato, pero hay algunos otros objetivos que podemos equilibrar ahí 13:21 <jrandom> quizás podamos encontrar una manera de integrar algunas de las rutas AS (Sistema Autónomo) en la selección, como sugirió bla 13:22 <jrandom> eso puede mejorar el anonimato (jurisdiccional) y, si intentamos permanecer dentro de un AS (o dos), puede mejorar el rendimiento 13:22 <bla> jrandom: Esto básicamente está relacionado con un artículo de los creadores de Tor: http://theland.i2p/files/routing-zones.pdf 13:22 <jrandom> sí 13:23 <jrandom> hay un montón de estrategias distintas que la gente puede usar, y probar nuevas debería ser bastante fácil 13:24 <jrandom> no vamos a pasar meses implementando todo lo que se nos ocurra, sino proporcionar lo básico para lo que la mayoría necesita. cualquiera que quiera añadir nuevas está muy animado a ayudar a integrarlas 13:25 <jrandom> en fin, una vez que lo básico esté en su lugar, pasaremos a centrarnos en el transporte UDP para 0.6 13:26 <jrandom> eso es todo lo que tengo para 2) próximos pasos, ¿alguien tiene comentarios/preguntas/preocupaciones? 13:26 <bla> ¿Quiénes eran las personas que empezaron a mirar en I2P, otra vez? 13:26 <bla> Parece que no hemos oído mucho de ellos últimamente. 13:27 <bla> s/into I2P/into UDP/ 13:27 <bla> perdón 13:27 <jrandom> ah, mule ha estado enfermo, aunque creo que detonate está avanzando 13:28 <jrandom> detonate: ¿alguna novedad? 13:29 <jrandom> o quizá no ;) 13:30 <jrandom> vale, pasando a 3) azneti2p 13:30 <+detonate> perdón 13:30 <+detonate> estoy avanzando 13:30 <+detonate> todavía necesito terminar la parte de reensamblado 13:31 <+detonate> en lo que respecta a dividir los datos en paquetes y enviarlos de forma ordenada, eso funciona 13:31 <+detonate> vamos con el 3) 13:31 <jrandom> ¡genial! 13:31 <godmode0> perdón paso 2) ¿i2p tiene algún problema con ataques? 13:31 <bla> detonate: ¡Genial! ¿Puedes mantenernos informados a todos en el foro? 13:32 <+detonate> bla: claro 13:32 <tracker> Sobre azneti2p, mira aquí: http://sourceforge.net/forum/forum.php?thread_id=1233727&forum_id=377614 parece que descargar funciona, sembrar no. 13:32 <jrandom> godmode0: las diferentes estrategias de ordenación deberían permitir al usuario elegir el impacto de los ataques de predecesor 13:33 <microsoft> quienquiera que administre i2p.net debería añadir más palabrejas de moda de Enterprise Class Solutions a la página. 13:33 <+detonate> alguien tiene que asegurarse de que ese nuevo rastreador DHT no se esté portando mal también, con respecto al plugin de Azureus 13:33 <tracker> Mis pruebas locales parecen demostrarlo: puedo descargar con Azureus pero no sembrar. 13:34 <jrandom> hmm ok genial, tracker, gracias; sé que actualizaron algunas cosas y sacaron la b34 anoche, pero parece que queda más por hacer 13:34 <jrandom> detonate: buena observación 13:35 <tracker> Buena observación, detonate; tengo DHT desactivado porque Azureus muere tras unas horas con 100% de uso de CPU cuando está activado. 13:35 * jrandom quisiera reiterar que el plugin azneti2p aún está en una beta bastante temprana, y que las implicaciones de anonimato de Azureus no se han auditado completamente 13:36 <jrandom> aunque estoy seguro de que les encanta que la gente lo pruebe, quienes necesitan anonimato quizá quieran ser cautos 13:36 <tracker> Por otro lado, i2p-bt funciona muy bien. Excepto que no cierra los tunnels, pero eso no es tan grave en mi opinión. 13:37 <jrandom> oh, ¿eso te sigue pasando, tracker? no he podido reproducirlo 13:37 <jrandom> estás en la revisión 0.1.7, ¿verdad? 13:37 <tracker> Sí. 13:38 <jrandom> ok genial, si te pasa todo el tiempo me encantaría exprimirte el cerebro después de la reunión para ayudar a localizar la causa 13:39 <tracker> Quizá esté relacionado con ejecutarlo en XP en lugar de Linux o Unix. Cerrar el tunnel funciona con Azureus, así que supongo que es algo de I2P-BT. 13:39 <jrandom> hmm claro, i2p-bt usa SAM, mientras que Azureus usa el SDK de i2p directamente 13:40 <tracker> Por cierto. Te envié un informe de bug en el foro. El timestamper se cae en los últimos builds de CVS de I2P. 13:40 <jrandom> ah genial, gracias, no he mirado mis MPs allí hoy 13:41 <jrandom> ¿en -5 o -4? ¿o antes? 13:42 <jrandom> ah, -4. ok genial 13:42 <jrandom> gracias, arreglaré eso para 0.5.0.1 13:42 <jrandom> ok, ¿alguien tiene algo más para 3) azneti2p? 13:43 <tracker> También pasa en -5 13:43 <jrandom> tienes un servidor SNTP definido explícitamente, ¿verdad? 13:44 <tracker> Sí. Los 2 de nuestro país. 13:44 <jrandom> acabo de revisar el código fuente y la excepción ocurre si el nº de servidores concurrentes (por defecto = 3) es mayor que el nº de servidores especificados (el nuevo valor por defecto es 3) 13:44 <jrandom> ok genial, es un arreglo trivial de hacer % # servidores 13:45 <jrandom> ok, si no hay nada más para azneti2p, pasamos al clásico 4) ??? 13:46 <jrandom> ¿alguien más tiene algo que plantear para la reunión? 13:46 <tracker> Bien. Acabo de enviarte en el foro los errores del log del router al cerrar i2p-bt. 13:47 <jrandom> 'k genial, gracias 13:47 <cervantes> nada que mencionar excepto: buen trabajo con el despliegue de 0.5, parece que va a ser impresionante una vez que se planchen los bugs 13:48 <tracker> Sí, los últimos builds de CVS realmente están rindiendo bien por aquí. 13:48 <jrandom> gracias, con vuestra ayuda y la del resto de testers de 0.5-pre pudimos limpiar un montón de problemas 13:49 <jrandom> el rendimiento ha sido mejor de lo que esperaba, aunque aún no con un throughput tan alto como antes. sin embargo, queda mucho por optimizar 13:49 <cervantes> extrañamente las versiones pre eran más estables... para mí, pero claro, las estaba ejecutando en otra máquina ;-) 13:49 <jrandom> (y estos malditos bugs, para llevar la fiabilidad adonde debería estar) 13:50 <jrandom> je, bueno, sí, pero la red -pre eran 5-7 routers, todos increíblemente fiables en conexiones realmente, realmente rápidas 13:50 <cervantes> :) 13:51 <cervantes> apúntame para la prueba pre de 0.6 entonces :) 13:51 <jrandom> je 13:51 <tracker> Quizá debería participar en la próxima red pre entonces. Aportando una conexión muy poco fiable y lenta ;). 13:51 <jrandom> la migración a 0.6 probablemente será incluso más fácil, eso espero, ya que simplemente podremos añadir nuevas direcciones de router al routerInfo (direcciones UDP) 13:51 <jrandom> je, eso 13:51 <cervantes> puedo poner mi compartición de 1TB en línea... 13:52 <jrandom> definitivamente necesitaremos mucha ayuda con las pruebas de 0.6, incorporando toda una variedad de configuraciones de red 13:52 <hobbs> el comando ssh '~C' es ingenioso 13:52 <laberhorst> ¿será este otro paso no compatible? 13:53 <Myo9> ¿Alguien sabe qué servidores NNTP están activos? 13:53 <jrandom> laberhorst: no, 0.6 será retrocompatible 13:53 <jrandom> Myo9: ni idea, podrían estar arriba y simplemente verse afectados por los bugs de 0.5-0 13:54 <jrandom> la revisión 0.5.0.1 debería corregir muchos problemas, y una vez que salga, se recomendará mucho actualizar 13:54 <laberhorst> entonces simplemente construid una 0.6 de prueba y ponedla a los testers 13:54 <cervantes> podemos hacer que el tráfico BT use solo routers desactualizados... eso animará a la gente a actualizar ;-) 13:54 <laberhorst> así que gran fiesta de actualización mañana 13:54 <jrandom> habrá un anuncio en el foro y en la lista cuando esté listo 13:54 <jrandom> exacto, laberhorst 13:54 <jrandom> je, cervantes ;) 13:55 <laberhorst> *con muchas ganas de probar por vosotros* 13:55 <jrandom> El rendimiento de BT ha sido bastante bueno en 0.5, he visto muchas transferencias de archivos grandes exitosas en los trackers 13:55 <laberhorst> pload rate: 8.85 kB/s 13:55 <jrandom> (y el irc no se ha visto afectado como antes, más allá de los problemas que hemos tenido con el tunnel de duck) 13:55 <tracker> Depende de lo que llames grande ;) 13:56 <jrandom> tracker: estoy pensando en un archivo concreto de 874MB que tiene un montón de descargas exitosas ;) 13:56 <jrandom> pero es cierto, eso es pequeño para algunos 13:56 <laberhorst> solo porno del bueno y viejo 13:56 <laberhorst> supongo ;-) 13:57 <laberhorst> esperemos que a partir de mañana, mi router no participe en>3000 tunnels 13:57 <tracker> Vale, eso es grande. 13:57 <laberhorst> o, si es así, la red ES grande 13:57 <jrandom> je, laberhorst 13:58 <jrandom> ok, ¿alguien más tiene algo para la reunión? 13:58 <laberhorst> por cierto, ¿participar en >3000 es sinónimo de un buen router fiable en i2p con conexión rápida? 13:58 <+detonate> voy a poner boondock saints después de que consiga House esta noche :) 13:59 <+detonate> serán unos buenos 4,1 GB :) 13:59 * laberhorst solo quiere agradecer a los desarrolladores por aplastar bugs rápidamente 13:59 <+detonate> parece que hay mucha demanda 13:59 <laberhorst> oh, por aquí también hay algunas imágenes de DVD 13:59 <hobbs> detonate: ooh, cierto. House. :) 13:59 <tracker> cervantes, ¿ya actualizaste a phpBB 2.0.12 13:59 <laberhorst> pero esperad hasta que salga 0.5.0.1 13:59 <+detonate> debería darle una buena sacudida a 0.5.0.1 también 14:00 <+detonate> sí 14:00 <+detonate> eso pretendo 14:00 <jrandom> solo deberían descargarlos quienes ya posean copias legales de esos archivos, por supuesto. es solo para pruebas 14:00 <jrandom> *tos* 14:00 <tracker> rofl 14:01 * jrandom toma nota de mpaa.i2p 14:01 <+detonate> je 14:01 <laberhorst> oh, puedo generar imágenes ISO de Debian, Fedora, SuSE, fotos que hice,... 14:01 <laberhorst> así que mucho material legal 14:01 <laberhorst> si solo quieres probar, /dev/random es MUY grande 14:01 <Ragnarok> no siempre 14:02 <laberhorst> por cierto, para fines de semana solitarios: cat /dev/random | grep linux :-) 14:02 <jrandom> je 14:02 <frosk> /dev/random se vacía todo el tiempo, prefiero /dev/urandom :) 14:02 <frosk> o el nuevo y mejorado /dev/jrandom 14:02 <jrandom> nah, eso hace core dump todo el tiempo 14:03 <jrandom> y necesita su descanso nocturno 14:03 <Ragnarok> ¿cuál es la mejor manera de generar entropía para /dev/random? 14:03 <laberhorst> realmente deberíamos crear el fondo de "consíguele unas cervezas a jrandom" 14:03 <frosk> llámalo descanso o recolección de entropía :) 14:03 <hobbs> Ragnarok: Depende de lo que realmente quieras decir. Conseguir un RNG de hardware sería más o menos la forma "mejor" :) 14:03 <jrandom> Ragnarok: depende de tu SO (y de si tienes hardware ;) 14:04 <tracker> dd if=/dev/urandom of=/dev/hda bs=1M count=4 Siempre agradable ;) 14:04 <jrandom> en realidad incluiremos una implementación de Fortuna en uno de estos builds, y necesitaremos rebuscar varias fuentes de entropía 14:04 <Ragnarok> sin hardware :P 14:04 <susi23> . o O ( Pensé que alguien que usa i2p sabe por qué no debería usar /dev/urandom ) 14:05 <cervantes> tracker: los exploits de seguridad cubiertos en 2.0.12 mi mod_rocinante los corrige inadvertidamente, así que no me he molestado en actualizar aún 14:05 <hobbs> susi23: cuando es solo por travesura, creo que está bien ;) 14:05 <ant> <Nolar> ¿quién aquí hace el port de BT en Python? 14:05 <jrandom> Nolar: ese sería duck 14:06 * duck silba 14:06 <ant> <Nolar> duck: ¿por qué cambiaron el tamaño del bloque de petición a 128k? 14:06 <susi23> . o O ( el siguiente sugerirá: while true; do echo $RANDOM>> largefile; done ) 14:06 <ant> <Nolar> por eso az no puede sembrarte 14:06 <tracker> cervantes: Ok 14:06 <ant> <Nolar> bloqueamos peticiones> 64k 14:06 <laberhorst> rayos, necesito más mp3 14:06 <frosk> susi23: para grepear 'linux' en una tarde ociosa, /dev/urandom está bien :) 14:07 <jrandom> ah, ¿siempre lo hicieron? si mal no recuerdo i2p-bt ha usado 128k desde hace un tiempo 14:08 <ant> <Nolar> sí, desde el principio :) 14:08 <ant> <Nolar> ¿alguna razón para usar 128? 14:08 <ant> * duck revisa el log de cvs 14:08 <jrandom> mantiene lleno el pipeline, i2p tiene algo de latencia ;) 14:08 <jrandom> con 32KB, eso es esencialmente una ventana fija de tamaño 1 14:09 <jrandom> así que cada mensaje se bloquea esperando un ACK, mientras que 128KB permite que 4 mensajes vuelen dentro del RTT 14:09 <@duck> correcto, tamaño máximo de porción permitido según las especificaciones de BT 14:09 <ant> <Nolar> así que, en vez de hacer una única petición de 128k, envía por ejemplo dos de 64k 14:09 <cervantes> i2pbt está un poco más ágil que antes... quizá puedas permitirte reducirlo... 14:10 <@duck> schni, schna, schnappi 14:10 <ant> <Nolar> así que, en vez de hacer una única petición de 128k, envía por ejemplo dos de 64k 14:10 <hobbs> duck: jaja... esa cosa ha dado la vuelta al mundo. 14:10 <@duck> ¿por qué bloquean 128k? 14:11 <cervantes> *escalofrío* europop 14:11 <laberhorst> duck: por favor, cállate O te tumbo a tiros! 14:11 <tracker> A veces me arrepiento de haber aprendido alemán hace algunos años... 14:11 <laberhorst> nada de europop, de verdad no POP 14:11 * cervantes ordena al Reino Unido que repela fronteras antes de que una canción así entre en las listas 14:11 <laberhorst> tracker: no importa, está bien 14:12 <ant> <duck> ahora es (2^17)-13 14:12 <ant> <Nolar> duck: bueno, el límite ha estado ahí por un tiempo, pero una buena razón es que los bloques de 128K tardan en subirse... 16KB (nuestro valor por defecto) permite un control de solicitudes más fino 14:12 <ant> <duck> 13 bytes es la longitud del comando de BitTorrent 14:12 <ant> <duck> no tendría problema con (2^16)-13 14:12 <laberhorst> algo de música es realmente ridícula, pero música industrial de verdad, boh, no 14:13 <ant> <duck> ¿o volver al valor por defecto? 14:13 <jrandom> reducirlo a 64KB parece lo más simple (¿es eso un parámetro de CLI en este momento?) 14:13 <ant> <duck> --download_slice_size 14:14 <ant> <Nolar> bueno, mi pregunta es: ¿tienen una razón de peso para mantenerse en bloques de 128K? me parece un poco grande, especialmente para i2p 14:14 <ant> <Nolar> en lugar de simplemente hacer más pipelining (envío en canalización) de múltiples solicitudes más pequeñas? 14:14 <ant> <duck> no tengo ninguna razón. 14:14 <tracker> laberhorst: A veces pillo algunos canales alemanes vía satélite. Especialmente Viva y ese "Theater Kanal" son realmente espantosos... 14:15 <ant> <Nolar> un problema con los bloques grandes es que, una vez que te hago choke, aún tengo que terminar de enviar ese bloque de 128k 14:15 <jrandom> No recuerdo si el BT vainilla sabe hacer pipeline, pero debería ser bastante simple (especialmente dado que yo no lo estoy haciendo ;) 14:15 <ant> <Nolar> lo cual puede llevar un rato 14:15 <laberhorst> tracker: viva solo es interesante durante la hora de "hard rock", todo lo demás "por favor ignorar", y theater, no sé 14:15 <jrandom> con i2p, 128KB no es realmente tan grande, ya que hay una latencia inherente del orden de segundos 14:15 <ant> <Nolar> lo cual puede fastidiar el chunk/unchoke 14:16 <@duck> jrandom: ¿sigue teniendo sentido restar los 13 bytes de overhead de bittorrent para que quepa en un mensaje sam? 14:16 <jrandom> duck: nah, puesto que la biblioteca de streaming ya lo reduce más a mensajes de 16KB, así que simplemente que sea 64KB 14:17 <@duck> ok, 2**16 es 14:17 <jrandom> (y luego los tunnels rompen esos mensajes de 16KB en fragmentos de 996 bytes..) 14:17 <ant> <Nolar> el problema con 128k, es que si estoy subiendo a, digamos, 12 k/s, entonces me tomará más de 10 segundos terminar ese bloque 14:18 <cervantes> wow, eso es casi tanto como la latencia en irc... 14:18 <jrandom> lo cual son 1-10 RTTs (mientras que en la red normal, 10-500) 14:18 <+detonate> yo estaba listo para usar bloques de 512K 14:18 <ant> <Nolar> también podrían experimentar con pipelining de bloques de 16KB 14:18 <jrandom> je 14:18 <+detonate> ¿entonces 64 es preferido? 14:19 <ant> <Nolar> hasta donde sé, todos los clientes BT usan bloques de 16KB 14:19 <ant> <duck> arreglado en CVS; 14:19 <jrandom> ¡genial, gracias duck! (¡y Nolar!) 14:19 <ant> <duck> esperad que aparezca en la versión 0.1.8 junto con algunos ajustes SAM I2CP 14:19 <tracker> laberhorst: Su nombre completo es "ZDF Theater" o algo así. Y bueno, dicen que emiten un programa cultural de alto nivel. Realmente espero que lo que emiten no sea lo mejor que la cultura alemana puede ofrecer ;) 14:19 <jrandom> ok, je, acabo de recordar que aún estamos en una reunión 14:19 <jrandom> ¿alguien más tiene algo para la reunión? 14:20 <ant> <Nolar> así que si queremos un chunk de 128k, simplemente hacemos 8 solicitudes simultáneas 14:20 <susi23> . o O ( ¿y descartar los 448 bytes restantes? ) 14:20 <jrandom> sí, sí 14:20 <laberhorst> tracker: oh, ese es un canal lateral pequeño... arte o 3sat son realmente más interesantes 14:20 <laberhorst> y arte es alemán/francés :-) 14:20 <ant> <Nolar> si el uploader puede satisfacer tal petición, los 128k deberían empujarse en el flujo de la tubería de i2p 14:20 <jrandom> genial 14:21 <cervantes> . o O ( se pregunta por qué puede oír todo lo que piensa susi ) 14:21 <ant> <Nolar> así que podría valer la pena experimentar con tamaños de bloque de 16KB vs 32KB vs 64KB 14:21 <jrandom> sí 14:21 <jrandom> mientras esté en pipelining, a i2p no le importa 14:21 <ant> <Nolar> genial 14:22 <jrandom> la velocidad con 16KB sin pipelines es bastante mala, o al menos solía serlo 14:22 <tracker> laberhorst: Ok, intentaré ver si puedo pillar arte en los próximos días... 14:22 <ant> <duck> sugiero dejar estos ajustes para 0.2 14:22 <ant> <duck> ya que incluirá las mejoras de BitTorrent 3.9.1 14:22 <jrandom> sí, DTSTTCPW 14:22 <susi23> . o O ( oh, eso es fácil... la gente es tan predecible... ) 14:23 <ant> <duck> lo cual podría reestructurar completamente el código de red 14:23 <cervantes> http://www.gavelstore.com 14:24 <jrandom> ok, creo que eso es todo por el momento; la gente debería revisar la lista y el sitio en unas horas ya que la revisión 0.5.0.1 saldrá pronto 14:24 <ant> <Nolar> sí, puedo ver cómo peticiones individuales de 16KB serían lentas 14:24 * jrandom se descarga un mazo 14:24 * jrandom cierra la reunión con un *baf*