Reunión de desarrolladores de I2P - 28 de febrero de 2006

15:11 <jrandom> 0) hola 15:11 <jrandom> 1) Estado de la red y 0.6.1.12 15:11 <jrandom> 2) Camino a 0.6.2 15:12 <jrandom> 3) Miniproyectos 15:12 <jrandom> 4) ??? 15:12 <jrandom> 0) hola 15:12 * Complication lee rápidamente las notas 15:12 * jrandom saluda con la mano 15:12 <jrandom> notas semanales de estado publicadas en http://dev.i2p.net/pipermail/i2p/2006-February/001266.html 15:12 <jrandom> (¡y yo aquí publicando las notas con más de 15 minutos de antelación a la reunión! ;) 15:13 <jrandom> vale, mientras leen esas partes tan emocionantes, pasemos a 1) Estado de la red y 0.6.1.12 15:14 <jrandom> como se mencionó, los objetivos principales de las versiones 0.6.1.10-0.6.1.12 parecen haberse cumplido, abordando la modificación criptográfica en la creación de tunnel (túnel) y mejorando sustancialmente la fiabilidad de la creación 15:16 <jrandom> los baches que vimos en 0.6.1.10 han desaparecido, y la estabilidad de IRC parece bastante buena de nuevo 15:16 <jrandom> ¿alguien tiene algo más que plantear para 1) Estado de la red y 0.6.1.12, o nos movemos hacia 2) Camino a 0.6.2? 15:17 <+Complication> Estado de la red por aquí: ya no vuelve a bajar de 20 KB/s :) 15:18 <jrandom> genial; sí, 0.6.1.12 corrigió un bug bastante grande en 0.6.1.11 por el que no aprovechaba el ancho de banda disponible. ahora debería hacer un mejor uso de los recursos disponibles 15:20 <jrandom> bien, saltemos a 2) 15:20 <jrandom> como se mencionó, hay algunas cosas que hay que resolver antes de aplicar el último cambio funcional para 0.6.2, pero estamos avanzando en ese frente 15:20 <nymisis> el estado de la red está bien :) 15:22 <jrandom> cierto. habrá más información disponible sobre los detalles de las nuevas estrategias de ordenación de pares antes de que salgan, pero la esencia debería quedar clara por su breve mención en las notas 15:23 <jrandom> ¿alguien tiene preguntas/comentarios/preocupaciones respecto a 2) camino a 0.6.2? 15:23 <postman> jrandom: ¿alguna red de pruebas esta vez? 15:24 <postman> (¿necesitan routers, participantes para probar cosas?) 15:24 <postman> ? 15:24 <+Complication> La esencia del asunto parecía bastante directa: limitar la oportunidad de que un adversario recoja datos estadísticos diversos 15:25 <+Complication> Suena como una característica bastante deseable 15:25 <jrandom> postman: lo nuevo debería funcionar de forma transparente en la red en producción usando información solo local, así que no debería necesitarse una red separada para probar 15:25 <jrandom> sí, exactamente, Complication 15:26 <postman> ok 15:26 <postman> jrandom: ¿eres lo bastante audaz como para revelar una fecha estimada (ETA) para 0.6.2? :) 15:27 <blubb> 1 de abril 15:27 <jrandom> bueno, dado que hoy es fin de febrero, supongo que marzo o abril 15:27 <postman> jeje 15:27 <jrandom> blubb: ya tenemos programada una backdoor de MI6 para entonces ;) 15:29 <@cervantes> más bien una gatera de MI6 15:29 <@cervantes> (recortes presupuestarios) 15:29 <postman> en una casa de elefantes 15:30 <nymisis> Es SIS, no MI6, si vamos a ser precisos. :) 15:30 <jrandom> bueno, llamémosles simplemente Ellos ;) 15:31 <jrandom> bien, ¿algo más para 2)? 15:31 <jrandom> si no, pasemos con ritmo a 3) miniproyectos 15:31 <@cervantes> perdón, «la firma» 15:34 <jrandom> ok, solo quería señalar algunas cosas interesantes que serían 1) simples de hacer y 2) realmente útiles 15:34 <+Complication> En cuanto a los miniproyectos, no estoy seguro de si llegó mi respuesta sobre Syndie o no, pero me pregunto si podría agarrar uno. 15:34 <+Complication> Aún no estoy seguro de cuál. Ahora mismo estoy practicando un poco más de Java (haciendo un microproyecto :D) solo para tener más certeza de que, cuando lo intente, podré encargarme de uno 15:35 <DeltaQ> hmm, si subo el bw en la consola, ¿los cambios son inmediatos o se necesita reiniciar? 15:35 <+Complication> Cuando me ponga al día con el «microproyecto» (suponiendo, claro, que la mesa no se haya quedado vacía), intentaré escoger uno 15:35 <jrandom> w3wt, genial, Complication 15:36 <jrandom> DeltaQ: inmediatamente 15:36 <@cervantes> ¿no está 1) el planificador de Syndie vinculado con 4) el Gestor de Descargas / planificador de eepget 15:36 <+Complication> DeltaQ: surte efecto casi al instante (dentro de los periodos sobre los que se promedia el ancho de banda) 15:37 <@cervantes> me parece que un gestor de subidas y descargas más general cubriría ambas necesidades 15:37 <jrandom> cervantes: hmm, no necesariamente. 1) está bastante enfocado y también incluye pushes, mientras que 4) es bastante genérico 15:37 <+Complication> cervantes: suena a que podría 15:37 <jrandom> pero sí, el motor detrás de ambos es EepGet (herramienta de transferencia HTTP de I2P) 15:37 <jrandom> (eepget hace las transferencias HTTP de Syndie, de forma programática) 15:38 <DeltaQ> el promedio no parece subir por encima de 13 kb/s 15:38 <DeltaQ> puse 64 kb/s con 192 de ráfaga de bajada 15:38 <DeltaQ> 32/64 de subida 15:38 <@cervantes> así que un eepget genérico para push y pull con una API de planificación y gestión... 15:39 <@cervantes> aun así, probablemente deja de ser un miniproyecto en ese punto 15:39 <+Complication> DeltaQ: el promedio también depende de cuánta carga generen tus client tunnels (y los participating tunnels de otros pares) 15:39 <+Complication> perdón, s/average/actual bandwidth 15:39 <jrandom> cervantes: sí, aunque en lo de Syndie hay una lógica considerable implicada. 15:40 <DeltaQ> je, por fin subió 15:40 <DeltaQ> 1s: 30.82/29.33KBps 15:40 <DeltaQ> supongo que necesitaba subir el ancho de banda de subida 15:40 <jrandom> DeltaQ: el promedio también se verá afectado por cómo te ven los demás, lo cual depende de tus acciones, no de ninguna tasa anunciada, así que llevará un poco 15:40 <+Complication> DeltaQ: para el tráfico de paso (participating tunnels), lo que entra también debe salir 15:41 <+Complication> DeltaQ: así que tasas de subida/bajada muy distintas estrangularían el tráfico participante al menor de los dos valores 15:42 <+Complication> DeltaQ: además, el tráfico participante depende de cómo otros nodos «perciben» la capacidad de encaminamiento de tu nodo 15:42 <DeltaQ> oki 15:43 <+Complication> Si creen que puede encaminar bien, pedirán más a menudo 15:43 <jrandom> bien, si no hay nada más sobre 3) miniproyectos, pasemos a 4) ??? 15:43 <jrandom> ¿alguien tiene algo más que plantear para la reunión? 15:43 <DeltaQ> bueno, estoy detrás de un router, pero reenvié el puerto 8887 a esta PC 15:43 <+Complication> Si es nuevo, o solo ha aumentado recientemente de capacidad, son un poco tímidos 15:44 <DeltaQ> oh, perdón, no quería interferir en una reunión ^^ 15:44 <+Complication> Alguien preguntó el otro día sobre posibles ataques basados en la desviación del reloj. Creo que vi tu respuesta sobre la parte de tunneling (el mensaje de creación solo contiene el período de validez del tunnel, no la hora desde la perspectiva de su creador)... 15:44 <@cervantes> (gracias por la mención en las notas de estado) ;-)_ 15:46 <+Complication> Así que pensé, de hecho, en preguntar... ¿qué puntos, si es que hay alguno, en la mensajería de I2P podrían contener la hora desde la perspectiva del remitente? 15:47 <+Complication> No he logrado ponerme al día en esto, así que estoy un poco perdido al respecto 15:47 <jrandom> Complication: nada dice explícitamente «Creo que ahora es $time», pero con tráfico suficiente y análisis de temporización, probablemente se podría acotar sustancialmente 15:48 <jrandom> cuantizamos los tiempos con un período amplio, aunque no tan amplio como nuestra desviación máxima del reloj, así que hay margen ahí 15:49 <+Complication> ¿Crees que en última instancia habría algún beneficio en un cliente NTP más «afinado»? 15:49 <+Complication> ¿Uno que pudiera mantener más fácilmente desviaciones más pequeñas? 15:50 <jrandom> bueno, desde que se introdujo el cliente sntp en i2p, ha ido mejorando cada vez más, de modo que ahora no vemos la variación que veíamos antes 15:51 <jrandom> quizá podríamos reducir el límite mínimo de desviación de 10 s a quizá 2 o 3 s, o incluso menos 15:51 <jrandom> alternativamente, podríamos permitirle mirar también las desviaciones de reloj de ssu para evitar desviaciones innecesarias 15:52 <+Complication> O, alternativamente, ¿sería posible limitar aún más cualquier oportunidad de adivinar el posible valor de reloj de otro par? 15:53 * Complication no sabe qué camino sería más práctico, solo sugiere posibilidades al azar :D 15:53 <jrandom> no, conocemos la desviación del reloj de los pares conectados directamente 15:55 <Magii> ¿hay alguna manera de saber si la actualización se hizo correctamente? 15:55 <+Complication> Ajá, así que el protocolo de sesión realmente depende de esa información... 15:55 <tethra> mira tu número de versión 15:55 <+Complication> Magii: debería registrar un CRIT como «update verified, restarting to install» en los logs 15:55 <tethra> :/ 15:55 <+Complication> Luego, debería hacer una cuenta atrás de minutos hasta un reinicio ordenado 15:56 <+Complication> Y finalmente reiniciar 15:57 <+Complication> Oh, apunte: ¿el cliente NTP interno conoce un concepto como «tasa de deriva del reloj»? 15:58 <jrandom> sí, el número de versión en la esquina superior izquierda de http://localhost:7657/index.jsp debería delatarlo :) 15:58 <jrandom> Complication: no, no garantiza tics de reloj secuenciales 15:59 <jrandom> s/secuenciales/ordenados/ 15:59 <+Complication> ¿Ni desarrolla conocimiento como «nuestro reloj del sistema es 0.00345 veces más rápido de lo necesario»? 16:00 <jrandom> ah, no, aunque añadir eso a net.i2p.util.Clock no sería tan difícil (¿quieres un miniproyecto? :) 16:00 <+Complication> Estaba pensando en algo por esas líneas 16:01 <+Complication> Creo que ahora estoy pensándolo un poco más :) 16:01 <+Complication> Aunque primero otros miniproyectos :) 16:02 <jrandom> ok, ¿alguien tiene algo más para la reunión? 16:03 <nymisis> ¿Muffins? 16:04 <jrandom> no, tortitas 16:04 <jrandom> (mmMMmm tortitas) 16:04 <jrandom> hablando de eso 16:04 * jrandom se prepara 16:04 <nymisis> Oh, caray, buen punto. 16:04 * jrandom *baf* cierra la reunión