Réunion des développeurs I2P - 25 avril 2005

16:12 <jrandom> 0) salut 16:12 <jrandom> 1) État du réseau et 0.6.1.17 16:12 <jrandom> 2) I2Phex 16:13 <jrandom> 3) ??? 16:13 <jrandom> 0) salut 16:13 * jrandom fait coucou 16:13 <@cervantes> ’lo 16:13 <jrandom> les notes d’état hebdomadaires sont en ligne @ http://dev.i2p.net/pipermail/i2p/2006-April/001283.html 16:14 <jrandom> pendant que vous parcourez ça, passons à 1) État du réseau 16:14 <jrandom> donc, comme la plupart d’entre vous l’ont vu, on a une nouvelle version, et jusqu’ici les résultats sont plutôt positifs 16:15 <@cervantes> (youpi !) 16:15 <jrandom> ce n’est pas encore là où il faut, mais ça règle en gros les principaux problèmes qu’on voyait 16:15 <jrandom> ouaip, ça fait plaisir d’avoir de nouveau des taux de construction de tunnel corrects, même pour des tunnels à 2+ sauts :) 16:16 * jrandom a des taux de réussite de 50 %+ sur un autre router avec des tunnels 1‑hop 16:17 <jrandom> je pense que les dernières modifs de la 0.6.1.17 devraient aussi aider à éviter ce type d’effondrement dû à la congestion à l’avenir 16:17 <jrandom> le résultat visible pour l’utilisateur, cependant, c’est qu’on verra occasionnellement des expirations de lease (baux dans I2P), mais au lieu de s’aggraver, ça fera marche arrière 16:17 * cervantes lance Azureus 16:18 <+Complication> Ce matin, j’ai enregistré des taux de réussite de tunnel client (longueur 2 +/- 1) proches de 35 % 16:18 <+Complication> Actuellement c’est plus bas, puisque j’ai essayé quelques modifs, et la dernière n’était pas terrible :D 16:18 <@cervantes> jrandom: bien joué pour avoir trouvé ça — on commençait à ressembler à freenet un moment :) 16:19 <jrandom> *tousse* ;) 16:20 <+fox> <inkeystring> jrandom: ça te dérangerait de décrire brièvement le mécanisme de backoff (ralentissement adaptatif) ? je travaille sur quelque chose comme ça pour freenet 0.7 en ce moment 16:21 <jrandom> inkeystring: on avait déjà en place un mécanisme de backoff au niveau de la couche de transport pour réduire les transmissions vers un pair quand la couche de transport est surchargée, mais ce n’était pas suffisant 16:21 <@cervantes> *tousse* ai‑je dit freenet, je voulais dire tor 16:21 <+fox> <inkeystring> :-) 16:22 <jrandom> inkeystring: la nouveauté a été de propager ça à un niveau plus haut pour qu’on arrête d’essayer de construire des tunnels quand notre couche de communication est saturée 16:22 <jrandom> (au lieu d’envoyer encore plus de tentatives de construction de tunnel) 16:22 <+fox> <inkeystring> merci — est‑ce que la couche de transport ne fait du backoff que quand des paquets sont perdus, ou y a‑t‑il un moyen pour le récepteur de contrôler le flux ? 16:23 * jrandom il me semble me souvenir avoir discuté de l’impact de la congestion *vs* le routage avec toad à quelques reprises (sur IRC et mon vieux flog), même si je ne me souviens d’aucune solution réellement positive pour le réseau :/ 16:23 <jrandom> le récepteur peut envoyer un NACK, et on a des hooks pour ECN, mais ils n’ont pas été nécessaires 16:23 <+fox> <inkeystring> oui, le débat a refait surface sur freenet-dev :-) toujours pas de solution miracle 16:24 <+fox> <inkeystring> cool, merci pour l’info 16:24 <+Complication> Ils utilisent aussi UDP ces temps‑ci, non ? 16:24 <jrandom> actuellement, les pairs très congestionnés ont des problèmes non pas avec la limitation par pair, mais avec l’ampleur des communications entre pairs 16:24 <+Complication> (comme protocole de transport) 16:24 <+fox> <inkeystring> breadth = nombre de pairs ? 16:24 <jrandom> oui 16:25 <jrandom> avec l’augmentation des taux de réussite de tunnel, les pairs n’ont plus besoin de parler à des centaines de pairs juste pour construire un tunnel 16:25 <jrandom> donc ils peuvent s’en sortir avec seulement 20–30 pairs 16:25 <jrandom> (des pairs directement connectés, c’est‑à‑dire) 16:26 <+fox> <inkeystring> j’imagine que c’est une bonne nouvelle pour le NAT hole punching, les keepalives, etc. ? 16:26 <jrandom> par contre, avec 2–300 connexions SSU actives, un lien à 6 KB/s va avoir du mal 16:26 <jrandom> ouaip 16:26 <+fox> <inkeystring> Complication : oui 16:27 <+fox> <inkeystring> (dans l’alpha 0.7) 16:27 <+Complication> Aha, alors ils affrontent sans doute des choses similaires 16:27 <+Complication> J’espère que quelqu’un trouvera la solution miracle :D 16:27 <jrandom> mais d’une autre manière. La couche de transport est un problème relativement facile 16:27 <+fox> <inkeystring> je pense qu’ils ont pu réutiliser une partie du code SSU… ou au moins ils en ont parlé 16:27 <jrandom> (alias bien étudiée depuis plus de 30 ans) 16:28 <jrandom> mais l’équilibrage de charge d’i2p (et de freenet) fonctionne à un niveau plus élevé que les liens point à point, et a des exigences différentes 16:28 <+fox> <inkeystring> oui, c’est l’interaction avec le routage qui est délicate 16:29 <jrandom> ouaip, même si i2p l’a plus facile (on n’a pas besoin de trouver des pairs précis avec les données en question, juste n’importe qui avec la capacité de participer à nos tunnels) 16:30 <+fox> <inkeystring> donc il n’y a pas de perte d’efficacité si tu évites un pair surchargé… 16:30 <+fox> <inkeystring> alors que dans freenet, contourner un pair surchargé peut augmenter la longueur du chemin 16:30 <+fox> <inkeystring> bref, désolé pour le hors‑sujet 16:31 <jrandom> pas de souci, expliquer pourquoi les changements en 0.6.1.17 affectent notre effondrement dû à la congestion était pertinent :) 16:31 <jrandom> ok, quelqu’un a autre chose pour 1) État du réseau ? 16:32 <+Complication> Eh bien, comme mentionné, en tournant en .17 pur, j’ai observé un périodisme notable du débit et du nombre de pairs actifs 16:32 <+Complication> Et quelques autres personnes semblent l’observer aussi, même si je n’ai aucune idée de sa fréquence 16:33 <+Complication> Je me demande quelles en sont les causes principales, surtout sous l’angle de la limitation des tunnels, mais pas encore de solution 16:33 <+Complication> J’ai réussi à aplatir un peu mes propres graphes, mais au prix d’une certaine dégradation globale 16:33 <+Complication> Essayé des modifications comme : 16:34 <+Complication>> _log.error("Allowed was " + allowed + ", but we were overloaded, so ended up allowing " + Math.min(allowed,1)); 16:34 <+Complication> (c’était pour éviter qu’il s’abstienne totalement de tenter des constructions pour ses propres tunnels) 16:35 <jrandom> ah oui 16:35 <+Complication> (oh, et bien sûr le niveau de log est farfelu, puisque je les ai modifiés pour les tests) 16:35 <jrandom> on a du code là‑dedans qui essaie de décaler un peu la périodicité, mais ça ne marche pas tout à fait comme il faut (évidemment) 16:36 * perv vient de flinguer son système :( 16:36 <+Complication> Mais j’ai essayé des trucs comme ça, et tenté de réduire le facteur de croissance du nombre de tunnels 16:36 <perv> il y a un undelete pour reiser4 ? 16:36 <jrandom> en gros, si on agit comme si les tunnels expiraient (aléatoirement) plus tôt qu’en réalité, ça devrait aider 16:36 <+Complication> Actuellement en train de lire la grosse fonction "countHowManyToBuild" dans TunnelPool.java :D 16:36 <+Complication> Mais je ne l’ai pas encore lue jusqu’au bout 16:37 <jrandom> (même si ça augmenterait évidemment la fréquence de construction de tunnel, ce qui, avant 0.6.1.17, n’aurait pas été raisonnable) 16:37 <+Complication> perv : il y a quelque chose 16:37 <jrandom> hmm, mettre une randomisation là‑dedans serait difficile, Complication, car on appelle cette fonction assez fréquemment 16:38 * perv envisage de récupérer ce qu’il peut et de passer à Gentoo 16:38 <jrandom> ce que je recommanderais, ce serait de regarder pour randomiser le temps d’expiration des tunnels construits avec succès 16:38 <+Complication> perv : tu es mieux avec reiser qu’avec ext3, clairement 16:38 <+Complication> perv : mais je ne le connais pas par cœur 16:38 <+Complication> jrandom : vrai, parfois ça pourrait sur‑construire comme ça 16:38 <jrandom> (de sorte que le "countHowManyToBuild" existant pense qu’il en a besoin avant que ce ne soit réellement le cas) 16:38 <+Complication> (et parfois ça sur‑construit inévitablement, quand des tunnels cassent et qu’il se hâte) 16:40 <+Complication> Hmm, une possibilité à laquelle je n’ai pas pensé… 16:41 <+Complication> Dans tous les cas, je joue aussi avec ça, mais pas encore d’observations utiles 16:42 <jrandom> cool, j’ai quelques ajustements sur lesquels je travaille là‑dessus, peut‑être qu’on pourra les regrouper pour la prochaine build afin de voir comment ça marche sur le réseau raisonnablement viable ;) 16:43 <spinky> Y a‑t‑il une stat où l’on peut voir la quantité d’overhead que le réseau i2p ajoute aux données applicatives ? 16:43 <jrandom> « overhead » est un terme tellement chargé… ;) 16:43 <jrandom> on appelle ça le coût de l’anonymat ;) 16:43 <spinky> hehe 16:45 <jrandom> (alias pas vraiment. La charge utile de la couche applicative sur un réseau parfait sans congestion et avec 1+1 sauts obtient quelque chose comme 70–80 % d’efficacité pour les extrémités) 16:45 <jrandom> ((la dernière fois que j’ai mesuré)) 16:45 <jrandom> mais ce sont vraiment des conditions de labo 16:45 <jrandom> le réseau en conditions réelles est bien plus compliqué 16:47 <spinky> D’accord, je pensais juste à la quantité de données supplémentaires utilisées pour l’établissement des tunnels, les clés, le padding, etc 16:47 <spinky> ...par rapport aux données applicatives transférées 16:47 <jrandom> ça dépend du framing des messages, de la congestion, des taux de réussite de construction de tunnel, etc. 16:48 <jrandom> un tunnel 2‑hop peut être construit par le réseau en transportant 20 KB 16:48 <+Complication> J’ai voulu tester ça parfois, principalement afin d’estimer le « gaspillage » des applications de transfert de masse comme BitTorrent et I2Phex 16:48 <+Complication> Mais je n’ai jamais pris le temps de faire une mesure propre entre mes deux nœuds 16:48 <+Complication> Un jour, je m’y remettrai, toutefois 16:49 <jrandom> Complication: c’est assez difficile avec des applis bavardes, beaucoup plus simple de mesurer wget :) 16:49 <+Complication> Très vrai 16:50 <+Complication> Dans ce que j’ai réussi à essayer, il n’y avait rien qui ressemble à de la précision 16:54 <jrandom> ok, s’il n’y a rien d’autre sur le 1), passons au 2) I2Phex 16:55 <jrandom> Complication : tu fais quoi ? :) 16:55 <+Complication> Eh bien, le commit d’hier corrigeait certains problèmes que des gens rencontraient avec mon détecteur de premier lancement un peu idiot 16:56 <+Complication> Le détecteur de premier lancement est maintenant moins idiot, et bar a signalé qu’il semblait recommencer à se comporter normalement 16:56 <+Complication> Cependant, puisque I2Phex semble déjà exécutable dans les conditions actuelles du réseau, 16:56 <+Complication> je vais essayer de trouver aussi le bug de rehash. 16:57 <+Complication> Si seulement je peux 16:57 <jrandom> cool, je sais que celui‑là te hante depuis des mois maintenant 16:57 <+Complication> Ce qui est intéressant, c’est que la branche principale de Phex l’a peut‑être aussi, et localiser + lire leurs observations est quelque chose que j’essaierai de faire également 16:58 <jrandom> mais c’est bien d’entendre que le correctif de démarrage est dedans 16:58 <jrandom> ah, clair 16:58 <+Complication> =c’est ça 16:58 <+Complication> Je ne peux toutefois pas confirmer pour l’instant si la branche principale de Phex l’a ou non — je ne l’y ai jamais vu personnellement 16:59 <jrandom> (bugs intermittents)-- 16:59 <+Complication> C’est difficile à provoquer de manière contrôlée, et donc difficile à trouver 17:00 <+Complication> Et de mon côté, c’est à peu près tout pour l’instant 17:00 <+Complication> Plus tard, je me demandais s’il vaudrait la peine de limiter le nombre de tentatives de contact de pairs parallèles qu’I2Phex lance en même temps 17:01 <jrandom> ouaip, probablement 17:01 <+Complication> Puisqu’elles créeraient tout un tas de requêtes NetDB en peu de temps, et ça pourrait être potentiellement pas top du point de vue d’un router I2P 17:02 <jrandom> et les contacts de nouvelle destination nécessitent elG au lieu d’aes 17:02 <+Complication> Mais je n’ai encore rien lu ni écrit de code concret en ce sens 17:04 <jrandom> ok np. peut‑être que la fusion mythique i2phex/phex embarquera une solution :) 17:04 <+Complication> Et de mon côté, c’est à peu près toutes les nouvelles du front I2Phex… 17:04 <jrandom> cool, merci pour la mise à jour et pour l’effort d’exploration ! 17:05 <jrandom> ok, passons à 3) ??? 17:05 <jrandom> quelqu’un a autre chose à aborder pour la réunion ? 17:05 <lsmith> bonjour ! je tiens juste à féliciter les devs pour les améliorations fantastiques de la dernière version, mon bw total affiche 0,9/1,4 KB/s et je reste connecté à l’irc… c’est… incroyablement cool :) 17:05 <+Complication> :D 17:06 <jrandom> merci pour ta patience tout du long — prendre en charge les utilisateurs à faible bw est critique 17:06 <@cervantes> lsmith : c’est vraiment bien de 17:06 <@cervantes> * Connection Reset 17:06 <jrandom> heh 17:07 <lsmith> :) 17:09 <jrandom> oh, une autre chose à noter est que zzz est de retour, et avec lui revient stats.i2p :) 17:09 <jrandom> [wewt] 17:11 <+Complication> Une source de données de comparaison très utile :) 17:11 <jrandom> tout à fait 17:11 <jrandom> ok, quelqu’un a autre chose pour la réunion ? 17:13 <jrandom> sinon… 17:13 <jdot> j’ai une ou deux questions post‑baf 17:13 <jrandom> heh ok, alors lançons le baffeur :) 17:13 * jrandom s’élance… 17:13 * jrandom *baf* clôt la réunion