Réunion des développeurs I2P - 29 novembre 2005

15:25 <jrandom> 0) salut 15:25 <jrandom> 1) État du réseau et 0.6.1.6 15:25 <jrandom> 2) Syndie 15:25 <jrandom> 3) I2P Rufus 0.0.4 15:25 <jrandom> 4) ??? 15:25 <jrandom> 0) salut 15:25 * jrandom fait coucou 15:25 <jrandom> notes d'état hebdomadaires publiées @ http://dev.i2p.net/pipermail/i2p/2005-November/001234.html 15:26 * bar tend à jrandom un « baf » 15:26 <c3rvantes> pas encore ! 15:26 * jrandom se prépare 15:26 <jrandom> euh... 15:26 <jrandom> attaquons d'abord les premiers points de l'ordre du jour :) 1) État du réseau et 0.6.1.6 15:27 <jrandom> beaucoup de choses ont été mises à jour dans les dernières versions, mais le réseau semble toujours raisonnablement stable. 15:28 <jrandom> nous avons eu de sérieux pics de participation de router sur quelques routers, même si c'est assez inoffensif 15:28 <+legion> cool, je suis d'accord, l'état du réseau s'améliore. Et oui, pourquoi ne pas abandonner tcp pour 0.6.1.7 15:28 <jrandom> (euh, des pics de participation de tunnel, en fait) 15:29 <@cervantes> tu ne plaisantes pas 15:29 <jrandom> pas sûr, legion. il peut y avoir des utilisateurs limités à tcp uniquement, mais il me semble me souvenir qu'il n'y en avait qu'un ou peut‑être deux 15:29 <+legion> eh bien, j'ai remarqué qu'avec 0.6.1.5 le router redémarrait parfois tout seul. 15:29 <+Complication> Chez moi, ça oscille dans des limites raisonnables, de 100 à 250 tunnels participants 15:29 <jrandom> Je ne vois pas de bonne raison de le garder, et j'en vois quelques‑unes pour le supprimer 15:30 <jrandom> cool Complication 15:30 <jrandom> (ces chiffres sont assez moyens, selon stats.i2p/, mais rappelez‑vous que de tels nombres peuvent nuire à l'anonymat, donc il ne faudrait pas vraiment les divulguer, surtout pas dans des réunions enregistrées ;) 15:30 <+Complication> Mon vieux Celeron redémarre encore automatiquement toutes les ~10 heures 15:30 <+Complication> Sinon, il est mieux connecté que jamais 15:30 <Pseudonym> quelles sont les raisons de le supprimer ? 15:31 <+Complication> TCP coûte cher 15:31 <@cervantes> mon router est HS 15:31 <+Complication> En termes de threads par connexion 15:31 <@cervantes> Complication : multiplie ça par 10 et tu obtiens la plage actuelle de mon router ;-) 15:31 <+legion> Chez moi ça oscille entre 200 et 400 tunnels participants, donc ça semble mieux que jamais. 15:32 <+Complication> cervantes : ouille ouille 15:32 <+Complication> J'ai vu un accident bizarre qui a causé 2000 tunnels participants, mais c'était en été 15:32 <jrandom> Pseudonym : performances (CPU/mémoire, meilleur ordonnancement grâce à nos exigences semi‑fiables), maintenabilité, mise sur liste noire plus efficace 15:32 <+Complication> Un seul pic qui ne s'est jamais reproduit 15:32 <+legion> oui, avec certaines versions passées il y avait de tels pics 15:32 <jrandom> Complication : nous avons eu des pics de > 2000 tunnels avec cette dernière rév. 15:33 <jrandom> mais avec un peu de chance 0.6.1.7 s'en chargera 15:33 <+legion> Eh bien, voilà de bonnes raisons d'abandonner tcp :) 15:33 <jrandom> mais, encore une fois, les pics de participation de tunnel ne posent pas problème, car la plupart ne sont pas utilisés 15:34 <@cervantes> Pseudonym : il ne semble y avoir qu'un ou deux routers qui utilisent encore tcp sur le réseau 15:34 <jrandom> il pourrait aussi être judicieux de supprimer tcp dans cette rév., puisqu'elle n'a pas d'autres changements majeurs. ainsi on peut voir assez clairement comment cela affecte les choses 15:34 <jrandom> (et on peut le réactiver si nécessaire) 15:35 <Pseudonym> s'il n'y a que deux routers qui l'utilisent, je ne peux pas imaginer que cela ait beaucoup d'effet, dans un sens comme dans l'autre 15:35 <Pseudonym> (sauf qu'il y aurait deux routers de moins sur le réseau) 15:35 <@cervantes> 2 clients mécontents 15:35 <jrandom> eh bien, le transport apparaît dans des situations bizarres, ce qui est l'une des raisons pour lesquelles je veux le désactiver :) 15:35 <+Complication> J'espère qu'ils ne le prendront pas trop personnellement 15:36 <+Complication> C'est vraiment méchant de la part de certains FAI de filtrer l'UDP. 15:36 <+Complication> Méchant, et complètement insensé. 15:36 <jrandom> (par ex. quand un router est HS, les gens marquent leur transport SSU comme défaillant, et du coup ils retombent sur le transport tcp) 15:36 * Pseudonym adore son FAI. aucune restriction 15:37 <+Complication> Donc sans TCP, on verrait comment l'UDP s'en sort tout seul ? 15:37 <+Complication> « sans les petites roulettes » :P 15:37 <+legion> hein, alors comment contourne‑t‑on un filtrage aussi méchant sans tcp ? 15:38 <jrandom> exactement, Complication :) 15:38 <jrandom> legion : on ne le contourne pas 15:38 <jrandom> (restricted routes) 15:38 <+Complication> Eh bien, n'y a‑t‑il pas un certain nombre d'applis utiles, en dehors des programmes de partage de fichiers, qui utilisent aussi des paquets UDP plus gros que les paquets DNS ? 15:39 <+legion> :( ça n'a pas l'air bon 15:39 <+Complication> De taille similaire à la plus petite taille de paquet qu'I2P utilise ? 15:39 <jrandom> eh legion, ce n'est pas un problème 15:39 <jrandom> Complication : des protocoles de streaming 15:39 <+Complication> On ne peut jamais bloquer l'UDP directement sans estropier le DNS. 15:39 <+Complication> On peut limiter la taille des paquets. 15:40 <+legion> ok, ça sonnait comme si ça pouvait l'être 15:40 <+Complication> VoIP ? 15:40 <jrandom> ce serait un problème si c'était généralisé — si la communauté Internet en général interdisait l'udp 15:40 <+Complication> Hmm, la VoIP utilise de gros ou de petits paquets ? 15:40 <jrandom> mais si ce ne sont que quelques FAI, on peut les traiter comme des restricted routes 15:40 <+Complication> Ou tu voulais dire plutôt... du spreaming vidéo ? 15:40 <+legion> Je penserais que ça utilise un mélange des deux 15:41 <jrandom> les deux, Complication, RTSP fonctionne sur UDP, et Real fonctionne sur RTSP si je me souviens bien 15:41 <+Complication> s/p/s 15:42 <+legion> Alors, on passe au point suivant ? 15:42 <+Complication> cat /etc/services | grep -c udp 15:42 <+Complication> 227 15:43 <jrandom> Je ne suis toujours pas sûr qu'on abandonnera tcp dans 0.6.1.7, mais probablement. 15:43 <jrandom> d'accord, quelqu'un a autre chose sur le 1) ? si non, passons au 2) Syndie 15:43 <+Complication> Autrement dit, il y a au moins 227 applis (certaines peut‑être obsolètes ou locales) qui utilisent l'UDP 15:44 <jrandom> bah, c'est l'intarweb. tout ce dont tu as besoin, c'est d'un accès HTTP via un proxy 15:44 <jrandom> Je n'ai pas grand‑chose à ajouter au 2) au‑delà de ce qu'il y a dans le mail (et sur Syndie) 15:44 <+legion> Je suis convaincu, oui, supprimez‑le. :) 15:44 <jrandom> quelqu'un a quelque chose à propos de Syndie à soulever ? 15:45 <+legion> Je n'ai rien à dire sur le 2) non plus. 15:45 * Complication est en train de lire « how Syndie works » 15:46 <+Complication> Un petit effet d'interface me surprend à chaque fois. :D 15:46 <+Complication> Quand j'ouvre un fil de messages, ça me surprend toujours que le message actif se déplace pour devenir le premier de la liste. :P 15:47 <+Complication> Mais vous pouvez probablement ignorer ça sans risque. Je suis juste très pointilleux et une créature d'habitude. :P 15:47 <@cervantes> le modèle de fil de discussion est quelque chose qui est longuement discuté 15:47 <@cervantes> ;-) 15:47 <+Complication> Je m'y ferai. :) 15:48 <+Complication> cervantes : dans Syndie ? Je dois trouver ce fil. :) 15:48 <@cervantes> Je n'aime pas ça non plus — mais ça pourrait bien changer 15:48 <jrandom> oui, c'est un peu bizarre je suppose 15:48 <+legion> ouais 15:48 <@cervantes> « subject: syndie threading » 15:49 <+Complication> En plus, si le message développé était le plus bas, il devrait de toute façon bouger. 15:49 <+Complication> Sinon il resterait coincé là. 15:50 <jrandom> eh bien, la nav en bas affiche 10 *threads* à la fois, pas 10 messages. donc il pourrait développer le thread du bas 15:50 * cervantes teste en ce moment différentes implémentations de styles d'interface pour l'affichage en fils 15:51 <jrandom> nickel 15:51 <jrandom> oui, idéalement on pourra les changer via le CSS, ou sinon côté serveur 15:52 <@cervantes> ou plutôt « threading navigation styles » 15:53 <@cervantes> hmm mes tests utilisent par défaut des listes non ordonnées HTML imbriquées 15:53 <@cervantes> tu peux superposer autant de CSS et de JavaScript que nécessaire ou souhaité 15:53 <jrandom> une estimation de quand on pourra voir des maquettes ? 15:53 <@cervantes> (cependant ce n'est qu'une preuve de concept, pas une vraie implémentation d'interface) 15:54 <@cervantes> Je fais la plupart de mon code pendant les réunions I2P ;-) 15:54 <jrandom> hein 15:54 <@cervantes> peut‑être que la première maquette sera prête ce soir 15:54 * jrandom programme des réunions quotidiennes 15:54 <jrandom> nickel 15:54 <@cervantes> zut :) 15:55 <jrandom> ok, quelqu'un a autre chose pour 2) Syndie ? 15:55 <jrandom> sinon, passons à 3) I2P Rufus 0.0.4 15:56 <jrandom> Je n'ai pas grand‑chose à ajouter au‑delà de ce qu'il y a dans le mail - Rawn/defnax, vous êtes là ? 15:56 <+legion> alors, à quel point 0.0.4 est bon ? Quels problèmes restent, s'il y en a ? 15:57 * jrandom n'en a aucune idée 15:58 <+legion> Peut‑être qu'un de ses utilisateurs peut répondre. Ça semble bon et stable ? 15:58 <jrandom> ok, on dirait que Rawn et defnax sont absents en ce moment. si quelqu'un a des questions/commentaires/inquiétudes concernant I2P Rufus, passez sur le forum et postez‑les 15:58 <+legion> zut, on dirait qu'il va falloir. 15:59 <+legion> on passe au 4) ? 15:59 <jrandom> oui, on dirait. ok, 4) ??? 15:59 <+Complication> Je n'ai pas essayé I2P Rufus, malheureusement. 16:00 <jrandom> quelqu'un a autre chose à soulever ? 16:00 <jrandom> (allez, il faut faire durer pour que cervantes puisse encore bosser un peu !) 16:00 <+legion> ouais, quel genre de choses intéressantes arrivent bientôt ? 16:00 <+bar> y a‑t‑il un endroit où je pourrais lire plus à propos des « restricted routes » ? 16:00 <+bar> (j'ai *cherché*) 16:01 <+legion> Peut‑être qu'on pourrait même discuter d'i2phex ? 16:01 <jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD 16:01 * cervantes place sa souris au‑dessus du bouton de fermeture 16:01 <jrandom> euh, #future.restricted 16:02 <jrandom> ainsi que les pages how_* et todo 16:02 <jrandom> (sur le web) 16:02 <+Complication> Hé, I2P semble avoir sauté une build :D 16:02 <+Complication> :D 16:02 <+bar> merci 16:02 <+Complication> - public final static long BUILD = 1; 16:02 <+Complication> + public final static long BUILD = 3; 16:03 <jrandom> legion : un peu de hacking sur le netDb, des modifs de performance, des restricted routes, des améliorations du streaming, des améliorations d'eepproxy, des améliorations de tunnel, etc. plein de choses, mais rien de prêt pour l'instant 16:03 <+legion> hein, étrange 16:03 <jrandom> quelque chose à soulever à propos d'i2phex, legion ? 16:03 <jrandom> Complication : oui, c'était voulu. J'ai oublié de l'augmenter pour BUILD = 2 16:03 <+Complication> (ce n'est pas que ça change quoi que ce soit, je me demandais juste si j'avais déjà vu ce cas rare :) 16:04 <+legion> super, ça a l'air génial, merci ! 16:04 <jrandom> oh, ça me rappelle... ce serait cool si quelqu'un voulait se pencher sur une refonte de notre page web 16:05 * jrandom n'a pas envie d'y penser, mais il faudra bien le faire tôt ou tard 16:05 <+legion> oui, il y a 16:05 <+legion> est‑ce que ça vaudrait la peine de mettre à jour i2phex à ce stade vers le dernier code CVS de phex ? 16:06 <+Complication> Pas sûr, je n'ai pas eu de nouvelles de Redzara récemment 16:06 <jrandom> la dernière fois, redzara attendait les mises à jour de gregorz pour phex 16:06 <jrandom> (pour qu'on puisse avoir une mise à jour/extension assez propre) 16:08 <+legion> hein, alors pourquoi avoir i2phex ? 16:08 <+Complication> Au cas où ? 16:08 <jrandom> hmm ? 16:08 <jrandom> i2phex est une extension de phex 16:08 <+legion> On dirait qu'ils voulaient qu'il n'y ait que phex avec une extension i2p 16:09 <jrandom> extension, c'est‑à‑dire une modification d'un très petit nombre d'éléments 16:09 <jrandom> euh, s/bits/components/. ainsi on peut facilement mettre à jour le code quand les devs phex corrigent des choses 16:10 <+legion> si c'est le cas, ça ne devrait pas me prendre beaucoup de travail pour le mettre à jour vers le dernier code CVS, même si je sais que ça le fera. 16:10 <jrandom> la dernière chose que j'ai entendue sur le forum, c'est que le plan est d'avoir I2Phex et Phex comme applications séparées, mais elles partageraient la majorité du code 16:10 <jrandom> oui, legion, ce serait génial, mais la dernière fois, Gregor n'avait pas encore fini les modifications de Phex 16:11 <jrandom> (ce que redzara attendait) 16:11 <+legion> ah je vois 16:11 <jrandom> donc, l'alternative est soit d'aider Gregor, soit de continuer à modifier la base de code I2Phex existante 16:12 <+legion> alors si je n'attends pas et que je mets simplement i2phex à jour avec le nouveau code, il n'y aurait plus besoin que redzara continue 16:12 <jrandom> eh bien, pas vraiment. 16:12 <jrandom> mettre à jour I2Phex vers le code Phex actuel serait super, oui 16:13 <jrandom> mais dès que les développeurs Phex mettront à jour leur code Phex, on sera de nouveau désynchronisés 16:13 <+legion> ok, je m'y mettrai probablement ce soir ou d'ici un ou deux jours. 16:13 <jrandom> nickel 16:13 <+legion> Ça va. 16:14 <+legion> En fait, je ne cherche pas à ce qu'i2phex reste synchronisé avec le code de phex, c'est juste qu'on dirait que le CVS contient des correctifs dont i2phex pourrait certainement bénéficier. 16:15 <+legion> Je cherche aussi à supprimer tout code et toutes fonctionnalités de phex dont i2phex n'a pas besoin. 16:15 <jrandom> cool 16:16 <+legion> Quant aux nouvelles fonctionnalités et à la correction de ce qui ne fonctionne toujours pas comme les files d'attente d'upload... Eh bien, j'ai déjà regardé pour faire fonctionner les webcaches, mais il me reste beaucoup à faire. 16:17 <jrandom> OK. oui, phex avait un support gwebcache fonctionnel, mais sirup l'a désactivé, car ce n'était pas nécessaire au début 16:17 <+legion> Je prévois d'ajouter jeti à i2phex à terme. 16:17 <jrandom> chouette 16:18 * jrandom n'a jamais utilisé jeti, et j'espère que ça restera un composant optionnel, mais supporter plus de choses, c'est cool 16:18 <+legion> Oui, ce sera facultatif, les utilisateurs pourront télécharger un jeti2phex ;) 16:19 <jrandom> OK 16:19 <+legion> Il y a encore beaucoup à faire avec i2phex, même s'il fonctionne très bien en l'état. 16:20 <+legion> Jusqu'ici, garder un client connecté, qui tourne 24/7, est possible et facile. 16:21 <jrandom> oui, j'ai eu de bons résultats avec... « en sauvegardant mes enregistrements sous licence » 16:21 <+legion> hein :) 16:22 <jrandom> ok, quelqu'un a autre chose pour la réunion ? 16:23 * cervantes amène le gong chinois 16:23 <+legion> On dirait que j'oublie quelque chose... hmm 16:24 <+legion> Ah oui, des idées sur la façon de réduire la quantité de mémoire que i2p et i2phex consomment ? 16:25 <+Complication> Eh bien, le transport TCP prend un peu 16:25 <jrandom> on pourrait faire tourner les deux dans la même JVM 16:25 <+Complication> Si ça part, ça libérera un peu 16:26 <@cervantes> retire quelques barrettes de RAM de ta machine 16:26 <cat-a-puss> anyone with any experence with javolution know if it would help? http://javolution.org/ 16:26 <jrandom> (clients.config dans le répertoire d'installation i2p définit la classe principale et les arguments pour lancer les clients) 16:26 <+legion> Donc si on faisait tourner les deux dans la même JVM et que tcp disparaît, pourrait‑on descendre sous 50MB ? 16:27 <jrandom> aucune idée, legion. ça dépend aussi de ce que tu entends par 50MB. RSS/VSS/etc 16:27 <jrandom> je ne recommanderais vraiment pas de faire tourner les deux dans une seule JVM, sauf si tu gardes les deux en marche tout le temps, puisque arrêter l'un tuerait l'autre 16:27 <@cervantes> legion : limiter la bande passante et plafonner les participants pourrait aussi aider 16:27 <jrandom> oui, ce que cervantes a dit 16:28 <cat-a-puss> il me semble que si nous savons exactement combien d'objets d'un certain type nous sommes susceptibles d'utiliser au final, cela aiderait à éviter une allocation JVM trop zélée 16:28 <+Complication> Oui, ça fait ces différentes allocations, auxquelles je n'ai jamais vraiment réussi à donner du sens 16:28 <jrandom> oui, on fait un peu de ça, cat-a-puss (voir net.i2p.util.ByteCache) 16:29 <+Complication> (mais comme dit, Java est très nouveau pour moi) 16:29 <jrandom> J'ai déjà jeté un œil à javolution, mais il semble avoir beaucoup progressé. je vais y regarder à nouveau 16:30 <cat-a-puss> jrandom : je connais des gens à mon boulot qui l'utilisent et en sont contents, même s'ils ne se soucient pas de l'allocation mémoire 16:31 <jrandom> eh bien, ça n'économiserait pas vraiment de mémoire, mais ça aiderait à réduire l'activité du GC (garbage collector) 16:31 <+legion> Personnellement, l'allocation mémoire m'importe peu, mais beaucoup de gens s'en soucient. 16:31 <jrandom> oh, et c'est aussi sous licence BSD 16:31 <cat-a-puss> exact 16:31 <jrandom> legion : l'allocation mémoire implique des performances 16:32 <+legion> euh, ah, la consommation mémoire alors 16:33 <+legion> Beaucoup de gens sont très contents d'utorrent à cause de sa très petite empreinte mémoire. 16:33 <jrandom> ah, oh, oui. on pourra l'optimiser plus tard, mais puisque i2p tourne dans les tailles par défaut de la JVM, je ne suis pas trop inquiet (on a beaucoup de marge pour ajuster) 16:34 <jrandom> ok, quelqu'un a encore quelque chose pour la réunion ? 16:35 <+legion> non, pour moi c'est bon... 16:37 * jrandom se prépare 16:37 * jrandom *baf* ferme la réunion