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

16:09 <jrandom> 0) salut 16:09 <jrandom> 1) État du réseau et 0.6.1.16 16:09 <jrandom> 2) Création de tunnel et congestion 16:10 <jrandom> 3) Feedspace 16:10 <jrandom> 4) ??? 16:10 <jrandom> 0) salut 16:10 * jrandom fait coucou 16:10 <jrandom> notes d'état hebdomadaires publiées à http://dev.i2p.net/pipermail/i2p/2006-April/001281.html 16:10 * frosk aussi 16:10 <jrandom> (presque deux heures *avant* la réunion, aussi :) 16:11 <jrandom> ok, puisque je suis sûr que vous avez déjà épluché les notes, passons à 1) État du réseau 16:12 <+Complication> Salut :) 16:12 * Complication attrape rapidement les notes 16:12 <jrandom> la version 0.6.1.16 a corrigé un bug très ancien dans notre PRNG (générateur pseudo-aléatoire), qui avait provoqué un nombre conséquent de refus arbitraires de tunnel 16:13 <jrandom> (la cause racine a été introduite en octobre dernier, mais elle est corrigée maintenant) 16:13 <+Complication> Statut ici : fonctionne de façon tolérable avec des tunnels à 1 + 0..1 saut, ne se comporte pas bien avec 2 + 0..1 ou 2 +/- 0..1 16:14 <jrandom> ouais, c'est compréhensible aussi, surtout sur des liaisons plus lentes 16:14 <jrandom> (malheureusement, « plus lentes » n'est pas si lent que ça non plus) 16:15 <jrandom> il reste encore beaucoup de travail, et 0.6.1.16 n'est pas là où nous devons être, mais c'est un progrès 16:17 <+Complication> Quelque chose à quoi je pensais, au sujet de ce que tu as appelé « effondrement par congestion » 16:18 <+Complication> Une façon d'en limiter l'impact serait peut‑être de réellement *exiger* d'un router qu'il accepte un certain quota de requêtes de participation 16:19 <+Complication> (quelque chose spécifié par l'utilisateur, directement ou indirectement ?) 16:19 <jrandom> spécifié par quel utilisateur ? 16:19 <+Complication> (par ex. une partie du pourcentage de partage ou un paramètre supplémentaire) 16:19 <jrandom> l'utilisateur local, ou par nous en tant qu'utilisateurs distants ? 16:19 <+Complication> Spécifié par chacun pour soi 16:19 <@frosk> devrions‑nous passer à 2) alors ? :) 16:20 <jrandom> ouais, on peut considérer qu'on est sur 2) :) 16:20 <+Complication> Afin que je puisse, par exemple, dire à mon router « même si tu es congestionné, continue à router un minimum de 4 KB/s » 16:21 <jrandom> Complication : Ce n'est pas vraiment possible — si un router est trop congestionné, les autres (espérons‑le ;) arrêteront de lui demander de participer à des tunnels. 16:21 <+Complication> (cela signifierait bien sûr que certaines destinations locales pourraient rester hors ligne un peu plus longtemps) 16:21 <jrandom> et s'ils ne sont pas sollicités, ils /ne peuvent pas/ acheminer les données des autres 16:22 <+Complication> Ah, j'aurais peut‑être dû le formuler nettement plus clairement 16:24 <+Complication> J'imaginais que, sous un certain quota de trafic de participation, il pourrait limiter ses propres messages de création de tunnel au lieu de limiter les tunnels de participation 16:24 <+Complication> par ex. « Je ne réduirai jamais mes tunnels de participation en dessous de 4 KB/s. Si cela était nécessaire, je réduirai plutôt mon propre trafic. » 16:26 <jrandom> hmm, il y a des risques pour l'anonymat là‑dedans (bien que ce soit dans la même veine que les DoS sélectifs, contre lesquels nous ne nous défendons pas de toute façon) 16:27 <jrandom> mais limiter nos propres constructions de tunnel locales face à la congestion est quelque chose que je suis en train de tester — ajouter la prise en charge pour ignorer de façon optionnelle le plancher à 4KBps devrait être assez simple 16:28 <spinky> Actuellement, vous n'obtenez aucun trafic de couverture lorsque vous transférez beaucoup de données. 16:29 <spinky> Avoir un plancher pour la bande passante de participation semble bien. 16:30 <jrandom> eh bien, nous avons un plancher (à la fois via le pourcentage de partage et un 4KBps interne réservé après que toute la bande passante est affectée) 16:30 <+Complication> Bah, déconnexions... J'espère que je n'ai pas perdu grand‑chose de ce que j'ai dit, mais je devrai lire les réponses dans le log :) 16:32 <@frosk> y a‑t‑il quelque chose de significatif à propos de 4KBps ? 16:33 <jrandom> quelques éléments — 4KB ≃ sizeof(tunnel create message), et heuristiquement, je n'ai jamais entendu parler d'un router fonctionnant avec succès en‑dessous 16:33 <spinky> Peut‑être que ce sont des bugs qui empêchent alors le pourcentage de partage de fonctionner ? 16:34 <jrandom> qu'est‑ce qui te fait dire que le pourcentage de partage ne fonctionne pas ? 16:34 <@frosk> je vois 16:34 <+Complication> frosk : non, c'est juste un nombre dans le code actuel, et j'y ai fait référence en essayant d'expliquer ce que j'imaginais aussi 16:35 <+Complication> (pas pour des raisons pertinentes, juste parce que ce que j'imaginais était, en un certain sens, son égal opposé) 16:35 <spinky> Il est réglé à 80 % et la participation tombe à 0 lors de la génération locale de données. Peut‑être que je ne comprends pas bien. 16:36 <jrandom> ah, oui, ce n'est pas ce que fait le pourcentage de partage 16:36 <+Complication> spinky : c'est une limite maximale de ce qui peut être partagé, sous réserve de la bande passante réellement disponible pour le partage 16:37 <+Complication> Si le trafic local prend 70 %, il ne vous reste que 10 % pour le partage 16:37 <+Complication> Si le trafic local est lourd, il vous restera 0 %, et la limite haute de 80 % ne sera jamais atteinte 16:37 <spinky> Ok. Je vois que ça dit « jusqu'à »... 16:38 <+Complication> Et il y a aussi la réserve de 4 KB/s 16:38 <jrandom> ah, c'est le pourcentage de partage de ce que vous avez de disponible 16:38 <spinky> Peut‑être un autre réglage pour la bande passante plancher de participation, en dessous duquel le router acceptera plus de tunnels ? 16:38 <jrandom> si vous utilisez 95 % de votre bande passante, il partagera jusqu'à 80 % des 5 % restants 16:39 <+Complication> Oh, alors je l'avais aussi en partie mal compris 16:40 <fox> <zorglu1> comment i2p mesure‑t‑il la quantité de bande passante utilisée par d'autres applications locales ? 16:40 <spinky> (Je dis ça comme ça : si vous considérez le trafic de couverture comme une bonne chose, peut‑être qu'avoir quelque chose de configurable même sous une forte utilisation locale de bande passante est une bonne chose) 16:40 <+Complication> Je pensais que c'était appliqué par rapport à la limite soutenue 16:40 <jrandom> zorglu1 : il mesure l'utilisation de bande passante d'i2p, et connaît les limites de bande passante d'i2p 16:41 <jrandom> oh, hmm, en regardant le code, int availBps = (int)(((maxKBps*1024)*share) - used); 16:41 <jrandom> donc tu as raison Complication 16:42 <jrandom> spinky : le trafic de couverture n'est utile que dans une certaine mesure sur un mixnet à faible latence 16:42 <jrandom> cela ajoute une incitation pour les routers à plus grande bande passante, mais ceux qui n'ont pas de bande passante à revendre ont peu de recours 16:49 <jrandom> de toute façon, le problème de congestion de tunnel existe depuis un moment, mais il n'a été récemment exacerbé que par des taux de rejet de tunnel délirants 16:49 <jrandom> avec un peu de chance, la prochaine révision arrangera ça 16:49 <jrandom> ok, quelqu'un a autre chose sur 2) création de tunnel et congestion ? 16:50 <@frosk> on dirait que cela nécessiterait quelques changements au schéma de construction de tunnel 16:50 <+Complication> J'espère que ça aidera à améliorer les choses :) 16:51 <+Complication> Oh, au fait... 16:52 <jrandom> eh bien, nous avons quelques correctifs bon marché, comme réduire la concurrence maximale, limiter nos tentatives de construction en cas de congestion, réduire la fréquence des abandons (par opposition aux rejets explicites), et ajuster le profilage pour encourager les rejets explicites plutôt que les abandons 16:52 <+Complication> ...aurais‑tu par hasard trouvé quelque chose qui pourrait expliquer la grande disparité entre les indicateurs de bande passante brute et les indicateurs de charge utile de tunnel ? 16:52 <+Complication> (par ex. bande passante totale 1 Go, charge utile de tunnel cumulée 300 Mo) 16:52 <jrandom> mais c'est vrai, cela n'affecte que l'ampleur 16:52 <+Complication> (comme je n'ai pas été sur IRC récemment, je ne sais pas si vous avez regardé ça dernièrement) 16:54 <jrandom> je n'ai pas trop creusé ça, mais souviens‑toi, les requêtes de construction de tunnel pour les tunnels sortants ne sont pas des messages de tunnel (et il y en a beaucoup si seulement 0,1 % aboutissent. et à 4KB chacune...) 16:54 * Complication n'est pas certain que ce soit les indicateurs, ou un effet réel 16:55 <+Complication> Oh... des requêtes de construction sortantes... en effet 16:55 <jrandom> la build -1 à venir ajoute une flopée de statistiques pour surveiller les paquets par type de message 16:55 <+Complication> Cela pourrait être précisément ça 16:55 <jrandom> (sont également incluses dans ces requêtes de construction sortantes des requêtes de participation à la construction — faire suivre une réponse) 16:56 <jrandom> ((donc ce n'est pas juste du local)) 17:00 <+Complication>> Merci, ça explique beaucoup :) 17:00 <+Complication>> Ce n'est donc pas du vaudou, mais bien du trafic réel, que j'ai juste oublié, puisqu'il n'était pas compté spécifiquement dans les endroits que j'ai vérifiés 17:00 <+Complication> Cela devait effectivement se produire, et coûter effectivement beaucoup d'octets 17:00 <+Complication> Surtout avec des taux de réussite faibles 17:01 <jrandom> ouais, bien que ça ne devrait pas coûter autant que ça, puisque nous devrions avoir des taux de réussite plus élevés que ceux que nous avons :) 17:01 <jrandom> ok, autre chose sur 2) ? 17:02 <jrandom> si non, passons à 3) Feedspace 17:02 <jrandom> frosk : tu veux nous donner une mise à jour ? 17:03 <jrandom> (ou nous dire d'aller nous faire fsck et de lire l'eepsite ? ;) 17:04 <@frosk> eh bien, pour ceux qui n'ont pas prêté attention à frosk.i2p ou feedspace.i2p, feedspace fonctionne maintenant en gros (pour ma propre définition de « en gros ») 17:04 <jrandom> (w00t) 17:05 <@frosk> il y a eu quelques ajouts sympas dernièrement, comme un support infrastructurel pour des transports autres que i2p (tor et du tcp/ip non anonyme, par exemple) 17:06 <@frosk> donc, en temps voulu, nous prévoyons de permettre à syndie (dans une réécriture à venir et probablement très chouette) d'utiliser feedspace comme l'une de ses méthodes de syndication 17:06 <@frosk> pour l'instant, il n'y a pas d'apps clientes pour réellement *utiliser* feedspace pour quoi que ce soit :) j'ai testé avec une appli servlet extrêmement rudimentaire 17:07 <jrandom> (rudimentaire + fonctionnelle)++ 17:07 <@frosk> donc il y a bien sûr un poste ouvert pour un hacker côté client ;) 17:08 <@frosk> il y a encore quelques éléments nécessaires dont feedspace a besoin avant tout test public, mais ça ne devrait plus être très long :) 17:08 <jrandom> bien vu 17:08 <jrandom> quelque chose que nous puissions faire pour aider ? 17:08 <@frosk> j'ai aussi travaillé un peu sur la documentation, qui faisait défaut 17:09 <spinky> Penses‑tu que feedspace sera utilisable pour des gros fichiers ? 17:10 <@frosk> 1) des apps clientes utilisant l'API xmlrpc (encore non documentée), 2) http://feedspace.i2p/wiki/Tasks, 3) participer aux tests quand ce sera le moment 17:10 <@frosk> la prise en charge des gros fichiers n'est pas une priorité pour l'instant, mais peut‑être plus tard 17:10 <@frosk> l'objectif pour la « 1.0 » est des messages plus petits comme des billets de blog et des entrées de discussion, et des événements de toute sorte 17:11 <jrandom> bien qu'alimenter un client bt compatible rss/feedspace avec des fichiers .torrent ne poserait pas de problème 17:11 <@frosk> les gros fichiers peuvent marcher... ou pas :) 17:11 <@frosk> ce serait super chouette 17:12 <jrandom> feed2snark ;) 17:12 <@frosk> j'espère qu'on verra toutes sortes d'applis « adaptateur » :) 17:12 <+Complication> Eh bien, je suis sûr que les gens trouveront des moyens de déplacer de gros fichiers via des canaux... euh, latéraux :) 17:15 <@frosk> je me sens un peu coupable que le code de feedspace utilise toutes sortes de fonctionnalités java1.5. il serait probablement difficile de le compiler/l'utiliser sur du Java libre pour le moment, mais ça rattrapera, j'en suis sûr :) 17:15 <jrandom> ouille 17:16 <jrandom> eh bien, il y a des rumeurs comme quoi gcj adopterait ecj pour les « 1.5‑isms » 17:16 <spinky> Complication : des poneys avec des sacoches pleines de HDD ? 17:16 <@frosk> oui 17:17 <+Complication> spinky : des drones, dans mon cas préféré :P 17:17 * jrandom commence à peine à passer aux « 1.4‑isms » 17:17 <+Complication> Mais je suppose que les poneys marchent aussi :P 17:17 <jrandom> bien que la 1.6 soit vraiment sympa ;) 17:17 <@frosk> pour rester compatible gcj ? 17:18 <@frosk> eh bien la 1.6 n'a de toute façon pas beaucoup d'« isms » pour la plupart des choses, je pense :) 17:18 <+Complication> (ou des hérissons volants parachutant des cartes mémoire) 17:18 <jrandom> gcj/classpath/etc, mais aussi pour les performances (j'ai trouvé la 1.5 un peu plus lourde que la 1.4) 17:19 <jrandom> c'est vrai, les améliorations de la 1.6 sont en grande partie spécifiques à la VM/au bytecode 17:19 <@frosk> hm ok 17:20 * jrandom n'essaie pas de te persuader de ne pas utiliser les 1.5isms. je suis sûr que tu as tes raisons, et par ex. azureus nécessite déjà la 1.5 17:21 <@frosk> eh bien, pas de retour en arrière :) avec un peu de chance, ça ne sera pas trop cahoteux 17:24 <jrandom> ouais, je suis sûr que ça ira bien :) 17:25 <jrandom> ok cool, quelqu'un a autre chose sur 3) feedspace ? 17:25 * frosk câline ses generics et java.util.concurrent ;) 17:25 <jrandom> heheh 17:27 <jrandom> ok, s'il n'y a rien d'autre sur 3, passons à 4) ??? 17:27 <jrandom> quelqu'un a autre chose pour la réunion ? 17:27 <+Complication> Une petite question que j'aurais dû poser sous 2) 17:28 <+Complication> Sais‑tu comment se forment typiquement les tunnels de participation inactifs ? 17:28 <+Complication> Sont‑ils surtout le signe de constructions de tunnel échouées, où seul le créateur sait vraiment que ça a échoué ? 17:28 <+Complication> Ou ont‑ils d'autres raisons ? 17:28 <+Complication> (en dehors, bien sûr, de l'évident — à savoir une appli au repos) 17:29 <jrandom> une appli inactive n'aurait pas de tunnels inactifs (ils seraient testés) 17:29 <jrandom> les tunnels inactifs ont échoué pour une raison ou une autre 17:29 <jrandom> (soit ils n'ont pas été entièrement créés, soit ils ont échoué en cours de fonctionnement) 17:30 <+Complication> D'accord, donc tous les tunnels sont testés de toute façon, et les tests de tunnel devraient générer du trafic... en effet 17:30 <+Complication> Cela m'amène en fait à la deuxième partie de ma question : y aurait‑il un avantage à remarquer qu'un tunnel est inactif et à le supprimer plus tôt ? 17:31 <+Complication> Y a‑t‑il des ressources précieuses à économiser là ? 17:32 <jrandom> aucune — un tunnel qui n'achemine pas de données n'utilise pas de ressources 17:32 <jrandom> (ok, il utilise un peu de RAM, peut‑être 32 octets) 17:32 <+Complication> Ou peut‑être que cela pourrait aider un router à garder une meilleure image de sa charge et de paramètres similaires... 17:33 <jrandom> les prédictions sur l'utilisation de bande passante basées sur l'historique du tunnel sont certainement une question ouverte 17:33 <+Complication> Ou bien ce serait juste un travail vain, et il vaut mieux attendre qu'il expire naturellement ? 17:33 <+Complication> (comme c'est le cas actuellement) 17:34 <jrandom> nous faisions des prédictions, mais cela ne nous apportait pas de bénéfices clairs, donc nous utilisons maintenant un algorithme plus simple 17:34 <+Complication> Aha, donc pas de gain... 17:34 <+Complication> Merci, c'était en gros tout ce que je voulais demander à ce sujet :) 17:34 <jrandom> pas de souci, préoccupation compréhensible 17:34 <jrandom> ok, quelqu'un a autre chose pour la réunion ? 17:35 <+Complication> Oui, si on faisait des prédictions, le pourcentage de tunnels au repos pourrait fausser les estimations 17:35 <+Complication> (si cela variait significativement) 17:36 <jrandom> ouais, nous voudrions conserver le % d'inactivité comme partie de l'estimation 17:36 <jrandom> (nous le faisions — voir la méthode RouterThrottleImpl.allowTunnel) 17:37 <+Complication> Oh, je ne savais pas :) 17:37 <jrandom> et note le nouveau commentaire : 17:38 <jrandom> // ok, ignore any predictions of 'bytesAllocated', since that makes poorly 17:38 <jrandom> // grounded conclusions about future use (or even the bursty use). Instead, 17:38 <jrandom> // simply say "do we have the bw to handle a new request"? 17:39 * Complication est encore en train de parcourir vers le fichier, mais merci :) 17:39 <jrandom> w3rd 17:40 <jrandom> ok, s'il n'y a rien d'autre pour la réunion... 17:40 * jrandom se prépare à conclure 17:41 * jrandom *baf* clôt la réunion