Réunion des développeurs I2P - 22 février 2005

13:04 <jrandom> 0) salut 13:04 <jrandom> 1) 0.5 13:04 <jrandom> 2) Prochaines étapes 13:04 <jrandom> 3) azneti2p 13:04 <jrandom> 4) ??? 13:04 <jrandom> 0) salut 13:04 * jrandom salue de la main 13:05 <jrandom> Notes d'état hebdomadaires en ligne @ http://dev.i2p.net/pipermail/i2p/2005-February/000595.html 13:05 <jrandom> (ouais, seulement une minute ou deux avant la réunion, alors testons votre lecture rapide) 13:05 <+detonate> je pense que j'attendrai que ce soit un peu moins bogué avant de mettre Boondock Saints en ligne, dans ce cas 13:06 <jrandom> pourquoi... c'est... c'est... c'est une violation du droit d'auteur ! 13:06 <+detonate> étranges nouvelles fonctionnalités dans la bêta d'Azureus 13:06 <+detonate> catégories 13:06 <+detonate> haha 13:06 <+detonate> un tracker DHT 13:06 <+detonate> cool 13:07 <jrandom> oui, ça a l'air très cool, mais attaquons les points 1 et 2 avant le 3, hein ? ;) 13:07 <+detonate> salut 13:07 <+detonate> en effet 13:07 <jrandom> on passe au 1) 0.5 13:07 <jrandom> c'est, genre, sorti, tout ça 13:08 <cervantes> youpi ! 13:08 <jrandom> il y aura une nouvelle rév. plus tard ce soir avec un tas de mises à jour (le HEAD de CVS actuel est 0.5-5, avec une -6 en test sur certains routers) 13:09 <jrandom> ça s'est plutôt bien passé, mais on a croisé quelques bugs bizarres en route. mais c'est la vie 13:09 <frosk> je peux dire que la 0.5-5 se comporte de manière _beaucoup_ plus amicale que la -4 (qui me donnait souvent des comptes de tunnels participants par milliers) 13:09 <bla> jrandom : La version 0.5.0.1 corrigera-t-elle le problème de ne pas pouvoir trouver les destinations ? 13:09 <jrandom> ah, eh bien, ça dépend surtout des autres en fait, la build -0 construit réellement des centaines de tunnels 13:09 <bla> s/nor/not 13:10 <jrandom> bla : oui, c'est un bug dans le netDb 13:10 <bla> jrandom : Super ! 13:10 <jrandom> (dans la publication du leaseSet, précisément) 13:11 <jrandom> et oui, la rév. 0.5.0.1 supprimera ce bug occasionnel du proxy qui disparaît 13:12 <jrandom> il y a encore une fuite de mémoire étrange que je n'ai pas trouvée, qui affecte certains utilisateurs 13:12 <bla> Alors, dans l'ensemble, il semble qu'à part ces bugs, le réseau 0.5 se porte très bien. Youpi ! 13:12 <jrandom> à ma connaissance, cela ne touche vraiment que deux ou trois instances I2PTunnel cependant 13:12 <Meomia> est-ce un signe de progrès quand on est passé de 0 à 130 tunnels participants depuis la 0.5 ? 13:13 <jrandom> w3wt 13:13 <jrandom> Meomia : bah, j'ai eu plus de 5000 tunnels ;) 13:13 <jrandom> mais dm a en fait aidé à trouver un bug dans le code du pool exploratoire, donc nous construirons des tunnels plus souvent sur des pairs « random » 13:14 <jrandom> (youpi) 13:14 <Meomia> ok 13:14 <bla> jrandom : Cela signifie-t-il aussi que maintenant, contrairement à la 0.4, chaque pair peut à un moment devenir ta passerelle entrante ? 13:14 <jrandom> oui, pour les tunnels exploratoires 13:15 <jrandom> les tunnels clients n'utiliseront que des pairs dans le palier « fast » 13:15 <bla> bla : Ok. Le fait que les tunnels clients n'utilisent que les pairs fast est bon : sinon, on aurait le problème d'anonymat dont on a parlé avant 13:16 <jrandom> et les performances seraient nulles sinon ;) 13:17 <jrandom> en fait, cela nous amène à 2) Prochaines étapes 13:18 <jrandom> la grosse chose restante pour la série 0.5 est un ensemble de stratégies pour ordonner et/ou filtrer les pairs utilisés dans les tunnels 13:18 <godmode0> jrandom peut-on utiliser NNTP avec i2p ? 13:18 <jrandom> godmode0 : il y a deux serveurs NNTP sur i2p, oui. vois le forum 13:19 <godmode0> jrandom ok je teste 13:19 <godmode0> je peux monter mon serveur aussi ? 13:20 <jrandom> godmode0 : on est en réunion là, mais oui, tu peux faire tourner un serveur 13:20 <godmode0> jrandom ok désolé 13:20 <jrandom> pas de souci 13:20 <jrandom> les stratégies proposées visent essentiellement à améliorer l'anonymat, mais il y a quelques autres objectifs que l'on peut équilibrer là-dedans 13:21 <jrandom> peut-être pouvons-nous trouver un moyen d'intégrer certains chemins d'AS (système autonome) dans la sélection, comme bla l'a suggéré 13:22 <jrandom> cela peut à la fois améliorer l'anonymat (juridictionnel), ou si on essaie de rester au sein d'un AS (ou deux), cela peut améliorer les performances 13:22 <bla> jrandom : Ceci est essentiellement lié à un article des créateurs de Tor : http://theland.i2p/files/routing-zones.pdf 13:22 <jrandom> oui 13:23 <jrandom> il y a toute une flopée de stratégies différentes que les gens peuvent utiliser, et essayer de nouvelles devrait être assez facile 13:24 <jrandom> nous n'allons pas passer des mois à implémenter tout ce qui nous passe par la tête, mais simplement fournir les bases dont la plupart auront besoin. toute personne qui veut en ajouter de nouvelles est vivement encouragée à les brancher 13:25 <jrandom> bref, une fois les bases en place, nous passerons à un focus sur le transport UDP pour la 0.6 13:26 <jrandom> c'est à peu près tout pour 2) prochaines étapes, quelqu'un a des commentaires/questions/inquiétudes ? 13:26 <bla> C'étaient qui déjà les gens qui ont commencé à se pencher sur I2P ? 13:26 <bla> On dirait qu'on n'a pas beaucoup eu de nouvelles d'eux, dernièrement. 13:27 <bla> s/into I2P/into UDP/ 13:27 <bla> désolé 13:27 <jrandom> ah, mule a été malade, bien que je pense que detonate fait des progrès 13:28 <jrandom> detonate : des nouvelles ? 13:29 <jrandom> ou peut-être pas ;) 13:30 <jrandom> ok, on passe à 3) azneti2p 13:30 <+detonate> désolé 13:30 <+detonate> je progresse 13:30 <+detonate> je dois encore terminer la partie réassemblage 13:31 <+detonate> pour ce qui est de découper les données en paquets et de les envoyer de manière ordonnée, ça marche 13:31 <+detonate> passons au 3) 13:31 <jrandom> wikked 13:31 <godmode0> désolé étape 2) i2p a-t-il des problèmes avec des attaques ? 13:31 <bla> detonate : Cool ! Peux-tu nous tenir tous au courant sur le forum ? 13:32 <+detonate> bla : bien sûr 13:32 <tracker> À propos d'azneti2p, regardez ici : http://sourceforge.net/forum/forum.php?thread_id=1233727&forum_id=377614 on dirait que le téléchargement marche, pas le seeding. 13:32 <jrandom> godmode0 : les différentes stratégies d'ordonnancement devraient permettre à l'utilisateur de choisir l'impact des attaques de prédécesseur 13:33 <microsoft> celui qui gère i2p.net devrait ajouter plus de mots à la mode « Enterprise Class Solutions » à la page. 13:33 <+detonate> il faut que quelqu'un vérifie que le nouveau tracker DHT ne se comporte pas mal non plus, vis-à-vis du plugin Azureus 13:33 <tracker> Mes tests locaux semblent le prouver, je peux télécharger avec Azureus mais pas seed. 13:34 <jrandom> hmm ok cool tracker, merci - je sais qu'ils ont mis à jour quelques trucs et publié la b34 hier soir, mais il semble qu'il reste encore des choses à faire 13:34 <jrandom> detonate : bon point 13:35 <tracker> Bon point detonate, j'ai désactivé la DHT car Azureus meurt après quelques heures avec 100 % d'utilisation CPU quand elle est active. 13:35 * jrandom souhaite rappeler que le plugin azneti2p est encore une bêta assez précoce, et que les implications d'Azureus sur l'anonymat n'ont pas été entièrement auditées 13:36 <jrandom> même s'ils aiment certainement que des gens le testent, ceux qui ont besoin d'anonymat devraient être prudents 13:36 <tracker> D'un autre côté, i2p-bt fonctionne vraiment bien. Sauf qu'il ne ferme pas les tunnels, mais ce n'est pas trop grave AMHA. 13:37 <jrandom> oh, ça t'arrive toujours tracker ? je n'ai pas pu reproduire ça 13:37 <jrandom> tu es sur la rév. 0.1.7, n'est-ce pas ? 13:37 <tracker> Oui. 13:38 <jrandom> ok cool, si ça t'arrive tout le temps j'aimerais t'interroger après la réunion pour m'aider à traquer la cause 13:39 <tracker> Peut-être que c'est lié au fait de l'exécuter sous XP plutôt que sous Linux ou Unix. Fermer le tunnel marche avec Azureus, donc je suppose que c'est lié à I2P-BT. 13:39 <jrandom> hmm oui, i2p-bt utilise SAM, tandis qu'Azureus utilise directement le SDK i2p 13:40 <tracker> Au fait. Je t'ai envoyé un rapport de bug sur le forum. Le timestamper meurt sur les dernières builds CVS d'I2P. 13:40 <jrandom> ah cool, merci, je n'ai pas vérifié mes MPs là-bas aujourd'hui 13:41 <jrandom> sur -5 ou -4 ? ou plus tôt ? 13:42 <jrandom> ah, -4. ok cool 13:42 <jrandom> merci, je corrigerai ça pour 0.5.0.1 13:42 <jrandom> ok, quelqu'un a autre chose pour 3) azneti2p ? 13:43 <tracker> Ça arrive aussi sur -5 13:43 <jrandom> tu as un serveur sntp défini explicitement, n'est-ce pas ? 13:44 <tracker> Oui. Les 2 de notre pays. 13:44 <jrandom> je viens de vérifier le code source et l'exception se produit si le # de serveurs concurrents (par défaut = 3) est supérieur au # de serveurs spécifiés (le nouveau défaut est 3) 13:44 <jrandom> ok cool, c'est une correction triviale pour % # servers 13:45 <jrandom> ok, s'il n'y a rien d'autre pour azneti2p, passons au bon vieux 4) ??? 13:46 <jrandom> quelqu'un a autre chose à évoquer pour la réunion ? 13:46 <tracker> Parfait. Je viens de t'envoyer sur le forum les erreurs de log du router lors de la fermeture d'i2p-bt. 13:47 <jrandom> 'k cool, merci 13:47 <cervantes> rien à signaler sinon : beau travail pour le déploiement 0.5, on dirait que ça va déchirer une fois les bugs éliminés 13:48 <tracker> Yep, les dernières builds CVS tournent vraiment bien ici. 13:48 <jrandom> merci, avec votre aide ainsi que celle des autres testeurs 0.5-pre, nous avons pu nettoyer un paquet de problèmes 13:49 <jrandom> les performances ont été meilleures que je ne l'avais prévu, même si le débit n'est pas encore aussi élevé qu'avant. il reste beaucoup à optimiser toutefois 13:49 <cervantes> étrangement les versions pre étaient plus stables... pour moi, mais bon, je les faisais tourner sur une autre machine ;-) 13:49 <jrandom> (et ces satanés bugs à corriger pour atteindre la fiabilité voulue) 13:50 <jrandom> heh ben, oui, mais le réseau -pre était de 5 à 7 routers, tous incroyablement fiables sur des connexions vraiment très rapides 13:50 <cervantes> :) 13:51 <cervantes> inscris-moi pour le test pre de la 0.6 alors :) 13:51 <jrandom> heh 13:51 <tracker> Peut-être que je devrais participer au prochain réseau pre alors. En fournissant une connexion très peu fiable et lente ;). 13:51 <jrandom> la migration 0.6 sera probablement encore plus facile, j'espère, car on pourra simplement ajouter de nouvelles adresses de router au routerInfo (adresses UDP) 13:51 <jrandom> heh word 13:51 <cervantes> je peux mettre mon partage de fichiers de 1 To en ligne... 13:52 <jrandom> nous aurons définitivement besoin de beaucoup d'aide pour les tests 0.6, en couvrant toute une variété de configurations réseau 13:52 <hobbs> la commande ssh « ~C » est astucieuse 13:52 <laberhorst> est-ce que ce sera encore une étape non compatible ? 13:53 <Myo9> Quelqu'un sait quels serveurs NNTP sont en ligne ? 13:53 <jrandom> laberhorst : non, la 0.6 sera rétrocompatible 13:53 <jrandom> Myo9 : je ne sais pas, ils sont peut-être en ligne et simplement mordus par les bugs 0.5-0 13:54 <jrandom> la rév. 0.5.0.1 devrait corriger beaucoup de problèmes, et une fois sortie, la mise à niveau sera fortement recommandée 13:54 <laberhorst> donc il suffit de construire une 0.6 de test et de la donner aux testeurs 13:54 <cervantes> on peut faire en sorte que le trafic BT n'utilise que des routers obsolètes... ça encouragera les gens à mettre à jour ;-) 13:54 <laberhorst> donc grosse fête de mise à niveau demain 13:54 <jrandom> il y aura une annonce sur le forum et la liste quand ce sera prêt 13:54 <jrandom> exact laberhorst 13:54 <jrandom> heh cervantes ;) 13:55 <laberhorst> *impatient de tester pour vous* 13:55 <jrandom> les performances BT ont été plutôt bonnes sur 0.5, j'ai vu beaucoup de transferts de gros fichiers réussis sur les trackers 13:55 <laberhorst> débit d'upload : 8,85 kB/s 13:55 <jrandom> (et l'irc n'a pas été affecté comme avant, au-delà des problèmes que nous avons avec le tunnel de duck) 13:55 <tracker> Ça dépend de ce que tu appelles gros ;) 13:56 <jrandom> tracker : je pense à un fichier particulier de 874 Mo qui a un paquet de téléchargements réussis ;) 13:56 <jrandom> mais c'est vrai, c'est petit pour certains 13:56 <laberhorst> juste du bon vieux porno 13:56 <laberhorst> je suppose ;-) 13:57 <laberhorst> espérons qu'à partir de demain, mon router ne participera pas à >3000 tunnels 13:57 <tracker> Ok, ça c'est gros. 13:57 <laberhorst> ou, si oui, le réseau EST grand 13:57 <jrandom> heh laberhorst 13:58 <jrandom> ok, quelqu'un a autre chose pour la réunion ? 13:58 <laberhorst> au fait, participer à >3000 est-il synonyme d'un bon router fiable dans i2p avec une connexion rapide ? 13:58 <+detonate> je mets Boondock Saints en ligne après avoir pris House ce soir :) 13:59 <+detonate> ça fera un bon 4,1 Go :) 13:59 * laberhorst veut juste remercier les développeurs pour l'écrasement rapide des bugs 13:59 <+detonate> il semble qu'il y ait beaucoup de demande 13:59 <laberhorst> oh, quelques images DVD sont ici, aussi 13:59 <hobbs> detonate : ooh, oui. House. :) 13:59 <tracker> cervantes, as-tu déjà mis à niveau vers phpBB 2.0.12 13:59 <laberhorst> mais attends que la 0.5.0.1 sorte 13:59 <+detonate> devrait aussi donner une bonne mise à l'épreuve à la 0.5.0.1 14:00 <+detonate> ouais 14:00 <+detonate> c'est l'intention 14:00 <jrandom> seules les personnes qui possèdent déjà des copies légales de ces fichiers devraient les télécharger, bien sûr. c'est juste pour des tests 14:00 <jrandom> *tousse* 14:00 <tracker> rofl 14:01 * jrandom note mpaa.i2p 14:01 <+detonate> heh 14:01 <laberhorst> oh, je peux faire des images ISO de Debian, Fedora, SuSE, des photos que j'ai prises,... 14:01 <laberhorst> donc beaucoup de contenu légal 14:01 <laberhorst> si vous voulez juste tester, /dev/random est TRÈS grand 14:01 <Ragnarok> pas toujours 14:02 <laberhorst> au fait, pour les week-ends solitaires : cat /dev/random | grep linux :-) 14:02 <jrandom> heh 14:02 <frosk> /dev/random se vide tout le temps, je préfère /dev/urandom :) 14:02 <frosk> ou le nouveau, amélioré /dev/jrandom 14:02 <jrandom> nan, ça fait un core dump tout le temps 14:03 <jrandom> et a besoin de son repos nocturne 14:03 <Ragnarok> quelle est la meilleure façon de générer de l'entropie pour /dev/random ? 14:03 <laberhorst> on devrait vraiment créer le fonds « offrir quelques bières à jrandom » 14:03 <frosk> appelle ça du repos ou de la collecte d'entropie :) 14:03 <hobbs> Ragnarok : Ça dépend de ce que tu veux vraiment dire. Obtenir un RNG matériel serait plus ou moins la « meilleure » façon :) 14:03 <jrandom> Ragnarok : ça dépend de ton OS (et si tu as du matériel ;) 14:04 <tracker> dd if=/dev/urandom of=/dev/hda bs=1M count=4 Toujours sympa ;) 14:04 <jrandom> nous allons en fait intégrer une implémentation de Fortuna dans l'une de ces builds, et nous aurons besoin de fouiller pour diverses sources d'entropie 14:04 <Ragnarok> sans matériel :P 14:04 <susi23> . o O ( Je pensais que quelqu'un utilisant i2p sait pourquoi il ne devrait pas utiliser /dev/urandom ) 14:05 <cervantes> tracker : les failles de sécurité couvertes par la 2.0.12 sont involontairement corrigées par mon mod_rocinante, donc je ne me suis pas embêté à mettre à jour pour le moment 14:05 <hobbs> susi23 : quand c'est juste pour faire des bêtises, je pense que ça va ;) 14:05 <ant> <Nolar> qui ici fait le port BT en Python ? 14:05 <jrandom> Nolar : ce serait duck 14:06 * duck siffle 14:06 <ant> <Nolar> duck : pourquoi avez-vous changé la taille de bloc de requête à 128k ? 14:06 <susi23> . o O ( le prochain suggère : while true; do echo $RANDOM>> largefile; done ) 14:06 <ant> <Nolar> c'est pour ça qu'az ne peut pas te seed 14:06 <tracker> cervantes : Ok 14:06 <ant> <Nolar> nous bloquons les requêtes> 64k 14:06 <laberhorst> zut, j'ai besoin de plus de mp3 14:06 <frosk> susi23 : pour greper linux un soir d'ennui, /dev/urandom est très bien :) 14:07 <jrandom> ah, vous avez toujours fait ça ? si je me souviens bien, i2p-bt utilise 128k depuis un moment 14:08 <ant> <Nolar> ouais, depuis le début :) 14:08 <ant> <Nolar> une raison d'utiliser 128 ? 14:08 <ant> * duck regarde le log CVS 14:08 <jrandom> ça garde le pipeline rempli, i2p a un peu de latence ;) 14:08 <jrandom> avec 32 Ko, c'est essentiellement une taille de fenêtre fixe de 1 14:09 <jrandom> donc chaque message attend un ACK, tandis que 128 Ko permet à 4 messages de voler dans le RTT 14:09 <@duck> oui, taille de tranche maximale autorisée selon les spécifications BT 14:09 <ant> <Nolar> eh bien, il y a deux façons de gérer ça : 1) on relève la limite à 128k de notre côté, ou 2) vous pipelinez simplement plus de requêtes 14:09 <cervantes> i2pbt est un peu plus réactif qu'avant... peut-être pouvez-vous vous permettre de le réduire... 14:10 <@duck> schni, schna, schnappi 14:10 <ant> <Nolar> donc, au lieu de faire une seule requête de 128k, envoyez-en deux de 64k par exemple 14:10 <hobbs> duck : haha... ce truc a fait le tour du monde. 14:10 <@duck> pourquoi bloquez-vous 128k ? 14:11 <cervantes> *frisson* europop 14:11 <laberhorst> duck : stp. tais-toi OU je t'abats ! 14:11 <tracker> Parfois je regrette d'avoir appris l'allemand il y a quelques années... 14:11 <laberhorst> pas d'europop, pas du tout POP 14:11 * cervantes ordonne au Royaume-Uni de repousser les frontières avant qu'une chanson comme ça n'entre dans les charts 14:11 <laberhorst> tracker : pas grave, ça va 14:12 <ant> <duck> c'est maintenant (2^17)-13 14:12 <ant> <Nolar> duck : eh bien, la limite est là depuis un moment, mais une bonne raison est que les blocs de 128K mettent du temps à être uploadés.....16KB (notre valeur par défaut) permet un contrôle plus fin des requêtes 14:12 <ant> <duck> 13 octets étant la longueur de la commande BitTorrent 14:12 <ant> <duck> aucun problème pour (2^16)-13 14:12 <laberhorst> certaines musiques sont vraiment ridicules, mais la vraie musique industrielle, bof, non 14:13 <ant> <duck> ou revenir à la valeur par défaut ? 14:13 <jrandom> le réduire à 64KB semble le plus simple (c'est un paramètre CLI en ce moment ?) 14:13 <ant> <duck> --download_slice_size 14:14 <ant> <Nolar> eh bien, ma question est : avez-vous une raison impérieuse de rester sur des blocs de 128K, ce qui me semble un peu gros, surtout pour i2p 14:14 <ant> <Nolar> plutôt que de simplement mettre en pipeline plusieurs petites requêtes ? 14:14 <ant> <duck> je n'ai pas de raison. 14:14 <tracker> laberhorst : Parfois je capte quelques chaînes allemandes via satellite. Surtout Viva et cette « Theater Kanal » sont vraiment affreuses... 14:15 <ant> <Nolar> un problème avec les gros blocs est qu'une fois que je te choke, je dois quand même finir d'envoyer ce chunk de 128k 14:15 <jrandom> je ne me souviens pas si le BT vanilla sait pipeliner, mais ça devrait être assez simple (surtout puisque ce n'est pas moi qui le fais ;) 14:15 <ant> <Nolar> ce qui peut prendre un moment 14:15 <laberhorst> tracker : Viva n'est intéressante qu'à l'heure du « hard rock », toutes les autres heures « à ignorer s'il vous plaît », et Theater, je ne sais pas 14:15 <jrandom> avec i2p, 128KB n'est pas vraiment si grand, puisqu'il y a une latence inhérente de l'ordre de quelques secondes 14:15 <ant> <Nolar> ce qui peut perturber le chunk/unchoke 14:16 <@duck> jrandom : est-ce que ça a toujours du sens de soustraire les 13 octets d'overhead de BitTorrent pour que ça tienne dans un message sam ? 14:16 <jrandom> duck : nan, puisque la lib de streaming le réduit déjà davantage en messages de 16KB, donc mets simplement 64KB 14:17 <@duck> ok, 2**16 ce sera 14:17 <jrandom> (et ensuite les tunnels cassent ces messages de 16KB en fragments de 996 octets..) 14:17 <ant> <Nolar> le problème avec 128k, c'est que si j'upload, disons, à 12 k/s, alors il me faudra plus de 10 secondes pour finir ce bloc 14:18 <cervantes> wow c'est presque aussi long que la latence sur irc... 14:18 <jrandom> ce qui fait 1 à 10 RTT (alors que sur le net normal, 10 à 500) 14:18 <+detonate> j'étais prêt à utiliser des blocs de 512K 14:18 <ant> <Nolar> vous pourriez aussi expérimenter avec le pipelining de blocs de 16kb 14:18 <jrandom> heh 14:18 <+detonate> donc 64 est préféré ? 14:19 <ant> <Nolar> tous les clients BT AFAIK utilisent des blocs de 16KB 14:19 <ant> <duck> corrigé dans CVS ; 14:19 <jrandom> wikked, merci duck ! (et Nolar !) 14:19 <ant> <duck> attendez-vous à ce que ça apparaisse dans la version 0.1.8 avec quelques réglages sam i2cp 14:19 <tracker> laberhorst : Son nom complet est « ZDF Theater » ou quelque chose comme ça. Et bon, ils disent qu'ils diffusent un programme culturel de haut niveau. J'espère vraiment que ce qu'ils diffusent n'est pas le meilleur que la culture allemande puisse offrir ;) 14:19 <jrandom> ok, heh, je viens de me rappeler qu'on est toujours en réunion 14:19 <jrandom> quelqu'un a encore quelque chose pour la réunion ? 14:20 <ant> <Nolar> donc si on veut un chunk de 128k, on fait juste 8 requêtes simultanées 14:20 <susi23> . o O ( et on jette les 448 octets restants ? ) 14:20 <jrandom> oui oui 14:20 <laberhorst> tracker : oh, c'est une petite chaîne... arte ou 3sat sont vraiment plus intéressantes 14:20 <laberhorst> et arte est allemand/français :-) 14:20 <ant> <Nolar> si l'uploader peut satisfaire une telle requête, les 128k devraient tous être poussés dans le flux i2p 14:20 <jrandom> cool 14:21 <cervantes> . o O ( se demande pourquoi il peut entendre tout ce que susi pense ) 14:21 <ant> <Nolar> donc, ça vaudrait le coup d'expérimenter des tailles de blocs de 16KB vs 32KB vs 64KB 14:21 <jrandom> oui 14:21 <jrandom> tant que c'est pipeliné, i2p s'en fiche 14:21 <ant> <Nolar> super 14:22 <jrandom> la vitesse à 16KB sans pipelines est assez mauvaise quand même, ou du moins ça l'était 14:22 <tracker> laberhorst : Ok, j'essaierai de capter arte dans les prochains jours... 14:22 <ant> <duck> je suggère de laisser ces réglages pour 0.2 14:22 <ant> <duck> puisqu'elle inclura les améliorations BitTorrent 3.9.1 14:22 <jrandom> ouais, DTSTTCPW 14:22 <susi23> . o O ( oh c'est facile... les gens sont si prévisibles... ) 14:23 <ant> <duck> ce qui pourrait complètement restructurer le code réseau 14:23 <cervantes> http://www.gavelstore.com 14:24 <jrandom> ok, je pense que c'est tout pour le moment, les gens devraient consulter la liste et le site dans quelques heures car la rév. 0.5.0.1 va bientôt sortir 14:24 <ant> <Nolar> ouais, je vois en quoi des requêtes uniques de 16kb seraient lentes 14:24 * jrandom télécharge un marteau 14:24 * jrandom *baf*s la réunion est close