Réunion des développeurs I2P - 18 mai 2004

14:07 <jrandom> 0) salut 14:07 <jrandom> 1) statut du testnet 14:07 <jrandom> 2) SAM 14:07 <jrandom> 3) mises à jour de la feuille de route 14:07 <jrandom> 4) MyI2P 14:07 <jrandom> 5) ??? 14:07 <jrandom> 0) salut 14:07 * jrandom fait coucou 14:08 <Nightblade> salut 14:08 * jteitel fait coucou en retour 14:08 <jar> salut 14:08 <duck> lo 14:08 <Masterboy> :P 14:08 <jrandom> notes d'état hebdomadaires publiées jusqu'à http://dev.i2p.net/pipermail/i2p/2004-May/000239.html 14:09 <jrandom> désolé si je suis un peu à côté de la plaque aujourd'hui, mon rythme de sommeil est encore plus déréglé que d'habitude 14:09 <jrandom> bref, passons à 1) statut du testnet 14:10 <duck> la diversification se produirait automatiquement avec un réseau plus grand, non ? 14:10 <jrandom> oui, et/ou des seuils de sélection des pairs moins biaisés 14:11 <jrandom> par exemple, si le seuil de vitesse était la médiane plutôt que la moyenne, on aurait deux fois moins de pairs rapides que de pairs fiables 14:11 <jrandom> contrairement à la situation actuelle où les vitesses sont fortement biaisées 14:12 <Masterboy> eh bien le réseau s'est rétabli, ce n'est pas si mal 14:12 <jrandom> oui, ça a pris plus de temps que prévu, et ça a mis en évidence des pistes d'amélioration 14:13 <jteitel> le réseau s'est rétabli ? Je n'arrive toujours pas à me connecter de manière fiable à l'IRC i2p 14:13 <jrandom> les profils des pairs ne se dégradaient pas assez vite, ni ne promouvaient efficacement de nouveaux candidats 14:14 <jrandom> cela a aussi déclenché une chaîne d'événements secondaires – surcharge de routers qui n'étaient pas capables de tenir la charge (en raison d'un profilage insuffisant), provoquant chez certains routers surchargés une panne de mémoire et un arrêt 14:15 <human> ayeee ayeee ayeee ! 14:15 <jrandom> ça a été progressif, jteitel — certains des problèmes que nous avons vus sont liés aux défaillances de la netDb 14:15 <jrandom> salut human 14:15 <jteitel> Oh, d'accord 14:16 <_cervantes_> un router en difficulté ne pourrait-il pas déléguer des tunnels à un autre pair ? 14:16 <ugha_node> Waouh, Débit cumulé : 8.87KBps envoyés 8.35KBps reçus. 14:16 <Nightblade> jteitel : je viens de me connecter après plusieurs tentatives... j'attends toujours que mon /join passe 14:16 * BrianR regarde autour de lui. 14:16 <jrandom> non — un router peut simplement abandonner un tunnel (s'il n'aurait pas dû l'accepter au départ) 14:16 <ugha_node> (Et j'ai redémarré mon router il y a une demi-heure) 14:16 <BrianR> zut. Je suis en retard. 14:17 <BrianR> jrandom : (merci d'avoir placé myi2p vers la fin de l'ordre du jour) 14:17 <jrandom> ugha > ouais, vous avez dû rattraper la charge pour ces trois rapides 14:17 <jrandom> hehe :) 14:18 <duck> c'était une belle attaque 14:18 <ugha_node> jrandom : Évidemment. 14:18 <_cervantes_> ne vaudrait-il pas mieux être plus strict et rejeter des tunnels à un seuil plus bas 14:19 <jrandom> oui cervantes — les routers, actuellement, ne rejettent jamais un tunnel à moins qu'ils ne puissent pas atteindre le prochain saut 14:19 <jrandom> on voudra inclure une forme de limitation (throttling), peut-être basée sur la taille du jobQueue / la latence moyenne (avg lag), etc. 14:20 <jrandom> de plus, il faudra s'assurer qu'on n'essaie pas de construire trop de tunnels en même temps, comme cela s'est produit quand une grande partie d'entre eux a échoué 14:20 <_cervantes_> ou simplement permettre à l'utilisateur de fixer un seuil en fonction du matériel/de la bande passante dont il/elle sait disposer 14:20 <jrandom> (à cause des pairs rapides+fiables qui sont passés hors ligne) 14:20 <_cervantes_> au moins à ce stade 14:20 <jrandom> oh, bon point — permettre aux gens de définir explicitement un nombre max de tunnels participants. 14:21 <jrandom> on mettra ça dans la prochaine révision. Bonne idée. 14:21 <ugha_node> Ça ressemble à de la logique floue. 14:21 <jrandom> il faut gérer la surcharge, et simplement mettre en file d'attente des messages en mémoire ne fonctionne clairement pas 14:21 <duck> (salut fvw) 14:21 <_cervantes_> ce serait bien d'avoir des stats regroupées sur les performances des tunnels... le type de charge qu'ils pourraient infliger à un processeur de référence (benchmark) 14:22 <_cervantes_> au fait, j'ai mis mon serveur hors ligne... il recevait une tonne de tunnels et je n'ai pas encore compilé jbigi ;-) 14:22 <jrandom> voir http://localhost:7655/routerStats.html#Tunnels 14:23 <jrandom> ah ! oui, jbigi est quelque chose que nous voulons encourager tout le monde à utiliser 14:23 <BrianR> Des idées sur la mise en place d'un budget de bande passante par tunnels ? 14:24 <jrandom> actuellement prévu pour 3.0 (avec une limitation globale de bande passante pour le router dans son ensemble @ 0.4.1) 14:24 <jrandom> mais avoir des limites de bande passante par tunnel plus tôt ne ferait pas de mal 14:25 <fvw> Est-il judicieux d'y consacrer des efforts si tôt alors que c'est bien plus facile et précis à faire dans le noyau des OS que la plupart des utilisateurs/testeurs actuels utilisent ? 14:25 <_cervantes_> quelque chose que j'aimerais voir, ce sont des réglages de profondeur par tunnel (c'est peut-être déjà possible) 14:25 <_cervantes_> par exemple, je sais déjà que je peux faire confiance à mon serveur... donc je ne veux pas devoir passer par _x_ sauts pour l'atteindre 14:25 <jrandom> fvw > c'est un bon point, surtout qu'actuellement nous ne dévorons pas tant de bande passante 14:26 <jrandom> hmm cervantes — oui, chaque client peut spécifier la longueur de ses tunnels, mais je ne suis pas sûr que ce soit exactement ce que tu veux 14:26 <_cervantes_> non 14:26 <jrandom> cervantes — je pense que tu veux une QoS où tu peux raccourcir la connexion pour un pair en particulier 14:26 <_cervantes_> par exemple... 14:26 <_cervantes_> oui 14:27 <jrandom> (ce qui était prévu pour i2p 4.0, mais c'est à plus d'un an == l'infini) 14:27 <_cervantes_> dans ce cas, sélectionner aussi la profondeur par hôte i2p 14:27 <BrianR> fvw : oui, mais un i2p doit savoir à peu près combien de bande passante les membres potentiels d'un tunnel ont à disposition afin de prendre des décisions judicieuses pour construire des tunnels... 14:27 <_cervantes_> ah ok 14:27 <_cervantes_> :) 14:27 <jrandom> mais c'est une bonne idée, et techniquement faisable, mais patchs bienvenus :) 14:28 <_cervantes_> le patch est déjà parti par la poste... avec ce chèque pour 5000 barres d'e-gold 14:28 <_cervantes_> ;-) 14:28 <jrandom> BrianR : on peut peut-être faire à mi-chemin — suivre combien de tunnels auxquels il participe, ainsi que la bande passante que ces tunnels utilisent, et utiliser cela dans la décision d'accepter ou non une requête de création de tunnel ? 14:28 <jrandom> heh 14:30 <jrandom> ok, quelqu'un a autre chose pour le statut du testnet ? 14:30 <Masterboy> et mon paradoxe ? 14:30 <Masterboy> :) 14:30 <jrandom> mon plan est de sortir une 0.3.1.3 avec les mises à jour d'ici jeudi ou vendredi 14:31 <jrandom> Masterboy : je n'ai pas eu le temps de parcourir tes journaux, mais on réglera ça 14:31 <_cervantes_> vendredi 2005 ? 14:31 <_cervantes_> cool 14:31 <Masterboy> k 14:31 <jrandom> ok, passons à 2) SAM 14:31 <Masterboy> maintenant on sait qui fait tourner le router obsolète.. 14:32 * jrandom tend le micro à notre intrépide dev SAM.pm 14:33 <jrandom> (c'est toi, BrianR :) 14:33 <BrianR> une seconde.. :) 14:33 * duck applaudit 14:33 <jrandom> en attendant, dm ou firerabbit dans le coin ? 14:33 -!- Irssi : #i2p : Total de 26 pseudos [0 ops, 0 halfops, 0 voices, 26 normaux] 14:33 * jrandom vérifie le /names, non. tant pis 14:33 <jrandom> (pas de mises à jour de la lib sam .net/C# alors) 14:34 <duck> le bazar en .py est-il toujours à jour ? 14:34 <duck> ou rendu obsolète par les améliorations de SAM 14:34 <jrandom> pas sûr 14:34 <BrianR> Ok. Je suis de retour. 14:34 <Nightblade> Ma bibliothèque C semble fonctionner... je n'ai pas encore écrit d'application pour l'utiliser cependant 14:34 <jrandom> super, nightblade ! 14:35 <Nightblade> Quelqu'un ici a-t-il fait du développement GTK+/C sous Windows ? 14:35 <human> duck : la lib cliente a besoin d'un petit changement pour la gestion de versions 14:35 <_cervantes_> "hello world" ? 14:35 <human> duck : le reste devrait fonctionner sans problème 14:35 * jrandom suggère un datagram comme tftp comme test sam idéal :) 14:35 <Nightblade> eh bien, n'importe quoi en fait... GTK fonctionne-t-il bien sous Windows..... ? 14:35 <jrandom> (ou même du streaming SAM au lieu de datagram ou raw) 14:36 <jrandom> cool, BrianR — où en sont le .pm et le samcat ? 14:36 <BrianR> Net::SAM est dans le CVS, en grande partie non fonctionnel. 14:36 <BrianR> J'espère avoir aplati tous les bugs et faire fonctionner datagram et raw avant la fin de la semaine. 14:37 <BrianR> Il faudra un peu plus de travail pour mettre une jolie couche OO sur les streams. 14:37 <Nightblade> ah oui, je ne me suis pas embêté avec datagram ou raw... juste stream 14:37 <Nightblade> mais c'est tout ce que j'utiliserais de toute façon 14:37 <fvw> human : as-tu envisagé wxWindows ? C'est assez utile pour ce genre de choses (je ne pense pas qu'il y ait une cible GTK pour Windows cependant) 14:37 <jrandom> génial, BrianR 14:38 <BrianR> Ma femme me tanne pour que je la rejoigne pour dîner. Je reviendrai peut-être à temps, ou pas, pour la discussion myi2p. J'ai posté le modèle de menace et des trucs de fileserver idiot sur le nœud 208 14:38 <human> fvw : le client GTK pour Windows existe (The GIMP tourne aussi sous Windows) 14:38 <jrandom> cool, nightblade, le mieux est d'implémenter ce qui est nécessaire d'abord 14:38 <human> fvw : s/client/port/ 14:38 <jrandom> heh 'k BrianR, merci 14:38 <fvw> human : je veux dire une cible GTK pour Windows avec wxWindows (que je te suggérais d'utiliser) 14:38 * fvw fait signe à BrianR. Bon appétit. 14:38 <human> fvw : ah... eh bien, je ne connais pas vxWidgets (le nouveau nom de vxWindows :-) 14:39 <human> fvw : mais c'était Nightblade qui parlait de GTK+, pas moi :-) 14:40 <fvw> Oups, j'ai les yeux de travers, ignorez-moi. 14:40 <Nightblade> Je suis moins à l'aise avec le C++ qu'avec le C 14:40 <Nightblade> à ma connaissance, GTK est la seule bibliothèque d'interface graphique C multiplateforme 14:40 <Nightblade> ce n'est pas que j'aime particulièrement GTK 14:40 <fvw> ça n'a pas vraiment d'importance, wxWindows est facilement abordable depuis le C. 14:40 <Nightblade> hmm 14:40 <Nightblade> bon, peut-être que je regarderai ça aussi 14:40 <Nightblade> je connais le C++, mais je n'ai pas écrit de gros programmes avec 14:41 * fvw n'est pas non plus codeur C++, mais j'ai mis en place un visualiseur de transactions assez conséquent pour une entreprise de transport il y a quelque temps sans problèmes. 14:42 <Nightblade> je suis sûr que wxWindows a un port Windows plus mature 14:42 <Nightblade> que GTK 14:42 <fvw> très probablement, oui. 14:43 <Nightblade> (ok, continuez la réunion) heh 14:43 <jrandom> :) 14:43 <jrandom> ok, passons à 3) mises à jour de la feuille de route 14:44 * jrandom a été négligent pour mettre à jour http://www.i2p.net/roadmap le mois dernier 14:44 <jrandom> mais maintenant c'est à jour 14:44 <jrandom> malheureusement, nous n'aurons de toute évidence pas la 0.4 la semaine prochaine 14:44 <duck> (les 1.1, 2.0, 3.0 sont-elles aussi à jour ?) 14:45 <jrandom> oui m'sieur 14:45 * Masterboy l'a lue, a aimé — pas de panique, on ne brûle pas.. 14:46 <duck> quelqu'un devrait mettre à jour wikipedia/infoanarchy aussi :) 14:46 <jrandom> oh, je devrais probablement retirer « SAM bridge and client libraries implemented and tested » de la 0.4 14:46 <jrandom> heh ouais, c'est pour ça que j'ai !thwappé iA il y a quelque temps quand ils ont juste copié la page du wiki 14:46 <jrandom> (ils devraient simplement pointer vers /roadmap, pas dupliquer le contenu) 14:47 <Masterboy> SAM est terminé ? 14:47 <jrandom> c'est fonctionnel, oui, même si le travail sur des bibliothèques clientes supplémentaires est en cours 14:47 <jrandom> s/are/is/ 14:48 <jrandom> ok, à moins qu'il n'y ait d'autres questions/préoccupations sur la feuille de route, passons à 4) MyI2P 14:50 <jrandom> bien que j'aie arrêté de travailler moi-même sur myi2p, nous avons ouvert l'effort à une prime (bounty) — http://www.i2p.net/node/view/216 14:50 <jrandom> cela signifie en partie qu'il faut bien définir les exigences, et il y a eu quelques débats sur ce qu'elles devraient être 14:51 <Masterboy> j'ai essayé d'y intéresser mon ami, il a dit trop de travail pour trop peu d'argent ;P bon, c'est un capitaliste ;) 14:51 <Masterboy> eh bien j'ai proposé de le coder.. 14:52 <jrandom> toute contribution de code est toujours la bienvenue :) 14:53 <jrandom> la question architecturale en suspens, cependant, est de savoir comment gérer les personnes qui ne peuvent pas faire tourner leur router i2p / nœud myi2p en permanence 14:53 <Nightblade> il faut juste avoir un FAI i2p de confiance 14:53 <jrandom> les deux propositions sont soit d'utiliser des prestataires hébergés, soit de scinder le système pour utiliser un distributed backing store (magasin de données distribué) 14:54 <_cervantes_> la seconde étant la solution idéale à long terme 14:54 <_cervantes_> *latter 14:54 <duck> (et constituant une autre prime (bounty)) 14:55 <_cervantes_> ou un service de proxy webcache... 14:55 <jrandom> exact — si nous choisissons le prestataire hébergé (ou un nœud local), quand une DHT/etc sera disponible nous pourrons pousser de plus en plus de contenu dans la DHT 14:55 <jrandom> _cervantes_ : c'est essentiellement le distributed backing store — des caches de données non fiables 14:57 <deer> * Masterboy se demande où est bogobot 14:57 <jrandom> la partie difficile est d'obtenir la fonctionnalité de contrôle d'accès nécessaire — avec des caches de données non fiables / un distributed backing store, les ACL sont essentiellement du chiffrement 14:57 <jrandom> mais un « canal parallèle » à cette discussion vient des trois points soulevés par une personne anonyme @ http://www.i2p.net/node/view/215#comment-105 14:57 <_cervantes_> et du contenu signé 14:58 <jrandom> oui, dans les deux cas, il faudra du contenu signé 15:00 <_cervantes_> c'est là que le modèle d'hypercubus a du mérite... mais ce n'est en aucun cas une solution « rapide » 15:00 <jrandom> d'après les discussions sur IRC hier soir, nous nous sommes concentrés sur le « modèle de menace LiveJournal » — les attaques qui préoccupent les utilisateurs de LJ, et celles qui ne les préoccupent pas 15:01 <wilde> une chose à la fois, commencer par obtenir un MyI2P de base 15:02 <jrandom> oui, et pour implémenter le myi2p de base, il faut connaître l'architecture de déploiement 15:03 <jrandom> avec le modèle de menace LJ pour les utilisateurs qui ne peuvent pas faire tourner leurs propres nœuds, je ne pense pas qu'on ait besoin d'aller vers la voie des caches de données non fiables 15:03 <jrandom> et pourquoi quelqu'un utiliserait myi2p s'il n'a besoin que du modèle de menace de LJ ? parce que c'est anonyme 15:04 <jrandom> on pourrait poursuivre vers un système idéalisé, mais il y a la loi des rendements décroissants 15:04 -!- Irssi : #i2p : Total de 24 pseudos [0 ops, 0 halfops, 0 voices, 24 normaux] 15:05 <jrandom> c'est pourquoi je penche pour garder la prime (bounty) dans les grandes lignes actuelles — on pourra ajouter des alternatives plus tard, après la sortie du système de base 15:05 -!- duck_ est maintenant connu sous le nom de duck 15:06 <jrandom> bref, je pense que c'est tout pour 4) MyI2P, à moins que quelqu'un ait autre chose à soulever 15:06 <jrandom> sinon, passons à 5) ??? 15:07 <_cervantes_> hmm il te faut un gros maillet :) 15:07 <jrandom> j'ai oublié de mentionner le nouvel eepsite de morph.i2p dans les notes de réunion, et nickster.i2p a maintenant un fproxy public disponible ! 15:08 <jrandom> (et sungo.i2p a sa webcam en ligne :) 15:08 <_cervantes_> heh... 15:08 <_cervantes_> i2pr0n 15:08 <jrandom> quelqu'un d'autre a quelque chose à aborder ? 15:10 <jrandom> sinon, cela nous amènera à la marque des 70 minutes 15:10 <deer> <Masterboy> non 15:10 * jrandom conclut 15:10 * jrandom *baf* clôt la réunion