Réunion des développeurs d'I2P - 27 mars 2007

16:02 <jrandom> 0) salut 16:02 <jrandom> 1) État du réseau 16:02 <jrandom> 2) propositions NTCP/SSU de zzz 16:03 <jrandom> 3) état du développement de Syndie 16:03 <jrandom> 4) statut DNS/registrar 16:03 <jrandom> 5) ??? 16:03 <jrandom> 0) salut 16:03 * jrandom agite la main 16:03 <jrandom> notes d'état hebdomadaires publiées à http://dev.i2p.net/pipermail/i2p/2007-March/001342.html 16:04 <jrandom> on passe à 1) état du réseau 16:04 <jrandom> les choses ont l'air plutôt bonnes, et comme mentionné il y a davantage de recherches à faire concernant les derniers changements 16:05 <+Complication> Je voulais me plaindre un peu de la connectivité IRC (le reste semble assez correct), mais ce dernier jour, je n'ai eu qu'environ 6 déconnexions, ce qui n'est pas si mal 16:05 <cervantes> /mute Complication 16:05 <jrandom> héhé 16:05 <+Complication> :D 16:06 <+Complication> Le taux de réussite de construction de tunnel est très bon, toutefois 16:06 * Complication revérifie, au cas où 16:06 <jrandom> oui j'ai vu un peu de churn de déconnexions (même si, pour être honnête, je lis mon backlog avec un grep -v -\!- donc je ne vois jamais les déconnexions ;) 16:06 <cervantes> il y a eu divers couacs de FAI récemment sur le front irc - postman examine des solutions d'hébergement alternatives 16:06 <jrandom> les taux de construction de tunnel dans les stats sont repartis à la hausse, bien qu'ils semblent globalement en phase avec les cycles sur stats.i2p 16:06 <cervantes> avec un peu de chance, on pourra obtenir une meilleure redondance réseau 16:06 <jrandom> ah ok cervantes 16:07 * jrandom proposerait bien de l'aide pour dev.i2p.net, mais je ne me souviens pas de la dernière fois où la charge est passée sous 4 dessus 16:08 <jrandom> ok, quelqu'un a autre chose à soulever concernant l'état du réseau ? 16:10 <jrandom> sinon, on passe à 2) propositions NTCP/SSU de zzz 16:10 <jrandom> zzz ne semble pas être là en ce moment, et j'ai laissé mes posts Syndie répondant au fil chez moi (d'oh) 16:11 <jrandom> en tout cas, postez vos idées sur le blog de zzz (ou lisez là-bas pour plus d'infos) 16:11 <jrandom> quelqu'un a quelque chose à discuter là-dessus ici maintenant toutefois ? 16:12 <+Complication> Eh bien, j'y ai personnellement écrit une réponse, exprimant une inquiétude concernant une trop grande dépendance à UDP (puisque pour moi personnellement, UDP avait des taux de retransmission assez élevés) 16:12 <jrandom> oui 16:12 <+Complication> J'ai toutefois pensé à une approche... 16:12 <+Complication> Actuellement, les offres sont entièrement déterministes (par opposition à probabilistes avec une composante aléatoire), n'est-ce pas ? 16:13 <jrandom> oui, entièrement déterministes 16:13 <+Complication> Je me demandais s'il y aurait un bénéfice (au sens d'éviter les extrêmes) à leur donner une composante de probabilité 16:14 <+Complication> Du genre « 60 % de chances d'obtenir NTCP, 40 % de chances d'obtenir SSU » 16:14 <+Complication> (en supposant l'absence de données préalables - si des données d'échec/succès préalables existent, il faudrait probablement biaiser la probabilité en faveur du transport le plus performant pour ce lien) 16:15 <jrandom> eh bien, ça dépend de ce qu'on cherche à atteindre - d'après ce que je comprends de la proposition de zzz, le but est d'utiliser ssu dès que possible 16:15 <+Complication> (en supposant bien sûr que les deux transports soient utilisables pour un lien donné - parfois ils ne le sont clairement pas) 16:15 <jrandom> la randomisation n'aiderait pas à cela, mais offrirait plus de possibilités de recueillir des données sur les deux transports sur le terrain 16:16 <+Complication> Juste une idée sur une façon possible d'essayer de trouver un équilibre entre eux (parce que si l'un a toujours une offre plus élevée, les routers n'« expérimenteront » probablement pas beaucoup) 16:19 <jrandom> c'est une méthode que nous pourrions utiliser pour recueillir plus de données, à garder à l'esprit 16:19 <jrandom> ok, comme dit, postez dans ce fil pour plus de détails :) 16:20 <jrandom> on passe à 3) état du développement de Syndie 16:20 <jrandom> je n'ai pas grand-chose à ajouter au-delà de ce qui est dans le mail 16:20 <jrandom> quelqu'un a des questions/commentaires/inquiétudes ? 16:21 <+Complication> Pas encore. :) 16:22 <jrandom> héhé 16:22 * Complication nourrit l'espoir d'aider davantage, soit sur le front I2P soit sur celui de Syndie, mais je dois vraiment sortir ce truc de webcache d'abord 16:22 <jrandom> w3rd, hâte des deux :) 16:24 <jrandom> ok passons le point 4 et allons au 5) ??? 16:25 <jrandom> quelqu'un a autre chose à aborder pour la réunion ? 16:26 <TrevorReznik> y a-t-il un intérêt pour un générateur de hashcash pour I2P ? 16:26 <TrevorReznik> c.-à-d. via l'interface du navigateur. 16:26 <TrevorReznik> j'y ai pensé comme une manière d'éliminer des scénarios DoS possibles à l'intérieur d'I2P. 16:27 <jrandom> hmm, en javascript ou c/java ? 16:27 <jrandom> je pense qu'il existe déjà quelques générateurs de hashcash 16:27 <TrevorReznik> en java. 16:28 <+Complication> eh bien, des recherches sur les schémas de hashcash seront probablement nécessaires à un moment donné 16:28 <TrevorReznik> www.hashcash.org en a quelques-uns je crois. 16:28 <TrevorReznik> c'est une initiative pour l'établir dans les clients de messagerie comme mécanisme antispam. 16:28 <+Complication> peut-être pas de la recherche au sens strict, mais un travail d'implémentation et de bonnes pratiques 16:28 <+Complication> =sens 16:28 <TrevorReznik> ils ont une collection d'implémentations dans une multitude de langages. 16:28 <TrevorReznik> il y a 2 classes java et au moins une applet là-bas, même si je ne connais pas encore les paramètres exacts de licence. 16:30 <+Complication> endroits où on pourrait l'utiliser : 1) enregistrement de nym (pseudonyme) dans Syndie 2) enregistrement de nom dans I2P 16:30 <+Complication> 3) email, évidemment 16:30 * TrevorReznik est d'accord. 16:30 <+Complication> 4) dans des scénarios moins optimistes, les messages ordinaires dans Syndie 16:31 <+Complication> au niveau même du réseau I2P... 16:31 <+Complication> hmm 16:31 <jrandom> il est possible de les intégrer dans les messages de création de tunnel, mais on est déjà à la ramasse sur ce front CPU tel quel ;) 16:39 <jrandom> ok, quelqu'un a autre chose pour la réunion ? 16:41 <jrandom> sinon 16:41 * jrandom conclut 16:41 * jrandom *baf*s clôt la réunion