Reunión de desarrolladores de I2P - 29 de noviembre de 2005

15:25 <jrandom> 0) hola 15:25 <jrandom> 1) Estado de la red y 0.6.1.6 15:25 <jrandom> 2) Syndie 15:25 <jrandom> 3) I2P Rufus 0.0.4 15:25 <jrandom> 4) ??? 15:25 <jrandom> 0) hola 15:25 * jrandom saluda 15:25 <jrandom> notas semanales de estado publicadas en @ http://dev.i2p.net/pipermail/i2p/2005-November/001234.html 15:26 * bar le entrega a jrandom un baf 15:26 <c3rvantes> ¡todavía no! 15:26 * jrandom se prepara 15:26 <jrandom> eh... 15:26 <jrandom> vamos a abordar primero los primeros puntos del orden del día :) 1) Estado de la red y 0.6.1.6 15:27 <jrandom> se han actualizado muchas cosas en las últimas versiones, pero la red sigue pareciendo razonablemente estable. 15:28 <jrandom> hemos tenido algunos picos serios en la participación de router en algunos routers, aunque eso es bastante inofensivo 15:28 <+legion> genial, coincido en que el estado de la red está mejorando. Además, sí, ¿por qué no dejar de lado tcp para 0.6.1.7 15:28 <jrandom> (eh, picos en la participación de tunnel, eso quería decir) 15:29 <@cervantes> no bromeas 15:29 <jrandom> no estoy seguro, legion. Puede que haya algunos usuarios por ahí limitados solo a tcp, pero me parece recordar que solo había uno o quizá dos 15:29 <+legion> bueno, he notado que con la 0.6.1.5 el router a veces se reiniciaba solo. 15:29 <+Complication> El mío ha estado oscilando dentro de límites razonables, de 100 a 250 tunnels participantes 15:29 <jrandom> no se me ocurre ninguna gran razón para mantenerlo, y sí se me ocurren varias para quitarlo 15:30 <jrandom> genial, Complication 15:30 <jrandom> (esos números son bastante normales, según stats.i2p/, pero recuerda, cifras así pueden dañar el anonimato, así que no deberían divulgarse, especialmente no en reuniones registradas ;) 15:30 <+Complication> Mi viejo Celeron sigue reiniciándose automáticamente cada 10 horas más o menos 15:30 <+Complication> Por lo demás está mejor conectado que nunca 15:30 <Pseudonym> ¿cuáles son las razones para quitarlo? 15:31 <+Complication> TCP es costoso 15:31 <@cervantes> mi router está hecho polvo 15:31 <+Complication> En términos de hilos por conexión 15:31 <@cervantes> Complication: multiplícalo por 10 y obtienes el rango actual de mi router ;-) 15:31 <+legion> El mío ha estado oscilando entre 200-400 tunnels participantes, así que parece mejor que nunca. 15:32 <+Complication> cervantes: ay ay 15:32 <+Complication> He visto un accidente raro que causó 2000 tunnels participantes, pero eso fue en verano 15:32 <jrandom> Pseudonym: rendimiento (cpu/memoria, mejor planificación debido a nuestros requisitos semiconfiables), mantenibilidad, una lista negra más efectiva 15:32 <+Complication> Un solo pico que nunca volvió a repetirse 15:32 <+legion> sí, con algunas versiones pasadas hubo esos picos 15:32 <jrandom> Complication: hemos tenido picos de > 2000 tunnels con esta última revisión 15:33 <jrandom> pero con suerte 0.6.1.7 se encargará de eso 15:33 <+legion> Bueno, esas son buenas razones para quitar tcp :) 15:33 <jrandom> pero, de nuevo, los picos en la participación de tunnel están bien, ya que la mayoría no se usan 15:34 <@cervantes> Pseudonym: solo parece haber uno o dos routers que sigan usando tcp en la red 15:34 <jrandom> también puede ser buena idea quitar tcp en esta revisión, ya que no tiene otros cambios importantes. así podemos ver con bastante claridad cómo afecta a las cosas 15:34 <jrandom> (y podemos volver a habilitarlo si es necesario) 15:35 <Pseudonym> si solo hay dos routers usándolo, no puedo imaginar que tenga mucho efecto en ningún caso 15:35 <Pseudonym> (excepto que habría dos routers menos en la red) 15:35 <@cervantes> 2 clientes descontentos 15:35 <jrandom> bueno, el transporte sí aparece en algunas situaciones raras, lo cual es una de las razones por las que quiero deshabilitarlo :) 15:35 <+Complication> Espero que no se lo tomen muy a pecho 15:36 <+Complication> Es realmente feo por parte de ciertos ISP filtrar UDP. 15:36 <+Complication> Feo, y completamente sin sentido. 15:36 <jrandom> (p. ej., cuando un router está estropeado, la gente marca su transporte SSU como fallando y, por ello, vuelven al transporte tcp) 15:36 * Pseudonym ama a su ISP. sin restricciones 15:37 <+Complication> Entonces, sin TCP, ¿se vería cómo UDP lo maneja por sí solo? 15:37 <+Complication> «sin ruedas auxiliares» :P 15:37 <+legion> huh, entonces ¿cómo sorteamos un filtrado tan feo sin tcp? 15:38 <jrandom> exacto, Complication :) 15:38 <jrandom> legion: no lo hacemos 15:38 <jrandom> (rutas restringidas) 15:38 <+Complication> Bueno, ¿no hay bastantes aplicaciones útiles, además de los programas de intercambio de archivos, que también usan paquetes UDP de tamaño superior a los paquetes DNS? 15:39 <+legion> :( no suena bien 15:39 <+Complication> ¿De un tamaño similar al tamaño de paquete más pequeño que I2P usa? 15:39 <jrandom> eh, legion, no es un problema 15:39 <jrandom> Complication: protocolos de streaming 15:39 <+Complication> No se puede bloquear UDP directamente, jamás, sin inutilizar DNS. 15:39 <+Complication> Se puede limitar el tamaño de los paquetes. 15:40 <+legion> ok, sí sonaba como que podría serlo 15:40 <+Complication> ¿VoIP? 15:40 <jrandom> sería un problema si fuera generalizado: si la comunidad de Internet en general prohibiera udp 15:40 <+Complication> Hmm, ¿VoIP usa paquetes grandes o pequeños? 15:40 <jrandom> pero si son solo unos pocos isps, podemos tratarlos como rutas restringidas 15:40 <+Complication> ¿o te referías más a... video spreaming? 15:40 <+legion> Yo diría que usa una mezcla de ambos 15:41 <jrandom> ambos, Complication, RTSP va sobre UDP, y real va sobre RTSP si no recuerdo mal 15:41 <+Complication> s/p/s 15:42 <+legion> Entonces, ¿pasamos al siguiente punto? 15:42 <+Complication> cat /etc/services | grep -c udp 15:42 <+Complication> 227 15:43 <jrandom> Aún no estoy seguro de si quitaremos tcp en 0.6.1.7, pero probablemente. 15:43 <jrandom> sí, ¿alguien tiene algo más sobre el 1)? si no, pasemos al 2) Syndie 15:43 <+Complication> Es decir, hay al menos 227 aplicaciones (algunas posiblemente obsoletas o de LAN) que usan UDP 15:44 <jrandom> bah, esto es la intarweb. todo lo que necesitas es acceso HTTP con proxy 15:44 <jrandom> No tengo mucho que añadir al 2) más allá de lo que está en el correo (y lo que está en Syndie) 15:44 <+legion> Estoy convencido, sí, quítalo. :) 15:44 <jrandom> ¿alguien tiene algo respecto a syndie que quiera comentar? 15:45 <+legion> Yo tampoco tengo nada que decir sobre el 2). 15:45 * Complication está leyendo "how Syndie works" 15:46 <+Complication> Un pequeño efecto de UI me sigue sorprendiendo. :D 15:46 <+Complication> Cuando expando un hilo de mensajes, siempre me sorprende que el mensaje activo se mueva para convertirse en el primero de la lista. :P 15:47 <+Complication> Pero probablemente puedan ignorar eso sin problema. Solo soy muy quisquilloso y una criatura de hábitos. :P 15:47 <@cervantes> el modelo de threading es algo que se está discutiendo en detalle 15:47 <@cervantes> ;-) 15:47 <+Complication> Me acostumbraré. :) 15:48 <+Complication> cervantes: ¿en Syndie? Tengo que encontrar ese hilo. :) 15:48 <@cervantes> A mí tampoco me gusta, pero bien podría cambiar 15:48 <jrandom> sí, supongo que es un poco raro 15:48 <+legion> sí 15:48 <@cervantes> "subject: syndie threading" 15:49 <+Complication> Además, si el mensaje expandido fuera el último, *tendría* que moverse de todos modos. 15:49 <+Complication> Porque si no, se quedaría atascado ahí. 15:50 <jrandom> bueno, la navegación de abajo muestra 10 *threads* a la vez, no 10 mensajes. así que podría expandir el thread de abajo 15:50 * cervantes está probando algunas implementaciones de estilos de UI de threading distintas en este momento 15:51 <jrandom> wikked 15:51 <jrandom> sí, idealmente podremos alternarlos en css, o si no, del lado del servidor 15:52 <@cervantes> o más bien "threading navigation styles" 15:53 <@cervantes> hmm, mis pruebas usan listas no ordenadas anidadas en html puro por defecto 15:53 <@cervantes> puedes añadir tanto css y javascript como necesites o quieras 15:53 <jrandom> ¿algún eta de cuándo podremos ver algunos mockups? 15:53 <@cervantes> (sin embargo es solo una prueba de concepto, no una implementación de UI real) 15:54 <@cervantes> Hago la mayor parte de mi programación durante las reuniones de I2P ;-) 15:54 <jrandom> jeje 15:54 <@cervantes> quizá el primer mockup esté listo esta tarde 15:54 * jrandom programa reuniones diarias 15:54 <jrandom> wikked 15:54 <@cervantes> maldición :) 15:55 <jrandom> ok, ¿alguien tiene algo más para el 2) syndie? 15:55 <jrandom> si no, pasemos al 3) I2P Rufus 0.0.4 15:56 <jrandom> No tengo mucho que añadir más allá de lo que está en el correo: Rawn/defnax, ¿están por aquí? 15:56 <+legion> entonces, ¿qué tan buena es la 0.0.4? ¿Qué problemas quedan, si es que hay? 15:57 * jrandom no tiene ni idea 15:58 <+legion> Quizá alguno de sus usuarios pueda responder. ¿Parece buena y estable? 15:58 <jrandom> ok, parece que Rawn y defnax están ausentes por el momento. si alguien tiene preguntas/comentarios/inquietudes sobre I2P Rufus, pásense por el foro y publíquenlas 15:58 <+legion> rayos, supongo que tendremos que hacerlo. 15:59 <+legion> ¿pasamos al 4)? 15:59 <jrandom> sí, eso parece. ok, 4) ??? 15:59 <+Complication> No he probado I2P Rufus, por desgracia. 16:00 <jrandom> ¿alguien tiene algo más que quiera plantear? 16:00 <jrandom> (¡vamos, tenemos que alargar esto para que cervantes pueda hacer un poco más de trabajo!) 16:00 <+legion> sí, ¿qué tipo de cosas interesantes vienen en camino? 16:00 <+bar> ¿hay algún lugar donde pueda leer más sobre "restricted routes"? 16:00 <+bar> (ya *he* buscado) 16:01 <+legion> Quizá hasta podríamos discutir i2phex? 16:01 <jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD 16:01 * cervantes posa su ratón sobre el botón de cerrar 16:01 <jrandom> eh, #future.restricted 16:02 <jrandom> además de las páginas how_* y el todo 16:02 <jrandom> (en la web) 16:02 <+Complication> Je, parece que I2P se saltó un build :D 16:02 <+Complication> :D 16:02 <+bar> gracias 16:02 <+Complication> - public final static long BUILD = 1; 16:02 <+Complication> + public final static long BUILD = 3; 16:03 <jrandom> legion: algo de hacking en el netDb, modificaciones de rendimiento, rutas restringidas, mejoras de streaming, mejoras en eepproxy, mejoras de tunnel, etc. muchas cosas, pero nada listo aún 16:03 <+legion> huh, raro 16:03 <jrandom> ¿algo que plantear respecto a i2phex, legion? 16:03 <jrandom> Complication: sí, intencional. Me olvidé de subirlo para BUILD = 2 16:03 <+Complication> (no es que importe para nada, solo me preguntaba si ya había visto esta ocasión rara antes :) 16:04 <+legion> genial, suena muy bien, ¡gracias! 16:04 <jrandom> oh, eso me recuerda... estaría bien si alguien quisiera ponerse a ver cómo rediseñar nuestra página web 16:05 * jrandom no quiere pensar en ello, pero hay que hacerlo tarde o temprano 16:05 <+legion> sí, hay 16:05 <+legion> ¿valdría la pena actualizar i2phex a estas alturas al último código cvs de phex? 16:06 <+Complication> No estoy seguro, no he sabido de Redzara recientemente 16:06 <jrandom> lo último que recuerdo es que redzara estaba esperando las actualizaciones de phex de gregorz 16:06 <jrandom> (para que pudiéramos tener una actualización/extensión bastante limpia) 16:08 <+legion> huh, entonces ¿para qué tener i2phex? 16:08 <+Complication> ¿Por si acaso? 16:08 <jrandom> ¿hmm? 16:08 <jrandom> i2phex es una extensión de phex 16:08 <+legion> Parece que querían que solo hubiera phex con una extensión i2p 16:09 <jrandom> extensión, es decir, modificación a un número muy pequeño de bits 16:09 <jrandom> eh, s/bits/components/. así podemos actualizar fácilmente el código cuando los devs de phex arreglen cosas 16:10 <+legion> si es así entonces no debería llevarme mucho trabajo actualizarlo al último código cvs, aunque sé que sí lo llevará. 16:10 <jrandom> lo último que escuché en el foro fue que el plan es que I2Phex y Phex sean aplicaciones separadas, pero compartirían la mayor parte del código 16:10 <jrandom> sí, legion, eso estaría genial, pero lo último que supe es que Gregor aún no había terminado las modificaciones a Phex 16:11 <jrandom> (que es lo que redzara estaba esperando) 16:11 <+legion> ah, ya veo 16:11 <jrandom> entonces, la alternativa es ayudar a Gregor o seguir modificando la base de código existente de I2Phex 16:12 <+legion> bueno, entonces si no espero y simplemente actualizo i2phex con código nuevo, no habría necesidad de que redzara continuara 16:12 <jrandom> bueno, no exactamente. 16:12 <jrandom> actualizar I2Phex al código actual de Phex estaría muy bien, sí 16:13 <jrandom> pero en cuanto los desarrolladores de Phex actualicen su código de Phex, volveremos a desincronizarnos 16:13 <+legion> ok, probablemente me ponga con ello esta noche o dentro de un par de días. 16:13 <jrandom> wikked 16:13 <+legion> Está bien. 16:14 <+legion> Realmente no busco que i2phex se mantenga en sincronía con el código de phex, es solo que suena a que el cvs contiene correcciones que i2phex ciertamente podría usar. 16:15 <+legion> Además, realmente quiero eliminar cualquier código y funciones de phex que i2phex no necesite. 16:15 <jrandom> bien 16:16 <+legion> En cuanto a nuevas funciones y arreglar lo que todavía no funciona como las colas de subida... Bueno, ya he estado mirando cómo hacer que funcionen los webcaches, pero me queda mucho por hacer. 16:17 <jrandom> cierto. sí, phex solía tener soporte gwebcache funcionando, pero sirup lo deshabilitó, ya que al principio no era necesario 16:17 <+legion> Planeo añadir jeti a i2phex eventualmente. 16:17 <jrandom> genial 16:18 * jrandom nunca ha usado jeti, y espero que siga siendo un componente opcional, pero soportar más cosas está bien 16:18 <+legion> Sí, puede ser opcional, los usuarios podrán descargar un jeti2phex ;) 16:19 <jrandom> cierto 16:19 <+legion> Todavía hay mucho que podemos hacer con i2phex, aunque funciona muy bien tal como está. 16:20 <+legion> Hasta ahora mantener un cliente conectado, en marcha 24/7, es posible y fácil. 16:21 <jrandom> sí, he tenido bastante éxito con él... «haciendo copias de seguridad de mis grabaciones con licencia» 16:21 <+legion> jeje :) 16:22 <jrandom> ok, ¿alguien más tiene algo para la reunión? 16:23 * cervantes entra con el gong chino 16:23 <+legion> Parece que estoy olvidando algo... hmm 16:24 <+legion> Ah, sí, ¿alguna idea de cómo podemos reducir la cantidad de memoria que i2p e i2phex consumen? 16:25 <+Complication> Bueno, el transporte TCP consume un poco 16:25 <jrandom> se podría ejecutar ambos en la misma jvm 16:25 <+Complication> Si eso se va, liberará un poco 16:26 <@cervantes> quita algunos módulos de RAM de tu máquina 16:26 <cat-a-puss> ¿alguien con experiencia con javolution sabe si ayudaría? http://javolution.org/ 16:26 <jrandom> (clients.config en el directorio de instalación de i2p define la clase principal y los argumentos para lanzar clientes) 16:26 <+legion> Entonces, si ejecutáramos ambos en la misma jvm y cuando se vaya tcp, ¿podríamos bajarlo a menos de 50mb? 16:27 <jrandom> ni idea, legion. también depende de qué quieres decir con 50MB. RSS/VSS/etc 16:27 <jrandom> realmente no recomendaría ejecutar ambos en una sola JVM, a menos que mantengas ambos en ejecución todo el tiempo, ya que al cerrar uno matarías el otro 16:27 <@cervantes> legion: limitar el ancho de banda y poner un tope a los participantes también podría ayudar 16:27 <jrandom> sí, lo que dijo cervantes 16:28 <cat-a-puss> me parece que si sabemos exactamente cuántos de cierto tipo de objeto es probable que usemos, ayudaría a prevenir una asignación demasiado entusiasta de la jvm 16:28 <+Complication> Cierto, hace esas distintas asignaciones, de las cuales nunca he logrado entender bien 16:28 <jrandom> sí, hacemos algo de eso, cat-a-puss (ver net.i2p.util.ByteCache) 16:29 <+Complication> (pero como dije, Java es algo muy nuevo para mí) 16:29 <jrandom> He echado un vistazo a javolution antes, pero parece que ha avanzado mucho. le daré otro vistazo 16:30 <cat-a-puss> jrandom: sé que algunas personas en mi trabajo lo usan y están contentas, aunque no les importa la asignación de memoria 16:31 <jrandom> bueno, realmente no ahorraría memoria, pero ayudaría a reducir la agitación del GC 16:31 <+legion> Bueno, personalmente no me importa mucho la asignación de memoria, sin embargo a mucha gente sí. 16:31 <jrandom> ooh, y además tiene licencia BSD 16:31 <cat-a-puss> exacto 16:31 <jrandom> legion: asignación de memoria significa rendimiento 16:32 <+legion> eh, oh, entonces consumo de memoria 16:33 <+legion> Mucha gente está muy contenta con utorrent por su huella de memoria muy pequeña. 16:33 <jrandom> ah, oh, sí. podemos ajustarlo más adelante, pero como i2p se ejecuta dentro de los tamaños predeterminados de la jvm, no me preocupa demasiado (tenemos mucho margen para ajustar) 16:34 <jrandom> ok, ¿alguien tiene algo más para la reunión? 16:35 <+legion> nah, estoy bien... 16:37 * jrandom se prepara 16:37 * jrandom *baf* cierra la reunión