Réunion des développeurs d'I2P - 20 juillet 2004

14:05 <jrandom> 0) salut 14:05 <jrandom> 1) 0.3.2.3, 0.3.3, et la feuille de route 14:05 <jrandom> 2) s/reliability/capacity/g 14:05 <jrandom> 3) mises à jour du site web 14:05 <jrandom> 4) attaques et défenses 14:05 <jrandom> 5) ??? 14:05 <jrandom> 0) salut 14:05 * jrandom fait coucou 14:05 <jrandom> notes d’état hebdomadaires en ligne @ http://dev.i2p.net/pipermail/i2p/2004-July/000358.html 14:06 <jrandom> on enchaîne directement avec 1) 0.3.2.3, 0.3.3, et la feuille de route 14:07 <jrandom> (pendant que vous lisez la suite, j’imagine ;) 14:07 <jrandom> la version 0.3.2.3 est sortie et semble bien se comporter 14:07 <jrandom> quels sont les principaux points douloureux que vous voyez ? 14:08 <deer> <Nightblade> aucun problème du tout 14:08 <deer> <duck> 4 jours d’uptime sans problème 14:08 <jrandom> hmm, word 14:08 <deer> <duck> pour certains, irc ne semble pas très stable 14:08 <deer> <duck> par exemple kaji qui se fait éjecter chaque minute 14:08 <deer> <duck> mais ce n’est pas nouveau 14:09 <jrandom> oui, ça lui arrive aussi sur le réseau freenode, donc je ne sais pas quoi blâmer 14:09 <deer> <duck> ouais 14:09 <deer> <duck> connelly a eu quelques téléchargements foireux d’après ce que je sais 14:10 <deer> <duck> mais vous ne m’entendez pas me plaindre 14:10 <jrandom> ah vraiment ? hmm, je crois qu’on a trouvé que certains étaient liés à sa lib, mais j’ai aussi rencontré des échecs occasionnels sur des transferts de gros fichiers 14:10 <jrandom> surtout en aspirant des livres depuis alexandria 14:10 <jrandom> (enfin, pas spécialement, mais c’est le seul site d’où je télécharge) 14:11 <deer> <duck> :) 14:11 <jrandom> ok, eh bien, mon plan : une fois la 0.3.3 sortie, je consacrerai mon temps à nous amener vers 0.4, en parallèle des corrections de bugs que vous remontez 14:12 <jrandom> le travail restant pour 0.4 est largement du web simple (nouvelle console router avec servlets, intégration Jetty, servlet pour contrôler le router, et une servlet pour configurer les instances i2ptunnel) 14:13 <jrandom> peut-être que des gens du monde JSP/servlet peuvent aider sur une partie pour se faire la main avec le code, même si j’ai déjà fait pas mal de ce genre de trucs donc l’impl ne sera pas trop dure 14:13 <jrandom> d’après ce que je sais, l’installeur de hypercubus est pratiquement prêt 14:13 <jrandom> (même si je lui ai collé du nouveau boulot aujourd’hui ;) 14:13 <deer> <duck> featurecreep++ 14:14 <jrandom> ça maintient les gens en alerte :) 14:14 <jrandom> (mais allez, tout le monde déteste télécharger tous les JAR séparément pour les mises à niveau) 14:14 <deer> <duck> oui, c’est mon plus gros problème avec les mises à niveau 14:14 <deer> <duck> (même si j’utilise cvs) 14:14 <deer> <duck> mais ça le serait si je ne le faisais pas 14:15 <jrandom> heh 14:15 <mihi> jrandom: tar simplement tout -> 1 téléchargement ;) 14:15 <jrandom> ce serait assez simple, et laisser updgrade.sh/upgrade.bat == jar xf upgrade.jar 14:16 <jrandom> (après un appel façon wget) 14:16 <jrandom> eh bien, je pense que hypercubus a le code pour faire tout ça sous contrôle, donc on peut lui laisser faire la bonne chose 14:17 <jrandom> bref, oui, comme vous l’avez peut-être remarqué, notre planning n’est plus exactement celui d’avant 14:17 <jrandom> la feuille de route a été mise à jour et aaalllooonnnggée 14:18 <mihi> jjrraannddoomm:: vvérriiffiie ttoon ccoommuuttaatteurr dduuppleexx 14:18 <deer> <Nightblade> hah 14:18 <jrandom> heh 14:18 * mihi a fait une erreur... qui la repère en premier ? 14:19 <jrandom> (\n\n) 14:19 <jrandom> mais bref 14:19 <mihi> ok, une autre ;) 14:19 <duck> (pas d’espaces doubles) 14:19 <mihi> duck++ 14:20 <jrandom> je pense que la feuille de route est assez réaliste au moins jusqu’à la version 1.0 maintenant, même si, selon l’adoption et les retours des utilisateurs, nous pourrions réorganiser ou supprimer l’une des 0.4.2 ou 0.4.3 14:20 <jrandom> (et, bien sûr, comme toujours, la feuille de route est sujette à changement si plus de gens s’impliquent :) 14:21 <modulus> peut-être qu’un jour je le ferai, après avoir appris Java, mais i2p ne ressemble pas à un projet pour novice. 14:21 <deer> <Sandworm> ouais, ça prendra plus longtemps :) 14:21 <deer> * duck s’attend à encore quelques glissades en chemin 14:21 <modulus> :-) 14:22 <deer> * duck peut à peine appeler ça des glissades, regardez l’impressionnant tableau sur http://www.i2p.net/redesign/announcements 14:22 <jrandom> des dérapages peuvent arriver bien sûr, mais je pense que les jalons restants sont assez faisables 14:22 <jrandom> ouais, merci de montrer que je n’ai pas de vie, duck ;) 14:22 <deer> <duck> c’est ta vie 14:22 <modulus> alors, c’est pour quand la 1.0 ? :-) 14:22 <deer> <duck> sois-en fier 14:23 <jrandom> modulus: même si certaines parties d’i2p sont une vraie plaie, il y a pas mal de morceaux qu’un nouveau développeur peut attaquer assez facilement 14:23 <modulus> probablement des parties plutôt ennuyeuses, non ? 14:24 <jrandom> non, pas du tout. par exemple, bricoler une chouette appli de transfert de fichiers ou de chat anonyme, un mini serveur web, un MUD, une appli d’échecs, etc. 14:24 <duck> (mises à jour du site web) 14:24 <modulus> hmm, ça a l’air cool. 14:24 <jrandom> (alias des applis clientes simples pouvant être anonymes) 14:24 <jrandom> et bien sûr des mises à jour web ;) 14:25 <modulus> c’est quoi cette histoire de mises à jour web ? 14:25 <jrandom> notre site web a besoin de travail (voir http://dev.i2p.net/pipermail/i2p/2004-July/000358.html ou attendez quelques minutes pour le point 3 de l’ordre du jour) 14:25 <cat-a-puss> Où myi2p s’insère-t-il là-dedans ? 14:25 <modulus> ah ah 14:26 <jrandom> cat-a-puss: http://www.i2p.net/redesign/myi2p :) 14:26 <modulus> il me semble que myi2p n’est pas une priorité pour le moment... 14:26 <jrandom> (je viens d’écrire une brève page à ce sujet il y a quelques heures) 14:27 <jrandom> au passage, toutes les mises à jour du site sont publiées sur la liste de diffusion i2pwww (http://dev.i2p.net/pipermail/i2pwww/2004-July/thread.html) 14:28 <modulus> hmm, je pourrais écrire une appli globale de nommage :-) 14:28 <jrandom> mais je vois toujours l’implémentation de myi2p (au moins le carnet d’adresses de base et le blogging) réalisée pour la version 1.0 14:28 <jrandom> (d’après la feuille de route, prévue pour novembre) 14:28 <jrandom> oui, certainement 14:28 <modulus> quelque chose de plus simple que le DNS, avec authentification et délégation des TLD 14:28 <jrandom> ce ne serait pas mal non plus d’avoir ça — une appli simple qui puisse interroger un serveur de noms central, ce serait sympa 14:29 <modulus> yep 14:29 <jrandom> alors, au code :) 14:29 <modulus> je commence demain. passez-moi un savon si je suis sur autre chose ;-) 14:29 <jrandom> hé hé cool, on fera 14:29 <jrandom> ok, on passe à 2) s/reliability/capacity/g 14:29 <duck> petite question sur le site : 14:29 <duck> oh attendez 14:29 <duck> c’est le 3 14:29 <duck> désolé 14:29 <jrandom> bien sûr, quoi de neuf ? 14:30 <jrandom> ah, ok 14:30 <jrandom> il va y avoir un changement assez fondamental du profilage des pairs et du code de sélection dans la 0.3.3, comme décrit dans l’e-mail et http://www.i2p.net/redesign/how_peerselection 14:31 <jrandom> je l’ai en cours d’exécution sur une paire de routers pour l’instant et ça a l’air assez sage (Vitesse : 25.18 (5 pairs rapides) Capacité : 17.50 (8 pairs à haute capacité) Intégration : 37.00 (2 pairs bien intégrés)) 14:31 <jrandom> et plus de valeurs négatives :) 14:31 <modulus> :) 14:32 <jrandom> je vais encore tester un peu, peut-être un jour ou deux, puis la publier en 0.3.3 14:32 <cat-a-puss> d 14:32 <cat-a-puss> <modulus> 14:32 <cat-a-puss> oups 14:33 <duck> tu suggères de ne pas mettre à jour cvs ? 14:33 <cat-a-puss> pour faire du dns, regardez un cache de http://www.levien.com/thesis/compact.pdf 14:33 <jrandom> non, cvs est assez stable pour l’instant 14:33 <jrandom> (mais, comme toujours, soyez prêts à revenir en arrière si une saleté survient) 14:35 <jrandom> ça a l’air cool cat-a-puss, merci 14:35 <cat-a-puss> (j’ai une copie de l’original si quelqu’un la veut) 14:36 <jrandom> le cache Google abîme un peu les images, donc si tu as le PDF brut ce serait top 14:36 <jrandom> bref, on s’éloigne un peu du sujet pour le moment (mais on pourra y revenir) 14:37 <jrandom> c’est à peu près tout pour le changement reliability/capacity, donc passons à 3) mises à jour du site web 14:37 <jrandom> duck : tu avais quelque chose à soulever ? 14:38 <jrandom> pendant que duck prépare ses notes, est-ce que quelqu’un a des idées/suggestions/inquiétudes à propos des éléments postés dans l’e-mail ? 14:39 <deer> <Nightblade> le site a l’air bien 14:39 <jrandom> oui, j’aime la nouvelle nav et la mise en page du site est assez propre 14:40 <deer> <Nightblade> plus facile de trouver des choses 14:40 <cervantes> _beaucoup_ plus facile de trouver des choses 14:40 <duck> d’abord je veux remercier notre défenseur des utilisateurs, protocol, d’être devenu utile :) 14:40 <jrandom> heh 14:40 <duck> il a eu de bonnes suggestions et il vient juste de commencer 14:40 <cervantes> hip hip hourra ! 14:40 <jrandom> (bien dit !) 14:41 <duck> ensuite, je pense qu’il n’y a guère de raison de ne pas mettre en ligne la refonte pour de bon 14:42 <jrandom> d’accord — peut-être qu’on peut simplement marquer news/development/documentation comme éléments hors nav de page, laisser de côté les tweaks JVM et config pour le moment, et mettre un peu de contenu de base sur la page I2PTunnel ; je pense qu’on peut la déployer 14:42 <jrandom> je veux juste la mettre en ligne avec tous les liens qui fonctionnent (et toutes les pages qui ne fonctionnent pas) 14:43 <jrandom> il y aura bien sûr d’autres mises à jour après qu’elle sera en vie ;) 14:43 <jrandom> euh, en ligne 14:44 <jrandom> au passage, wilde a aussi branché notre compte 34sp, donc nous pourrons migrer le site là-bas si nécessaire 14:44 <cervantes> coolio 14:44 <jrandom> des pensées, duck ? le bidule menu.php peut-il gérer des entrées de nav non liées à une page ? 14:44 * cervantes vérifie sa boîte de réception pour des points de parrainage 14:45 <jrandom> (ou ce serait trop d’effort pour le modifier et l’ajouter ?) 14:45 <jrandom> hé hé cervantes, ça devrait être en route 14:45 <cervantes> ;-) 14:45 <cervantes> ah, la vieille manœuvre du « le chèque est dans le courrier » 14:47 <duck> désolé ; je faisais autre chose entre-temps. 14:47 <duck> ok ; oui, possible d’en faire uniquement un titre de section de nav 14:47 <jrandom> pas de souci, on peut avancer et y revenir plus tard si tu préfères 14:47 <jrandom> ok cool 14:47 <jrandom> (duck++) 14:48 <jrandom> ok, d’autres trucs liés au site web ? 14:48 <duck> avec ta suggestion, ça semble prêt pour mise en ligne. 14:48 <jrandom> sinon, on peut passer à 4) attaques et défenses 14:48 <duck> . 14:48 <jrandom> ok 14:49 <jrandom> ok, je suppose que vous avez lu la liste de diffusion et vu les messages de connelly et les différentes réponses 14:50 <cervantes> il a été occupé :) 14:50 <cervantes> (presque autant que proto) 14:50 <Connelly> à mon avis, le réseau paraît solide sauf face à l’analyse de trafic (sites avec beaucoup de trafic), aux attaques de coupure de connexions par des gouvernements, et aux attaquants qui prendraient le contrôle d’une large majorité du net 14:50 <jrandom> même si je pense qu’on est en assez bonne posture, je suis sûr qu’il y a des choses qu’on a manquées, donc ne présumez pas qu’i2p fait ou fera ce qu’il prétend — challengez les hypothèses et dites pourquoi ça craint 14:50 <Connelly> le chiffrement met à mal la plupart des attaques non agressives 14:51 <jrandom> c’est l’idée 14:51 <jrandom> et avec les capacités i2p 2.0 et 3.0, des défenses face à des adversaires de niveau gouvernement seront possibles 14:51 <Connelly> bien sûr, en pratique il y aura des failles de sécurité à corriger 14:52 * jrandom doit encore écrire des docs expliquant comment les délais en 3.0 empêcheront les attaques de segmentation 14:52 <jrandom> certainement, connelly 14:54 <jrandom> ok, s’il n’y a rien de plus dans ce sens, je pense que c’est tout pour moi 14:54 <jrandom> donc 5) ??? 14:55 <jrandom> oh, au passage, j’ai tracé le graphe de l’utilisation de bande passante en fonction du nombre de tunnels auxquels on participe pour une des simulations sur une période de 4 jours 14:55 <jrandom> c’est posté @ http://dev.i2p.net/~jrandom/4daybandwidth.webp 14:56 <jrandom> la simu envoyait des messages de 32 Ko dans les deux sens toutes les 30 s, avec deux routers bridés à 6 Ko/s, et les choses se comportaient exactement comme elles « devraient » 14:56 <duck> (propriété nolink implémentée pour le site) 14:56 <jrandom> (p. ex. charge distribuée sur les pairs rapides et fiables, pairs lents évités, etc.) 14:56 <jrandom> w00t 14:56 <Connelly> un graphe log de bande passante/utilisateur en fonction de la taille du réseau serait sympa 14:57 <Connelly> pour pouvoir dire « ouais, ça passe vraiment à l’échelle » 14:58 <jrandom> ça n’aurait même pas besoin d’un graphe log — la scalabilité de la comm client est strictement O(1) [nécessitant 2k*msgSize, où k = # de sauts dans le tunnel] 14:58 <jrandom> mais oui, je suis d’accord, il nous faut des docs décrivant comment i2p passe à l’échelle 14:58 <Connelly> et pour Kademlia... c’est dans ta simu ? 14:58 <jrandom> oui, la simu est en fait le code complet du router, le tout exécuté dans une seule JVM 14:58 <jrandom> je la fais tourner même avec les connexions TCP complètes au lieu du système de comm de la VM aussi 14:59 <jrandom> le code Kademlia est utilisé la première fois qu’Alice veut contacter Bob — tant qu’ils continuent à parler, leur communication est en O(1) puisqu’ils joignent leur LeaseSet avec la charge utile 14:59 <jrandom> (donc il n’y a pas besoin de requêtes netDb ultérieures) 15:00 <cervantes> vl07 et onb0 sont les routers bridés ? 15:00 <jrandom> mais oui, il nous faut une simulation pour démontrer comment la netDb elle-même passe à l’échelle 15:01 <jrandom> cevantes: 0jvf et onb0 15:01 <cervantes> qu’est-ce qui explique le plongeon de vl07 après une journée d’uptime ? 15:02 <cervantes> semble croiser 00u0 15:02 <jrandom> tous les routers non bridés sont essentiellement égaux — ils sont tous sur le même CPU, tous avec la même latence (0 ms), donc l’attribution de l’un comme « fast » vs « reliable » est juste arbitraire 15:04 <Connelly> vos désignations « fast and reliable », « slow », etc. se remettent-elles de grandes valeurs ? 15:04 <jrandom> pourquoi son classement/utilisation a-t-il diminué après une journée ? je ne suis pas sûr ; peut-être qu’une surcharge CPU ou IO transitoire pendant le test a fait baisser un peu sa vitesse 15:04 <jrandom> oui, les classements utilisent maintenant la médiane, pas la moyenne, et il y a en plus une décroissance assez rapide des données 15:05 <jrandom> s/fiarly/fairly/ 15:05 <Connelly> donc si je te fais croire que ma reliability est 1000000000, tu peux t’en remettre quand je commence à laisser tomber des messages 15:06 <jrandom> certainement — si tu « échoues », j’arrête immédiatement de te demander des choses et je diminue ton classement 15:06 <jrandom> le nouveau calcul de « capacity » est d’ailleurs assez sensible à ce genre de changements 15:06 <jrandom> (la speed est aussi assez difficile à trafiquer, puisque tous les rangs de speed sont des valeurs réellement mesurées) 15:07 <jrandom> ((comme l’était la reliability, et comme l’est le calcul de capacity)) 15:09 <jrandom> ok, quelqu’un d’autre a quelque chose à aborder ? 15:10 <deer> * jrandomi2p suggère le *baf*er 15:11 * jrandom est d’accord 15:11 * jrandom se prépare 15:11 * jrandom *baf* clôt la réunion