Réunion des développeurs d'I2P - 25 janvier 2005

13:50 <jrandom> 0) salut 13:50 <jrandom> 1) état 0.5 13:50 <jrandom> 2) sam.net 13:50 <jrandom> 3) avancées gcj 13:50 <jrandom> 4) udp 13:50 <jrandom> 5) ??? 13:50 <jrandom> 0) salut 13:50 * jrandom fait un signe de la main en retard 13:51 <jrandom> notes d'état hebdomadaires publiées jusqu'à http://dev.i2p.net/pipermail/i2p/2005-January/000560.html 13:51 <+postman> salut 13:51 * brachtus renvoie le signe de la main 13:52 * cervantes brandit un mot de retard pour retard 13:52 <jrandom> ouais ouais, blâmez le code qui m'aspire 13:52 <jrandom> ok, on passe à 1) état 0.5 13:53 <jrandom> beaucoup de progrès depuis la semaine dernière - tous les problèmes compliqués que nous avions avec la nouvelle crypto sont résolus sans trop de difficultés 13:54 <jrandom> la dernière version http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD sera très probablement celle que nous déploierons en 0.5 et au-delà, à moins/jusqu’à ce que des gens y trouvent des problèmes 13:55 <jrandom> pas sûr d'avoir autre chose à ajouter au-delà de ce qui est dans l'e-mail 13:55 <jrandom> quelqu'un a des questions/inquiétudes ? 13:56 <Ragnarok> à quoi vont ressembler les performances ? 13:56 <jrandom2p> (pas moi) 13:56 <jrandom> Ragnarok : les performances du tunnel devraient être bien meilleures 13:56 <frosk> une surcharge significative par rapport à ce qu'on a aujourd'hui ? 13:57 <jrandom> frosk : parfois 13:57 <jrandom> frosk : quand on peut fusionner des messages dans un tunnel, la surcharge sera minimale 13:58 <jrandom> cependant, quand on ne peut pas les fusionner ou quand ce n'est pas efficace, il peut y avoir un gaspillage non négligeable 13:58 <frosk> je vois 13:59 <jrandom> d'un autre côté, on supprime certaines absurdités de notre I2NP actuel (où nous préfixons actuellement un SHA256 de 32 octets avant chaque message I2NP, même ceux à l'intérieur des garlic messages (messages « garlic »), etc.) 13:59 <jrandom> la fragmentation et la taille fixe seront un point à régler, mais on a beaucoup de marge pour le faire 14:01 <jrandom> ok, autre chose sur 0.5 ? 14:02 <jrandom> sinon, on passe à 2) sam.net 14:02 <jrandom> smeghead a porté la lib cliente sam Java vers .NET (youpi !) 14:02 <jrandom> smeghead : tu veux nous faire un petit résumé ? 14:03 <smeghead> bien sûr 14:03 <smeghead> j'écris des tests pour ça, je devrais les mettre dans le CVS dans les prochains jours 14:04 <smeghead> devrait fonctionner avec .net/mono/portable.net 14:04 <smeghead> et C# et VB.NET 14:05 <frosk> (et toutes les autres langues qui fonctionnent avec .NET je suppose) 14:05 <cervantes> (beurk) 14:05 <smeghead> l'interface est d'une simplicité enfantine 14:05 <smeghead> il suffit d'enregistrer des méthodes d'écouteur avec SamReader, ou de sous-classer SamBaseEventHandler et de surcharger les méthodes selon les besoins 14:05 <smeghead> oui, je vise une compatibilité totale CLR 14:06 <jrandom> mortel 14:06 <cervantes> cool... smeg.net ;-) 14:06 <frosk> chouette 14:06 <smeghead> pas grand-chose de plus à dire 14:06 <+protokol> CLR ? 14:06 <smeghead> Common Language Runtime 14:06 <smeghead> l'équivalent .NET du JRE 14:07 <+protokol> JRE ? 14:07 <+protokol> je plaisante 14:07 <jrandom> !thwap protokol 14:07 <Ragnarok> jrandom : comment se comporte le pont sam ces jours-ci ? tous les problèmes liés à BT ont été résolus ? 14:08 <Tracker> J'en doute, i2p-bt peut même rendre fou mon AMD64 3000, côté CPU... 14:08 <jrandom> Ragnarok : je n'y ai pas touché dernièrement. Il y a toujours le problème de choke en suspens que polecat a soulevé, mais où le pont i2p-bt<-->sam décroche, je ne suis pas sûr 14:09 <jrandom> hmm, les connexions échouées forceront du ElGamal complet au lieu de l'AES 14:10 <Ragnarok> ok 14:10 <jrandom> on devrait pouvoir réduire une partie de ça après la 0.5, mais seulement partiellement 14:12 <Tracker> Ok, l'I2P sera bon pour des trackers anonymes mais pas pour des clients anonymes. Essayez d'imaginer ce qui se passe sur un torrent vraiment populaire avec environ 1000 seeders et leechers. 14:12 <jrandom> ok, le truc sam.net a l'air cool, merci encore smeghead. j'attends avec impatience les tests unitaires et peut-être une appli de démo :) 14:12 <ant> <Evil-Brotten> bonjour tout le monde 14:12 <smeghead> une appli de démo, oui je ferai ça aussi 14:13 <smeghead> j'ai d'ailleurs porté la tienne 14:13 <jrandom> Tracker : i2p peut très bien gérer des clients anonymes, on doit juste comprendre ce qui ne va pas avec le pont i2p-bt<-->sam pour réduire les ElG complets 14:13 <smeghead> elles sont juste truffées de bugs pour le moment 14:13 <ant> <Evil-Brotten> cerf ? 14:13 <jrandom> salut Evil-Brotten 14:13 <ant> <Evil-Brotten> bonjour 14:14 <jrandom> réunion de dev hebdo en cours, n'hésitez pas à rester. deer est une passerelle vers i2p/iip 14:14 <ant> <Evil-Brotten> es-tu un expert i2p ? 14:14 <ant> <Evil-Brotten> :P 14:14 <ant> <Evil-Brotten> ah, ok 14:14 <ant> <cervantes> Evil-Brotten : tu peux parler dans #i2p-chat si tu veux pendant que la réunion se déroule 14:14 <jrandom> Tracker : on a beaucoup à faire avant de gérer des torrents avec ~1k de participants 14:14 <ant> <Evil-Brotten> j'essayais juste d'installer votre programme, mais j'ai quelques problèmes 14:14 <ant> <Evil-Brotten> cool, je demanderai là-bas 14:15 <jrandom> mortel smeghead 14:15 <Tracker> jrandom : j'espère, le BT non anonyme ne survivra pas beaucoup plus longtemps... 14:15 <frosk> n'importe quoi 14:15 <jrandom> "mais exeem est anonyme !@#" </snark> 14:15 <Tracker> jrandom : mais c'est une autre histoire 14:15 <ant> <MikeW> quoi ? 14:15 <ant> <MikeW> qui a dit qu'exeem est anonyme ? 14:16 <jrandom> mikew : juste l'occasionnel fanboy 14:16 <jrandom> Tracker : après 0.5 on aura beaucoup de boulot pour amener les performances au niveau nécessaire 14:16 * DrWoo note que « les gens » sont de sacrés abrutis (parfois) 14:16 <Tracker> jrandom : ouais, installer des logiciels espions/adwares n'est vraiment pas ce que je ferais ;) 14:16 <jrandom> heh 14:17 <smeghead> j'aime bien les gens, moi 14:17 <smeghead> ils sont bons sur des toasts 14:17 <jrandom> *croque* 14:17 <smeghead> certains ont juste besoin d'un peu plus de beurre que d'autres 14:18 <jrandom> ok, je pense que c'est tout pour 2) sam.net (à moins que quelqu'un ait autre chose à ajouter ?) 14:18 <jrandom> sinon, on passe à 3) avancées gcj 14:19 <ant> <dm> sam.net ?? 14:19 <ant> <dm> ça marche ?/ 14:19 <jrandom> j'ai lu dans mon backlog que smeghead a bien avancé - tu veux nous faire une mise à jour sur l'état ? 14:19 <smeghead> oui 14:20 <ant> <dm> cooooooool 14:20 <smeghead> j'ai modifié quelques classes pour que le router compile avec gcj 3.4.3 14:20 <smeghead> je soumettrai le patch après la réunion 14:20 <smeghead> après ça, moi et tous ceux qui voudront aider pourrons nous mettre à le faire tourner 14:21 <jrandom> sympa 14:21 * frosk décore smeghead avec la médaille d'Employé de la semaine pour sam.net ET le travail sur gcj 14:21 <jrandom> ouais, v. cool 14:21 <smeghead> :) 14:22 <Tracker> frosk : mieux vaut utilisateur du forum de la semaine ;) 14:22 <frosk> je n'ai pas lu le forum cette semaine, désolé :) 14:22 <cervantes> la gloire du canard n'a pas encore expiré ;-) 14:23 * jrandom a très hâte de voir i2p compatible gcj 14:24 <jrandom> (et il y a toujours la prime dessus, donc les gens devraient contacter smeghead et s'impliquer ;) 14:24 <smeghead> oui, ça augmenterait significativement la portabilité d'i2p 14:24 <cervantes> on pourra peut-être extraire quelque chose qui ressemble à des performances du router :P 14:24 <ant> <dm> ma série de 32 semaines en tant que travailleur I2P le plus acharné se termine enfin... 14:25 <jrandom> je ne m'attends pas à ce que gcj améliore réellement les performances ou réduise l'empreinte mémoire, mais il fonctionnera sur des OS pour lesquels Sun ne publie pas de JVM et sur lesquels Kaffe est b0rked 14:25 <jrandom> (mais si je me trompe, tant mieux !) 14:25 <frosk> tout ce qui peut faire tourner i2p mieux sans logiciel propriétaire est une Bonne Chose 14:26 <jrandom> d'accord. Prendre en charge à la fois Kaffe et gcj serait une Bonne Chose 14:27 <jrandom> ok, autre chose sur 3) avancées gcj, ou on passe à la suite ? 14:27 <smeghead> l'installation serait plus simple aussi 14:27 <Teal`c> gcj a-t-il fonctionné pour autre chose que des exemples 'hello world' ? 14:27 <Ragnarok> quelqu'un a construit Eclipse avec 14:27 <smeghead> Teal`c : oui, je l'ai utilisé pour des .exe sous MinGW auparavant en fait 14:27 <smeghead> oui, Eclipse tournait sous gcj avec Red Hat il n'y a pas très longtemps 14:28 <jrandom> avoir l'option de distribuer des exécutables compilés avec gcj, des installeurs .jar simples, et des .jar+JVM embarqués sera définitivement une Bonne Chose 14:29 <jrandom> ok, on passe à 4) udp 14:30 <jrandom> il y a eu un message récent sur le forum sur lequel je voulais attirer l'attention, qui demande (et répond) pourquoi l'udp est important 14:30 <Tracker> Beurk 14:30 <jrandom> (voir http://forum.i2p.net/viewtopic.php?t=280 et commentez si vous avez des suggestions/questions/inquiétudes) 14:31 <jrandom> beurk Tracker ? 14:32 <jrandom> bref, mule et detonate avancent tous les deux côté udp. detonate/mule : vous avez des nouvelles à partager ? 14:32 <Tracker> L'UPD est diabolique ici, alors qu'il marche bien à l'intérieur des frontières du pays, ça devient vraiment moche quand on essaie de l'utiliser vers des destinations hors de nos pays. 14:32 <jrandom> hmm 14:32 <Tracker> Juste mon expérience de 5 ans de jeux en ligne... 14:33 <jrandom> nous devrons certainement prendre en compte la congestion et les problèmes de MTU quand ça sort sur le net 14:33 <Tracker> D'une manière ou d'une autre, les deux grands backbones ici n'aiment pas acheminer l'UPD très bien, et seulement avec une priorité très basse. 14:34 <Tracker> Ce qui veut dire des pings entre 5 et 20 secondes. 14:34 <jrandom> je serais assez surpris s'il existait un FAI qui n'autorise pas du tout l'UDP (puisqu'on utilise tous le DNS) 14:34 <Tracker> Et une forte perte de paquets 14:34 <jrandom> le contrôle de congestion est certainement important 14:35 <Tracker> Pourquoi pensez-vous que je fais tourner mon propre DNS avec cache très gros depuis des années ;) 14:35 <jrandom> heh 14:35 <jrandom> eh bien, nous aurons la solution de repli en TCP pour les gens qui ne peuvent pas utiliser l'udp pour une raison quelconque 14:36 <jrandom> mais l'UDP sera largement privilégié 14:36 <Tracker> C'est bien. 14:36 <jrandom> (c’est-à-dire que j'espère qu'il n'y aura peut-être que 10 personnes utilisant TCP sur plus d'1M de nœuds ;) 14:37 <jrandom> mais, encore une fois, ce lien du forum explique pourquoi nous devons faire ce que nous faisons, même si quelqu'un trouve une meilleure façon, je suis tout ouïe 14:37 <Tracker> Je suppose que j'en ferai partie. 14:37 <jrandom> peut-être. 14:38 <jrandom> on verra lors du déploiement de la 0.6 si c'est le cas, ou si nous pourrons contourner les problèmes de ton FAI 14:38 <jrandom> ok, autre chose sur udp ? ou on passe à 5) ??? 14:39 <jrandom> considérons que c'est fait 14:39 <jrandom> 5) ?? 14:39 <jrandom> quelqu'un a autre chose à soulever ? 14:40 <Teal`c> la pizza est arrivée ? 14:40 <Jhor> quelqu'un sait où je devrais regarder pour trouver/déboguer des problèmes dans BitTorrent ? 14:41 <jrandom> Jhor : dans i2p-bt, un bon point de départ serait probablement d'ajouter un peu de journalisation pour savoir quels messages BT sont envoyés/reçus, afin qu'on sache où ça bloque/expire/etc. 14:41 <jrandom> (en supposant que tu parles d'i2p-bt et pas d'azneti2p ?) 14:42 <Jhor> ouais, i2p-bt. quels sont les différents niveaux de spew ? 14:42 <jrandom> aucune idée, tout ce que je sais c'est --spew 1 14:42 <Jhor> Ok, je vais essayer ça 14:43 * Jhor se prépare à un cours intensif de Python 14:43 <jrandom> :) 14:44 <jrandom> ok, quelqu'un d'autre a quelque chose à discuter ? 14:44 * cervantes sort le Gong Strand 14:44 <jrandom> on est autour de la barre des 60 minutes, donc un rythme plutôt bon 14:44 <Teal`c> quand l'udp sera-t-il prêt pour le grand public ? 14:44 <jrandom> Teal`c : avril 14:44 <jrandom> c'est la 0.6, on travaille encore sur la 0.5 14:45 <Teal`c> beau boulot. 14:46 <jrandom> progrès, toujours en avant 14:46 * jrandom s'élance 14:46 * jrandom donne un *baf* au gong, clôturant la réunion