Réunion des développeurs I2P - 16 novembre 2004

13:05 <jrandom> 0) salut 13:05 <jrandom> 1) Congestion 13:05 <jrandom> 2) Streaming 13:05 <+dinoman> la clé de pgforge a changé :/ désolé 13:05 <jrandom> 3) BT 13:05 <jrandom> 4) ??? 13:05 <jrandom> ah cool, on peut faire un peu de magie pour ça 13:05 <jrandom> 0) salut 13:05 * jrandom fait signe 13:05 <ant> <lucky> salut 13:05 <jrandom> notes d'état hebdomadaires publiées @ http://dev.i2p.net/pipermail/i2p/2004-November/000489.html 13:05 <wiht> Bonjour. 13:06 <jrandom> (et on a posté les notes avant la réunion. w00t) 13:06 <jrandom> autant passer à 1) Congestion 13:07 <jrandom> pour ceux qui trainent sur le canal depuis quelques jours, vous avez entendu beaucoup de discussions sur ce qui se passait, et à la fois cet e-mail et le post de duck plus tôt devraient couvrir ça en général 13:07 <jrandom> cela dit, quelqu'un a des questions / commentaires / préoccupations à soulever/discuter ? 13:09 <wiht> Qu'entends-tu par « sélection de pairs sauvage » ? 13:10 <jrandom> la façon dont notre construction de tunnel actuelle fonctionne permet malheureusement de se stabiliser autour des pairs rapides 13:10 <jrandom> si ces pairs rapides ne tombent pas en panne de temps en temps, on se contente de les utiliser, point, au lieu d'explorer au-delà d'eux lors de notre construction de tunnel 13:11 <jrandom> ça veut dire que lorsqu'ils finissent par tomber en panne plus tard, on n'a à peu près aucune idée de la capacité du reste du réseau, et du coup, on choisit les pairs assez arbitrairement 13:11 <+DrWoo> jrandom: qu'est-ce qui est prévu pour mieux utiliser la capacité ? 13:12 <jrandom> DrWoo: la version 0.4.3 inclura une nouvelle manière de mutualiser les tunnels de façon à avoir plus de tunnels de secours « expérimentaux » (nous permettant d'apprendre davantage sur le réseau sans sacrifier les performances) 13:13 <jrandom> une répartition de charge plus agressive via des réservations de type ATM est aussi prévue, mais ce n'est pas encore programmé pour une version particulière (aka on le fera quand on en aura besoin) 13:14 <ant> <Connelly> beurk 13:14 <ant> <Connelly> pas encore de réunion ? 13:14 <jrandom> (réservations de type ATM, c.-à-d., suivre combien de bande passante les tunnels utilisent en moyenne, multiplier par le nombre de tunnels auxquels on participe, et comparer ça à nos limites/capacité de bande passante, en se basant sur cette comparaison pour accepter/refuser d'autres requêtes de tunnel) 13:15 <jrandom> Connelly: commencé il y a 10 min, notes d'état postées sur la liste ;) 13:15 <+DrWoo> jrandom: quel impact cela aura-t-il sur les performances ? 13:15 <+DrWoo> performances du PC local 13:15 * wiht se demande combien de protocoles différents sont utilisés sur le réseau I2P à part HTTP, IRC et BT. 13:16 <jrandom> DrWoo: la mutualisation 0.4.3 nous donnera une plus grande résilience (moins d'échecs), et les réservations permettront un partage de charge plus basé sur la capacité (aka réduire la contention) 13:16 <jrandom> aucun des deux n'est toutefois particulièrement lié à la latence 13:17 <jrandom> wiht: ces trois-là sont les principaux à ma connaissance, même si des trucs moches se font au-dessus de HTTP 13:17 <jrandom> c'est d'ailleurs un point intéressant, concernant irc et la congestion 13:18 <jrandom> ce qui a vraiment tué irc.duck.i2p l'autre jour, c'est que pendant la congestion, le serveur irc de duck devait quand même émettre 20x le nombre de messages qu'il recevait 13:19 <jrandom> ajoutez le renvoi automatique des messages toutes.10.secondes.sans.backoff, et ça grimpe à 120 messages pour chaque ligne de texte ;) 13:19 <jrandom> en gros ce que je dis, c'est qu'un protocole de chat décentralisé serait Bien ;) 13:19 <+DrWoo> ça existe, ce truc-là ? 13:20 <jrandom> (même si la nouvelle bibliothèque de streaming va virer ce surcoût de 6x) 13:20 <+dinoman> est-ce qu'il y en a une bonne 13:20 <jrandom> je ne sais pas si quelqu'un a évalué un truc à la SILC pour i2p ces 12 derniers mois 13:20 <susi23> pop3 et smtp sont horriblement lents sur i2p 13:21 <ant> <duck> silc == irc+un peu de crypto 13:21 <susi23> (en réponse à la question sur quels protocoles sont utilisés aussi) 13:21 <jrandom> ah, je pensais que silc s'était éloigné du concept d'ircd 13:21 <jrandom> oh, mince, c'est vrai, j'avais oublié ces deux-là :) 13:21 <wiht> susi23: Oui, j'avais oublié qu'on a du mail sur I2P maintenant. 13:21 <ant> <duck> pas beaucoup en tout cas 13:21 <jrandom> 'k 13:21 <ant> <protok0l> réunion ? 13:22 <ant> <lucky> tout de suite protok0l 13:22 <ant> <protok0l> k 13:22 <jrandom> ok, avons-nous autre chose pour 1) congestion ? 13:23 <jrandom> sinon, passons à 2) streaming 13:23 <jrandom> [voir l'email] 13:24 <jrandom> j'ai gardé toutes les mises à jour de la bibliothèque de streaming hors de history.txt, mais vous pouvez voir ce qui se passe via la liste cvs 13:24 <jrandom> (si vous êtes fous) 13:24 <jrandom> je n'ai rien d'autre à ajouter vraiment. donc, des questions/commentaires/préoccupations ? 13:25 <+postman> juste une 13:25 <+postman> merci :) 13:25 <ant> <protok0l> quel gain de vitesse y aura-t-il 13:25 <jrandom> hehe t'es censé attendre d'avoir le logiciel postman ;) 13:25 <jrandom> protokol: un peu. ça varie. 13:25 <+postman> jrandom: je parierais sur toi les yeux fermés 13:26 <+DrWoo> jrandom: je vais te poser ce que tu détestes, y a-t-il une ETA pour la nouvelle bibliothèque de streaming, la situation actuelle est clairement un point de vulnérabilité ? 13:27 <jrandom> si les tests de cette semaine se passent bien, on peut prévoir la semaine prochaine 13:27 <jrandom> il y aura des services en ligne et opérationnels sur la nouvelle bibliothèque de streaming avant ça, afin qu'on puisse la tester en charge 13:28 <wiht> Si je me souviens bien, vous utilisez un réseau simulé pour les tests. C'est toujours vrai ? 13:29 <jrandom> pour certains, oui 13:29 <jrandom> quand je n'utilise pas la simu, je le fais tourner sur le réseau live 13:30 <jrandom> (parce que j'aime abuser de votre bande passante ;) 13:30 <susi23> de rien ;) 13:30 <+dinoman> hehe l'allumer et voir si ça explose ? 13:31 -!- x est maintenant connu sous le nom de fidd 13:31 <jrandom> en gros oui - j'ai un peu de code de journalisation qui déverse essentiellement les en-têtes des paquets de streaming, me permettant de vérifier que tout est bien envoyé et que diverses situations sont gérées comme elles devraient l'être 13:32 <jrandom> les tests simulés sont plus impliqués cependant, avec peut-être une demi-douzaine de tests unitaires avec divers paramètres d'exécution 13:33 <wiht> Dans quelle mesure les tests de simulation reflètent-ils l'utilisation observée du réseau ? 13:33 <jrandom> plutôt bien, puisque le code de simulation est le même que le code du réseau live 13:34 <jrandom> je n'ai pas l'injection de latence et de pertes parfaite dans la simu, mais c'est dans le bon ordre de grandeur 13:35 <ant> <cat-a-puss> la nouvelle bibliothèque de streaming utilisera-t-elle la même interface ? Ou les applis Java devront-elles faire quelque chose de nouveau ? 13:35 <wiht> Merci pour la précision. 13:36 <jrandom> cat-a-puss: la même interface. il y a quelques options de configuration supplémentaires que vous pourriez ajouter en construisant un I2PSocketManager, mais c'est une bonne vieille Map de propriétés 13:36 <ant> <cat-a-puss> k 13:37 <jrandom> k, autre chose, ou on passe à 3) BT ? 13:38 <jrandom> duck: ping 13:38 <@duck> *coin 13:38 <@duck> La semaine dernière j'ai signalé que nous avions BitTorrent sur I2P qui fonctionne. Il y a eu un peu de 13:38 <@duck> confusion mais c'est anonyme à la fois pour les trackers et pour les clients (seeders et leechers). 13:38 <@duck> Mises à jour depuis la semaine dernière : 13:38 <@duck> travail sur la GUI (wxPython), tracker inclus, corrections de bugs. 13:39 <@duck> liste complète sur http://dev.i2p/cgi-bin/cvsweb.cgi/~checkout~/i2p-bt/CHANGES.txt?rev=HEAD 13:39 <@duck> le code est aussi sur le CVS sur cvs.i2p 13:39 <@duck> et un eepsite dédié : http://duck.i2p/i2p-bt/ 13:39 <@duck> Le tracker inclus est très spartiate et vous devez toujours fournir les 13:39 <@duck> torrents eux-mêmes quelque part ; donc DrWoo, thetower et moi avons regardé 13:39 <@duck> plusieurs alternatives offrant des fonctionnalités comme suprnova, jusqu'à ce que je devienne dingue. 13:39 <@duck> *flierp* 13:40 <jrandom> w00t 13:40 <@duck> Finalement bytemonsoon est retenu, l'original est moche, mais DrWoo a corrigé ça, 13:40 <@duck> L'idée est de l'améliorer encore et de le publier comme une solution de tracker prête pour I2P, 13:40 <@duck> voir : http://brittanyworld.i2p/bittorrent/ 13:40 <@duck> répondant aux exigences sur : http://duck.i2p/i2p-bt/txt/bytemonsoon.txt 13:40 <@duck> . 13:40 <jrandom> canon 13:40 <+DrWoo> vous pouvez récupérer quelques petits fichiers de test sur le joli tracker que duck a retapé 13:41 <+DrWoo> il n'y a rien de gros pour engorger le réseau hehe 13:41 <jrandom> quoi, vous ne voulez pas qu'on télécharge plus d'épisodes de Lost ? :) 13:41 <@duck> si celui de thetower est en ligne.. 13:42 <jrandom> le portage de bytemonsoon a vraiment belle allure. 13:42 <+DrWoo> je n'arrive pas à joindre thetower ici pour l'instant 13:42 <+DrWoo> jrandom: ça semble vraiment fournir à peu près tout ce dont on a besoin 13:42 <+dinoman> quelles vitesses les gens voient ? 13:43 <@duck> ~5 ko/s par pair 13:43 <+DrWoo> dino: de ce côté ça ressemble à 4-10K par pair 13:43 <@duck> (optimistement, bien sûr il y a ceux avec un ADSL pourri) 13:44 <+dinoman> wow mieux que je ne pensais 13:44 <@duck> jusqu'à ce que i2p plante ; voir 1) 13:44 <jrandom> heh 13:44 <+DrWoo> dinoman: en d'autres termes, ça devrait être assez impressionnant avec un swarm (essaim) 13:44 <@duck> il y a eu divers appels pour améliorer la GUI 13:45 <+DrWoo> dinoman: et quelques pairs à 0 saut ;) 13:45 <@duck> mais pas beaucoup de volontaires 13:45 <jrandom> duck (& la bande): que pouvons-nous faire pour aider ? 13:45 <@duck> toi : préparer la nouvelle bibliothèque de streaming 13:46 <@duck> la bande : regardez le todo : http://duck.i2p/i2p-bt/txt/todo.txt 13:46 <@duck> lucky travaille sur un howto 13:47 <@duck> DrWoo: autre chose ? 13:47 <jrandom> sympa 13:47 <+DrWoo> jrandom: peux-tu parler un peu de ta position quant à l'importance (ou pas) du partage de fichiers (et d'autres services populaires actuellement utilisés sur Internet) et ce que cela signifie pour les perspectives d'anonymat d'I2P. 13:47 <ant> <lucky> je fais ça ? 13:48 <ant> <lucky> oh 13:48 <ant> <lucky> je fais ça 13:48 <ant> <lucky> :) 13:48 <+DrWoo> duck: il y a toujours autre chose heh 13:48 <jrandom> le partage de fichiers est essentiel au succès d'I2P, car c'est réalistement le plus grand vivier potentiel d'utilisateurs dans lequel se fondre pour notre ensemble d'anonymat 13:49 <ant> <lucky> euh oh. 13:49 <ant> <lucky> Donc ça veut dire que je devrais vraiment, vraiment bosser sur ce howto alors. 13:49 <jrandom> sans système viable de transfert de gros fichiers, nous devons faire des merveilles pour susciter des applications utilisateur 13:50 <jrandom> ce que nous faisons - le travail de susi et postman est assez prometteur 13:50 <jrandom> mais la demande pour l'e-mail anonyme est bien moindre que celle pour le transfert de fichiers sûr 13:51 <jrandom> tandis que I2P lui-même passe à l'échelle quelle que soit la taille (si les choses sont comme on l'espère ;), il nous faut un grand ensemble d'anonymat pour soutenir quoi que ce soit de valable 13:51 <jrandom> </mes 2 cents> 13:52 <@duck> que penses-tu des paramètres par défaut pour ces applis de partage de fichiers ? 13:52 <jrandom> ça je ne sais pas 13:53 <@duck> ou ce n'est pas vraiment pertinent encore vu les possibilités actuelles 13:54 <+DrWoo> duck: il faudra peut-être « sortir des sentiers battus » pour franchir quelques obstacles en route ? 13:54 <jrandom> les tunnels à 1 saut peuvent être pertinents pour les BT-ers, avant la 0.4.3 13:57 <jrandom> ok, avons-nous autre chose pour 3) BT ? 13:57 <@duck> pas moi 13:57 <+DrWoo> merci à duck et aux gars 13:58 <+DrWoo> c'était du travail assez impressionnant 13:58 <jrandom> ouais, vous tous faites un boulot d'enfer 13:58 <+dinoman> je n'ai pas fait ça 13:58 <jrandom> (j'adore regarder le --spew 1 on the btdownloadheadless :) 13:58 <@duck> dinoman: c'est toi qui as lancé le truc 13:58 <+Ragnarok> headless spew... ça sonne crade 13:59 <+DrWoo> dino: faire avancer l'effort est une véritable contribution 13:59 * Ragnarok va préparer un patch pour les options en ligne de commande qui sont sur la todo list 13:59 <jrandom> w00t 14:00 <ant> <dm> N'oubliez pas le WWW anonyme, c'est important aussi. 14:00 <jrandom> dm: ouais, peut-être des milliers ou des dizaines de milliers, mais pas l'attrait de millions 14:01 <jrandom> (pour les trucs d'outproxy, amha) 14:01 <jrandom> ok, s'il n'y a rien d'autre, passons au bon vieux 4) ??? 14:01 <jrandom> quelque chose qui n'a pas encore été abordé et qui devrait l'être ? 14:02 <wiht> postman: Quel est l'état du système de mail ? Comment fonctionne-t-il, en particulier pour les communications en dehors du réseau I2P ? 14:02 <+DrWoo> dm: tout fait partie du grand cirque de la vie :) 14:03 <ant> <dm> beaucoup de gens utilisent le web 14:03 <ant> <dm> (ils viennent d'installer surfcontrol à mon boulot) ;) 14:03 <jrandom> ouais, l'hébergement www anonyme sera crucial pour ceux qui ont vraiment besoin d'i2p, même s'ils ne constitueront probablement pas l'ensemble d'anonymat nécessaire 14:03 <jrandom> ah, naze 14:04 <jrandom> wiht: s'il n'est pas là, je peux dire que l'in- et l'outproxy ont plutôt bien marché pour moi - rien de perdu pour l'instant 14:04 <jrandom> (et vérifier mon courrier prend quelques secondes, mais biff me prévient quand il faut de toute façon) 14:05 <jrandom> ok, y a-t-il autre chose ? 14:06 <ant> <dm> tu « baffes » la réunion ? 14:07 <jrandom> on dirait bien 14:07 * jrandom se prépare 14:07 * jrandom *baf* clôt la réunion