Réunion des développeurs I2P - 28 février 2006

15:11 <jrandom> 0) salut 15:11 <jrandom> 1) État du réseau et 0.6.1.12 15:11 <jrandom> 2) Feuille de route vers 0.6.2 15:12 <jrandom> 3) Miniprojets 15:12 <jrandom> 4) ??? 15:12 <jrandom> 0) salut 15:12 * Complication lit rapidement les notes 15:12 * jrandom fait signe 15:12 <jrandom> notes d’état hebdomadaires publiées sur http://dev.i2p.net/pipermail/i2p/2006-February/001266.html 15:12 <jrandom> (et voilà que je postais les notes plus de 15 minutes avant la réunion ! ;) 15:13 <jrandom> ok pendant que vous lisez ces morceaux ô combien excitants, passons à 1) État du réseau et 0.6.1.12 15:14 <jrandom> comme mentionné, les objectifs principaux des versions 0.6.1.10-0.6.1.12 semblent avoir été atteints, en traitant le changement cryptographique pour la création de tunnel et en améliorant substantiellement la fiabilité de la création 15:16 <jrandom> les à-coups vus en 0.6.1.10 ont disparu, et la stabilité IRC semble de nouveau très bonne 15:16 <jrandom> quelqu’un a autre chose à ajouter pour 1) État du réseau et 0.6.1.12, ou on passe à 2) Feuille de route vers 0.6.2 ? 15:17 <+Complication> État du réseau ici : plus de retours sous 20 KB/s :) 15:18 <jrandom> cool, oui 0.6.1.12 a corrigé un gros bug dans 0.6.1.11 où la bande passante disponible n’était pas exploitée. Il devrait désormais mieux utiliser les ressources disponibles 15:20 <jrandom> ok, passons à 2) 15:20 <jrandom> comme mentionné, quelques points doivent être réglés avant que le dernier changement fonctionnel ne soit mis en place pour 0.6.2, mais nous progressons sur ce front 15:20 <nymisis> l’état du réseau est bon :) 15:22 <jrandom> ok. il y aura plus d’infos disponibles sur les détails des nouvelles stratégies d’ordonnancement des pairs avant leur sortie, mais l’essentiel devrait être clair d’après leur brève mention dans les notes 15:23 <jrandom> quelqu’un a des questions/commentaires/inquiétudes concernant 2) Feuille de route vers 0.6.2 ? 15:23 <postman> jrandom : des réseaux de test cette fois ? 15:24 <postman> (besoin de routers, de participants pour tester des trucs) 15:24 <postman> ? 15:24 <+Complication> L’essence du sujet semblait assez simple : limiter l’occasion pour un adversaire de collecter des données statistiques diverses 15:25 <+Complication> Ça semble être une fonctionnalité assez souhaitable 15:25 <jrandom> postman : les nouveautés devraient fonctionner de manière transparente sur le réseau en production en utilisant uniquement des infos locales, donc pas besoin d’un réseau séparé pour tester 15:25 <jrandom> oui, exactement Complication 15:26 <postman> ok 15:26 <postman> jrandom : assez audacieux pour annoncer une date estimée (ETA) pour 0.6.2 ? :) 15:27 <blubb> 1er avril 15:27 <jrandom> eh bien, puisque nous sommes fin février, je dirais mars ou avril 15:27 <postman> hehe 15:27 <jrandom> blubb : nous avons déjà une porte dérobée MI6 prévue pour ce moment-là ;) 15:29 <@cervantes> plutôt une chatière du MI6 15:29 <@cervantes> (restrictions budgétaires) 15:29 <postman> dans la maison des éléphants 15:30 <nymisis> C’est SIS, pas MI6, si tu veux être précis. :) 15:30 <jrandom> bon, appelons-les « Eux » ;) 15:31 <jrandom> ok, autre chose pour 2) ? 15:31 <jrandom> sinon, passons à 3) miniprojets 15:31 <@cervantes> désolé « the firm » 15:34 <jrandom> ok, je voulais juste signaler quelques trucs sympas qui seraient 1) simples à faire et 2) vraiment utiles 15:34 <+Complication> Côté miniprojets, je ne sais pas si ma réponse Syndie est passée ou non, mais je me demandais si je pouvais en prendre un. 15:34 <+Complication> Je ne sais pas encore lequel. Je pratique un peu plus le Java en ce moment (je fais un micro-projet :D) juste pour être plus sûr que lorsque j’essaierai, je pourrai en gérer un 15:35 <DeltaQ> hmm si j’augmente la bw sur la console, les changements sont-ils immédiats ou faut-il redémarrer ? 15:35 <+Complication> Quand j’aurai fini le « micro-projet » (en supposant bien sûr que le tableau n’ait pas été vidé d’ici là), j’essaierai d’en choisir un 15:35 <jrandom> w3wt, super Complication 15:36 <jrandom> DeltaQ : immédiatement 15:36 <@cervantes> est-ce que 1) l’ordonnanceur Syndie n’a pas un lien avec 4) Gestionnaire de téléchargement / ordonnanceur eepget 15:36 <+Complication> DeltaQ : ça prend effet presque instantanément (sur les périodes sur lesquelles la bande passante est moyennée) 15:37 <@cervantes> il me semble qu’un gestionnaire d’envoi et de téléchargement plus général répondrait aux deux besoins 15:37 <jrandom> cervantes : hmm, pas forcément. 1) est assez ciblé, et inclut aussi des pushes, tandis que 4) est plutôt générique 15:37 <+Complication> cervantes : ça pourrait, oui 15:37 <jrandom> mais oui, le moteur derrière les deux est EepGet 15:37 <jrandom> (eepget fait les transferts HTTP de Syndie, programmatiquement) 15:38 <DeltaQ> la moyenne ne semble pas aller au-dessus de 13kb/s 15:38 <DeltaQ> j’ai mis 64kb/s avec 192 burst down 15:38 <DeltaQ> 32/64 up 15:38 <@cervantes> donc un eepget générique pour pousser et tirer avec une API de planification et de gestion... 15:39 <@cervantes> malgré tout, à ce stade, ça cesse probablement d’être un miniprojet 15:39 <+Complication> DeltaQ : la moyenne dépend aussi de la charge générée par tes tunnels clients (et les tunnels participants des autres pairs) 15:39 <+Complication> désolé, s/moyenne/bande passante réelle 15:39 <jrandom> cervantes : oui, mais il y a cependant une logique substantielle dans les trucs de Syndie. 15:40 <DeltaQ> heh ça a fini par monter 15:40 <DeltaQ> 1s: 30.82/29.33KBps 15:40 <DeltaQ> je suppose que je devais augmenter la bw ul 15:40 <jrandom> DeltaQ : la moyenne sera aussi affectée par la manière dont les autres te perçoivent, ce qui dépend de tes actions, pas d’un débit annoncé, donc ça prendra un peu 15:40 <+Complication> DeltaQ : pour le trafic de transit (tunnels participants), ce qui entre doit aussi sortir 15:41 <+Complication> DeltaQ : donc des débits ul/dl très différents étranglent le trafic participant au plus faible des deux 15:42 <+Complication> DeltaQ : aussi, le trafic participant dépend de la façon dont les autres nœuds « perçoivent » la capacité de routage de ton nœud 15:42 <DeltaQ> oki 15:43 <+Complication> S’ils pensent qu’il peut router correctement, ils demanderont plus souvent 15:43 <jrandom> ok, s’il n’y a rien d’autre sur 3) miniprojets, passons à 4) ??? 15:43 <jrandom> quelqu’un a autre chose à apporter pour la réunion ? 15:43 <DeltaQ> eh bien je suis derrière un router mais j’ai mappé le port 8887 sur ce PC 15:43 <+Complication> S’il est nouveau, ou s’il vient seulement d’augmenter en capacité, ils sont un peu timides 15:44 <DeltaQ> oh désolé je ne voulais pas interrompre une réunion ^^ 15:44 <+Complication> Quelqu’un a demandé l’autre jour, à propos d’attaques possibles basées sur le décalage de l’horloge. Je crois avoir vu ta réponse sur la partie tunneling (le message de création ne contient que la période de validité du tunnel, pas l’heure du point de vue de son créateur)... 15:44 <@cervantes> (merci pour la mention dans les notes d’état) ;-)_ 15:46 <+Complication> Donc je me suis dit, en fait, demander... quels points, s’il y en a, dans la messagerie I2P, pourraient contenir l’heure du point de vue de l’expéditeur ? 15:47 <+Complication> Je n’ai pas réussi à me remettre à jour là-dessus, donc je suis un peu paumé 15:47 <jrandom> Complication : rien ne dit explicitement « I think it is now $time », mais avec suffisamment de trafic et d’analyse de timing, on pourrait probablement réduire l’incertitude de façon substantielle 15:48 <jrandom> nous quantisons les temps sur une grande période, mais pas aussi grande que notre décalage d’horloge max, donc il y a une marge là 15:49 <+Complication> Penses-tu qu’il y aurait, au final, un bénéfice à tirer d’un client NTP plus optimisé ? 15:49 <+Complication> Qui pourrait plus facilement maintenir de petits décalages ? 15:50 <jrandom> eh bien, depuis que le client sntp a été introduit dans i2p, il s’est amélioré encore et encore, si bien que maintenant on ne voit plus les variations d’avant 15:51 <jrandom> on pourrait peut-être réduire la limite minimale de décalage de 10s à 2 ou 3s, voire moins 15:51 <jrandom> alternativement, on pourrait lui permettre de regarder aussi les décalages d’horloge ssu pour éviter des décalages inutiles 15:52 <+Complication> Ou alors, serait-il possible de limiter davantage toute possibilité de deviner la valeur d’horloge possible d’un autre pair ? 15:53 * Complication ne sait pas laquelle serait la plus pratique, il propose juste des possibilités au hasard :D 15:53 <jrandom> non, nous connaissons le décalage d’horloge des pairs connectés directement 15:55 <Magii> y a-t-il un moyen de savoir si la mise à jour s’est effectuée avec succès ? 15:55 <+Complication> Ah, donc le protocole de session dépend vraiment de cette info.. 15:55 <tethra> regarde ton numéro de version 15:55 <+Complication> Magii : il devrait écrire un CRIT du genre « update verified, restarting to install » dans les logs 15:55 <tethra> :/ 15:55 <+Complication> Ensuite, il devrait compter les minutes jusqu’à un redémarrage en douceur 15:56 <+Complication> Et enfin redémarrer 15:57 <+Complication> Oh, à propos : le client NTP interne connaît-il un concept comme le taux de dérive de l’horloge ? 15:58 <jrandom> oui, le numéro de version dans le coin en haut à gauche de http://localhost:7657/index.jsp devrait être un indice :) 15:58 <jrandom> Complication : non, il ne garantit pas des ticks d’horloge séquentiels 15:59 <jrandom> s/séquentiels/ordonnés/ 15:59 <+Complication> Ni développer une info comme « notre horloge système est 0.00345 fois plus rapide que nécessaire » ? 16:00 <jrandom> ah, non, bien qu’ajouter ça à net.i2p.util.Clock ne serait pas très difficile (tu veux un miniprojet ? :) 16:00 <+Complication> J’y pensais justement 16:01 <+Complication> Je crois que j’y réfléchis un peu plus maintenant :) 16:01 <+Complication> D’abord d’autres miniprojets, ceci dit :) 16:02 <jrandom> ok, quelqu’un a autre chose pour la réunion ? 16:03 <nymisis> Des muffins ? 16:04 <jrandom> non, des pancakes 16:04 <jrandom> (mmMMmm des pancakes) 16:04 <jrandom> en parlant de ça 16:04 * jrandom s’apprête 16:04 <nymisis> Oh, mince, bon point. 16:04 * jrandom *baf* clôt la réunion