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

16:10 <jrandom> 0) salut 16:10 <jrandom> 1) 0.6.1.3 16:10 <jrandom> 2) Freenet, I2P, et darknets (oh là là) 16:10 <jrandom> 3) attaques de bootstrap de tunnel 16:10 <jrandom> 4) I2Phex 16:10 <jrandom> 5) Syndie/Sucker 16:10 <jrandom> 6) ??? 16:10 <jrandom> 0) salut 16:10 * jrandom agite la main 16:10 <jrandom> les notes d'état hebdomadaires sont en ligne à http://dev.i2p.net/pipermail/i2p/2005-October/001017.html 16:10 <dust> youpi, ça marche maintenant. merci Gregor 16:10 <cervantes> salut 16:11 <+fox> <blx> salut 16:11 <jrandom> ok, passons à 1) 0.6.1.3 16:11 <jrandom> vous avez tous mis à jour à un bon rythme, merci ! 16:12 <jrandom> les choses semblent en état raisonnable, mais je n'ai pas grand-chose à ajouter au-delà de ce qui est dans les notes d'état 16:12 <jrandom> quelqu'un a des questions/commentaires/inquiétudes à propos de 0.6.1.3 ? 16:13 <jrandom> ok sinon, allons directement à 2) Freenet, I2P, et darknets (oh là là) 16:13 <cervantes> 609 pairs connus ! 16:14 <cervantes> (w00t) 16:14 <jrandom> ouais, le réseau a bien grossi 16:14 <+fox> <blx> oh là là ! 16:14 * cervantes organise un pari sur dans combien de temps on atteindra le grand 1000 16:14 <jrandom> héhé 16:14 <tethra> héhéhé 16:15 <tethra> on parie avec du cash numérique ? ;) 16:15 <cervantes> mais ça montre à quel point le cœur I2P est devenu solide dernièrement, vu que l'adoption utilisateur a accéléré 16:16 <cervantes> nan... jrandom a déjà, sans le savoir, donné tout son argent bière pour cette année 16:16 <jrandom> héhé 16:16 <jrandom> ok, sur le 2), je ne suis pas sûr d'avoir autre chose à ajouter sur le sujet (je pense qu'on a fait le tour). quelqu'un a des questions/commentaires/inquiétudes à ce propos ? 16:18 <cervantes> comme tu l'as dit, à défaut d'autre chose ça a stimulé des discussions de sécurité semi-liées intéressantes, c.-à-d. 3) 16:18 <jrandom> sinon, on peut avancer rapidement vers 3) attaques de bootstrap de tunnel 16:18 <jrandom> ouais, c'est sûr 16:19 <jrandom> le point que Michael a soulevé quantifie une intuition générale que j'avais, mais c'est bien de la rendre explicite 16:20 <jrandom> il y aura d'autres discussions sur la nouvelle attaque plus tard ce soir (une fois que je pourrai rédiger une réponse), mais la première ne semble pas poser grand problème 16:21 <jrandom> est-ce que ça parle aux gens, ou avez-vous des questions ou des inquiétudes à ce sujet ? 16:22 <cervantes> heh... ça veut dire soit que tout le monde est ok avec ça, soit qu'ils ne comprennent ni queue ni tête aux enjeux 16:23 <cervantes> je me mets dans la catégorie 'l'ignorance, c'est le bonheur' 16:23 <jrandom> heh c'est en gros une attaque où les méchants se trouvent être l'extrémité sortante de chaque tunnel que tu as jamais construit 16:23 <jrandom> or, quand tu viens de démarrer, "chaque tunnel que tu as jamais construit" est un très petit nombre (p. ex. 0, 1, 2) 16:24 <jrandom> mais après quelques secondes, le nombre devient assez grand pour transformer (c/n)^t en un nombre vraiment, vraiment petit 16:25 <tethra> (c/n)^t c'est... 16:25 <jrandom> (c'est une des raisons pour lesquelles on ne démarre pas le i2cp listener - et donc, i2ptunnel/etc - avant un petit moment après le démarrage) 16:25 <jrandom> c == nombre de pairs de connivence (méchants), n == nombre de pairs dans le réseau, t == nombre de tunnels que tu as construits. 16:25 <cervantes> d'accord... 16:25 <tethra> ah 16:26 <jrandom> donc quand t augmente, la probabilité de réussite de l'attaque devient très faible 16:26 <cervantes> donc pour que ce soit même viable, il faudrait commencer à utiliser ton router pour des tâches sensibles dans les deux minutes qui suivent son démarrage ? 16:26 <jrandom> (ou, en tout cas, plus petite que la probabilité de contrôler tous les sauts dans un tunnel) 16:26 <tethra> ahh, je vois 16:27 <jrandom> cervantes : immédiatement, avant que le 3e tunnel ne soit construit 16:27 <jrandom> (en supposant que tu utilises des tunnels à 3 sauts) 16:27 <cervantes> c'est assez improbable 16:28 <cervantes> rien que d'un point de vue cas d'usage 16:28 <jrandom> exactement. 16:28 <jrandom> et comme on construit plus de 3 tunnels au démarrage avant de laisser tourner des clients, ce n'est pas qu'une question de probabilité 16:28 <jrandom> mais c'est bien de quantifier l'attaque quand même 16:29 <cervantes> est-ce que ça vaut le coup de laisser le router mouliner un peu plus longtemps pour se prémunir de toute éventualité ? 16:30 <cervantes> ou mouliner plus fort... 16:30 <jrandom> peut-être. si on ignore le temps d'établissement de connexion ainsi que la sélection non aléatoire des pairs, ça n'a aucune probabilité 16:31 <tethra> c'est une raison de dire "woot !", j'imagine ? 16:32 <jrandom> ouais, même si d'un point de vue ingénierie, on ne devrait pas ignorer ces caractéristiques ;) 16:32 <jrandom> donc, pour la 0.6.2 on voudra peut-être regarder ça lors de la refonte de l'implémentation de sélection/ordonnancement des pairs de tunnel, pour s'assurer que ça se comporte sainement 16:34 <jrandom> ok, s'il n'y a rien d'autre sur le 3), passons au 4) I2Phex 16:34 <jrandom> sirup n'est pas là, et je n'ai pas vu striker sur irc - redzara, tu es là ? 16:36 <+redzara> oui 16:36 <+redzara> Première passe presque terminée : porter le mod de Sirup vers le dernier CVS de Phex. 16:36 <jrandom> chouette ! 16:36 <+redzara> ensuite : deuxième passe : diff du code de Sirup vers le code de base de Phex utilisé dans la release initiale, pour être sûr que je n'oublie rien :) 16:37 <+redzara> peut-être terminé pour ce week-end 16:37 <jrandom> wow ce serait génial 16:37 <+redzara> troisième passe : refactoriser la couche de communication avec GregorK 16:37 <+fox> <GregorK> j'espère que tu es au courant que dans le dernier CVS de Phex le code de téléchargement n'est pas stable et le fichier de téléchargement n'est pas compatible avec les versions précédentes 16:38 <jrandom> c'est I2P, on a l'habitude de l'instabilité :) 16:38 <+fox> <GregorK> :) 16:38 <+redzara> pour la dernière passe, comme je n'ai actuellement aucun contact avec GregorK, ça risque d'être assez dur :( 16:38 <jrandom> GregorK : que recommanderais-tu pour l'intégration ? 16:39 <+fox> <GregorK> eh bien tu as maintenant un contact avec moi ;) 16:39 <jrandom> ah 'k redzara, les deux premières sont déjà assez grosses de toute façon :) 16:39 <+redzara> GregorK : salut mec 16:40 <+redzara> GregorK : j'ai lu attentivement tous les codes 16:40 <+fox> <GregorK> j'ai une idée sur la façon de construire une couche... je peux essayer de la préparer au mieux et ensuite on verra comment ça s'intègre et ce qu'il faut modifier 16:40 <+fox> <GregorK> tous ?? wow... 16:40 <+redzara> Gregork : oui, tous !! 16:41 <cervantes> il connaît même la taille de tes sous-vêtements 16:41 <Rawn> :D 16:41 <+fox> <GregorK> super... la prochaine fois que je fais du shopping je n'aurai qu'à te demander... 16:43 <+fox> <GregorK> ce serait bien si on pouvait peut-être avoir quelqu'un de l'équipe i2phex aussi dans l'équipe phex.. 16:43 <jrandom> redzara : alors, tu penses qu'on aura une release I2Phex 0.1.2 avec les résultats de ta deuxième passe avant qu'on ne fusionne tout dans une couche plugin dans le Phex principal ? ou bien tout en une seule fois ? 16:43 <+redzara> désolé, mais je ne comprends/parle/lis/écris pas assez bien l'anglais pour rire de ce que tu as écrit 16:43 <+fox> <GregorK> ça aiderait aussi à résoudre des bugs présents des deux côtés 16:44 <jrandom> GregorK : avec un peu de chance on trouvera un moyen pour que la partie I2P ne soit qu'un plugin léger dans Phex, non ? 16:44 <jrandom> ou tu penses que les deux devraient rester séparés ? 16:44 <+redzara> jrandom : je pense qu'on pourrait avoir un Phex 2.6.4 over I2P, pour moi I2Phex est fini 16:45 <jrandom> fini ? 16:45 <+fox> <GregorK> je ne suis pas sûr qu'on puisse faire comme ça dès le début, mais je pense que la majeure partie pourrait être séparée dans un plugin. 16:45 <jrandom> cool, ouais, c'est beaucoup de boulot, je n'en doute pas 16:46 <jrandom> surtout quand on regarde des choses comme java.net.URL (qui fuit des requêtes DNS à l'instanciation, etc.) 16:46 <+redzara> jrandom : fini, terminé 16:46 <+Ragnarok> grr 16:47 <jrandom> ok d'accord redzara, une fois qu'on pourra faire tout fonctionner dans Phex 2.6.4 over I2P, je suis d'accord, il ne semblera plus y avoir grand besoin d'un I2Phex 16:47 <+fox> <GregorK> oui... je pense que Phex utilise la classe URI d'apache à certains endroits pour contourner ça.. mais seulement quand c'est nécessaire 16:48 <jrandom> ah oui, je me souviens d'avoir bricolé avec cette bibliothèque, ça a l'air bien 16:49 <jrandom> nous aiderons assurément à auditer un peu les choses pour l'anonymat/la sécurité avant de le pousser aux utilisateurs finaux sur i2p 16:49 <jrandom> (ce n'est pas pour dire qu'il y a des problèmes dans Phex, juste qu'il y en a dans toute appli, et on espère pouvoir aider à les régler) 16:50 <+fox> <GregorK> pour certaines choses comme l'utilisation de Socket et ce genre de trucs j'ai une idée de la façon de les intégrer en douceur... mais ailleurs comme pour différentes fonctionnalités UDP et autres... je ne suis pas encore sûr de la meilleure façon de les résoudre 16:50 <+fox> <GregorK> oh je suis sûr qu'il y a plein de problèmes dans phex. :) 16:50 <jrandom> ah, oui les sockets ce sera facile, mais on devra peut-être désactiver d'autres trucs. à quoi sert l'udp — requêtes rapides ? 16:51 <+fox> <GregorK> actuellement uniquement le bootstrapping 16:51 <+fox> <GregorK> UDP Host Cache.. un remplacement pour GWebCache 16:52 <jrandom> ahhh, ok. 16:52 <+redzara> donc on n'en a pas besoin si on a un GwebCache correct ? 16:53 <+fox> <GregorK> oui... mais les GWebCache standard ont leurs problèmes de sécurité aussi... 16:53 <+redzara> GregorK : pas à l'intérieur d'I2P je pense 16:54 <jrandom> oh, cette partie peut être contournée — I2PSocket est authentifié — tu connais la 'destination' du pair de l'autre côté, donc ils ne peuvent pas dire "je suis, euh... whitehouse.gov.. ouais !" 16:54 <jrandom> mais tu as raison, c'est quelque chose qu'il faut vérifier 16:54 <+fox> <GregorK> par ailleurs les transferts de pare-feu à pare-feu seraient un sujet UDP qu'on aimerait implémenter une fois qu'on aura un volontaire :) 16:54 <jrandom> ah, eh bien, I2P n'a pas besoin de transferts pare-feu à pare-feu — I2P expose un espace d'adressage de bout en bout entièrement ouvert :) 16:55 <jrandom> mais... ooh, c'est quelque chose qui pourrait être utile 16:55 <jrandom> si les utilisateurs de Phex avaient des "0 hop tunnels", ils auraient la traversée de NAT/le transfert pare-feu à pare-feu gratuitement, avec une vitesse plutôt correcte 16:55 <+fox> <GregorK> une autre serait les diffusions LAN de requêtes et autres... pour partager plus facilement du contenu dans des réseaux privés 16:56 <jrandom> (les 0 hop tunnels offrent un niveau de déni plausible sans exiger que des pairs intermédiaires transportent le trafic) 16:57 <jrandom> hmm, la diffusion LAN c'est bien, mais je ne suis pas sûr qu'i2p en ait vraiment besoin (puisque c'est un risque pour l'anonymat de savoir où se trouve l'autre pair :), donc peut-être que cette fonctionnalité pourrait être désactivée lors de l'utilisation du plugin I2P ? 16:58 <cervantes> *désactivée par défaut 16:58 <+fox> <GregorK> eh bien ce n'est pas encore disponible.. mais dans ce cas les utilisateurs se connaissent généralement de toute façon pour construire ce réseau privé.. 16:58 <jrandom> oh oui cervantes 16:58 <jrandom> oui oui GregorK 16:59 <+fox> <GregorK> y a-t-il des changements concernant l'interface utilisateur ?? 17:00 <+bar> eh bien, on n'aura pas besoin de drapeaux :) 17:00 <jrandom> au minimum, la possibilité d'avoir quelques options de configuration liées à I2P serait utile. 17:01 <jrandom> je crois que sirup a pu changer une partie de l'affichage pour utiliser les 'destinations' I2P au lieu de montrer IP + numéros de port, donc je pense que c'était bon 17:01 <+redzara> et qu'en est-il de bitzyNot pour le moment, mais les drapeaux et pays sont inutilisés 17:01 <jrandom> bitzy ? 17:01 <+redzara> désolé, mauvais copier/coller :( 17:02 <+fox> <GregorK> pouvez-vous fournir une liste des options de configuration et fonctionnalités optionnelles dont vous avez besoin ? 17:03 <jrandom> je suis sûr qu'on peut te fournir ça. un host+port sur lequel I2P tourne et quelques listes déroulantes concernant des réglages de performance/anonymat devraient suffire 17:03 <jrandom> on te donnera les détails 17:02 <cervantes> [x] Mode super vitesse de transfert 17:02 <+fox> <GregorK> eh bien bitzi est utilisé pour identifier des fichiers.. est-ce un problème d'anonymat ? 17:03 <vulpine> <redzara> GregorK : je le prépare, mais en gros, il n'y a pas de changements 17:03 <+fox> <GregorK> :) demande à ton fournisseur cervantes... 17:03 <redzara> GregorK : peut-être, je travaille dessus 17:04 <cervantes> GregorK : heh résident au Royaume-Uni.... aucune chance ;-) 17:04 <+fox> <GregorK> si tu transfères des fichiers entre 2 instances Phex sur le même PC.. les transferts sont ultra rapides ;) 17:05 <cervantes> cool... j'ai plein de super films que je peux partager avec moi-même :) 17:05 <cervantes> * rayer ça du compte-rendu de réunion * 17:06 <bar> jrandom a abordé le sujet tout à l'heure, mais voici encore cette idée folle : 17:06 <+bar> et si on intégrait i2p dans Phex, pour que les utilisateurs ordinaires aient des 0-hop tunnels ? 17:07 <+fox> <GregorK> je pense que l'affichage des drapeaux et IP+port vient de l'objet HostAddress.. qui serait caché par la nouvelle couche.. donc vous pouvez afficher autre chose 17:07 <+bar> (pour le déni plausible et le percement de pare-feu udp) 17:08 <+fox> <GregorK> pas sûr de vraiment comprendre ce que ça signifie ;) 17:08 <+bar> probablement moi non plus ;) 17:09 <jrandom> GregorK : essentiellement, ça veut dire que les utilisateurs de Phex se parleraient directement, mais bénéficieraient d'un déni plausible, puisqu'ils pourraient aussi parler indirectement 17:09 <+bar> jrandom, je suis sûr que tu vois où je veux en venir, tu peux développer ? 17:09 <jrandom> ils auraient aussi la traversée de NAT d'I2P offerte gratuitement, ainsi que la sécurité des données et la protection contre le sniffing par les FAI/etc 17:09 <+redzara> GregorK : donc tu dois retirer tout le code lié à host+port + IsLocalIP + Is PrivateIP + ... 17:10 <jrandom> d'un autre côté, (un GROS autre côté), ça ne pourrait pas parler aux clients gnutella qui ne tournent pas au-dessus d'I2P 17:10 <jrandom> (même si, à terme, ils le feront tous ;) 17:10 <+fox> <GregorK> eh bien je pense que la première étape — et elle est déjà assez grande — c'est de rapprocher i2p et phex. 17:10 <jrandom> d'accord 17:10 <+bar> (zut, je n'y avais pas pensé) 17:11 <+bar> ouais, carrément. 17:11 <jrandom> là on parle de poneys volants. faisons d'abord les choses pratiques 17:11 <+fox> <GregorK> et après avoir vu à quel point ça fonctionne bien on décidera comment aller plus loin.. 17:11 <jrandom> exactement 17:12 <+fox> <GregorK> redzara : j'aimerais avoir deux implémentations de HostAddress, une pour i2p et une comme l'actuelle. 17:14 <+redzara> Gregork : pas de souci, j'ai commenté tout le code dans mon mod tu pourrais facilement construire deux implémentations. Laisse-moi juste terminer le travail initial s'il te plaît 17:14 <+fox> <GregorK> bien sûr.. pas de problème.. 17:14 <jrandom> :) ok, donc redzara, tu penses qu'on pourra faire un test alpha de la nouvelle version basée sur Phex-2.4.2 quelque part la semaine prochaine ? 17:15 <jrandom> (pour la partie phase 2. ta phase 3 demandera plus de travail d'intégration avec la branche principale) 17:15 <+redzara> jrandom : la semaine prochaine ça semble ok pour moi 17:16 <jrandom> ok super 17:16 <+redzara> s/next/next week/ 17:16 <jrandom> ok, c'est assez excitant, ce sera formidable de faire tourner ça en douceur 17:17 <jrandom> quelqu'un a autre chose à évoquer pour 4) I2Phex, ou on passe brièvement à 5) Syndie/Sucker ? 17:17 <cervantes> I2P bénéficiera sûrement de telles killer apps 17:18 <+fox> <GregorK> au fait il y a une liste de diffusion Phex CVS pour tous les changements CVS dans Phex... si ça peut aider 17:18 <jnymo> *ehem*.. carrément oui 17:18 <jrandom> ok super, merci GregorK 17:18 <jrandom> absolument cervantes 17:19 <jrandom> ok, sur le 5), je n'ai pas grand-chose à ajouter au-delà de ce qui est là 17:19 <jrandom> dust : tu es là ? 17:19 <+redzara> GregorK : merci mais gérer une seule version est déjà bien assez pour moi :) 17:19 <jrandom> héhé redzara 17:19 <dust> je n'ai pas eu beaucoup de temps libre dernièrement, mais si j'en ai je pense essayer de prendre en main ce truc addresses.jsp, ajouter 'RSS' dans la liste déroulante des protocoles là-dedans puis construire un chemin via Updater, Sucker jusqu'à BlogManager. 17:20 <dust> à moins que quelqu'un ait une meilleure idée 17:20 <jrandom> mortel 17:20 <jrandom> ça paraît parfait. 17:21 <jrandom> quoique, hmm, il faudrait peut-être un champ supplémentaire (le "dans quel blog le publier" et "quel préfixe de tag")... 17:21 <jrandom> peut-être qu'un formulaire/table séparé aurait du sens, ou pas 17:22 <dust> oh, je pensais que addresses.jsp était pour un seul blog (vu qu'il faut se connecter pour y accéder ?) 17:22 <jrandom> ah, vrai, bon point 17:23 <jrandom> la partie updater est un peu floue, mais tu as raison 17:23 <dust> (on verra quand on y sera) 17:23 <jrandom> ouais 17:24 * jnymo pense que www.i2p.net pourrait lancer un genre de 'merchandise cafe' 17:24 <jnymo> avec des t-shirts eyetoopie où il est écrit "I am Jrandom" ;) 17:24 * mrflibble est encore en train de rattraper la "flamewar", qui semble tourner à une vraie flamewar :) 17:24 <jrandom> heh jnymo 17:25 <jrandom> ouais, il y a beaucoup de contenu dans ce fil 17:25 <jrandom> ok, ça nous mène peut-être à 6) ??? 17:25 <jrandom> quelqu'un a autre chose à soulever pour la réunion ? 17:25 <+bar> oui, juste une petite note sur le problème des NAT symétriques (j'ai un peu fouiné') : 17:25 <+nickless_head> jrandom : je connais la vérité ! 17:25 <+fox> <blx> kaffe ? 17:25 <mrflibble> oups, désolé jr 17:26 <jnymo> mais sérieusement.. chaque projet open source d'une certaine taille a sa propre section merchandising 17:26 <+nickless_head> jrandom : j'ai la preuve formelle que tu as hacké la page d'accueil de last.fm ! 17:26 <+nickless_head> (la section "ce que vous obtenez quand vous vous inscrivez" listait 'a pony') 17:26 <jrandom> jnymo : je pense que tu as raison, on voudra explorer cette voie, ça pourrait aussi être une bonne méthode de levée de fonds 17:27 <jnymo> jrandom : exactement 17:27 * mrflibble achèterait le t-shirt 17:27 <+bar> bon, à propos des NAT symétriques, 17:27 <+bar> pour ce que ça vaut, je pense qu'à la différence des NAT déjà pris en charge, il n'y a pas de tour de magie. la seule manière de faire ça correctement, c'est d'étudier et examiner le comportement de chaque NAT symétrique et d'utiliser des introducteurs pour sonder. 17:28 <jrandom> blx : le dernier CVS de kaffe est complètement b0rked. les packages crypto ne sont pas dans la source, le prng échoue à s'initialiser, et les gestionnaires d'url ne savent pas gérer file:// :( 17:28 <jnymo> tu ne voudrais probablement pas le porter en public avant qu'i2p ait quelques milliers d'utilisateurs ;) 17:28 <+bar> (je crois que c'est comme ça que, par ex., Hamachi et Skype font le hole punching udp depuis derrière des NAT symétriques) 17:28 <+nickless_head> jnymo : des tasses, ce serait top :) 17:28 <+bar> d'après ce que j'ai lu sur le net jusqu'ici, les algos de prédiction des NAT symétriques sont vraiment nuls. 17:28 <jrandom> hmm bar 17:28 <mrflibble> héhé, je ne mettrais pas mon nick dessus. oh, et je suis toujours en vie/non arrêté même si j'ai un t-shirt IIP 17:28 <jrandom> ouais, c'est ce que j'ai lu aussi 17:29 <+bar> je vais essayer de rassembler quelques bonnes lectures pertinentes là-dessus. 17:29 <+redzara> petite question : quel était le pourcentage moyen commun d'octets retransmis en 0.6.1.3 ? 17:29 <jrandom> merci bar 17:29 <+fox> <jme___> bar, les prédictions qu'ils obtiennent sont cohérentes ? 17:29 <+fox> <jme___> bar, laisse-moi reformuler :) 17:29 <+fox> <blx> jrandom, ça me rend triste d'entendre ça 17:30 <jrandom> redzara : j'ai malheureusement oublié de mettre ça dans le netDb. je vois 2.6 et 3.8 en ce moment toutefois 17:30 <jrandom> blx : moi aussi :( 17:30 <+fox> <jme___> bar, quand tu analyses le comportement de la box nat et que tu trouves une formule pour le prédire. est-ce que ça marche toujours pour cette box nat ? ou plus tard ça marche une fois, ça échoue une autre ? 17:30 <jrandom> blx : je sais qu'ils font une fusion avec classpath maintenant, donc avec un peu de chance une fois que ce sera réglé 17:30 <+fox> <blx> ça veut probablement dire que je ne rejoindrai pas la fête 17:30 <jrandom> blx : tu es spécifique à kaffe, ou spécifique OSS/DFSG ? 17:31 <+fox> <blx> logiciel libre 17:31 <+fox> <blx> dfsg on pourrait dire 17:31 <jnymo> au cas où un utilisateur i2p voudrait utiliser un serveur hébergé pour i2p, quelle société d'hébergement tolérante et bon marché choisir ? 17:31 <+bar> jme___ : hamachi serait capable de médier 97% de toutes les tentatives de connexion. je suppose qu'il existe des nat qui ont un comportement quasi aléatoire pour l'attribution des ports 17:32 <jrandom> ok, je suis sûr qu'on va trouver quelque chose blx. kaffe fonctionnait avant, et on ne dépend d'aucun élément spécifique à sun 17:32 <jrandom> jnymo : j'utilise sagonet.net, mais ils ont augmenté leurs prix de 65/mo à 99/mo (mais sur un lien rapide avec 1250GB/mo) 17:32 <jrandom> je sais qu'il y en a des pas chers en Allemagne aussi 17:33 <+fox> <jme___> bar, 97% serait formidable 17:33 <jrandom> redzara : qu'est-ce que tu vois comme taux de retransmission ? 17:33 <+bar> jme___ : ouais, donc je suppose que la plupart des NAT symétriques sont prédictibles 17:33 <+fox> <blx> jrandom, j'espère bien. je suis vraiment intéressé par ce truc :) 17:33 <+fox> <jme___> bar, tu ferais quoi ? relais, udp hole punching, inversion de cnx.. il y a d'autres tech ? 17:33 <jnymo> 99 c'est cher, en moyenne ? 17:34 <+redzara> jrandom entre 3;8 et 4.2 17:34 <jrandom> jme___ : on est en udp, pas besoin d'inversion de connexion :) 17:35 <+bar> jme___ : je ne suis pas expert, j'aurai peut-être plus d'infos pour la réunion de la semaine prochaine (mais ça sent clairement le profilage + udp hole punching ;) 17:35 <jrandom> jnymo : pour 1250GB, pas vraiment. j'ai vu 60-120USD/mo pour 50-100GB/mo 17:35 <jrandom> bar : peut-être qu'UPnP serait une meilleure voie ? 17:35 <+fox> <jme___> jrandom, même avec udp c'est utile :) 17:35 <+redzara> jrandom : mais seuls quelques noeuds ont un impact majeur, peut-être des plus anciens 17:35 <+fox> <jme___> vulpine : ok 17:35 <jrandom> mais ça n'aide que les gens qui peuvent contrôler leur NAT 17:36 <+fox> <jme___> upnp doit être pris en charge mais ce n'est pas exclusif aux autres moyens 17:36 <jrandom> eh bien, on fait tout ce qu'on fait aujourd'hui sans aucun UPnP 17:36 <+fox> <jme___> parce que upnp n'est pas supporté par tous les nat, loin de là 17:36 <jrandom> oui, p. ex. un nat d'un FAI 17:36 <+bar> jrandom : s'il n'y a pas de problèmes de sécurité avec upnp, je suppose que ça ne peut pas faire de mal. ceci dit, hamachi n'utilise pas upnp 17:36 <+fox> <jme___> ici par "doit" = pour fournir la connectivité maximale 17:37 <+fox> <jme___> ok, je retourne à mon c++ :) 17:38 <jrandom> oui jme___, même si on peut faire du hole punching symétrique en plus du hole punching cône/restreint, on sera en très bonne posture 17:38 <jrandom> à+ jme___ 17:38 <jrandom> ouais, ce serait idéal si on n'en avait pas besoin 17:39 <jrandom> ok, quelqu'un a autre chose à aborder pour la réunion ? 17:41 <jrandom> si non... 17:41 * jrandom s'apprête 17:41 * jrandom *baf* clôt la réunion