Réunion des développeurs I2P - 16 décembre 2003

[22:04] <jrand0m> 0) salut [22:04] <jrand0m> 1) iip [22:04] <jrand0m> 2) 0.2.3 & 0.2.3.1 [22:04] <jrand0m> 3) salut [22:04] <jrand0m> 0) salut [22:04] <jrand0m> bienvenue à la ... je-ne-sais-combième réunion [22:05] <jrand0m> (68? 69?) [22:05] <MrEcho> zut il est 13h ici [22:05] <jrand0m> GMT-8? [22:05] <duck> 69 [22:05] <jrand0m> h0t. [22:06] <jrand0m> ok, 1) iip [22:06] *** Déconnexion: tusko (EOF depuis le client) [22:06] * MrEcho compile un noyau pour la réunion [22:06] <jrand0m> iip agit bizarrement. tout ce que je sais, c'est que nop "déplace des serveurs", quoi que ça veuille dire. je ne sais pas quand ce sera fini, etc. [22:06] <jrand0m> quelqu'un a d'autres infos à partager avec tout le monde ? [22:06] *** mids (mids@anon.iip) a rejoint le canal #iip-dev [22:06] <MrEcho> aucune info de nop [22:07] <mids> ce matin on m'a dit que je pouvais relancer Trent [22:07] <mids> (je l'ai déjà fait hier soir) [22:07] <jrand0m> mortel [22:07] <jrand0m> gracias [22:07] <mids> donc ça indique que nop pense qu'IIP est de nouveau plus stable [22:07] <mids> si ça vaut quelque chose... [22:07] <mids> *tousse* [22:07] <jrand0m> ok cool [22:08] <jrand0m> [woot mon coloc vient de me tendre un verre de vin pour la réunion] [22:08] <MrEcho> lol [22:08] <jrand0m> ok, puisque nop est en ligne et ne viendra pas à la réunion, on gardera la foule lyncheuse pour plus tard [22:09] <jrand0m> 2) 0.2.3 & 0.2.3.1 [22:09] <mids> quelle question précise veux-tu lui poser ? [22:09] <protocol> quand est la réunion [22:09] <jrand0m> question précise> quand fera-t-il une annonce officielle décrivant les problèmes passés et comment les futurs seront abordés ? [22:09] <jrand0m> la réunion, c'est maintenant [22:10] <jrand0m> (aka, à partir de quand devrait-on explorer des moyens de communication non-iip) [22:10] <mids> si j'obtiens une réponse je vous le dirai. [22:10] <jrand0m> merci [22:11] <jrand0m> ok, trucs i2p. 0.2.3 est sortie hier, et même si la plupart du code kademlia fonctionne bien, certains bugs de 0.2.2 apparaissent ainsi que d'autres bugs en cours d'exploration. [22:11] <jrand0m> j'ai commité un changement pour utiliser des messages via tunnels pour dbStore au lieu de garlics, ce qui devrait réduire la charge que tc (et autres) ont observée sur les serveurs [22:12] <jrand0m> il y a aussi un nouveau persistent sessionKeyManager qui fera en sorte que les redémarrages ne bousillent plus complètement un router pendant 15 minutes [22:12] <MrEcho> qu'en est-il des temps de connexion des clients aux routers ? [22:12] <duck> jusqu'ici ça semble aussi bon/mauvais que 0.2.2 ; à moins que mon router/tunnels retombent cette nuit, auquel cas c'est pire que 0.2.2 [22:13] <jrand0m> MrEcho> ça semble venir de l'interaction de deux bugs de 0.2.2 qui s'expriment plus qu'avant. ces deux-là sont ma priorité. [22:13] <MrEcho> ok cool [22:13] <jrand0m> duck> mon impression est que c'est pire que 0.2.2, du point de vue utilisateur final. je travaille à corriger ça sans sacrifier l'anonymat ni la sécurité. [22:13] <MrEcho> c'est dur de travailler sur le DNS avec ce foutu bug .. je dois redémarrer le serveur DNS souvent [22:14] <jrand0m> MrEcho> avec des routers en local-only je n'ai pas pu reproduire les bugs - est-ce que ça marche pour toi en local-only ? [22:15] <MrEcho> non [22:15] <jrand0m> pourrais-tu m'envoyer les logs de debug pour ça ? [22:15] <MrEcho> déjà supprimés [22:16] <jrand0m> ok, si tu réessaies et que ça ne marche pas, si tu pouvais m'envoyer les logs de debug à la fois du router et du client, j'apprécierais. [22:16] <MrEcho> ça fait la même chose qu'avant .. le client reçoit le msg qu'il est envoyé .. mais il n'arrive jamais au client [22:16] <MrEcho> à l'autre client [22:17] <MrEcho> ouais .. je vais voir ce que je peux faire [22:17] <jrand0m> ok, ça ressemble au bug i2psessionImpl2. je n'ai pas pu le reproduire en local, mais une fois corrigé pour le distant j'espère que ça marchera pour ta situation [22:17] <jrand0m> gracias [22:17] <jrand0m> en tout cas, merci à tous pour votre patience avec la mise à jour. on progresse, même si en surface ça ne se voit pas [22:18] <protocol> brille, diamant fou [22:18] <duck> à l'avenir, disons une fois qu'i2p sera effectivement utilisé, comment le processus de développement/publication changera-t-il pour éviter que des versions cassées ne mettent le bazar sur le réseau ? [22:19] <jrand0m> une fois 1.0 sortie, je ferai du dev & un déploiement auprès d'un groupe de volontaires cinglés pour jouer avec pendant une semaine, puis si tout marche bien, ce sera déployé en sortie générale. [22:20] * FireRabbit sera un volontaire cinglé [22:20] <jrand0m> là tout de suite je dois me battre avec kaffe & jetty pour les mises à jour sur i2p.dnsalias.net [22:20] <duck> quelle espèce ? [22:20] * MrEcho l'est déjà [22:20] *** tusko (~tusko@anon.iip) a rejoint le canal #iip-dev [22:20] <jrand0m> vous êtes déjà des volontaires (très utiles) complètement fous :) [22:20] <FireRabbit> merci ! [22:20] <FireRabbit> :) [22:21] *** TC (~TC@anon.iip) a rejoint le canal #iip-dev [22:21] <jrand0m> hé si c'est pas tc [22:21] * MrEcho fouette TC .. tu es en retard [22:21] <TC> hey [22:21] <TC> on est de nouveau en marche ? [22:21] <MrEcho> ouais je peux taper aujourd'hui... [22:22] <jrand0m> iip semble en ligne... [22:22] <TC> youpi [22:22] <jrand0m> dans tous les cas, j'espère sortir 0.2.3.1 dans les prochains jours, une fois les deux bugs critiques corrigés (la surcharge CPU que tc a constatée a déjà été corrigée) [22:23] *** wiht (anon@anon.iip) a rejoint le canal #iip-dev [22:23] <TC> quelle en était la cause ? [22:23] <FireRabbit> il me semble avoir remarqué une activité disque accrue depuis la mise à jour vers 0.2.3 mais je n'ai pas pris le temps de voir si c'est réellement i2p ou juste le PC qui fait le con [22:23] *** Déconnexion: wiht ((null)) [22:23] <TC> FireRabbit, tu as combien de mémoire ? [22:24] <FireRabbit> cette machine a 128 je crois [22:24] <FireRabbit> tu penses que ce pourrait être le fichier d'échange ? [22:24] <jrand0m> la cause était que 0.2.3 envoie tous les messages dbStore via des messages routés en garlic au lieu de directement, ce qui utilise soit ElGamal soit AES+SessionTag (selon que les tags sont connus). le persistentSessionKeyMAnager fera durer les tags plus longtemps, et 0.2.3.1 enverra les messages dbStore via des tunnels à la place [22:24] <TC> parce que j'ai 512 et i2p m'a donné une erreur 'out of memory' hier soir [22:24] <jrand0m> vraiment ? merde [22:24] <FireRabbit> oh, intéressant [22:25] <MrEcho> wow [22:25] <jrand0m> ouais, c'est le n°3 sur la liste des bugs restants à résoudre (même si ce n'est pas un bloqueur pour 0.2.3.1) [22:25] <jrand0m> les OOM n'utilisent pas les 512 [22:25] <TC> mais ça semble tourner correctement maintenant [22:25] <jrand0m> ils n'utilisent que ce que Java a alloué (p. ex. 64M) [22:26] <TC> oui [22:26] <duck> Mémoire : En cours d'utilisation : 8187KB [22:26] <jrand0m> ouais [22:26] <duck> ce n'est pas beaucoup ! [22:26] <duck> encore [22:26] <MrEcho> Mémoire : En cours d'utilisation : 8908KB Libre : 4088KB [22:27] <jrand0m> oui, il y a quelque chose qui grossit là-dedans, j'espère l'avoir traqué d'ici 0.3 [22:27] <jrand0m> cool, 'free' veut dire qu'avant ça utilisait 12,9M, maintenant ça n'utilise plus que 8,9 [22:27] <TC> ça tourne à 30 Mo de mémoire en ce moment mais hier soir c'est monté à (d'après Windows) '70' et c'est à peu près là que ça a planté [22:27] <jrand0m> ouais, kaffe me fait ça aussi tc [22:28] <jrand0m> ok, en tout cas, les gens devraient s'abonner à la liste de diffusion i2p [22:28] * FireRabbit se dit qu'en rentrant chez lui aujourd'hui il va réécrire la lib meshwork car elle a quelques problèmes [22:28] <FireRabbit> soupir [22:28] <jrand0m> ((Link: http://i2p.dnsalias.net/pipermail/i2p/)http://i2p.dnsalias.net/pipermail/i2p/) [22:28] <jrand0m> d'oh FireRabbit [22:28] <FireRabbit> ce truc ne sera jamais fini [22:28] <TC> ouais, et la mémoire n'est pas un gros problème pour l'essentiel [22:28] <jrand0m> heh, aucun projet ne se passe aussi facilement qu'on l'espère [22:28] <FireRabbit> nope [22:28] <protocol> jrand0m: la liste de diffusion déclenche la protection anti-spam de Yahoo! [22:28] <protocol> juste pour info [22:28] <jrand0m> vraiment protocol ? [22:29] <protocol> ouais [22:29] <jrand0m> c'est peut-être ce qui a déclenché le filtre anti-spam quand j'ai mis iip-dev en copie [22:29] * jrand0m écrirai à mon FAI [22:29] <jrand0m> (ou peut-être le truc .dnsalias.net) [22:30] <protocol> je n'ai reçu aucun mailings pour l'instant, et j'ai vidé mon courrier indésirable avant de pouvoir vérifier [22:30] <duck> ou le pseudo jrandom [22:30] <jrand0m> lol duck [22:30] <FireRabbit> :) [22:30] <jrand0m> ce serait énorme si mon pseudo était filtré :) [22:30] <FireRabbit> hehe [22:30] *** wiht (anon@anon.iip) a rejoint le canal #iip-dev [22:30] <jrand0m> re wiht [22:30] <jrand0m> à ce propos, je suppose que je devrais injecter 3.1) apps :) [22:31] <jrand0m> hé MrEcho, comment va la bataille ? [22:31] <wiht> jrand0m: Bonjour. [22:31] <MrEcho> le jour où quelqu'un écrira un programme d'auto-détection pour la config de compilation Linux [22:31] <MrEcho> eh bien c'est en bonne voie [22:31] <duck> knoppix utilise un truc d'auto-détection, non ? [22:31] <jrand0m> ./configure ; make ; make check ; make install ; reboot [22:31] <duck> </offtopic> [22:31] <MrEcho> j'ai à peu près planifié comment je veux tout faire [22:31] <jrand0m> word [22:32] <jrand0m> as-tu une idée claire de la façon dont i2ptunnel pourrait être mis à jour pour tirer parti de ce que tu fais, MrEcho ? [22:32] <FireRabbit> je pense que knoppix utilise hotplug [22:32] <MrEcho> 0.1 ne sera pas/sera peut-être verrouillée .. je ne sais pas encore [22:32] <jrand0m> coo' [22:33] <TC> oh jrand0m, j'ai une question à propos du CVS [22:33] <jrand0m> que tal? [22:33] <MrEcho> pour les requêtes DNS je vais avoir un port serveur côté Client et côté RS pour les requêtes de noms [22:33] <FireRabbit> ok jrand0m alors éclaire-moi là-dessus, si tu as deux tableaux, l'un qui stocke les données juste reçues et l'autre qui sert de buffer comment tu les appellerais [22:33] <MrEcho> et je vais construire une lib que n'importe quelle app pourra utiliser [22:33] <jrand0m> FireRabbit> src, dest [22:34] <FireRabbit> humm [22:34] <TC> je pensais que ce serait une bonne idée si je mettais à jour le fichier hosts directement sur le CVS basé sur i2p pour qu'il puisse être inclus dans les futures versions [22:34] <jrand0m> clairement tc [22:34] <FireRabbit> c'est une assez grosse classe, je pense que je voudrais être un peu plus spécifique que ça [22:34] * jrand0m devrais te créer un compte CVS [22:34] <TC> je me demande juste comment s'y connecter [22:34] <duck> TC : tu veux (Link: http://www.tortoisecvs.org/)http://www.tortoisecvs.org/ [22:34] <duck> le client CVS le plus simple pour Windows que je connaisse [22:35] * MrEcho utilise la version DOS :) [22:35] <mihi> duck: pour Windows != win9x ;) [22:35] * FireRabbit utilise le port en ligne de commande cvs [22:35] <duck> mihi: je l'ai testé avec win9x [22:35] <jrand0m> tc> as-tu déjà utilisé cvs ? ou tu te soucies d'anonymat ? (tu devrais pouvoir cvs à travers i2p en ce moment) [22:35] * mihi utilise soit WinCVS soit le cvs de cygwin [22:35] * jrand0m utilise cvs.exe [22:35] <TC> ok, donc j'utilise ce client et je configure le proxy ? [22:35] <TC> non, je n'ai jamais utilisé cvs [22:35] <jrand0m> ok, je te guiderai pour la configuration après la réunion [22:36] <TC> bien sûr, merci [22:36] <duck> à propos de passer du cvs à travers le tunnel: [22:36] <duck> les doubles messages ne poseraient-ils pas un gros problème ? [22:36] *** Déconnexion: wiht (délai d'attente Ping dépassé) [22:37] <duck> surtout pour les commits [22:37] <jrand0m> oui duck, mais je n'ai pas rencontré ce problème (les messages cvs sont généralement petits) [22:37] <jrand0m> >64k messages (par ex. les specs .pdf ou .sxw) devraient pour l'instant passer par l'internet normal [22:38] <duck> les messages jabber se dédoublent aussi assez souvent [22:38] <jrand0m> tu as raison cependant, ce n'est pas encore une solution béton pour cvs [22:38] <duck> même s'ils sont en XML, ils ne sont pas si gros [22:40] <jrand0m> oui, les acks perdus sont l'un des emmerdes des bugs actuels perdus d'i2psessionimpl2 :/ [22:40] <duck> k [22:41] <duck> (c'était un ack partiellement perdu) [22:41] <jrand0m> (avec un réseau de cette taille, il ne devrait jamais y avoir de renvois, à moins que le pair soit hors ligne) [22:42] <jrand0m> hmm ok, d'autres trucs i2p ? [22:42] <mihi> jrand0m: que dirais-tu d'ajouter une sorte de numéro de séquence dans les paquets i2p ? [22:43] <jrand0m> paquets i2ptunnel ? [22:43] <mihi> ça aiderait avec les doublons. [22:43] <mihi> non, paquets i2pnp [22:43] <mihi> ok, on pourrait aussi le faire au niveau i2ptunnel. [22:43] <TC> alors jrand0m as-tu récupéré ta connexion ou es-tu encore dans un café ? [22:43] <mihi> si tu reçois deux fois le même numéro, ignore le second. [22:44] <jrand0m> ceux-là gèrent déjà les ids dupliqués pour la plupart des choses, même si tu as raison qu'il y aura une mise à jour en 0.3 pour les messages restants [22:44] <jrand0m> oui, actuellement on garde un historique des 1000 derniers msgIds pour jeter les doublons [22:44] <mihi> ok, si quelqu'un se porte volontaire pour écrire une bonne impl TCP pour i2p, ce serait encore mieux ;) [22:44] <jrand0m> oui ! :) [22:44] *** Nostradumbass (nostradum@anon.iip) a rejoint le canal #iip-dev [22:45] * jrand0m pense qu'il y aura une prime pour [une appli/fonctionnalité tueuse à déterminer] quand 1.0 approchera [22:45] <duck> gagnez une session de chat privé d'1 heure avec UserX ! [22:45] <jrand0m> lol [22:45] <MrEcho> lol [22:46] <jrand0m> ok, d'autres choses i2p, ou iip, ou autre pour cette 69e réunion iip-dev ? [22:46] <jrand0m> (autres que des commentaires sur les pin-up de userx) [22:47] <duck> d'autres apps que duck inc. devrait faire tourner ? [22:47] <jrand0m> bluebeep ! [22:47] <TC> 1. jrand0m as-tu réglé tes problèmes de connexion ? 2. que penses-tu de mon nouvel eepsite ? [22:47] <TC> bluebeep ? [22:47] <jrand0m> oh désolé tc. oui, j'ai enfin un accès net :) je n'ai pas vu ton nouvel eepsite au-delà du board (qui déchire), mais je regarderai plus tard :) [22:48] <duck> TC : j'aime le nouveau design [22:48] <TC> hmm, je devrais changer le board aussi pour réduire le temps de chargement [22:48] <duck> juste, tu devrais essayer de désactiver la fonction email dans le phpboard, là tu as une erreur à chaque fois [22:48] <TC> merci duck [22:48] <jrand0m> supprimer les images serait un plus [22:49] <TC> bonne idée [22:49] <jrand0m> (bluebeep est un vieux wardialer) [22:49] <MrEcho> ouais [22:49] <jrand0m> (et un jouet amusant tout court) [22:49] <duck> n'oubliez pas que l'âge moyen ici est 16 ans [22:50] * MrEcho a 24 ans [22:50] * duck se baisse [22:50] * jrand0m doute qu'il y ait beaucoup de enfants de 3 ans pour compenser les gériatriques parmi nous ;) [22:50] *** wiht (anon@anon.iip) a rejoint le canal #iip-dev [22:50] <MrEcho> lol [22:50] * TC a construit une blackbox une fois [22:50] <jrand0m> w3wt [22:50] <lonelynerd> la réunion est déjà terminée ? [22:50] <duck> dernière question: [22:50] *** protocol est maintenant connu sous le nom de proto_afk [22:51] <duck> comment peut-on lire les stats kademlia ? [22:51] * jrand0m n'a pas encore !baf, lonelynerd, alors vas-y :) [22:51] * MrEcho supprime le support pcmcia du noyau [22:51] <duck> juste pour qu'on comprenne ce que routerConsole.html déverse [22:51] <MrEcho> je commence à m'énerver [22:51] <jrand0m> ok, les stats JobQueue je suppose ? [22:52] * duck suppose que tout est probablement évident [22:52] <jrand0m> grossièrement, quand je regarde les stats JobQueue, je vérifie que le temps d'exécution moyen des jobs Build garlic message, buld tunnel, et handle * message est faible [22:52] <jrand0m> (ce sont les jobs qui prennent généralement le plus longtemps, et quand la file en attente devient grande, tout en pâtit) [22:53] <lonelynerd> (en fait, je ferais mieux de lire les logs d'abord) [22:53] <duck> entendu [22:53] <jrand0m> les .1-.6s de temps moyen en attente que j'ai vus sont vraiment pourris et c'est l'un des gros points que je vise quand il sera temps de les tuner [22:54] <jrand0m> la vivacité et la fiabilité du contenu du netDb sont largement des nombres aléatoires, tant qu'ils sont > 100. last sent successfully signifie la dernière fois où ça a été envoyé à 2 pairs ou plus [22:54] <jrand0m> (on renvoie aléatoirement si ce n'est pas local) [22:54] <jrand0m> (pas plus d'une fois toutes les 5 minutes cependant) [22:55] <jrand0m> y a-t-il une stat qui aiderait les gens, ou une autre visualisation qui pourrait aider ? (si ce n'est pas trivial je ne l'ajouterai peut-être pas, mais si c'est facile, probablement que si) [22:56] <duck> merci [22:57] <jrand0m> d'autres commentaires / questions / préoccupations / frisbees ? [22:59] <jrand0m> dans ce cas [22:59] * jrand0m se prépare [22:59] * jrand0m *baf* la réunion est close