Réunion des développeurs I2P - 31 janvier 2006

15:19 <jrandom> 0) salut 15:19 <jrandom> 1) Statut du réseau 15:19 <jrandom> 2) Statut 0.6.1.10 15:19 <jrandom> 3) ??? 15:19 * jrandom fait coucou 15:19 <jrandom> notes de statut publiées à http://dev.i2p.net/pipermail/i2p/2006-January/001257.html 15:20 <jrandom> ok, passons directement à 1) Statut du réseau 15:21 <jrandom> comme mentionné dans le mail, ceux en 0.6.1.9-0 (la version complète) devraient avoir comme d'hab 15:21 <jrandom> tandis que les utilisateurs sur des builds plus récents (depuis 0.6.1.9-5 ou plus) peuvent rencontrer des problèmes 15:21 <jrandom> (« des ennuis » est peut‑être un euphémisme...) 15:21 <+Complication> CVS -8 était un peu instable, donc je tourne -2 à la place (ça marche suffisamment bien) 15:22 <gloin> :-) 15:22 <+Complication> =instead 15:22 <Pseudonym> les choses semblent instables dernièrement (je suis en 0.6.1.9-0) 15:22 <jrandom> cool, j’envisageais d’annuler les changements de processus mais d’inclure la mise à jour ircclient de dust et le patch i2ptunnel httpserver sur head, mais 0.6.1.10 n’est probablement pas très loin 15:23 <jrandom> hmm Pseudonym, accès aux eepsites, à l’irc, ou à d’autres services, ou vous les hébergez ? 15:23 <+Complication> Instable avec -0 ? Comment le problème se manifeste‑t‑il ? 15:23 <Pseudonym> Je le remarque surtout sur IRC (je joue à idlerpg) 15:24 <jrandom> (« jouer » ;) 15:24 <Pseudonym> aussi, parfois le router part en vrille et doit être redémarré (aucun pair actif) 15:24 <Pseudonym> heh 15:24 <jrandom> hmm, des problèmes de connectivité Internet ? 15:24 <@frosk> -0 est stable ici, sauf bien sûr pour les redémarrages « router hung! » deux fois par jour 15:24 <jrandom> hrm frosk, vrai « router hung », ou « router hung » dû à l’expiration du leaseSet ? 15:25 <Pseudonym> la connectivité Internet est bonne. quand je redémarre le router I2P, ça revient tout de suite 15:25 <+Complication> Mon Cel300 se fige aussi au bout d’un moment, mais les périodes s’allongent, et je ne suis pas à jour sur la raison 15:25 <@frosk> jrandom: expiration de lease, je suis presque sûr 15:25 <jrandom> hmm 'k 15:26 <jrandom> presque tout cela a été réécrit pour le nouveau code de création et de gestion, donc on verra ce que ça donne en 0.6.1.10 15:27 <@frosk> cool 15:27 <@frosk> je serai ravi d’aider à le tester 15:28 <Pseudonym> Je n’ai pas besoin que vous diagnostiquiez le problème maintenant. Je voulais juste ajouter un point de données sur la stabilité 15:28 <jrandom> génial, une fois que ce sera stable localement je devrai certainement recruter un peu d’aide :) 15:28 <jrandom> cool, merci Pseudonym 15:28 <jrandom> ok, quelqu’un d’autre a quelque chose pour 1) Statut du réseau ? 15:30 <jrandom> sinon, passons directement à 2) Statut 0.6.1.10 15:30 <jrandom> comme mentionné dans le mail, plutôt que d’empiler correction sur correction sur le réseau en production, nous allons aller directement à la source 15:31 <jrandom> ce ne sera pas rétrocompatible, donc il y aura un… accroc, et comme nous regrouperons avec cela quelques autres changements rétro‑incompatibles, il y a la possibilité d’un autre ensuite 15:32 <jrandom> plus précisément, une idée que j’envisage est de migrer vers ElGamal 1024 bits pour le code de création de tunnel, plutôt que 2048 bits 15:32 <jrandom> mais ce ne sera peut‑être pas nécessaire. ça dépendra de l’impact sur le réseau en production 15:34 <jrandom> si c’est le cas, cela signifierait simplement une mise à niveau du réseau, mais toutes les destinations/etc resteraient identiques. 15:34 <jrandom> mais, de toute façon, c’est quelque chose à explorer après la sortie de 0.6.1.10 15:34 <+Complication> Une question vaguement liée : la longueur de la clé est‑elle d’une quelconque manière liée à la longueur de la structure de données de création de tunnel ? 15:34 <jrandom> oui 15:35 <jrandom> directement liée : longueur de clé * 2 * nb max de sauts == taille de la structure de données 15:36 <jrandom> (donc, 256*2*8 = 4KB, ce qui se trouve aussi être la taille des messages complets de la bibliothèque de streaming) 15:37 <jrandom> ((ElGamal a un facteur d’expansion de 2x)) 15:38 <+Complication> Aha, merci. :) 15:38 <jrandom> ah, une autre chose à propos de la nouvelle spec. pendant l’implémentation j’ai trouvé un autre élément de données dont j’ai besoin (un « reply message ID » de 4 octets) que j’ai ajouté à la spec localement, en utilisant certains des bits réservés 15:40 <jrandom> j’espère faire fonctionner le tout dans les prochains jours, donc il y aura peut‑être des tests précoces (non anonymes) d’ici le week‑end 15:40 <jrandom> mais, bien sûr, plus d’infos à ce sujet au fur et à mesure 15:41 <jrandom> ok, quelqu’un a des questions/commentaires/inquiétudes sur la 0.6.1.10 ? 15:41 <bar> autre question vaguement liée : pendant le déploiement de la .10, que diriez‑vous de garder i2p.net en .9 pendant quelques jours pour tous ceux qui mettent à jour automatiquement ? 15:41 <bar> rollout* 15:41 <jrandom> oui, carrément 15:42 <jrandom> j’aurai probablement deux ou trois routers sur cette machine pendant la migration 15:42 <jrandom> et il y aura des avertissements bien visibles au moins 5 jours avant la release 15:42 <bar> propre 15:42 <+Complication> De cette façon ce serait en effet plus fluide. 15:43 <+Complication> Le forum semble un bon canal. La boîte d’actualités sur la Console du router aussi... 15:43 * jrandom se souvient des jours où chaque release était rétro‑incompatible... on a eu beaucoup de pratique alors ;) 15:43 <jrandom> oui, forum, boîte d’actualités, liste, site web 15:43 <+Complication> Ainsi ceux qui surveillent leurs machines seraient au courant. 15:43 <tethra> heheh 15:44 <jrandom> et ceux qui sont encore en 0.6.0.1, eh bien, ils sont fscked de toute façon ;) 15:44 <@frosk> qu’on leur coupe la tête 15:44 <+Sugadude> Totalement sans rapport : peut‑on avoir plus souvent des changements rétro‑incompatibles pour forcer ces vieux routers à sortir ? 15:44 <+Complication> Je pense qu’ils ont juste oublié I2P en route :) 15:44 <jrandom> heh Sugadude 15:45 <jrandom> eh bien, s’ils sont compatibles, on peut utiliser leurs ressources, mais s’il y a une raison pour laquelle on ne peut pas, on devrait les marquer comme incompatibles 15:47 <jrandom> ok, s’il n’y a rien d’autre là‑dessus, passons à notre fourre‑tout : 3) ??? 15:47 <jrandom> quelqu’un a autre chose qu’il veut soulever pour la réunion ? 15:48 <tethra> il est écrit quelque part sur la console du router que les utilisateurs derrière des NAT symétriques ne sont actuellement pas pris en charge, est‑ce que ça va changer prochainement ? 15:48 <tethra> ou est‑ce que je montre une immense ignorance de quelque chose 15:49 <+Complication> Concernant le code du webcache... il semble que je sois à peu près prêt. 15:49 <jrandom> il y a quelques techniques pour aider les utilisateurs derrière des NAT symétriques, que bar a décrites sur la liste et le forum, même si je ne connais pas de progrès immédiats là‑dessus 15:49 <jrandom> oh, bien vu Complication, dis‑moi quand pousser la release :) 15:50 <+Complication> Le watchdog interrompt les téléchargements de manière raisonnable, je fais quelques tests et du nettoyage (il journalise actuellement bien plus que de raison).. 15:50 <+Complication> J’ai un serveur webcache en ligne, awup en a un autre... pour des tests réalistes, on voudra peut‑être activer la limitation... 15:51 <+Complication> ...si je parviens à croiser legion, je lui demanderai s’il serait intéressé pour en faire tourner un aussi. 15:52 <jrandom> cool, même un seul webcache serait un excellent début 15:52 <+Complication> Et si quelqu’un d’autre veut exécuter le script (disponible depuis awup.i2p, script Python utilisant SAM)... leurs références peuvent être ajoutées, bien que l’ajout de refs à davantage de « seed webcaches » nécessite actuellement une recompilation des sources. 15:53 <+Complication> (pas dans un fichier mais dans l’en‑tête de GWebCacheContainer.java) 15:53 * gloin ne sait pas ce que c’est que ce truc de webcache. 15:53 <jrandom> gloin: ça te permet de te connecter à i2phex sans devoir télécharger un fichier i2phex.hosts la première fois 15:54 <+Complication> gloin: pour une intégration plus facile d’I2PHex 15:55 * cervantes arrive en retard 15:55 <+Complication> Et pour les reconnexions ultérieures (p. ex. les personnes qui n’ont plus de refs de pairs actifs) il peut offrir des refs fraîches 15:55 <gloin> ok. 15:57 <+Complication> Oh, à nouveau hors ligne 15:58 <stealth> que diriez‑vous d’un démarrage automatique d’i2phex après le démarrage d’i2p ? 15:58 <+Complication> Ça semble exagéré 15:58 <+Complication> À ce stade au moins 15:58 <jrandom> stealth: tu peux faire lancer par le router i2p n’importe quelle application java que tu veux en ajoutant des entrées dans ton fichier client.config 15:59 <+Complication> De plus, je pense que I2Phex peut être démarré avant qu’I2P ne tourne 15:59 <@frosk> à n’importe quel stade 15:59 <+Complication> Théoriquement, il devrait continuer à essayer de se connecter jusqu’à ce qu’I2P se lance 15:59 <+Complication> (pas testé, toutefois) 15:59 <jrandom> mais n’oublie pas, si tu lui dis de lancer i2phex, quand i2phex se ferme, il y a des chances que le client i2phex tue la JVM (redémarrant ton router) 16:00 <+Complication> En plus, on pourrait aussi scripter ça assez facilement... 16:00 <+Complication> e.g. "cd /home/i2p; sh i2prouter start; cd /home/i2phex; sleep 100; sh run.sh;" 16:00 <+Complication> (ou peu importe) 16:01 <+Complication> Désolé, /home/user/i2p plus probable :) 16:01 <cervantes> n’oubliez pas de lancer /usr/games/tetris avant le sleep 100 16:02 <jrandom> tout à fait 16:02 <jrandom> ok, quelqu’un a autre chose pour la réunion ? 16:03 <stealth> eh bien j’y pensais, juste démarrer l’exe. la solution i2psnark avec « toujours actif » est meilleure parce que les gens oublient de partager leurs fichiers s’ils ne téléchargent pas... 16:04 <jrandom> oui, même si je n’ai pas encore entendu parler d’un client gnutella suffisamment léger (qui pourrait être intégré) 16:05 <cervantes> n’y a‑t‑il pas un travail en cours sur le Phex actuel pour abstraire l’UI ? peut‑être que le client finira par devenir léger 16:05 <+Complication> Je n’ai pas lu cette partie du CVS de Phex 16:06 <jrandom> si phex pouvait être exécuté en .war, ce serait en effet top 16:06 <cervantes> isn't the=isn't there 16:06 <cervantes> Je me trompe probablement 16:06 <+Complication> Sirup travaillait certainement sur une interface XML‑RPC, mais je ne suis pas sûr que Gregor & co aussi 16:07 <+Complication> Donc je ne sais pas si sirup l’a porté, ou s’il a commencé à l’écrire depuis zéro 16:09 <jrandom> si je me souviens bien il importait juste la lib xmlrpc d’Apache et exposait une partie des internes d’i2phex, mais il n’y a probablement pas eu de travail là‑dessus depuis 6–8 mois, et ça n’a jamais été fonctionnel à ma connaissance 16:10 <fox_> <tethra> mutella est un client gnutella basé web qui est assez léger, si je me souviens bien. pas sûr que ça aide, mais heh, ça vaudrait peut‑être le coup que quelqu’un (de plus talentueux) y jette un œil. 16:10 <fox_> <tethra> ce n’est peut‑être pas ce qui est recherché, toutefois. 16:12 <jrandom> porter un nouveau client est un gros travail, surtout un en C/C++, malheureusement 16:12 <+Complication> Personnellement il est peu probable que je bidouille du XML‑RPC. En revanche, essayer d’attraper divers bugs... fait partie de mes plans à court terme. 16:13 * Complication veut se débarrasser pour de bon de l’effet de rehash, puisque c’est une telle perte de temps 16:13 <jrandom> ooh, c’est peut‑être déclenché par un décalage de fuseau horaire ? 16:14 <jrandom> quand le SDK I2P se connecte au router, il récupère l’heure I2P (NTP) courante, et force la JVM du SDK en UTC 16:14 <+Complication> Ça paraît peu probable... mais à ce stade, je ne peux pas exclure grand‑chose 16:15 <jrandom> (et si le rehash dépendait de l’ordre et des horodatages de fichiers, peut‑être que le décalage de quelques heures changerait ça) 15:15 <jrandom> oui, tu as beaucoup creusé, je mentionne juste une possibilité 15:15 * jrandom n’en sait rien au‑delà de tes rapports de bugs :) 16:16 <+Complication> Ça arrive occasionnellement, et cela *semble* lié à quelque chose qui se produit lorsque le fichier de config « sharedlibrary » est chargé/réécrit 16:16 <+Complication> Hmm, possibilité intéressante... 16:16 <+Complication> Je n’ai pas assez creusé pour exclure ça 16:18 <jrandom> ok, quelqu’un d’autre a quelque chose pour la réunion ? 16:19 <jrandom> sinon... 16:19 * jrandom conclut 16:19 * bar souhaite bonne chance à jrandom pour la .10 et lui tend un baf tout brillant 16:19 <jrandom> gracias :) 16:19 * jrandom *baf* ferme la réunion