Reunión de desarrolladores de I2P - 18 de mayo de 2004

14:07 <jrandom> 0) hola 14:07 <jrandom> 1) estado de la testnet 14:07 <jrandom> 2) SAM 14:07 <jrandom> 3) actualizaciones del roadmap 14:07 <jrandom> 4) MyI2P 14:07 <jrandom> 5) ??? 14:07 <jrandom> 0) hola 14:07 * jrandom saluda 14:08 <Nightblade> hola 14:08 * jteitel devuelve el saludo 14:08 <jar> hola 14:08 <duck> hola 14:08 <Masterboy> :P 14:08 <jrandom> notas de estado semanales publicadas hasta http://dev.i2p.net/pipermail/i2p/2004-May/000239.html 14:09 <jrandom> perdón si estoy un poco fuera de lugar hoy, mi horario de sueño está más desajustado de lo habitual 14:09 <jrandom> en fin, pasando a 1) estado de la testnet 14:10 <duck> la diversificación ocurriría automáticamente con una red más grande, ¿no? 14:10 <jrandom> sí, y/o umbrales de selección de pares menos sesgados 14:11 <jrandom> por ejemplo, si el umbral de velocidad fuera la mediana en lugar del promedio, obtendríamos la mitad de pares rápidos que pares confiables 14:11 <jrandom> en lugar de la situación que tenemos hoy, donde las velocidades están muy sesgadas 14:12 <Masterboy> bueno, la red se recuperó, eso no está tan mal 14:12 <jrandom> sí, aunque tardó más de lo que debería, y expuso formas en que se puede mejorar 14:13 <jteitel> ¿la red se recuperó? Yo todavía no puedo conectar a i2p irc de forma confiable 14:13 <jrandom> los perfiles de pares no se degradaron lo suficientemente rápido, ni promovieron nuevos candidatos de manera eficiente 14:14 <jrandom> también desencadenó una cadena de eventos secundarios: sobrecargando routers que no eran capaces de soportar la carga (debido a perfilado insuficiente), provocando que algunos routers sobrecargados se quedaran sin memoria y se apagaran 14:15 <human> ¡ayee ayeee ayeee! 14:15 <jrandom> ha sido una progresión, jteitel: algunos de los problemas que hemos estado viendo están relacionados con los fallos de la netDb 14:15 <jrandom> hola human 14:15 <jteitel> Ah, OK 14:16 <_cervantes_> ¿no podría un router con problemas descargar tunnels a otro par? 14:16 <ugha_node> Wow, Tasa de por vida: 8.87KBps enviados 8.35KBps recibidos. 14:16 <Nightblade> jteitel: me conecté justo ahora después de varios intentos... aún esperando que pase mi /join 14:16 * BrianR mira alrededor. 14:16 <jrandom> no; un router sí puede simplemente descartar un tunnel (si no debería haberlo aceptado en primer lugar) 14:16 <ugha_node> (Y reinicié mi router hace media hora) 14:16 <BrianR> maldita sea. Llego tarde. 14:17 <BrianR> jrandom: (Gracias por poner myi2p hacia el final del orden del día) 14:17 <jrandom> ugha> sí, les tocó cubrir el hueco por esos tres rápidos 14:17 <jrandom> jeje :) 14:18 <duck> fue un buen ataque 14:18 <ugha_node> jrandom: Obviamente. 14:18 <_cervantes_> ¿no sería mejor ser más implacables y rechazar tunnels con un umbral más bajo? 14:19 <jrandom> sí, cervantes: los routers ahora mismo nunca rechazan un tunnel a menos que no puedan alcanzar el siguiente salto 14:19 <jrandom> querremos incluir algún tipo de throttling ahí, quizás basado en el tamaño de la jobQueue / latencia promedio, etc. 14:20 <jrandom> además, querremos asegurarnos de no intentar construir demasiados tunnels a la vez, como ocurrió cuando falló una gran parte de ellos 14:20 <_cervantes_> o simplemente permitir que el usuario establezca un umbral según el hardware/ancho de banda que sabe que tiene disponible 14:20 <jrandom> (debido a que los pares rápidos+confiables se fueron offline) 14:20 <_cervantes_> al menos en esta etapa 14:20 <jrandom> oh, ese es un buen punto: permitir que la gente establezca explícitamente un número máximo de tunnels participantes. 14:21 <jrandom> lo incluiremos en la próxima revisión. buena idea. 14:21 <ugha_node> Esto suena como lógica difusa. 14:21 <jrandom> tenemos que lidiar con la sobrecarga, y simplemente poner en cola mensajes en memoria ciertamente no funciona 14:21 <duck> (hola fvw) 14:21 <_cervantes_> sería bueno tener algún tipo de estadísticas consolidadas sobre el rendimiento de los tunnels... el tipo de carga que podrían infligir en un procesador(es) de benchmark 14:22 <_cervantes_> por cierto, saqué mi servidor offline... estaba recibiendo un montón enorme de tunnels y aún no he compilado jbigi ;-) 14:22 <jrandom> vean http://localhost:7655/routerStats.html#Tunnels 14:23 <jrandom> ¡ah! sí, jbigi es algo que queremos animar a todos a usar 14:23 <BrianR> ¿Alguna idea sobre presupuestar ancho de banda para tunnels? 14:24 <jrandom> actualmente previsto para 3.0 (con limitación de ancho de banda global para el router en su conjunto @ 0.4.1) 14:24 <jrandom> pero tener límites de ancho de banda por tunnel antes no haría daño 14:25 <fvw> ¿Tiene sentido dedicar esfuerzo a esto tan pronto cuando es mucho más fácil y preciso hacerlo en el kernel de los SO que la mayoría de los usuarios/probadores actuales están ejecutando? 14:25 <_cervantes_> algo que me gustaría ver son ajustes de profundidad por tunnel (quizá esto ya sea posible) 14:25 <_cervantes_> por ejemplo, ya sé que puedo confiar en mi servidor... así que no quiero tener que pasar por _x_ saltos para llegar a él 14:25 <jrandom> fvw> es un buen punto, especialmente porque actualmente no devoramos demasiado ancho de banda 14:26 <jrandom> hmm, cervantes: sí, cada cliente puede especificar la longitud de sus tunnels, pero no estoy seguro de que eso sea exactamente lo que quieres 14:26 <_cervantes_> nop 14:26 <jrandom> cervantes: creo que lo que buscas es un QoS (calidad de servicio) donde puedas acortar la conexión para un par en particular 14:26 <_cervantes_> por ejemplo... 14:26 <_cervantes_> sí 14:27 <jrandom> (que estaba previsto para i2p 4.0, pero eso está a más de un año == infinito) 14:27 <_cervantes_> en este caso también seleccionar la profundidad por host i2p 14:27 <BrianR> fvw: Sí, pero un i2p necesita saber aproximadamente cuánto ancho de banda tienen disponible los potenciales miembros del tunnel para tomar decisiones sensatas de construcción de tunnels... 14:27 <_cervantes_> ah ok 14:27 <_cervantes_> :) 14:27 <jrandom> pero es una buena idea, y técnicamente factible; se aceptan parches :) 14:28 <_cervantes_> el parche ya va en el correo... junto con ese cheque por 5000 barras de e-gold 14:28 <_cervantes_> ;-) 14:28 <jrandom> BrianR: quizá se pueda ir a medias: llevar cuenta de cuántos tunnels está participando, así como de cuánto ancho de banda están usando esos tunnels, y usar eso como parte de la decisión de aceptar o rechazar una solicitud de creación de tunnel? 14:28 <jrandom> jeh 14:30 <jrandom> ok, ¿alguien tiene algo más para el estado de la testnet? 14:30 <Masterboy> ¿qué hay de mi paradoja? 14:30 <Masterboy> :) 14:30 <jrandom> mi plan es sacar una 0.3.1.3 con las actualizaciones para el jueves o viernes 14:31 <jrandom> Masterboy: no he tenido tiempo de revisar tus logs, pero lo resolveremos 14:31 <_cervantes_> ¿viernes de 2005? 14:31 <_cervantes_> genial 14:31 <Masterboy> k 14:31 <jrandom> ok, pasando a 2) SAM 14:31 <Masterboy> ahora sabemos quién está ejecutando el router desactualizado.. 14:32 * jrandom pasa el micrófono a nuestro intrépido desarrollador de SAM.pm 14:33 <jrandom> (ese eres tú BrianR :) 14:33 <BrianR> Espera un segundo.. :) 14:33 * duck aplaude 14:33 <jrandom> mientras tanto, ¿dm o firerabbit por aquí? 14:33 -!- Irssi: #i2p: Total of 26 nicks [0 ops, 0 halfops, 0 voices, 26 normal] 14:33 * jrandom revisa /names, no. ni modo 14:33 <jrandom> (entonces no hay actualizaciones de la biblioteca SAM para .net/C#) 14:34 <duck> ¿lo de .py sigue vigente? 14:34 <duck> o quedado obsoleto por las mejoras de SAM 14:34 <jrandom> no estoy seguro 14:34 <BrianR> Ok. Ya volví. 14:34 <Nightblade> Mi biblioteca en C parece estar funcionando... aunque todavía no he escrito una aplicación para usarla 14:34 <jrandom> ¡genial, Nightblade! 14:35 <Nightblade> ¿Alguien aquí ha hecho programación GTK+/C en Windows? 14:35 <human> duck: la biblioteca cliente necesita un pequeño cambio para soporte de versionado 14:35 <_cervantes_> ¿"hola mundo"? 14:35 <human> duck: el resto debería funcionar sin problemas 14:35 * jrandom sugiere un datagrama tipo tftp como la prueba SAM ideal :) 14:35 <Nightblade> bueno, cualquier cosa realmente... ¿funciona bien GTK en windows.....? 14:35 <jrandom> (o incluso SAM streaming en lugar de datagram o raw) 14:36 <jrandom> bien, BrianR, ¿cómo va el .pm y el samcat? 14:36 <BrianR> Net::SAM está en el CVS en una forma mayormente no funcional. 14:36 <BrianR> Espero tener todos los bugs corregidos y datagram y raw funcionando antes de fin de semana. 14:37 <BrianR> Se requerirá un poco más de trabajo para darle un acabado OO (orientado a objetos) bonito a streams. 14:37 <Nightblade> oh sí, no me molesté con datagram ni raw... solo stream 14:37 <Nightblade> pero eso es todo lo que usaría de todos modos 14:37 <fvw> human: ¿Has considerado wxWindows? Es bastante útil para ese tipo de cosas (no creo que haya un target de GTK para windows) 14:37 <jrandom> impresionante, BrianR 14:38 <BrianR> Mi esposa me está insistiendo para que me una a ella para cenar. Puede que no regrese a tiempo para la discusión de myi2p. He publicado el modelo de amenazas y material de fileserver tonto en el nodo 208 14:38 <human> fvw: el port de GTK a Windows existe (The GIMP también corre en windows) 14:38 <jrandom> bien, Nightblade, es mejor implementar lo que se necesita primero 14:38 <human> fvw: s/client/port/ 14:38 <jrandom> jeh, 'k BrianR, gracias 14:38 <fvw> human: Me refiero a target de GTK en wxWindows (que era lo que te sugería usar) 14:38 * fvw saluda a BrianR. Buen provecho. 14:38 <human> fvw: ah... bueno, no sé sobre vxWidgets (el nuevo nombre de vxWindows :-) 14:39 <human> fvw: pero era Nightblade quien hablaba de GTK+, no yo :-) 14:40 <fvw> Ups, tengo los ojos torcidos, ignórenme. 14:40 <Nightblade> No estoy tan familiarizado con C++ como con C 14:40 <Nightblade> que yo sepa, GTK es la única biblioteca GUI en C multiplataforma 14:40 <Nightblade> no es que me encante GTK 14:40 <fvw> no importa realmente, wxWindows es fácilmente abordable desde C. 14:40 <Nightblade> hmm 14:40 <Nightblade> bueno, quizá también le eche un vistazo 14:40 <Nightblade> sé C++ pero no he escrito programas grandes en él 14:41 * fvw tampoco es programador de C++, pero monté un visor de transacciones bastante grande para una empresa de transporte en él hace un tiempo sin problemas. 14:42 <Nightblade> estoy seguro de que wxwindows tiene un port de Windows más maduro 14:42 <Nightblade> que gtk 14:42 <fvw> muy probablemente sí. 14:43 <Nightblade> (ok continúen con la reunión) jeh 14:43 <jrandom> :) 14:43 <jrandom> ok, saltando a 3) actualizaciones del roadmap 14:44 * jrandom ha sido negligente actualizando http://www.i2p.net/roadmap durante el último mes 14:44 <jrandom> pero ahora está al día 14:44 <jrandom> por desgracia, obviamente no vamos a tener 0.4 la próxima semana 14:44 <duck> (¿también están al día 1.1, 2.0, 3.0?) 14:45 <jrandom> sí señor 14:45 * Masterboy lo leí, me gustó - sin prisa, no estamos en llamas.. 14:46 <duck> alguien debería actualizar wikipedia/infoanarchy también :) 14:46 <jrandom> oh, probablemente debería quitar el "SAM bridge y bibliotecas cliente implementadas y probadas" de 0.4 14:46 <jrandom> jeh sí, por eso fue que !thwapped iA hace un tiempo cuando solo copiaron la página del wiki 14:46 <jrandom> (deberían simplemente apuntar al /roadmap, no duplicar el contenido) 14:47 <Masterboy> ¿SAM está terminado? 14:47 <jrandom> es funcional, sí, aunque el trabajo en bibliotecas cliente adicionales continúa 14:47 <jrandom> s/are/is/ 14:48 <jrandom> ok, a menos que haya más preguntas/preocupaciones sobre el roadmap, pasando a 4) MyI2P 14:50 <jrandom> aunque yo dejé de trabajar en myi2p, abrimos el esfuerzo a una recompensa - http://www.i2p.net/node/view/216 14:50 <jrandom> parte de eso significa que necesitamos acertar con los requisitos, y ha habido cierto debate sobre cuáles deberían ser 14:51 <Masterboy> intenté que entrara mi amigo, dijo demasiado trabajo y poco dinero ;P bueno, es un capitalista ;) 14:51 <Masterboy> bueno, me ofrecí a programarlo.. 14:52 <jrandom> programar en ello siempre es bienvenido :) 14:53 <jrandom> la cuestión arquitectónica pendiente ahora es cómo tratar con la gente que no puede ejecutar su i2p router / nodo myi2p todo el tiempo 14:53 <Nightblade> solo hay que tener algún ISP i2p de confianza 14:53 <jrandom> las dos propuestas son o usar proveedores de servicios hospedados, o dividir el sistema para usar un almacenamiento de respaldo distribuido 14:54 <_cervantes_> siendo esta última la solución ideal a largo plazo 14:54 <_cervantes_> *latter 14:54 <duck> (y siendo otra recompensa) 14:55 <_cervantes_> o un servicio de proxy de webcache... 14:55 <jrandom> correcto; si fuéramos por el proveedor de servicios hospedados (o nodo ejecutado localmente), cuando una DHT/etc estuvieran disponibles podríamos empujar cada vez más del contenido a la DHT 14:55 <jrandom> _cervantes_: eso es esencialmente el almacenamiento de respaldo distribuido: cachés de datos no confiables 14:57 <deer> * Masterboy se pregunta dónde está bogobot 14:57 <jrandom> la parte difícil es obtener la funcionalidad de control de acceso necesaria: con cachés de datos no confiables / almacenamiento de respaldo distribuido, las ACLs (listas de control de acceso) son básicamente cifrado 14:57 <jrandom> pero un "canal lateral" a esta discusión viene de los tres puntos planteados por una persona anónima @ http://www.i2p.net/node/view/215#comment-105 14:57 <_cervantes_> y contenido firmado 14:58 <jrandom> correcto, ambos caminos necesitarán tener contenido firmado 15:00 <_cervantes_> aquí es donde el modelo de hypercubus tiene mérito... pero no es de ninguna manera una solución "rápida" 15:00 <jrandom> de las discusiones en irc anoche, nos centramos en el "modelo de amenazas de LiveJournal": qué ataques les importan a los usuarios de LJ y cuáles no 15:01 <wilde> primero lo primero, conseguir un MyI2P básico en primer lugar 15:02 <jrandom> correcto, y para implementar el myi2p básico, tenemos que conocer la arquitectura de despliegue 15:03 <jrandom> con el modelo de amenazas de LJ para usuarios que no pueden ejecutar sus propios nodos, no creo que necesitemos ir por la ruta de cachés de datos no confiables 15:03 <jrandom> ¿y por qué usaría alguien myi2p si solo necesita el modelo de amenazas de LJ? porque es anónimo 15:04 <jrandom> podríamos seguir con algún sistema idealizado, pero existe la ley de rendimientos decrecientes 15:04 -!- Irssi: #i2p: Total of 24 nicks [0 ops, 0 halfops, 0 voices, 24 normal] 15:05 <jrandom> por eso me inclino por mantener la recompensa en los términos actuales: podemos añadir alternativas más adelante, después de que salga el sistema básico 15:05 -!- duck_ is now known as duck 15:06 <jrandom> en fin, creo que eso es todo lo que tengo para 4) MyI2P, a menos que alguien tenga algo más que quiera plantear 15:06 <jrandom> si no, pasando a 5) ??? 15:07 <_cervantes_> hmm necesitas un mazo grande :) 15:07 <jrandom> olvidé mencionar el nuevo eepsite de morph.i2p en las notas de la reunión, ¡y nickster.i2p ahora tiene un fproxy público disponible! 15:08 <jrandom> (y sungo.i2p tiene su webcam funcionando :) 15:08 <_cervantes_> jeh... 15:08 <_cervantes_> i2pr0n 15:08 <jrandom> ¿alguien más tiene algo que quiera plantear? 15:10 <jrandom> si no, eso nos deja en la marca de 70 minutos 15:10 <deer> <Masterboy> no 15:10 * jrandom concluye 15:10 * jrandom *baf* cierra la reunión