Réunion des développeurs I2P - 17 janvier 2006

15:40 <jrandom> 0) salut 15:40 <jrandom> 1) État du réseau et 0.6.1.9 15:40 <jrandom> 2) Cryptographie de création de tunnel 15:40 <jrandom> 3) Blogs Syndie 15:40 <jrandom> 4) ??? 15:40 <jrandom> 0) salut 15:40 * jrandom fait coucou 15:40 <jrandom> notes d'état hebdomadaires publiées @ http://dev.i2p.net/pipermail/i2p/2006-January/001251.html 15:41 <@cervantes> pfff, heureusement i2p est plus fiable que la NASA 15:41 <jrandom> heh 15:41 <tethra> haha 15:41 <jrandom> (même si j'ai 20 minutes de retard... ;) 15:41 <jrandom> bref, passons à 1) État du réseau et 0.6.1.9 15:42 <wmpq> NSA ou NASA, pas si différentes, hein ? 15:42 <@cervantes> J'ai dit I2P pas jrandom ;-) 15:42 <jrandom> bien vu cervantes ;) 15:42 <tethra> ne sois pas bête, jrandom C'EST i2p ! ;D 15:42 <@cervantes> oh je croyais que c'était un état d'esprit 15:42 <wmpq> [redact] 15:43 <jrandom> heh bon, bref, la 0.6.1.9 est sortie et circule, avec 70% du réseau mis à niveau (merci à tous) 15:43 <Pseudonym> mmmm, une nouvelle version savoureuse 15:44 <+zzz> le taux de réussite de construction des tunnels côté client reste <30% 15:44 <jrandom> Je n'ai pas eu beaucoup de retours indiquant une augmentation substantielle du débit de bout en bout, même si certains routers saturent largement des lignes T1 15:44 <+zzz> en baisse par rapport à ~40% 15:44 <+Complication> La bande passante semble normale, un peu plus élevée que sur le dernier CVS avant la sortie. Le nombre de pairs semble un peu plus élevé. 15:45 <jrandom> hmm, oui, ça ne m'inquiète pas trop zzz, puisque tout ça va être complètement refondu pour la 0.6.2 15:45 <+zzz> la BP moyenne est passée d'environ ~12K à ~20K 15:45 <jrandom> 0.6.1.9 ne devrait pas choisir des pairs plus susceptibles d'accepter (c.-à-d. à haute capacité), mais plutôt se concentrer sur ceux qui ont un débit plus élevé 15:46 <+Complication> Le pourcentage de retransmissions (noté 7% la nuit de la sortie) est descendu à 6 virgule quelque chose 15:46 <jrandom> oui, avec des routers qui poussent 1-300KBps, il va y avoir un biais 15:46 <jrandom> hmm, c'est un taux assez fou Complication, je n'ai vu que 2–3% 15:46 <jrandom> (mais je ne doute pas de ce que tu vois) 15:47 <+Complication> Je sature quasiment mon sortant 15:47 <+Complication> (je veux dire que je sature la capacité de la ligne) 15:47 <jrandom> ah, ça expliquerait 15:47 <+zzz> je reçois toujours des NULLs avant les gets, ce qui entraîne un 405 bad method ; le taux est peut-être en baisse, difficile à dire avec certitude 15:48 <jrandom> oui zzz, il y a des choses à régler dans la streaming lib (bibliothèque de streaming), mais je ne m'y attaquerai probablement qu'après les refontes de tunnel en 0.6.2 15:48 <jrandom> (mais si quelqu'un veut creuser avant, ce serait top, bien sûr) 15:49 <jrandom> Complication : si tu réduis ton limiteur de BP à environ 70% de la capacité de ta ligne, est-ce que le taux d'échec revient à une valeur raisonnable ? 15:49 <+zzz> Je pense toujours que c'est quelque chose qui est entré dans le code juste avant le Nouvel An, donc mieux vaut regarder avant qu'on oublie ces changements récents :) 15:50 <+zzz> Vu pour la première fois le 29 déc. 15:50 <jrandom> oui zzz, certainement. probablement lié à la façon dont on respecte maintenant les timeouts. 15:51 <+Complication> jrandom : je suis justement en train d'essayer :) 15:51 <+Complication> Ajusté quelques secondes avant que tu ne demandes, mais je n'aurai pas de résultat très vite, j'imagine 15:51 <jrandom> mais il y a pas mal de travail à faire là-dedans pour nettoyer, et il est plus important d'implémenter le nouveau code de création de tunnel (qui améliorera sensiblement les taux de réussite de construction de tunnel, ainsi qu'un ensemble complet d'améliorations d'anonymat) 15:51 <jrandom> cool Complication, oui, laisse 3–6 heures 15:51 <jrandom> (pour purger les anciennes valeurs / connexions) 15:52 <+zzz> environ 1%–3% des GETs sont corrompus en ce moment 15:54 <jrandom> donc suggères-tu de revenir sur les changements de la streaming lib (ce qui fera que i2psnark mettra tous ses utilisateurs en OOM en 12–48 heures) et de repousser la refonte de la streaming lib après le travail sur les tunnels 0.6.2, ou de décaler le travail sur les tunnels 0.6.2 d'une ou deux semaines le temps de revoir la streaming lib ? 15:55 <+zzz> certainement pas revenir en arrière 15:56 <+zzz> à toi de voir 15:56 <+Complication> C'est un bug assez sournois, c'est tout ce que je peux dire 15:58 <jrandom> il y a d'autres bugs dans la streaming lib, donc si je retrousse mes manches, je voudrais tous les traiter ensemble (puisqu'aucun des bugs restants n'est manifeste). 15:59 <jrandom> d'un autre côté, en commençant par le travail sur les tunnels, on aura une réduction substantielle de l'utilisation de la bande passante, un pourcentage de réussite de construction accru, un meilleur anonymat, et une meilleure capacité à surveiller l'équilibrage de charge sur le réseau en production 15:59 <Pseudonym> si ce n'est qu'un taux d'échec de 1–3% sur la navigation, je dirais que ça peut attendre, mais ce n'est que mon avis. 16:00 <jrandom> je penche pour faire d'abord le travail sur les tunnels, car après son déploiement, on pourra surveiller le réseau passivement tout en revoyant activement la streaming lib 16:01 <jrandom> (j'aimerais aussi créer une GUI pour éditer/publier sur Syndie, mais ça peut attendre que ces deux choses soient réglées ;) 16:01 <+Complication> C'est le même ordre de grandeur ici aussi 16:02 <+Complication> (sur mon eepsite) 16:04 <jrandom> Ok, ce serait bien que vous gardiez un œil pour voir si ces taux changent ; en attendant, je continue la refonte des tunnels, après quoi viendra celle de la streaming lib (les deux seront en place avant la 0.6.2) 16:05 <jrandom> (ou, si quelqu'un veut creuser la streaming lib [ou voir s'il y a une interaction étrange avec i2ptunnel], dites-moi !) 16:06 <+Complication> jrandom : par curiosité, pourrait-on exclure i2ptunnel avec une appli de test ? 16:07 <+Complication> par ex., si une appli d'exemple comme celle de jnymo recevait elle aussi des nulls, cela innocenterait i2ptunnel de la liste des causes suspectes ? 16:07 <jrandom> on pourrait brancher une implémentation I2PSocket légère (in-VM) pour faire ça, certainement 16:07 <+Complication> Puisque, si je me souviens bien (IIRC), cet exemple utilisait directement la streaming lib... 16:08 <+Complication> (ou presque directement) 16:08 <jrandom> oui, bien sûr, si quelque chose utilisant la streaming lib peut reproduire le problème, ça disculperait i2ptunnel 16:10 <+Complication> Hmm, à moins que quelqu'un d'autre ne s'y mette avant (je vais essayer de finir le truc de webcache d'abord) je pourrais essayer d'émuler HTTP avec quelque chose comme ça... 16:10 <jrandom> nickel, merci Complication 16:10 <jrandom> ok, autre chose sur 1) État du réseau et 0.6.1.9 ? 16:11 <jrandom> sinon, passons tranquillement à 2) Cryptographie de création de tunnel 16:11 <+Complication> Nan, ça ne mènera peut-être à rien d'utile, ou je vais peut-être trébucher en cours de route... mais c'est une possibilité qui m'intrigue 16:11 <jrandom> oui, ça vaut clairement le coup d'explorer, Complication 16:12 <jrandom> (et les explorations n'ont pas besoin d'aboutir pour valoir la peine :) 16:12 * cervantes repère une exception « moo » dans les changements de source avant le Nouvel An... peut-être que c'est ça le problème ? :) 16:13 <jrandom> ok, il y a une nouvelle spec de crypto de création de tunnel référencée dans l'email, basée sur la discussion que toad, Michael et moi avons eue sur la mailing list en octobre dernier 16:14 <jrandom> jetez-y un œil et dites-moi ce que vous en pensez — ce ne sera pas déployé sur le réseau en production avant un moment, car d'autres choses doivent être implémentées d'abord, mais ça arrive 16:14 <+Complication> « moo » est-il un mot réservé en Java ? ;P 16:14 <+zzz> sur 2) j'aiderai à revoir les références dans le mail de statut 16:14 <+Complication> Sur le sujet de la crypto de tunnel, peux-tu vérifier si la reformulation suivante est correcte — je voudrais juste m'assurer que j'ai bien compris... 16:14 <jrandom> merci zzz 16:15 <+Complication> "Chaque saut chiffre tous les enregistrements avec sa reply key (clé de réponse), qu'il a déchiffrée depuis son enregistrement à l'aide de sa clé privée ElGamal et, en chiffrant de cette façon, retire une couche de déchiffrement (ou devrais-je dire, de chiffrement) faite par le propriétaire du tunnel, rendant l'enregistrement du participant suivant lisible avec la clé privée ElGamal du participant suivant ?" 16:15 <jrandom> Complication : oui 16:15 <+Complication> Ou ma reformulation est-elle tout simplement fausse ? 16:16 <+fox> <jme___> et bien trop compliqué, si je puis me permettre 16:16 <jrandom> c'est correct je crois, mais oui, trop de propositions :) 16:16 <+Complication> Je n'ai pas pensé à une meilleure façon de le visualiser. C'était déjà assez dur comme ça. :P 16:16 <jrandom> (ou jme___ tu dis que l'algorithme est trop compliqué ?) 16:17 <+fox> <jme___> non, j'ai essayé rapidement de lire la doc et j'ai abandonné car trop de choses nécessitent des connaissances préalables 16:17 <+fox> <jme___> d'un autre côté je n'ai pas beaucoup essayé :) d'autres choses à faire 16:17 <jrandom> Complication: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/java/src/net/i2p/router/tunnel/BuildMessageProcessor.java?rev=HEAD 16:18 <+fox> <jme___> est-ce que cette revue par les pairs est une formalité, ou tu es vraiment inquiet/incertain à son sujet ? 16:19 <+Complication> Eh bien, c'est toujours bien de savoir ce que fait un mécanisme sous-jacent... 16:19 <jrandom> Je suis confiant que ça fait ce que je veux que ça fasse, mais je suis sincèrement intéressé si quelqu'un voit un problème 16:19 <+fox> <jme___> si c'est le second, je pourrais y consacrer du temps, mais mes connaissances datent et ne sont pas fraîches 16:20 <+fox> <jme___> sinon je fais confiance :) 16:20 <jrandom> la section notes contient quelques questions - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt-creation.html?rev=HEAD#tunnelCreate.notes 16:22 <jrandom> il n'y a pas d'urgence, il faudra probablement une ou deux semaines avant que cette nouvelle crypto soit effectivement utilisée dans le router 16:22 <@cervantes> jrandom : à ce sujet, y aurait-il un gros impact sur les performances à injecter un délai aléatoire entre les sauts ? 16:22 <@cervantes> car ça semble l'option la plus sensée pour prévenir les attaques temporelles 16:23 <jrandom> c'est de la création de tunnel, donc un délai ne ferait pas de mal, bien qu'il puisse provoquer une expiration prématurée du lease set en cas de pannes catastrophiques 16:25 <jrandom> eh bien, je ne suis pas sûr de l'efficacité de ces délais. ils peuvent aider sensiblement, ou pas. les tunnels actifs, cependant, peuvent simplement utiliser le blending pour détecter des pairs en collusion sur ce tunnel de toute façon, donc je ne suis pas sûr que ça change grand-chose 16:25 <+fox> <jme___> ok je relis 16:27 <jrandom> merci. ok, pas d'urgence, mais si/quand quelqu'un a des idées, envoyez-les-moi (ou à la liste, ou sur votre blog, etc.) 16:27 <jrandom> ok, autre chose sur 2, ou on passe à 3) Blogs Syndie ? 16:29 <jrandom> (considérez que c'est fait) 16:29 <jrandom> ok, des nouveautés sympas côté blog dans syndie, plongez-y ;) 16:29 <@cervantes> trop cool 16:30 <jrandom> les groupes à gauche peuvent contenir des liens vers des URLs arbitraires, ainsi que des liens vers des blogs, des billets au sein des blogs, ou des pièces jointes à des billets dans les blogs 16:30 <jrandom> il y a aussi tout un tas d'améliorations possibles, comme ajouter des styles par blog ou par tag pour les billets, des icônes, etc. si quelqu'un veut creuser ça, ce serait top (et aurait un impact très visible :) 16:31 <@cervantes> au fait, les liens externes définis dans les commentaires devraient aussi avoir un attribut title défini à l'URL cible (comme tu l'as fait sur le panneau de gauche) 16:31 <@cervantes> commentaires/billets 16:32 <jrandom> ah, bonne idée 16:33 <jrandom> (net.i2p.syndie.sml.BlogPostInfoRenderer method renderLinks(...) :) 16:34 <@cervantes> *griffonne* 16:35 <jrandom> de quoi d'autre les blogs syndie ont-ils besoin pour offrir une alternative fonctionnelle aux eepsites informatifs ? évidemment, syndie c'est du contenu statique, donc certaines choses ne sont pas possibles, mais on peut publier du contenu et laisser les gens commenter 16:36 <jrandom> y a-t-il des personnalisations particulières que vous voulez pouvoir faire ? si oui, dites-moi 16:37 <DoubtfulSalmon> jrandom : mettre à jour du contenu existant via script ? 16:37 <@cervantes> archiver par date 16:37 <jrandom> DoubtfulSalmon : via script ? 16:37 <jrandom> cervantes : ah, comme un petit widget de calendrier, plutôt que les liens « 5 entrées plus anciennes » ? 16:38 <@cervantes> oui 16:38 <DoubtfulSalmon> jrandom : disons que je veux que ce fichier/texte remplace cet autre fichier/texte. Comment je fais ? 16:38 <jrandom> ok cool, oui, ça devrait être vraiment facile (si quelqu'un pond le HTML :) 16:38 <@cervantes> ou plus simplement « voir les billets du mois dernier » 16:39 <@cervantes> jrandom : tu as juste besoin d'un tableau 7x6 avec quelques chiffres dedans ;-) 16:40 <jrandom> DoubtfulSalmon : modifier du contenu qui a déjà été publié est une piste intéressante. de manière générale, ça ne marcherait pas toujours, puisque ça devrait fonctionner comme les messages de contrôle usenet (annulation d'un ancien post, etc.) 16:40 <jrandom> DoubtfulSalmon : d'un autre côté, tu peux simplement publier un nouveau fichier/entrée et changer les liens dans la colonne de gauche pour pointer vers le nouveau fichier/la nouvelle entrée 16:40 <jrandom> (comme ça, l'ancien contenu est toujours là, mais les gens sont dirigés vers le nouveau) 16:41 <DoubtfulSalmon> jrandom : oui, ça irait si l'ancien contenu restait là, du moment que les liens de tout le monde pointent vers le nouveau contenu, sans qu'ils aient à changer leur contenu. 16:41 <jrandom> construire un wiki complet à partir de ça, en publiant essentiellement des diffs que syndie rendrait au final, est possible, mais ce serait peut-être excessif 16:41 <jrandom> hmm, ok je vois ce que tu veux dire 16:42 <jrandom> donc, tu veux la possibilité d'avoir des liens redirigeables, plutôt que les liens existants vers des versions exactes du contenu 16:43 <jrandom> peut-être que ça pourrait se faire en liant vers un signet du blog, et la version exacte se trouve en chargeant les signets actuels de ce blog et en voyant où il pointe 16:44 <jrandom> d'un autre côté, la nouvelle version pourrait être marquée comme une réponse à l'ancien post, ainsi quand les gens suivent un lien, ils peuvent aller à la réponse qui remplace le contenu 16:44 <jrandom> (quoique ce ne soit sans doute pas aussi transparent) 16:44 <DoubtfulSalmon> oui : disons que je veux un lien vers, disons, une image radar courante, ou quelque chose comme ça qui sera mis à jour toutes les 10 min. Ce n'est pas grave si le contenu ne se propage pas partout sur le net, mais si quelqu'un d'autre lie vers ma page, l'utilisateur devrait voir l'image actuelle. 16:45 <jrandom> eh bien, ça dépend de ce qu'ils veulent faire — veulent-ils lier l'image telle qu'elle était au moment où ils s'y réfèrent, ou veulent-ils lier le service qui rend l'image quand le lecteur la consulte 16:45 <+Complication> cervantes : bizarrerie du jour :D Dernier post dans : http://forum.i2p/viewtopic.php?t=1199&start=15 16:46 <+Complication> On aurait dit un de nos suzerains robotiques de plus :P 16:46 <jrandom> mais c'est une bonne idée de supporter les deux concepts, et je ne pense pas que ce serait très difficile 16:46 <@cervantes> merci 16:46 <jrandom> quoique ça nécessiterait une petite extension de sml (e.g. [blog bloghash="ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=" bookmark="radar.webp"]) 16:47 * cervantes améliorera les défenses du forum si on commence à en avoir beaucoup 16:47 <@cervantes> (je sais déjà comment arrêter celui-là) 16:47 <DoubtfulSalmon> jrandom : ils devraient pouvoir lier à la fois une version statique, pour autant que le syndicator n'ait pas supprimé le contenu, ainsi qu'une URL générique qui pointe vers la dernière version 16:47 <jrandom> (qui regarderait la meta post actuelle d'ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c= pour les signets, en tirant l'URI exacte de celui nommé « radar.webp ») 16:48 <DoubtfulSalmon> jrandom : est-ce que ça pourrait se faire maintenant avec quelque chose comme : « Afficher le billet le plus récent dans le tag <chaîne bizarre> » 16:48 <jrandom> ah, bon point — oui, c'est possible 16:49 <jrandom> ça pourrait même être restreint à « Afficher le billet le plus récent par $author avec le tag $tag » 16:49 <jrandom> (ainsi d'autres ne pourraient pas l'usurper) 16:49 <DoubtfulSalmon> donc peut-être ajouter une sorte d'UI pour que l'utilisateur n'ait pas à voir des tags bizarres et tout ça 16:50 <jrandom> il y a un exemple de quoi ça a l'air là-haut, même si je n'ai pas l'URI en tête... mais oui, c'est un lien autour du texte lié 16:50 <DoubtfulSalmon> Je suppose que toutes ces informations peuvent venir sous forme d'URL. 16:51 <jrandom> mais écrire le SML source est clairement compliqué, d'où l'utilité d'une GUI pour créer du SML 16:51 <jrandom> ce sont des attributs sur les balises SML, pas des URLs 16:52 <@cervantes> et une GUI SML sera délicate sans JavaScript 16:52 <DoubtfulSalmon> mais on peut mettre en signet un résultat de recherche, non ? 16:52 <jrandom> qu'est-ce qu'un résultat de recherche ? 16:52 <jrandom> et que veux-tu dire par mettre en signet ? 16:52 <@cervantes> (ou une extension de navigateur ;-) 16:52 <jrandom> oh, des signets côté navigateur, oui 16:52 <+Complication> Un résultat de filtre ? 16:53 <jrandom> mais ces signets ne sont généralement pas partageables 16:53 <DoubtfulSalmon> euh : un « obtenir le billet le plus récent par X avec le tag Y » 16:53 <jrandom> (en fait, la plupart le sont, mais ce n'est pas universel, car ce sont des URLs et non des URIs)) 16:53 <DoubtfulSalmon> oui, ce serait bien que d'autres blogs puissent aussi y lier 16:54 <jrandom> DoubtfulSalmon : ils peuvent, avec sml 16:54 <jrandom> [blog tag="Y" bloghash="X"] 16:54 <DoubtfulSalmon> oh super 16:55 <jrandom> cervantes : JavaScript, ou XUL, ou Java, ou une autre appli cliente spécifique à l'OS 16:57 <@cervantes> ah cool, donc une dépendance à un script ou à un plugin ne te gêne pas 16:57 <jrandom> (quand notre site web sera refondu pour 0.6.2, syndie aura assurément un site expliquant wtf est tout ce truc syndie, et comment il peut tout faire sauf la vaisselle ;) 16:57 <@cervantes> (tant que ça se dégrade proprement) 16:57 <jrandom> cervantes : syndie devrait être function avec lynx, mais il y a beaucoup de place pour des clients riches 16:58 <jrandom> (s/function/functional/) 16:58 <@cervantes> d'accord... donc les utilisateurs de lynx auraient un tableau de référence SML, mais rien de plus 16:58 <jrandom> oui, comme on a maintenant 16:58 <jrandom> quoique peut-être un sml simplifié, je ne sais pas. 17:01 <+Complication> jrandom : penses-tu qu'il soit même vaguement plausible... que le bug de null soit lié à l'encodage gzip ? 17:01 <+Complication> Je réfléchissais à comment désactiver le gzipping pour mon tunnel eepsite... 17:01 <+Complication> Ou est-ce complètement improbable ? 17:01 <@cervantes> il y a eu des trucs de compresseur http ajoutés juste avant le Nouvel An dans i2ptunnel 17:03 <jrandom> oui, c'est possible — yo ucan le désactiver côté client avec i2ptunnel.gzip=false (sur /configadvanced.jsp). pour l'instant je ne pense pas que tu puisses le désactiver dans i2ptunnelhttpserver toutefois 17:03 <+zzz> c'est côté requête qu'il n'y a aucune compression 17:03 <+zzz> le serveur ne compressera pas si le client est réglé sur false 17:03 <+Complication> zzz : oh, exact, j'avais oublié 17:04 <jrandom> (mais sans trop de difficulté tu pourrais l'ajouter à I2PTunnelHTTPServer [ligne 310, etc) 17:04 * Complication est un idiot, et s'en excuse 17:04 <@cervantes> (ou tu pourrais utiliser un tunnel normal) 17:04 <+Complication> Aha, merci... 17:05 <jrandom> hmm, pourtant au moment où i2ptunnelhttpserver reçoit le GET, le null est déjà là 17:05 <+zzz> oui, j'ai fait repasser orion à un tunnel HTTP, ce qui aide grandement les temps de chargement de ses pages puisqu'elles sont à nouveau compressées 17:05 <+Complication> J'ai complètement oublié que le gzipping commence quand le client et le serveur ont accepté de le faire 17:05 <jrandom> donc ça peut être côté client, mais certainement pas côté serveur 17:05 <jrandom> oui zzz, c'est incroyablement rapide maintenant :) 17:05 <+zzz> c'est côté _request_ et pas côté _response_ — ça pourrait être côté client ou serveur 17:06 <jrandom> vrai 17:09 <jrandom> ok, quelqu'un d'autre a quelque chose sur 3) Blogs Syndie ? 17:09 <jrandom> sinon, passons à 4) ??? 17:09 <jrandom> quelqu'un a autre chose à soulever pour la réunion ? 17:10 <cat-a-puss> Complication : les flux gzip de Java + les tunnels I2P. NE fonctionnent PAS et c'est un bug de Sun 17:10 <jrandom> hmm cat-a-puss ? vraiment ? 17:10 <+zzz> Mise à jour des connexions persistantes HTTP : côté client quasiment fini, côté serveur de bons progrès, beaucoup de blindage et de tests à faire, achèvement estimé 2–4 semaines 17:10 <jrandom> bravo zzz ! 17:11 <cat-a-puss> jrandom : oui je t'en ai parlé il y a longtemps, je pourrais probablement retrouver la longue explication du pourquoi, mais il vaut sans doute mieux simplement documenter ça quelque part car il n'y a aucune raison de le faire. 17:12 <jrandom> hmm je n'ai pas le contexte, qu'est-ce qui ne marche pas exactement ? quel est le bug de Sun ? 17:14 <dust> j'obtiens des logs bizarres comme ceci : 21:21:59.816 WARN [%d0%a2%d1%4f] net.i2p.util.EepGet : ERR: status <html> 17:14 <jrandom> hmm, intéressant 17:15 <jrandom> quel tracker ? 17:15 <cat-a-puss> jrandom : si je me souviens bien, Sun utilise des zips sans en-tête et un nombre magique pour indiquer que c'est un flux zip. Mais ce nombre se trouve être négatif, donc si tu te retrouves à créer un flux zip dans un flux zip pour une raison quelconque, il lit les données du flux comme une séquence d'octets non signés et donc le nombre magique est converti en un autre nombre positif. (je rate probablement des détails mais c'est l'idée) 17:16 <dust> par exemple le OSDevWithCVS_3E.pdf.torrent 17:17 <dust> d8:announce540:http://YRgrgTLGnbTq2aZOZDJQ... 17:17 <jrandom> hmm, je n'en sais rien, et je ne suis pas sûr de comment ça affecterait un flux gzip sur i2ptunnel (si c'était le cas, tout échouerait, car on gzip tout) 17:19 <jrandom> ok cool dust, donc le tracker de postman. hmm, tu es en 0.6.1.9 dust ? 17:20 <cat-a-puss> jrandom : oui, ça fait presque un an que j'ai eu ce problème donc je ne m'en souviens pas très bien, et je ne sais pas si c'est corrigé en 1.5 mais j'ai vraiment galéré à comprendre pourquoi tous les types de flux normaux marchaient, mais dès que je les enveloppais dans un flux compressé ils échouaient tous. 17:20 <dust> oui 17:20 <jrandom> cat-a-puss : on a beaucoup changé les choses pour la compression sur i2p l'année dernière ;) 17:21 <jrandom> (et je n'utilise pas personnellement la 1.5) 17:21 <jrandom> mais on fait notre propre encodage zip explicitement, plutôt que d'utiliser leur flux empaqueté (mais pour des raisons d'anonymat/efficacité, pas de compatibilité) 17:22 <@cervantes> zzz : où exactement dans la requête le null se produit-il ? juste après GET ? 17:22 <+Complication> Avant, si je me souviens 17:23 <+fox> <lordalbert> salut 17:23 <+Complication> Note annexe : un Celeron 300 affiche un pourcentage de retrans. deux fois moindre qu'un Sempron 17:23 <jrandom> 'lo lordalbert 17:23 <jrandom> cool Complication, 2–3% est raisonnable (bien que je préfère moins, bien sûr) 17:23 <@cervantes> ce serait intéressant d'envoyer une rafale de requêtes HEAD ou autre... 17:24 <jrandom> oui, un ensemble de tests locaux serait super, même si, de mémoire (iirc), Complication a essayé ça il y a quelque temps sans erreurs 17:24 <+fox> <lordalbert> quelqu'un peut faire un tracker anonyme ? J'essaie mais je ne comprends pas comment utiliser le tunnel 17:24 <+Complication> cervantes : j'ai déjà essayé de le provoquer, avec un wget récursif entre mes 2 nœuds 17:24 <+Complication> Je me suis lassé avant que ça arrive 17:25 <@cervantes> heh 17:26 <+fox> <lordalbert> 'lo b0unc3 ;) 17:26 <+fox> <b0unc3> lordalbert, :D 17:26 <+Complication> lordalbert : sur quelle partie aurais-tu besoin de conseils ? 17:27 <+Complication> Pour la mise en place de trackers, je ne sais malheureusement pas. 17:27 <+Complication> Pour I2PTunnel, je peux essayer d'expliquer... 17:27 <+fox> <lordalbert> J'ai installé BTtracker, et ça marche parfaitement 17:28 <+Complication> À noter aussi que, pour que le tracker reste anonyme, il devrait probablement tourner avec une configuration assez prudente 17:28 <+fox> <lordalbert> maintenant, j'aimerais l'anonymiser 17:28 <+fox> <lordalbert> donc 17:28 <jrandom> Je suis sûr qu'on peut t'aider à régler ça après la réunion. tu ne devrais pas utiliser des trackers génériques, il t'en faut un conçu pour l'anonymat 17:28 <+fox> <lordalbert> je viens juste de faire un i2ptunnel 17:29 <jrandom> (par ex. la modification bytemonsoon que tu peux trouver sur n'importe quel tracker i2p, ou dans le cvs) 17:29 <+fox> <lordalbert> maintenant, j'aimerais savoir comment utiliser ce tunnel. J'ai déjà fait un tunnel 17:29 <jrandom> ok, quelqu'un a autre chose pour la réunion ? 17:30 <jrandom> lordalbert: http://localhost:7657/i2ptunnel/ devrait te permettre de créer un 'http server tunnel' pointant sur ton serveur web/tracker, mais ton tracker ne fonctionnera pas à moins qu'il ait été modifié pour un usage anonyme 17:30 <+fox> <lordalbert> jrandom, quel tracker dois-je utiliser ? 17:31 <+Complication> postman utilise une version modifiée de ByteMonsoon, je crois 17:32 <jrandom> i2p-bytemonsoon a été modifié pour un usage anonyme — il y a un zip @ http://i2p-bt.postman.i2p/, et il y a le cvs sur http://dev.i2p.net/cgi-bin/cvsweb.cgi/bytemonsoon/ mais je n'en sais pas beaucoup plus 17:32 <+fox> <lordalbert> bytemonsoon n'est-il pas obsolète ? 17:32 <jrandom> si ça marche, ce n'est pas obsolète. ça marche 17:33 <+fox> <lordalbert> ok XD 17:33 <jrandom> il y a beaucoup de trackers, et si un développeur veut le modifier pour qu'il fonctionne de manière sûre et anonyme, ce serait génial 17:33 <+Complication> Peut très bien être un peu vieux... mais fonctionne définitivement avec des destkeys au lieu des IP... 17:33 <+Complication> Je ne peux rien dire sur la sécurité et l'absence de fuites 17:34 <jrandom> (il a été modifié par duck et al. pour l'anonymat et la sécurité) 17:34 <+Complication> Mais il est en ligne depuis un moment, et ça a l'air de tenir... 17:35 <jrandom> ok, s'il n'y a rien d'autre pour la réunion... 17:36 * jrandom conclut 17:36 * jrandom *baf* clôt la réunion