Reunión de desarrolladores de I2P - 04 de abril de 2006

16:21 <jrandom> 0) hola 16:21 <jrandom> 1) Estado de la red y 0.6.1.14 16:21 <jrandom> 2) Planificación de Syndie 16:21 <jrandom> 3) Optimizaciones locales de jbigi 16:21 <jrandom> 4) ??? 16:21 <jrandom> 0) hola 16:21 * jrandom saluda 16:21 <jrandom> notas semanales de estado publicadas en http://dev.i2p.net/pipermail/i2p/2006-April/001275.html 16:21 * Complication lee 16:22 <jrandom> mientras leen esa publicación (armada brevemente), vayamos directo a 1) Estado de la red 16:23 <@cervantes> (foro de vuelta) 16:23 <jrandom> hay algunos problemas que afectan el uso en 0.6.1.13, y la mayoría de ellos se han localizado y resuelto 16:24 <Complication> Por aquí, con la "cuarta" build de CVS, noté un cambio en mis gráficas 16:24 <jrandom> aún hay algunos detalles que se están probando y ajustando, pero debería haber un lanzamiento en los próximos días 16:24 <Complication> En general, las cosas se movieron hacia más estabilidad y menos saltos 16:24 <jrandom> oh, caray, olvidé incrementarlo a -4, ¿no? 16:24 <jrandom> (ok, -5 saldrá más tarde esta noche) 16:24 <jrandom> genial, Complication 16:25 <Complication> Pero mis percepciones podrían estar influenciadas también por jbigi, ya que no tomé medidas para excluirlo 16:25 <Complication> Ahora, después de un rato, la retransmisión también ha bajado hasta 15% 16:28 <jrandom> hmm, también veo que mi RTO promedio de ssu se acerca al techo de 3s 16:28 <jrandom> (aunque la retransmisión sigue siendo muy baja, por debajo del 5%) 16:29 * Complication le echa un segundo vistazo 16:29 <Complication> Digamos que el promedio bruto es un poco más de 1500 16:29 <Complication> (por aquí) 16:30 <+fox> <BrianR___> jrandom: ¿Hay un "MTU" de facto para los paquetes de i2p? 16:30 <jrandom> ah ok, quizá a medida que eso suba un poco, la tasa de retransmisión baje 16:30 <Complication> Noté que el mío empieza con MTUs más pequeños, ahora ha subido algo a 1350 16:30 <jrandom> BrianR___: sí, 1350 o 608 (como se muestra en http://localhost:7657/peers.js) 16:31 <jrandom> si la tasa de fallos es demasiado alta con el MTU más grande, retrocede al MTU más pequeño (y si es demasiado baja con el MTU más pequeño, salta al MTU más grande) 16:31 <+fox> <BrianR___> jrandom: ¿Y eso es para la carga interna o para los paquetes IP visibles? 16:31 <+fox> <BrianR___> Es decir, si enviara un bloque de datos sobre un stream de I2P, ¿cuál sería el tamaño ideal de los fragmentos para minimizar la sobrecarga? 16:31 <jrandom> eso es para la carga útil de UDP 16:32 <jrandom> los streams están dos capas arriba 16:32 <jrandom> (hay fragmentación para los túneles, y luego fragmentación a nivel de stream/i2cp) 16:32 <+fox> <BrianR___> Sí... ¿Hay un tamaño ideal para minimizar la fragmentación? 16:32 <jrandom> el tamaño de bloque ideal de una app que usa la biblioteca de streaming es «grande», para que la biblioteca de streaming pueda usar el tamaño apropiado. 16:33 <jrandom> (o sea, ignora al hombre detrás de la cortina) 16:33 <+fox> <BrianR___> Aah... Quizá entonces debería pensar en pipelining o algo así... 16:34 <+fox> <BrianR___> Estoy planeando una app con mucho tráfico de solicitud/respuesta... 16:34 <jrandom> entonces recomendaría agrupar en lotes para reducir la verbosidad 16:34 <Complication> Quizá mantener el tráfico focalizado ayudaría en cierta medida 16:37 <jrandom> ok, ¿algo más sobre 1) Estado de la red, o nos contoneamos hacia 2) Planificación de Syndie? 16:38 * jrandom se contonea 16:39 <jrandom> esto es en gran medida un marcador de posición y cfp: va a haber una remodelación sustancial de Syndie, tanto en operación como en la UI (interfaz de usuario), así que si tienen funciones clave o casos de uso que creen que deben abordarse, pónganse en contacto 16:40 <jrandom> (por supuesto, habrá más información a medida que se vaya concretando) 16:42 <jrandom> eso es todo lo que tengo que decir al respecto por el momento, así que pasemos a 3) optimizaciones de jbigi 16:42 <@frosk> y yo había supuesto que «plotting» se refería a algunas cosas de jrobin en Syndie :) 16:43 <jrandom> jeje 16:43 <jrandom> sería interesante graficar publicaciones/día, publicaciones/autor, autores nuevos/día, etc. ;) 16:44 <Complication> Oh, un bit sobre Syndie (perdón, recién me acordé ahora) 16:44 <Complication> =un bit 16:44 <@frosk> ¿cuál quieres, 0 o 1? :) 16:44 <Complication> ¿Crees que sería práctico, o fácil/difícil, separar autores favoritos y autores en lista negra (spam) en dos listas distintas? 16:45 <Complication> En addresses.jsp 16:45 <jrandom> oh, sí, sin mucho problema 16:46 <jrandom> esa es una buena idea para la remodelación también, pero quizá podamos meter eso en la build 0.6.1.14 16:47 <Complication> Nah, no me molesta, solo recordé algo que noté entonces 16:47 <Complication> De todos modos, jbigi se vuelve más rápido en Linux/AMD64 cuando compilas localmente y usas GMP 4.2 16:48 <jrandom> genial 16:48 <jrandom> ¿lo comparaste con -O3 -m64 en GMP 4.1.2? 16:48 <Complication> Y soy un condenado tonto por perseguir flags de compilación muy equivocadas :O 16:48 <@cervantes> el enlace relevante era http://forum.i2p/viewtopic.php?t=1523&start=30 por cierto 16:48 <jrandom> ah, gracias, cervantes 16:48 <Complication> jrandom: aún no he comparado, pero lo haré 16:49 <Complication> Durante el próximo reinicio programado 16:50 <jrandom> el proceso de build de jbigi es esencialmente «compilar GMP, luego compilar jbigi.o y enlazar ambos», así que cualquier tipo de optimizaciones que quieran hacer en GMP se puede hacer como primer paso 16:50 <@cervantes> No he visto mucha diferencia entre -O3 y -O2 en pruebas previas que he hecho; si eso es distinto en x86_64... *encoge los hombros* 16:50 <jrandom> sí, también podría depender de la revisión del compilador 16:50 <jrandom> (especialmente con todos estos temas de 3.3/3.4/4.0/4.1) 16:51 <@cervantes> solo para reiterar lo que mencioné en ese hilo... probablemente no veamos jbigi optimizado para windows64 en el corto plazo 16:51 <+fox> <BrianR___> ¿La biblioteca de streaming de i2p hace compresión de la carga útil? 16:52 <Complication> BrianR: sí 16:52 <@cervantes> a menos que alguien tenga M$ VC 2005 con SDK de 64 bits y le apetezca mucho sudor para lograr compilar gmp 16:52 <Complication> Al menos hasta donde sé 16:53 <@cervantes> (aunque había por ahí un proyecto para portar gmp a un proyecto de vc) 16:53 <jrandom> cervantes: bueno, tenemos uno que /funciona/ para amd64/win, pero no exprime al máximo el hardware ;) 16:53 <jrandom> (cuando llegue mi nueva máquina quizá pueda ajustar eso, ya que es un amd64) 16:53 <+fox> <BrianR___> tratando de decidir si debo usar un protocolo binario para ahorrar bits o si zlib o algo va a aplastar el protocolo ascii dejándolo lindo y pequeño... 16:54 <@cervantes> coolio; por desgracia, Mingw64 o cygwin64 no parecen estar en el horizonte cercano... 16:54 <jrandom> BrianR___: la optimización prematura es la raíz de todo mal, y todas esas zarandajas... 16:55 <Complication> los protocolos al menos parcialmente legibles por humanos suelen ser más fáciles de depurar, pero supongo que depende de lo que uno esté haciendo 16:56 <Complication> (porque a algunas cosas como el cifrado no les gusta ser legibles por humanos, pase lo que pase :) ) 16:57 <Complication> Pero si I2P hace el cifrado y además comprime, hay buenas probabilidades de que muchas cosas que ocurren encima de ello se puedan hacer con protocolos legibles por humanos 16:58 <jrandom> sí 16:58 <jrandom> ok, ¿algo más sobre 3) cosas de jbigi? 16:58 <jrandom> si no, pasemos a 4) ??? 16:59 <jrandom> ¿alguien tiene algo más para la reunión? 17:01 <+tethra> recuerdo haber oído algo sobre herramientas de colaboración anónimas recientemente 17:01 <+tethra> ¿quieres detallar de qué tipo, y si serán al estilo de Syndie o no? 17:02 <@cervantes> irc y Syndie son una herramienta de colaboración anónima :) 17:02 <jrandom> hmm, no estoy seguro a qué te refieres, o quizá hablas de las remodelaciones planificadas de Syndie? :) 17:02 <+tethra> cierto. 17:02 * tethra tampoco está seguro, por eso preguntó 17:02 <+tethra> se habló de ello en los foros: motivos para el anonimato y esas cosas 17:03 <+tethra> buscaré el hilo para poder sacar la cita 17:03 <jrandom> ah, claro 17:03 <+tethra> http://forum.i2p.net/viewtopic.php?t=1618 17:03 <jrandom> el hilo de casos de uso 17:03 <+tethra> - foros/tableros/wikis alojados anónimamente y públicamente accesibles 17:03 <+tethra> sí 17:04 <+tethra> ¿va a haber un proyecto tipo i2wiki basado en algo como Syndie o queda a criterio de los usuarios? 17:04 <jrandom> ha habido algunas buenas ideas allí, y buenos comentarios 17:05 <jrandom> la capacidad de editar publicaciones de Syndie es una función muy solicitada, y con eso podrías montar un wiki con un editor enriquecido 17:05 <jrandom> pero, por supuesto, nada existirá en el vacío: si alguien cree que eso es necesario, alguien debería decir «oye, un wiki es esencial, y aquí está el porqué» 17:06 <jrandom> hay una cantidad infinita de apps que /se pueden/ construir, pero como apuntamos a anonimato fuerte y seguridad fuerte, hay que tener cuidado con lo que se construye 17:07 <+tethra> correcto 17:07 <+tethra> dicho eso, algunas de las cosas más difíciles de mantener anónimas y seguras quizá sea mejor que las haga alguien que sea bueno manteniendo las cosas anónimas y seguras, ¿no? 17:08 <jrandom> probablemente sí, aunque no hay ninguna cábala: cualquiera puede aprender 17:08 <+tethra> (cosas clave, básicamente. no es que esté nombrando ninguna, pero bueno.) 17:08 <+tethra> cierto 17:09 <+tethra> pero aprender a costa del anonimato propio y ajeno no es la mejor manera de hacerlo 17:10 <jrandom> todos tienen que empezar por algún lado, por supuesto 17:10 <+tethra> (quizá si alguien hiciera algo tipo sandbox que permitiera a la gente ejecutar $software y que otros lo ataquen y demás, sería bueno para alguien nuevo/inexperto?) 17:10 <+tethra> sí 17:14 <jrandom> ok, ¿alguien más tiene algo para la reunión? 17:15 <jrandom> si no 17:15 * jrandom se dispone a concluir 17:15 <@cervantes> *ejem* 17:15 * jrandom hace una pausa 17:16 <jrandom> ¿qué se mueve, cerv? 17:16 <Complication> Genial, encontré un baf ;P 17:17 <jrandom> baf-bloqueado ;) 17:17 <@cervantes> ups, perdón, continúa baf-eando 17:17 * jrandom reanuda la conclusión 17:18 * jrandom *baf*ea la reunión para cerrarla