I2P Dev Meeting - May 03, 2005

14:08 <jrandom> 0) salut 14:08 <jrandom> 1) Statut du réseau 14:08 <jrandom> 2) Statut de SSU 14:08 <jrandom> 3) i2phex 14:08 <jrandom> 4) absence 14:08 <jrandom> 5) ??? 14:08 <jrandom> 0) salut 14:08 * jrandom agite la main 14:08 <jrandom> notes d'état hebdomadaires publiées avec près d'une heure d'avance @ http://dev.i2p.net/pipermail/i2p/2005-May/000738.html 14:09 * Masterboy agite la main en retour :P 14:10 <jrandom> ok, on passe à 1) Statut du réseau 14:10 <jrandom> je n'ai pas grand-chose de plus à ajouter, mais il semble que nous risquions quelques turbulences dues à l'afflux d'Azureus 14:11 <jrandom> espérons que ça tiendra suffisamment bien, on verra 14:11 <Masterboy> pas de gros problèmes pour moi et je ne me souviens pas des petits. 14:11 <jrandom> heh cool 14:11 <jrandom> quelqu'un d'autre a des questions/commentaires/inquiétudes à propos du statut actuel du réseau ? 14:11 <sirup> azureus utilise-t-il des proxys de sortie ? 14:12 <jrandom> heh j'espère que non 14:12 <jrandom> c'est probablement juste des gens qui essaient après avoir vu l'option listée 14:12 <@smeghead> la plupart se tireront d'ici une semaine environ 14:13 <Masterboy> :D 14:13 <+DrWoo> smeghead : ce n'est pas bon 14:13 <sirup> donc ils mettent deux réseaux différents sous le même capot 14:13 <+cervantes> ce n'est pas mentionné dans les notes de version d'Az 14:13 <+cervantes> bien que ce soit listé dans la section des plugins 14:14 <ant> <cat-a-puss> Il y a un lien qui le mentionne à gauche de leur page d'accueil 14:14 <jrandom> ce sera génial une fois la 0.6 sortie et que nous pourrons gérer la charge utilisateur accrue 14:14 <+DrWoo> jrandom : quel est l'état actuel pour sortir une build capable de gérer plus d'utilisateurs ? 14:14 <jrandom> oui, Azureus est actuellement notre plus grand référent vers le site web, bien plus même que les références de /. 14:15 <jrandom> DrWoo : aucune chance. 14:15 <sirup> ne te laisse pas stresser et ne sors pas la 0.6 trop tôt 14:15 * eAi fixe une limite de bande passante déraisonnable pour empêcher les gens de bidouiller ma vitesse de téléchargement 14:15 <ant> <cat-a-puss> quelle taille de réseau la .6 prendra-t-elle en charge ? 14:15 <jrandom> DrWoo : 0.6 est la solution, et ce sera prêt quand ce sera prêt :) 14:15 <+cervantes> il y a 445 résultats Google pour « i2p » et « azureus » 14:15 <jrandom> heh eAi 14:16 <+cervantes> je dois dire que j'ai été impressionné par le débit du réseau SSU de test 14:16 <Masterboy> w00t cervantes:) 14:16 <+DrWoo> jrandom : tu sais que je t'adore mais ton calendrier dérape comme la culotte d'une prostituée à 5 $ ;) 14:16 <jrandom> cat-a-puss : ça supprime notre goulet d'étranglement actuel au point que je ne vois pas clairement le prochain. j'espère que ça tiendra jusqu'à des milliers. 14:16 <+cervantes> j'ai réussi à saturer ma connexion DSL avec un simple transfert de fichier HTTP 14:17 <jrandom> tout à fait, DrWoo ;) si ça pouvait être fait plus vite, ce serait super, mais je dois déménager la semaine prochaine, donc il n'y a vraiment pas d'alternative 14:17 <sirup> cervantes : 0 sauts des deux côtés ;) 14:18 <jrandom> sirup : sûr, mais l'idée, c'est que le transport SSU a pu le gérer 14:18 <+DrWoo> jrandom : aïe, ça craint, bonne chance :) 14:18 <Teal`c__> il y a une alternative. J'appelle toad, il finira pendant que tu seras à Tahiti 14:18 <@smeghead> on monte, côté est, vers un appartement de luxe dans le cieeeeeel 14:18 <shendaras> Tu as un endroit en tête, jrandom, ou bien c'est encore en l'air où tu vas atterrir ? 14:19 <+cervantes> *muet* 14:19 <jrandom> heh 14:19 <jrandom> je pense savoir dans quel pays je vais finir. au-delà de ça, pas vraiment 14:19 <jrandom> ok, bref, revenons à l'ordre du jour 14:19 <jrandom> autre chose sur 1) Statut du réseau, ou on passe à 2) Statut de SSU ? 14:20 <Masterboy> on avance 14:20 <jrandom> considérez que c'est fait 14:21 <jrandom> ok, comme décrit dans les notes d'état et comme l'a dit cervantes il y a une minute, les choses s'annoncent prometteuses 14:22 <jrandom> cette première série de tests sur le réseau en production a attrapé quelques bugs mais a aussi aidé à mettre en évidence certains compromis en matière de bande passante, latence et compatibilité avec TCP 14:23 <Masterboy> comment peut-on rejoindre un réseau de test ? :P 14:23 <jrandom> c'est ça — les tests SSU se font sur le réseau en production 14:24 <jrandom> si vous regardez dans la netDb, vous verrez que certains pairs ont des adresses TCP et SSU, tandis que presque tout le monde n'a qu'une adresse TCP. 14:24 <jrandom> les pairs qui savent parler via SSU essaient d'abord ça, mais reviennent à TCP si le port SSU n'est pas joignable. 14:25 <jrandom> cependant, et je ne le répéterai jamais assez, SSU n'est pas prêt pour la production. ça cassera, et ça causera des problèmes, donc il ne faut pas l'utiliser sauf dans le cadre de tests explicites 14:25 <Masterboy> merci :) 14:26 <jrandom> pour l'instant, tout le monde devrait désactiver SSU, mais d'ici un jour ou deux il y aura plus d'infos sur mon blog pour la deuxième série de tests 14:27 <jrandom> ok, je pense que ça, plus le mail, couvre à peu près ce que j'avais à soulever à propos de SSU. quelqu'un a des questions/commentaires/inquiétudes ? 14:27 <Teal`c__> jrandom : peut-on utiliser SSU pendant que tu es parti ? 14:28 <jrandom> probablement, mais les gens voudront peut-être en parler avec d'autres utilisateurs pour voir si ça déconne, et si c'est le cas, désactivez-le 14:29 <shendaras> Quelle est ta nouvelle technique SACK ? =) 14:29 <jrandom> il me reste encore presque une semaine de temps de hacking, donc il y aura d'autres améliorations 14:30 <+bla> jrandom : Je me disais... Lorsqu'il y a une connexion SSU entre deux nœuds, abandonnent-ils la connexion TCP entre eux (puisque ce n'est alors pas nécessaire) ? 14:30 <jrandom> heh shendaras, c'est simplement exploiter la petite taille des messages et une fragmentation fixe pour permettre au récepteur d'envoyer des ACK/NACK explicites pour un message complet dans un champ de bits, plutôt que d'ACKer ou de NACKer chaque fragment séparément 14:31 <jrandom> bla : correct, ils n'établissent jamais de connexion TCP si SSU est disponible 14:31 <jrandom> les deux transports « enchérissent » sur chaque message envoyé, et le transport SSU est configuré pour enchérir « plus bas » que le transport TCP 14:31 <+bla> jrandom : C'est bien, mais ça veut dire que je vais devoir mettre à jour mes scripts theland.i2p :(... ;) 14:32 <jrandom> heh eh bien, ouais tant pis ;) 14:32 <jrandom> (le nouveau peers.jsp est peut-être ce que tu cherches toutefois) 14:33 <+bla> jrandom : Je vais jeter un œil. Mais je ne compte pas utiliser SSU avant qu'il ne soit prêt, ceci dit 14:33 <+cervantes> peut-être devrions-nous tous rester sur TCP pour que bla n'ait pas à coder 14:34 <jrandom> heh 14:34 <jrandom> cool bla, ouais, pas d'urgence 14:34 <+cervantes> ;) 14:34 <+bla> cervantes : ;) 14:35 <+cervantes> y aura-t-il des situations où une connexion SSU n'est pas appropriée et où une connexion TCP serait préférée ? 14:36 * Masterboy donne un petit coup à jr 14:36 <jrandom> la configuration par défaut actuelle préfère une connexion TCP établie à une connexion SSU non établie 14:36 <jrandom> (vous pouvez outrepasser cela avec un indicateur de config, je crois que c'est documenté dans le history.txt) 14:37 <@smeghead> il y a des gens qui ont affirmé que leurs FAI bloquent complètement l'UDP 14:37 <jrandom> mais en général, non, je ne vois pas pourquoi on voudrait utiliser TCP quand SSU est disponible 14:37 <+cervantes> oui je connais l'option de config... mais je veux dire, y a-t-il des circonstances où il vaudrait mieux utiliser TCP au lieu de paquets UDP 14:37 <jrandom> smeghead : il y a des gens qui ont affirmé qu'Elvis était un martien 14:38 <+cervantes> donc c'est bien juste comme repli 14:38 <jrandom> cervantes : aucune que je connaisse, tant que SSU est disponible par les deux pairs 14:39 <jrandom> peut-être comme solution de repli, même si cela soulève des problèmes de routes restreintes, puisque tous les pairs doivent pouvoir contacter tous les pairs. 14:40 <jrandom> si nous autorisons des nœuds uniquement TCP, cela signifie que tout le monde doit être joignable via TCP et UDP 14:41 <Teal`c__> :~( 14:41 <jrandom> pour cet été, nous prendrons probablement en charge les deux, mais je suis enclin à pencher vers UDP uniquement 14:41 <entroy> Salut, quelqu'un peut me dire où je peux poser une question sur la configuration d'I2P et d'Azureus ? 14:41 <jrandom> (jusqu'à la 2.0) 14:42 <jrandom> salut entroy, #i2p-chat pourra peut-être aider, ou forum.i2p.net. nous sommes en réunion de dev hebdomadaire en ce moment, mais on pourra t'aider après si tu as encore des difficultés 14:42 <+cervantes> les voilà, repoussez l'abordage :) 14:42 <jrandom> cervantes : quiconque arrive à venir sur IRC est des nôtres :) 14:42 <@smeghead> mieux vaut appeler les Minutemen 14:43 <Teal`c__> Liverpool ou Chelsea ?! 14:43 <entroy> ok, merci 14:43 <ant> <cat-a-puss> jrandom : À propos des champs de bits, si l'on suppose que la plupart des paquets seront reçus avec succès, alors les champs de bits seraient presque tous à 1. Ne serait-il pas plus efficace de lister le nombre de NACK puis de les encoder à la manière ECC. 14:43 <+cervantes> jrandom : tu en es sûr... quelqu'un a mentionné plus tôt un client mschat 14:43 <+cervantes> ;-) 14:45 <jrandom> cat-a-puss : il y a quelques options, mais quand on regarde la taille réelle des messages, c'est assez difficile à battre — les messages de tunnel, qui sont 4 fois plus fréquents que tous les autres messages, nécessiteront au *plus* deux fragments — seulement deux bits 14:45 <Teal`c__> <steve> # Apparaît comme TIKI 14:45 <jrandom> les messages de la bibliothèque de streaming entre le point de terminaison et la passerelle font seulement 4 Ko — jusqu'à 8 bits, soit 2 octets avec les champs de bits 14:45 <jrandom> c'est-à-dire, en supposant la MTU absolument la plus petite 14:46 <jrandom> avec 1492 (ou 1472, selon qui compte), on peut gérer à peu près tout dans un seul octet de champ de bits 14:46 <ant> <cat-a-puss> jrandom : ah, donc les champs de bits ne concernent que les fragments, pas chaque paquet alors ? 14:47 <jrandom> oui, si un message est partiellement reçu, on renvoie le champ de bits des fragments reçus de ce message 14:47 <ant> <cat-a-puss> ok 14:47 <jrandom> les identifiants de message sont malheureusement complètement aléatoires et non ordonnés, donc on ne peut pas utiliser des numéros de séquence à la TCP 14:48 <jrandom> (et, eh bien, on ne veut pas non plus de cette surcharge) 14:49 <jrandom> ok, s'il n'y a rien d'autre sur 2) SSU, passons à 3) i2phex 14:49 <jrandom> sirup : t'es dans le coin ? 14:49 <ant> <cat-a-puss> rapidement : pourquoi aléatoire ? 14:50 * sirup rôde 14:50 <jrandom> cat-a-puss : les identifiants de message sont exposés aux pairs — nous ne voulons pas qu'ils sachent qu'un message est lié à un autre message (celui avec un numéro de séquence antérieur) 14:50 <ant> <cat-a-puss> ok 14:51 <jrandom> salut sirup, j'ai posté quelques infos générales sur la liste, mais si tu pouvais nous faire une mise à jour, ce serait super 14:52 <sirup> bon. les premiers tests ont réussi 14:52 <jrandom> [w3wt] 14:52 <sirup> mais il semble aussi qu'il faille ajuster les paramètres de temporisation (timeouts). les connexions entre pairs ne tiennent pas pour une raison quelconque 14:53 <sirup> donc ce n'est pas prêt à l'emploi pour le moment :) 14:53 <sirup> mais je m'y attendais, car je n'ai rien changé concernant les timeouts et tout ça 14:54 <sirup> globalement, je serais content si quelques personnes étaient prêtes à m'aider à le tester jusqu'à atteindre un état supportable 14:55 <sirup> plusieurs instances sur la même machine ne t'emmènent que jusqu'à un certain point... 14:55 <sirup> oh. et toute expérience/retour est bienvenu. le mieux est d'envoyer un mail à sirup@mail.i2p 14:56 <sirup> un forum serait bien aussi (je ne peux pas en avoir à ma destination, parce que je ne suis pas 24/7) 14:56 <sirup> c'est tout :) 14:56 <jrandom> mortel 14:56 <jrandom> cervantes : y a moyen d'ajouter une section i2phex là-bas ? 14:57 <+cervantes> bien sûr 14:57 * sirup se demande qui télécharge cette musique sous licence Commons toute pourrie chez moi :) 14:58 <@smeghead> hé, au moins tu peux construire plus de merde par-dessus cette merde :) 14:58 <+cervantes> sirup : je suppose que « sirup » est ton pseudo sur le forum 14:58 <sirup> ce serait chouette 14:58 <sirup> oui 14:59 <ant> <BS314159> notes d'état ? 15:00 <jrandom> ok super. ça s'annonce vraiment très prometteur, sirup a fait du beau boulot, donc vous devriez passer sur sirup.i2p et lire ce qui se passe :) 15:00 <@smeghead> liste de diffusion ? 15:00 <RevDuck> ou www.i2phex.tk 15:01 <sirup> une liste de diffusion serait bien aussi, bien sûr 15:01 <sirup> lol. i2phex.tk est faux. récupérez vos dialers là-bas :) 15:01 <+cervantes> Forum I2Phex ajouté 15:01 <jrandom> !stab duck 15:02 <+cervantes> sirup est modérateur 15:02 <Masterboy> :D 15:02 <+cervantes> sirup : dis-moi si tu veux changer le texte de description 15:02 <jrandom> sirup : si tu veux des listes i2phex et i2phex-cvs, dis-le-moi, c'est assez facile à ajouter 15:02 <jrandom> (même si pour le moment, il est peut-être plus simple d'utiliser juste la liste i2p) 15:02 <sirup> cervantes, merci beaucoup 15:03 <sirup> ouais. le forum fera l'affaire pour l'instant 15:04 <jrandom> ok cool. quelqu'un a autre chose sur 3) i2phex ? 15:05 <jrandom> sinon, passons brièvement à 4) absence 15:05 <jrandom> je sais que vous piaffez d'impatience, à la recherche de moyens de contribuer du code à I2P, donc les notes d'état ont quelques suggestions 15:05 <+bla> jrandom : Tu es enfin déclassé par les Opérations ? 15:06 <jrandom> nan, la CIA est juste en train de me réaffecter^Ula la la 15:06 <@smeghead> non le budget noir a été augmenté ce trimestre 15:07 <+cervantes> « l'éléphant a quitté le nid » je répète « l'éléphant a quitté le nid » terminé 15:07 <jrandom> je n'ai pas vraiment grand-chose de plus à ajouter à 4) que ce qu'il y avait dans le mail, même si je suis sûr que vous avez plein d'autres idées sympas 15:07 * smeghead réprime une blague sur l'éléphantiasis 15:08 <jrandom> donc votre devoir pendant mon absence est de choisir quelque chose de sympa que vous voulez construire, et de le construire ;) 15:08 * cervantes panse les tempes qui saignent de smeghead 15:08 <jrandom> (que ce soit une page web ou un poney volant) 15:09 <jrandom> ok, passons à 5) ??? 15:09 <jrandom> quelqu'un d'autre a quelque chose à soulever pour la réunion ? 15:09 <shendaras> Tu vas nous manquer... 15:09 <@smeghead> oui qui présidera les réunions pendant ton absence ? 15:09 <+mancom> aum s'est-il montré la semaine dernière ? 15:09 <@smeghead> mancom : négatif 15:10 <Masterboy> frère duck ? :P 15:11 <jrandom> notre cher responsable des opérations prendra j'espère le relais, ou bien vous pourrez tirer à la courte paille pour savoir qui devra rédiger les notes d'état à la dernière minute :) 15:11 <jrandom> mancom : il est passé sur #i2p-chat l'autre jour brièvement 15:12 <RevDuck> peut-être ne tenir des réunions que lorsqu'il y a réellement quelque chose à annoncer, par contre 15:12 <+cervantes> ça va, j'écris un script de simulation de jrandom 15:12 <+cervantes> * w3wt 15:12 <jrandom> rien de mal à une réunion de 5 minutes ;) 15:13 <+cervantes> * jrandom lance une motte de boue sur son poney volant 15:13 * smeghead écrit un script de simulation de cervantes qui écrit un script de simulation de jrandom 15:13 * jrandom écrit une simu de smeghead[CRASH] 15:13 <+cervantes> oups, faut travailler cette grammaire 15:14 <@smeghead> haha 15:14 <jrandom> ok, quelqu'un d'autre a quelque chose à soulever pour la réunion ? 15:14 * cervantes écrit une simula d'aum......... 15:14 <@smeghead> java.util.RecursiveIdiocyException 15:15 <jrandom> en parlant de ça.. ;) 15:15 * jrandom prend de l'élan 15:15 * jrandom *baf* clôt la réunion