Réunion des développeurs I2P - 4 avril 2006

16:21 <jrandom> 0) salut 16:21 <jrandom> 1) État du réseau et 0.6.1.14 16:21 <jrandom> 2) planification de Syndie 16:21 <jrandom> 3) optimisations jbigi locales 16:21 <jrandom> 4) ??? 16:21 <jrandom> 0) salut 16:21 * jrandom fait coucou 16:21 <jrandom> notes d’état hebdomadaires publiées sur http://dev.i2p.net/pipermail/i2p/2006-April/001275.html 16:21 * Complication lit 16:22 <jrandom> pendant que vous lisez tous ce billet (rapidement assemblé), passons directement à 1) État du réseau 16:23 <@cervantes> (forum de retour) 16:23 <jrandom> il y a quelques problèmes affectant l’utilisation de la 0.6.1.13, et la plupart d’entre eux ont été identifiés et résolus 16:24 <Complication> Ici, avec la « quatrième » build CVS, j’ai remarqué un changement dans mes graphiques 16:24 <jrandom> il reste encore quelques pépins en cours de test et de refonte, mais une version devrait sortir d’ici quelques jours 16:24 <Complication> En général, les choses ont évolué vers plus de stabilité et moins d’instabilité 16:24 <jrandom> oh mince, j’ai oublié de l’incrémenter à -4, n’est-ce pas ? 16:24 <jrandom> (ok, -5 sortira plus tard ce soir) 16:24 <jrandom> cool Complication 16:25 <Complication> Mais mes impressions pourraient aussi être influencées par jbigi, car je n’ai pas pris de mesures pour écarter cela 16:25 <Complication> Maintenant, après un moment, la retransmission est descendue à 15 % également 16:28 <jrandom> hmm, je vois aussi mon RTO SSU moyen approcher le plafond de 3 s 16:28 <jrandom> (bien que la retransmission reste très basse, sous les 5 %) 16:29 * Complication y jette un second coup d’œil 16:29 <Complication> Disons que la moyenne brute est un peu au-dessus de 1500 16:29 <Complication> (chez moi) 16:30 <+fox> <BrianR___> jrandom: Y a-t-il une « MTU » de facto pour les paquets i2p ? 16:30 <jrandom> ah ok, peut-être qu’à mesure que cela augmente, le taux de retransmission baissera 16:30 <Complication> J’ai remarqué que chez moi ça démarrait avec des MTU plus petites, maintenant c’est monté à 1350 16:30 <jrandom> BrianR___: oui, soit 1350 soit 608 (comme indiqué sur `http://localhost:7657/peers.js)` 16:31 <jrandom> si le taux d’échec est trop élevé avec la MTU plus grande, on revient à la MTU plus petite (et s’il est trop bas avec la MTU plus petite, on remonte à la MTU plus grande) 16:31 <+fox> <BrianR___> jrandom: Est-ce que c’est pour la charge utile interne ou pour les paquets IP visibles ? 16:31 <+fox> <BrianR___> C.-à-d., si j’envoyais un bloc de données sur un flux I2P, quelle serait la taille idéale des morceaux pour minimiser la surcharge ? 16:31 <jrandom> c’est pour la charge utile UDP 16:32 <jrandom> les flux sont deux couches au-dessus 16:32 <jrandom> (il y a une fragmentation pour les tunnels, puis une fragmentation au niveau stream/i2cp) 16:32 <+fox> <BrianR___> Oui... Y a-t-il une taille idéale pour minimiser la fragmentation ? 16:32 <jrandom> la taille de bloc idéale d’une appli utilisant la streaming lib (bibliothèque de streaming) est « grande », afin que la streaming lib puisse utiliser la taille appropriée. 16:33 <jrandom> (alias ignorez l’homme derrière le rideau) 16:33 <+fox> <BrianR___> Aah... Peut-être que je devrais penser au pipelining ou quelque chose du genre alors... 16:34 <+fox> <BrianR___> Je prévois une appli avec beaucoup de trafic requête/réponse... 16:34 <jrandom> je recommanderais alors de regrouper par lots pour réduire le bavardage 16:34 <Complication> Peut-être que garder le trafic focalisé aiderait dans une certaine mesure 16:37 <jrandom> ok, autre chose sur 1) État du réseau, ou on se trémousse jusqu’à 2) planification de Syndie 16:38 * jrandom se trémousse 16:39 <jrandom> c’est en grande partie un appel à contributions (cfp) — il va y avoir une refonte substantielle de Syndie, à la fois côté fonctionnement et UI, donc si vous avez des fonctionnalités clés ou des cas d’usage qui, selon vous, doivent être pris en compte, contactez-nous 16:40 <jrandom> (plus d’infos arriveront bien sûr au fur et à mesure que les choses se préciseront) 16:42 <jrandom> c’est tout ce que j’ai à dire là-dessus pour le moment, donc passons à 3) optimisations jbigi 16:42 <@frosk> et je pensais que « plotting » faisait référence à des trucs jrobin dans Syndie :) 16:43 <jrandom> héhé 16:43 <jrandom> ce serait intéressant de tracer posts/jour, posts/auteur, nouveaux auteurs/jour, etc. ;) 16:44 <Complication> Oh, un point à propos de Syndie (désolé, je viens seulement de m’en souvenir) 16:44 <Complication> =un point 16:44 <@frosk> lequel tu veux, 0 ou 1 ? :) 16:44 <Complication> Penses-tu qu’il serait pratique, ou facile/difficile, de séparer les auteurs favoris et les auteurs sur liste noire (spam) en deux listes différentes ? 16:45 <Complication> Sur addresses.jsp 16:45 <jrandom> oh, oui, sans trop de difficulté 16:46 <jrandom> c’est une bonne idée pour la refonte aussi, mais on pourra peut-être l’intégrer dans la build 0.6.1.14 16:47 <Complication> Non, ça ne me chiffonne pas, je viens juste de me rappeler de quelque chose que j’avais remarqué à l’époque 16:47 <Complication> Quoi qu’il en soit, jbigi devient plus rapide sur Linux/AMD64 quand on compile localement et qu’on utilise GMP 4.2 16:48 <jrandom> cool 16:48 <jrandom> as-tu comparé ça avec -O3 -m64 sur GMP 4.1.2 ? 16:48 <Complication> Et je suis un sacré idiot d’avoir utilisé des options de compilation complètement à côté de la plaque :O 16:48 <@cervantes> le lien pertinent était `http://forum.i2p/viewtopic.php?t=1523&start=30` au fait 16:48 <jrandom> ah merci cervantes 16:48 <Complication> jrandom : je n’ai pas encore comparé, mais je le ferai 16:49 <Complication> Lors du prochain redémarrage planifié 16:50 <jrandom> le processus de compilation de jbigi consiste essentiellement à « compiler GMP, puis compiler jbigi.o, et lier les deux ensemble », donc tout type d’optimisations que les gens veulent faire sur GMP peut être fait en première étape 16:50 <@cervantes> Je n’ai pas vu beaucoup de différence entre -O3 et -O2 dans mes précédents tests, que ce soit différent sous x86_64 ... *hausse les épaules* 16:50 <jrandom> oui, ça pourrait aussi dépendre de la révision du compilateur 16:50 <jrandom> (surtout avec tous ces problèmes 3.3/3.4/4.0/4.1) 16:51 <@cervantes> juste pour réitérer ce que j’ai mentionné dans ce fil... on ne verra probablement pas de jbigi optimisé pour Windows64 de sitôt 16:51 <+fox> <BrianR___> Est-ce que la i2p stream lib effectue une compression de la charge utile ? 16:52 <Complication> BrianR : oui 16:52 <@cervantes> à moins que quelqu’un n’ait M$ VC 2005 w/64-bit SDK et l’envie de suer sang et eau pour réussir à compiler gmp 16:52 <Complication> À ma connaissance du moins 16:53 <@cervantes> (il y avait toutefois quelque part un projet pour porter gmp dans un projet vc) 16:53 <jrandom> cervantes: eh bien, on en a un qui /marche/ pour amd64/win, mais il n’exploite pas au mieux le matériel ;) 16:53 <jrandom> (quand ma nouvelle bécane arrivera, je pourrai peut-être ajuster ça, puisqu’elle est en amd64) 16:53 <+fox> <BrianR___> j’essaie de déterminer si je dois utiliser un protocole binaire pour économiser des bits ou si zlib ou autre va compresser un protocole ASCII bien propre et compact.. 16:54 <@cervantes> coolio - malheureusement Mingw64 ou cygwin64 ne semblent pas être pour tout de suite... 16:54 <jrandom> BrianR___: l’optimisation prématurée étant la racine de tout mal, et tout ce jazz... 16:55 <Complication> les protocoles au moins partiellement lisibles par des humains sont généralement plus faciles à déboguer, mais j’imagine que ça dépend de ce qu’on fait 16:56 <Complication> (parce que certaines choses comme le chiffrement n’aiment pas être lisibles par des humains, quoi qu’il arrive :) ) 16:57 <Complication> Mais si I2P fait le chiffrement et compresse aussi, il y a de bonnes chances que beaucoup de choses au-dessus puissent se faire avec des protocoles lisibles par des humains 16:58 <jrandom> oui 16:58 <jrandom> ok, autre chose concernant 3) le truc jbigi ? 16:58 <jrandom> sinon, passons à 4) ??? 16:59 <jrandom> quelqu’un a autre chose pour la réunion ? 17:01 <+tethra> je me souviens avoir entendu parler récemment d’outils de collaboration anonymes 17:01 <+tethra> tu veux bien développer sur le type, et s’ils seront dans l’esprit de Syndie ou non ? 17:02 <@cervantes> irc et Syndie sont des outils de collaboration anonymes :) 17:02 <jrandom> hmm, je ne suis pas sûr de ce à quoi tu fais référence - ou peut-être que tu veux dire les refontes de Syndie prévues ? :) 17:02 <+tethra> vrai. 17:02 * tethra n’est pas sûr non plus, c’est pour ça qu’il a demandé 17:02 <+tethra> on en a parlé sur les forums - raisons de l’anonymat et tout ça 17:03 <+tethra> je vais retrouver le fil pour pouvoir citer 17:03 <jrandom> ah oui 17:03 <+tethra> http://forum.i2p.net/viewtopic.php?t=1618 17:03 <jrandom> le fil des cas d’usage 17:03 <+tethra> - forums/boards/wikis hébergés anonymement et accessibles publiquement 17:03 <+tethra> ouais 17:04 <+tethra> est-ce qu’il va y avoir un projet de type i2wiki basé sur quelque chose comme Syndie, ou est-ce aux utilisateurs de s’en charger ? 17:04 <jrandom> il y a eu de bonnes idées là-dedans, et de bons retours 17:05 <jrandom> la possibilité d’éditer des posts Syndie est une fonctionnalité souvent demandée, et avec ça, on pourrait réaliser un wiki avec un éditeur riche 17:05 <jrandom> mais, bien sûr, rien n’existera dans le vide - si quelqu’un pense que c’est nécessaire, quelqu’un devrait dire « hé, un wiki est essentiel, et voici pourquoi » 17:06 <jrandom> il y a un nombre infini d’applis qui /peuvent/ être construites, mais comme nous visons un anonymat fort et une sécurité forte, il faut faire attention à ce qui est construit 17:07 <+tethra> d’accord 17:07 <+tethra> cela dit, certaines des choses les plus difficiles à garder anonymes et sécurisées seraient peut-être mieux faites par quelqu’un qui sait bien garder les choses anonymes et sécurisées, non ? 17:08 <jrandom> probablement, même s’il n’y a pas de cabale - tout le monde peut apprendre 17:08 <+tethra> (des choses clés, en gros. pas que j’en nomme, mais bon.) 17:08 <+tethra> c’est vrai 17:09 <+tethra> mais apprendre au prix de ton anonymat et de celui des autres n’est pas la meilleure façon de faire 17:10 <jrandom> tout le monde doit bien commencer quelque part, évidemment 17:10 <+tethra> (peut-être que si quelqu’un faisait une sorte de sandbox permettant aux gens d’exécuter $software et de le faire attaquer par d’autres, etc., ce serait bien pour quelqu’un de nouveau/inexpérimenté ?) 17:10 <+tethra> ouais 17:14 <jrandom> ok, quelqu’un d’autre a quelque chose pour la réunion ? 17:15 <jrandom> sinon 17:15 * jrandom se prépare à conclure 17:15 <@cervantes> *hum hum* 17:15 * jrandom fait une pause 17:16 <jrandom> quoi de neuf, cerv ? 17:16 <Complication> Chouette, j’ai trouvé un baf ;P 17:17 <jrandom> baf-bloqué ;) 17:17 <@cervantes> oups désolé, continue de baffer 17:17 * jrandom reprend 17:18 * jrandom *baf* clôt la réunion