Réunion des développeurs d'I2P - 11 octobre 2005

16:29 <jrandom> 0) salut 16:29 <jrandom> 1) 0.6.1.2 16:29 <jrandom> 2) I2PTunnelIRCClient 16:29 <jrandom> 3) Syndie 16:29 <jrandom> 4) I2Phex 16:29 <jrandom> 5) Stéganographie et darknets (cf. flamewar) 16:29 <jrandom> 5) ??? 16:29 <jrandom> 0) salut 16:29 <@cervantes> (6) 16:29 <+postman> tu veux dire 6) ? 16:29 <jrandom> ouais, je ne sais pas compter ;) 16:30 * postman fait un high-five avec cervantes 16:30 <jrandom> notes d'état hebdomadaires publiées @ http://dev.i2p.net/pipermail/i2p/2005-October/000990.html 16:30 <wiht> Les questions devraient être le point 6. 16:30 <jrandom> comme j’ai 30 minutes de retard, vous avez déjà lu ces notes, j’en suis sûr, alors lançons ça ;) 16:31 <jrandom> 1) 0.6.1.2 16:31 <@cervantes> 6) Discuter du piètre sens du timing du colocataire de jrandom 16:31 <jrandom> *tousse* ;) 16:31 <jrandom> ok, comme mentionné dans l’email, la version 0.6.1.2 semble bien se porter 16:32 <jrandom> nous avons trouvé le bug qui retenait les serveurs IRC sur une ancienne build, et ils sont maintenant à jour aussi (w00t!) 16:32 <+postman> :) 16:32 <wiht> À ce propos, dans le netDB sur la console du router, serait-il possible d’afficher en haut de la page le tableau avec les routers et leurs versions ? 16:33 <jrandom> le nombre de routers par version, c’est ça ? oui, ça pourrait se faire assez facilement, peut‑être l’intégrer dans le tableau peers.jsp (affichant la version par pair) et un nouveau tableau en bas ? 16:34 <jrandom> c’est plutôt sympa de voir 9 versions cohabiter correctement, même si bien sûr les plus récentes fonctionnent le mieux 16:35 <jrandom> ok, quelqu’un a autre chose à soulever concernant 1) 0.6.1.2 ? 16:35 <+postman> un de mes routers affiche 1080 connus 16:35 <jrandom> ouah 16:35 <+postman> je pense que c’est un peu étrange ? 16:35 <jrandom> c’est sur 0.6.1.2 ? 16:35 <+postman> ouais, je crois 16:36 <jrandom> hmm, oui, c’est... un peu élevé. j’en vois environ la moitié en ce moment 16:36 <+Complication> Stable autour de 400 ici 16:37 <+bar> pareil ici 16:37 <wiht> Je vois 260 routers connus. 16:37 <jrandom> postman : peut‑être qu’on peut creuser ce qui se passe sur ce router après la réunion (pourrais‑tu me tar.bz2 netDb/routerInfo-* ?) 16:38 <+postman> jrandom : oui merci 16:38 <jrandom> gracias 16:38 <jrandom> oui, tout le monde ne verra pas chaque référence netDb, donc c’est normal qu’il y ait des fluctuations 16:40 <jrandom> ok, s’il n’y a rien d’autre sur 1) 0.6.1.2, passons à 2) I2PTunnelIRCClient 16:40 <@cervantes> bien joué dust 16:40 <jrandom> comme mentionné dans l’email, nous avons un nouveau filtre spécifique au protocole IRC disponible dans le CVS, et il devrait devenir la valeur par défaut dans la prochaine révision 16:41 <+postman> cool 16:41 <jrandom> ouais, c’est très cool, les gens demandent quelque chose comme ça depuis des lustres 16:41 <+Myo9> Jrandom, tu es devenu plus ouvert récemment, on a appris des choses sur ton ex, et maintenant ton coloc, etc. Souviens‑toi : http://www.navysecurity.navy.mil/st031204.webp 16:41 <jrandom> *tousse* 16:42 <dust> si vous voulez voir ce que votre client envoie, vous pouvez ajouter net.i2p.i2ptunnel.I2PTunnelIRCClient=INFO puis regarder les logs pour tout voir 16:43 <dust> j’ai testé quelques clients mais il y en a beaucoup.. 16:43 <jrandom> ouais, je l’ai surveillé un petit moment, mais le filtrage semble solide 16:44 <jrandom> il y a aussi des trucs sympas qu’on pourra peut‑être faire à l’avenir – par ex. gérer les PING/PONG localement, pour réduire l’activité réseau 16:44 <+Complication> dust : merci pour l’« info » :) 16:44 <+bar> génial dust, merci beaucoup 16:44 <wiht> Ça veut dire qu’on n’a plus besoin de configurer un tunnel IRC supplémentaire ? 16:44 <jrandom> wiht : non, il te faudra un tunnel IRC, mais il peut remplacer celui que tu utilises déjà 16:45 <+Complication> wiht : disons qu’on se souciera moins que notre client IRC nous trahisse 16:45 <jrandom> postman/cervantes : des avis sur l’augmentation ou la suppression des timeouts de ping/pong côté serveur ? 16:45 <wiht> Ça explique, merci. 16:46 <+postman> mmh, je ne les supprimerais pas, mon client a complètement paniqué quand j’ai joué avec ça 16:46 <jrandom> postman : eh bien, je pense à y répondre localement, ainsi le client aurait un PING/PONG vraiment, vraiment rapide 16:46 <@cervantes> postman : le proxy pourrait répondre aux pings 16:46 <jrandom> (mais le ping/pong n’aurait pas besoin de traverser le réseau) 16:47 <jrandom> je ne connais pas l’impact, mais ça vaut peut‑être le coup d’étudier. 16:47 <@cervantes> mais je ne suis pas sûr de la réaction des serveurs, on pourrait se retrouver avec une flopée de clients zombies 16:47 <+postman> jrandom : eh bien 16:47 <jrandom> eh bien, le keepalive de la lib de streaming devrait gérer ça 16:47 * Complication a parfois connu de la zombification 16:47 <jrandom> Complication : récemment ? 16:47 <+postman> jrandom : si le proxy ping pour le client, le proxy doit aussi ping/pong vers le client 16:48 <+Complication> Il y a une semaine, je crois. 16:48 <jrandom> postman : un PING du client vers le proxy ferait que le proxy réponde directement au client avec un PONG sans rien envoyer sur i2p 16:48 <+Complication> Mais ma « copie » a fini par être éjectée. 16:48 <@cervantes> jrandom : la connexion serait maintenue ouverte... les serveurs devraient abaisser leur seuil pour décider à partir de quand un client est périmé et doit être éjecté 16:48 <jrandom> Complication : ah, les serveurs IRC n’étaient pas à jour à ce moment‑là, ça ne devrait plus arriver 16:49 <+Complication> Sans que j’emploie « ghost ». Les utilisations récentes de la commande ghost étaient dues au fait d’opérer avec de nombreux nœuds. 16:49 <+postman> jrandom : et la mesure de la latence ? 16:49 <jrandom> cervantes : exact. et/ou si nécessaire, le proxy pourrait injecter un message PING supplémentaire au serveur s’il en /a besoin/. 16:49 <+postman> je trouve assez utile de savoir si j’ai de la latence ou pas 16:49 <jrandom> moi aussi, mais tu peux toujours te /msg 16:50 <dust> on pourrait peut‑être réduire le nombre de pings 16:50 <jrandom> ça économiserait une quantité substantielle de bande passante, puisque les messages de tunnel sont des blocs de 1024 octets, envoyés sur 2*k+1 sauts 16:50 <jrandom> ça aussi 16:50 <jrandom> je ne sais pas, juste une idée. ce qu’on a maintenant déchire de toute façon 16:51 <+postman> ok, j’essaierais de patcher un serveur de test 16:51 <@cervantes> on pourrait peut‑être voir à réduire le nombre... mais je pense qu’on devrait quand même envoyer quelques vrais pings pour déterminer si les clients sont toujours en vie 16:51 <+postman> peut‑être que ça marche 16:51 <jrandom> ça semble raisonnable cervantes. je ne pense pas que ça nécessiterait de patch côté serveur, j’espère ? 16:52 <+postman> jrandom : pour désactiver peut‑être – mais abaisser l’intervalle est un paramètre de conf 16:53 * postman mâchonne la documentation ircd ( encore ) 16:53 <jrandom> cool, pas d’urgence. juste quelque chose à étudier un de ces jours 16:53 <@cervantes> class servers 16:53 <@cervantes> { 16:53 <@cervantes> pingfreq 120; 16:54 <@cervantes> class clients { pingfreq 90 } 16:54 <@cervantes> c’est ma config actuelle 16:54 <+postman> cervantes : oui, je sais - la question est de savoir si on peut le désactiver 16:54 <@cervantes> je ne les désactiverais pas... juste voir à les réduire 16:55 <+postman> ok, commençons par ça 16:55 <+postman> cervantes : que dirais‑tu de 180 s ? 16:56 <@cervantes> allons-y franco avec 240 16:56 <@cervantes> mais on devrait peut‑être préparer d’abord le côté ircproxy 16:57 <@cervantes> *à discuter après la réunion* 16:57 <+postman> d’accord 16:57 <jrandom> ça marche. ok, autre chose sur 2) I2PTunnelIRCClient, ou on passe à 3) Syndie ? 16:57 <@cervantes> tout ce qui réduit mes 40 kb/sec de trafic moyen du router ;-) 16:58 <jrandom> heh, pour une raison quelconque je doute que ce soit tout de l’IRC ;) 16:58 <jrandom> ok, on continue 16:59 * cervantes cache ses téléchargements de vidéos de poneys qu’il a pompés chez jrandom toute la semaine 16:59 <@cervantes> is=the 16:59 <+postman> LOL 16:59 <jrandom> comme mentionné dans le mail, il se passe des trucs assez cool avec Syndie 16:59 <jrandom> la CLI est triviale, mais le nouveau Sucker de dust a l’air très prometteur 16:59 <jrandom> dust : tu veux nous faire un topo ? 17:00 <dust> oh, 17:01 <dust> eh bien, il utilise rome pour analyser les flux puis les convertit en sml, comme décrit dans le blog de jrandom 17:02 <dust> ce n’est pas ce qu’on appellerait « robuste » pour l’instant, mais il n’a que deux jours :) 17:02 <dust> j’ai du Dilbert dans mon Syndie.. 17:02 <dust> :) 17:02 <dust> . 17:02 <jrandom> sympa 17:03 <jrandom> ok, tu penses qu’on l’emmène où – on l’intègre dans les sources de Syndie et on l’expose en CLI, ou on le garde séparé et on le distribue indépendamment, ou autre chose ? 17:04 * dust ne sait pas, à toi de décider 17:04 <dust> moins il y a d’outils séparés, mieux c’est 17:04 <jrandom> ouais, probablement plus simple de tout regrouper, comme ça tout le monde sait qu’il peut l’utiliser 17:05 <jrandom> on pourrait alors faire des choses comme l’intégrer à l’interface web, et peut‑être à l’ordonnanceur de Ragnarok (syndication avec d’autres nœuds et récupération depuis RSS/Atom/etc.) 17:07 <jrandom> ok, quelqu’un a des questions/commentaires/inquiétudes sur 3) Syndie ? 17:07 <wiht> Si vous continuez à intégrer des logiciels dans I2P, ça pourrait devenir un paquet logiciel boursouflé. 17:07 <wiht> Bien sûr, je peux désactiver Syndie si je ne l’utilise pas. 17:08 <jrandom> le SDK i2p fait 13KLOC 17:08 <jrandom> et le router i2p n’en fait que 22KLOC 17:08 <jrandom> mais oui, il y a un impact sur le temps de téléchargement de l’installeur 17:09 <jrandom> si quelqu’un le voulait, il pourrait construire un router allégé sans applications clientes, en n’utilisant que router.jar, jbigi.jar et i2p.jar 17:09 <wiht> Oui, je parlais du téléchargement. 17:09 <jrandom> (mais c’est bien plus utile quand il y a une interface web pour le contrôler, et i2ptunnel, et la lib de streaming, etc ;) 17:11 <jrandom> smeghead travaillait sur un système de distribution (comme emerge, pour Java), et il y a aussi les gens de jpackage 17:11 <jrandom> si quelqu’un veut chercher une manière transparente et fiable de gérer les applis sans les empaqueter, ce serait plutôt cool 17:12 <jrandom> ok, s’il n’y a rien d’autre là‑dessus, passons à 4) I2Phex 17:13 <jrandom> je n’ai pas vraiment grand‑chose à ajouter au‑delà de ce qui est dans les notes d’état 17:13 <jrandom> redzara : tu es là ? 17:13 <+redzara> oui, je suis là 17:13 <+redzara> Je travaille déjà sur la prochaine version, en attendant la réunion avec Gregor. 17:13 <jrandom> ah super 17:13 <+redzara> Le travail, pour le moment, consiste principalement à identifier les différences et les besoins liés à l’utilisation d’I2P, comme par exemple TCP/UDP vs I2P, la gestion des paramètres spécifiques à I2P (et la gestion de la mise à jour de ces mêmes paramètres lors des prochaines versions, ...), le portage de GWebCache vers I2P, utiliser RSS ou pas, utiliser push ou pas... 17:14 <+redzara> J’ai beaucoup de documentation et de code à lire 17:15 <jrandom> wow, oui, ça fait beaucoup. dis‑moi si tu as des questions concernant l’intégration I2P, ou si tu veux simplement quelqu’un avec qui échanger des idées 17:16 <jrandom> faire de la partie I2Phex un plugin pour le Phex principal serait vraiment top 17:17 <jrandom> ok, quelqu’un a autre chose pour 4) I2Phex ? 17:18 <+redzara> J’aurais certainement besoin d’assistance pour la partie petname (nom local/convivial) 17:19 <+redzara> et peut‑être aussi pour le réglage fin des paramètres de tunnel 17:19 <jrandom> cool, la partie nommage est assez simple – à un niveau basique, tu pourrais même t’en sortir sans utiliser de noms du tout (c’est comme ça qu’I2Phex fait actuellement) 17:20 <jrandom> la config de tunnel ne devrait pas poser de problème non plus, même si ça amène l’idée que Phex aurait peut‑être besoin d’une section « configuration avancée » pour les plugins 17:20 <jrandom> (on voudrait évidemment de bons réglages par défaut de toute façon) 17:21 <+redzara> peut‑être quelque chose comme ircclient, un filtre pour être sûr 17:22 <@cervantes> mieux vaut mettre l’app en forme d’abord à mon humble avis 17:22 <jrandom> ça pourrait marcher, même si gérer des séquences d’octets arbitraires peut être ardu 17:23 <jrandom> ceci dit, un proxy comme ircclient pourrait peut‑être permettre à n’importe quel client Gnutella de l’utiliser. mais ce serait pas mal de boulot. 17:23 <+redzara> humm, c’est juste une idée ;) 17:23 * jrandom ne connaît pas assez bien le protocole pour dire quelle est la meilleure approche, donc je suggère d’aller avec la chose la plus simple qui puisse marcher :) 17:25 <jrandom> ok, s’il n’y a rien d’autre, on peut peut‑être survoler brièvement 5) stégo et darknets 17:26 <jrandom> je ne suis pas sûr d’avoir quoi que ce soit à ajouter au‑delà de ce qui se dit sur la liste (et la discussion principale devrait probablement continuer là‑bas) 17:27 <jrandom> cela dit, y a‑t‑il des choses que les gens veulent soulever au sujet des points abordés ? 17:27 <wiht> Les versions 0.5 et 0.7 de Freenet ont été mentionnées dans la discussion. Y a‑t‑il une version 0.6 pour Freenet ? 17:27 <jrandom> 0.6 est leur branche « instable » actuelle du réseau 17:27 <jrandom> a priori 17:27 <+postman> ohh et je pensais qu’elle avait été volée par des forces extraterrestres 17:28 <jrandom> même si blâmer les aliens est généralement un pari sûr, c’est l’un des rares cas où ils n’y sont pour rien 17:28 <+postman> :) 17:28 <wiht> Toad parlait de la possibilité de récolter les adresses IP des nœuds I2P ou Freenet, non ? 17:28 <jrandom> entre autres 17:29 <wiht> Je voulais juste clarifier ça, merci. 17:29 <jrandom> pas de souci. ok, quelqu’un a autre chose sur le 5), ou on passe au bon vieux 6) ??? 17:30 <+postman> ok, j’en ai une pour le 6) 17:30 <jrandom> considérez que c’est fait. 17:30 <jrandom> quoi de neuf postman ? 17:30 <+postman> on a tous vu que les proxies capables de filtres spécifiques au protocole sont utiles et nécessaires 17:31 <+postman> serait‑il faisable d’investir de la réflexion dans un proxy générique 17:31 <+postman> qu’on peut alimenter avec une description de protocole 17:31 <+redzara> J’aimerais avoir une application comme cron utilisant BeanShell pour exécuter du code Java dynamiquement 17:31 <+postman> avec des éléments à surveiller/filtrer/dissimuler 17:31 <+postman> comme une description XML pour filtrer/assainir 17:32 <+postman> afin de ne pas avoir besoin d’un nouveau source mais juste d’un nouveau fichier/profil de filtre 17:32 <+postman> (juste une question pour savoir si ça vaut le coup d’y penser) 17:32 <jrandom> très, très compliqué postman. il serait possible d’utiliser un lexer comme JavaCC pour construire des langages d’entrée et une appli pour traduire ce langage vers le format de sortie 17:32 <@cervantes> ce qui est délicat, c’est d’attraper ce qui dévie du protocole 17:33 <+postman> c’était juste une idée pour déclencher un brainstorming 17:33 <+postman> amha quelque chose comme un proxy générique avec filtre/parser modélisés est très exploitable 17:33 <wiht> Quelqu’un a‑t‑il pu se connecter à eepsites.i2p ? J’ai essayé plusieurs fois la semaine passée, mais sans succès. 17:33 <jrandom> wiht : je l’ai chargé une fois, c’est le même que eepsites.com 17:34 <jrandom> (ou c’est .net ? ou .org ? j’oublie) 17:34 * wiht visite eepsites.com 17:34 <jrandom> postman : si quelqu’un pouvait sortir quelque chose qui marche, ce serait mortel 17:34 <+postman> jrandom : ok, je vais réfléchir un peu là‑dessus avec susi 17:34 <jrandom> w3wt 17:34 <+postman> jrandom : peut‑être qu’on laissera tomber la semaine prochaine 17:35 <wiht> C’est eepsites.com, et c’est un moteur de recherche pour les eepsites. 17:35 <+postman> mais j’ai fait un rêve où ça marchait 17:35 <+postman> :] 17:35 <jrandom> :) 17:36 * Complication soupçonne que décrire toutes les subtilités qui surviennent dans les protocoles... nécessite du code, et rien de moins que du code 17:36 <+Complication> (pour la plupart des protocoles, au moins) 17:36 <@cervantes> nan, juste quelques regex maléfiques 17:36 <+postman> Complication : peut‑être que ce soupçon est la raison qui nous empêche d’aller plus loin 17:37 <+postman> Complication : je ne suis pas encore sûr, mais le soupçon seul ne me laissera pas en paix sur ce sujet 17:37 <jrandom> eh bien, un point important ici est quelque chose que dust nous a démontré – 17:37 * Complication craint une regex capable de telles choses 17:37 <jrandom> le code n’est pas forcément si effrayant. 17:37 <+postman> tu vois ? :) 17:37 <+postman> un bon langage de modélisation de filtres fera la même chose 17:38 <+postman> :) 17:38 <@cervantes> tcl ? :) 17:38 <+Complication> il faudrait qu’il soit bon. 17:38 * jrandom voit que toi aussi tu as tes poneys volants, postman ;) 17:38 * dust n’aimait pas non plus dupliquer du code ici et là 17:38 <+postman> jrandom : pas de vaches :) 17:38 <jrandom> code qui marche>>> améliorations théoriques du code 17:39 <+postman> mmh 17:40 <+postman> une chose que j’ai apprise d’I2P 17:40 <wiht>>>> signifie « bien, bien meilleur ? » 17:40 <+postman> ne pas abandonner aux premières apparences 17:40 <jrandom> tout à fait postman 17:40 <jrandom> oui wiht 17:41 <jrandom> ce serait vraiment cool 17:41 <jrandom> ok, quelqu’un a autre chose à aborder pour la réunion ? 17:41 <+bar> bon, comment fonctionne l’IMAP, postman ? (j’en ai lu à ce sujet sur les forums mais je ne l’ai pas encore essayé moi‑même) 17:41 <+postman> bar : essaie toi‑même – je n’ai pas encore de retours d’utilisateurs 17:41 * cervantes amène le gong en forme de poney 17:42 <+bar> ok, je vais le faire :) 17:42 <+postman> bar : et chez moi ça marche TRÈS BIEN :) 17:42 <jrandom> sympa 17:42 <+bar> cool 17:42 <+postman> cervantes : tu es obsédé 17:42 <@cervantes> moi ?! 17:42 <@cervantes> :) 17:43 <jrandom> ok, avant qu’on atteigne les 90 minutes 17:43 * jrandom prend de l’élan 17:43 * jrandom *baf* clôt la réunion