Réunion des développeurs I2P - 30 décembre 2003

<jrandom> 0) salut <jrandom> 1) statut du router <jrandom> 2) i2ptunnel <jrandom> 3) IM (messagerie instantanée) <jrandom> 4) plans pour 0.3 <jrandom> 5) synchronisation de l'heure <jrandom> 6) ??? <jrandom> salut mihi, polo <polo> bonjour ! <mihi> salut jrandom <jrandom> 0) salut <jrandom> :) <rsk> salut <i2p> <duck> salut <jrandom> 1) statut du router <jrandom> 0.2.3.3 est sorti, et ça a l'air de fonctionner <jrandom> il reste bien sûr beaucoup à faire <jrandom> mais ce devrait être la dernière version 0.2 <jrandom> 0.3 va ajouter le profilage des pairs pour permettre aux routers d'éviter les mauvais routers <jrandom> (et 0.3.1 est une refonte des transports) <jrandom> hola Ophite1 <Ophite1> Heya. <rsk> donc davantage de surcharge pour 0.3 ? <jrandom> oui et non <jrandom> il y aura des tests de pairs, mais ce sera plus ciblé <rsk> verra-t-on une accélération avec la sélection de chemin ? <jrandom> oui <jrandom> il y a ces calculateurs de 'vivacité', et on ajoutera de nouveaux calculateurs de latence et de débit <jrandom> en plus, les gens pourront ajuster leurs préférences pour certains pairs <jrandom> par ex., si vous savez que vous voulez préférer le pair X au pair Y, vous pourrez leur attribuer un bonus de pondération de quelques points aléatoires <mihi> y aura-t-il un arrêt propre ? *g* <jrandom> c’est en fait une bonne question, mihi <jrandom> i2p en arrive au point où il a besoin d’une interface d’administration. <jrandom> le Job le plus long qui bloque son fonctionnement est GenerateStatusConsoleJob <jrandom> qui peut maintenant prendre jusqu’à 4–6 secondes <jrandom> (ce qui retarde tout le reste) <jrandom> ça doit passer en asynchrone et à la demande. <jrandom> mais je ne veux pas écrire un listener web / etc. <jrandom> peut-être l’inverse — un servlet qui démarre le router et communique avec lui <mihi> tu n’as pas besoin d’un serveur web complet. quand tu vois GET, renvoie simplement tes données. <jrandom> oui <jrandom> tu as raison, ce genre de truc devrait aussi être dans 0.3. <mihi> et quand tu vois autre chose (comme SHUTDOWN), fais ce que tu veux. bien sûr uniquement depuis localhost ;) <jrandom> oh allez <mihi> ensuite quelqu’un pourra faire un joli programme d’admin <jrandom> oui <mihi> tu avais des triggers par fichiers, non ? sont-ils documentés quelque part ? >>> mihi [~mihi@ags9-d9ba536a.pool.mediaWays.net] a demandé un PING 1072820995 à jrandom <jrandom> ceux-là étaient dans IDN, pas dans le router lui-même <jrandom> mais ça pourrait être une bonne voie <jrandom> c’est un système trivialement simple <jrandom> bonne idée, allons dans ce sens <jrandom> (et je peux simplement réutiliser ce code :) <i2p> <duck> ce truc magique autour des fichiers commence à ressembler à plan9 <jrandom> lol <mihi> mais les triggers par fichier nécessitent du polling <jrandom> oui mihi, lire un répertoire toutes les 30 s c’est pas si terrible <mihi> mais un ServerSocket#accept coûte moins cher. <mihi> car ça ne consommera pas de temps. (avec un bon OS) <mihi> d’accord, des triggers par fichier c’est mieux que rien, certes. <jrandom> un server socket permettrait l’admin à distance <jrandom> (quand c’est approprié) <jrandom> je sais pas. <jrandom> c’est à définir. <jrandom> (ou si quelqu’un veut s’y mettre et coder... :) <mihi> et un server socket pourrait aussi fournir la routerConsole. <jrandom> oui <jrandom> ok, 2) i2ptunnel <jrandom> :) <jrandom> i2ptunnel déchire toujours, et on dirait qu’on veut lui ajouter une API basée sur des sockets pour le piloter <i2p> <anon> les plans ic2cp2pc d’aum sont-ils suspendus pour l’instant ? <jrandom> oui, ci2cp est mort-né, remplacé par l’API basée sur des sockets pour contrôler I2PTunnel <jrandom> je pense pouvoir greffer cette API dans les prochains jours, pour qu’il puisse se lancer sur l’impl <mihi> utilise juste un socket, fais in.readLine() et passe cette ligne à runCommand() ;) <rsk> qu’est-ce que l’API apporte à i2p ? <jrandom> à peu près ça, mihi (sauf qu’elle formate les résultats et les renvoie d’une manière standard) <mihi> avec un « logger » approprié pour renvoyer les commandes. <mihi> s/commands/results/ <jrandom> rsk> ça permet aux développeurs d’applications de construire des sockets client et serveur au-dessus d’i2p sans gérer les exigences de chiffrement d’I2CP <jrandom> oui oui <jrandom> i2ptunnel a bien une surcharge dans les situations où il y a beaucoup d’i2ptunnels <jrandom> quelle que soit la JVM <jrandom> les clients i2ptunnel créent une nouvelle destination par client contacté, et le router se comportera bien moins bien à mesure que le nombre de destinations locales augmente. <rsk> ah <jrandom> c’est dû aux besoins d’anonymat du réseau liés à la façon dont notre chiffrement fonctionne <jrandom> pour les applications qui veulent juste ouvrir un ou deux tunnel(s) vers un pair, cette nouvelle API va TUER <jrandom> mais pour les applications qui doivent parler à beaucoup d’autres pairs, I2CP est la bonne voie. <jrandom> (puisque c’est une seule destination, multiplexée par i2cp) <jrandom> je suppose que c’est l’éternel équilibre TCP vs UDP, d’une certaine manière <jrandom> mihi> as-tu des réflexions, ou des idées pour l’avenir d’i2ptunnel ? <rsk> où en sont les travaux sur l’IP sur i2p, ou le bazar VPN ? <mihi> jrandom : que quelqu’un écrive une bonne API de streaming, et ensuite faisons utiliser i2ptunnel avec. <mihi> idem pour le serveur de noms. <mihi> peut-être ajouter quelques numéros de séquence si personne ne fait ce qui précède. <mihi> ce qui impliquera un changement incompatible. <jrandom> les changements incompatibles ne sont pas mauvais, on est tôt dans le dev <jrandom> (si on pouvait aussi augmenter la taille des IDs à deux ou quatre octets par côté ?) <mihi> l’API de streaming sera de toute façon un changement incompatible. et si i2p fonctionnait, nous n’aurions pas besoin de numéros de séquence. <jrandom> rsk> en pause, jusqu’à ce que quelqu’un ait le temps de s’en emparer ? ≡ rsk/#i2p pense que les changements incompatibles sont les meilleurs <jrandom> exact mihi <mihi> l’ID devrait faire 3 octets atm, donc pourquoi l’*augmenter* à 2 octets ? <jrandom> mihi> en fait, j’aimerais déprécier progressivement mode=GUARANTEED et l’implémenter dans l’API de streaming ≡ mihi/#i2p aussi <jrandom> en laissant i2p = IP, pas TCP ni UDP <jrandom> bon sang, j’aimerais avoir 14 heures de plus dans la journée. <mihi> seulement 14 ? ;) <jrandom> ;) <jrandom> les IDs de 3 octets ne sont-ils pas dérivés par les deux côtés de la conn ? ou alors je suis juste confus <mihi> chaque côté a un ID de 3 octets, cependant, un seul doit être envoyé à la fois. <jrandom> peut-être que je vais implémenter l’API de streaming, retirer GUARANTEED, et ajouter ensuite ce contrôleur de socket. <jrandom> ah ok <mihi> voir /apps/i2p/i2ptunnel/java/src/protocol.txt <jrandom> oui oui <mihi> au fait, qui a égaré ce fichier *là* ? ≡ jrandom accuse eco ;) <jrandom> attends, non, c’est toi qui les as mis là <jrandom> n’est-ce pas ? <jrandom> oh attends, non, je les ai importés ≡ jrandom se blâme d’être idiot. <jrandom> (la la la) <jrandom> zut. ok, oui, travailler sur l’API de streaming et le contrôleur de socket me permettra de réfléchir au manifeste de test/profilage/sélection des pairs <jrandom> je posterai ça dans quelques jours pour commentaires <jrandom> (et ça me sortira la tête du router. variety++) <jrandom> mihi> autre chose sur i2ptunnel ? <mihi> pas que je sache <jrandom> cool <jrandom> (merci encore de prendre le temps d’intervenir là-dessus, je sais que tu es occupé avec fiw et le reste) <jrandom> ok, thecrypto n’est pas là, mais il fait des progrès sur l’application IM (messagerie instantanée). <jrandom> (c’est le point 3 de l’ordre du jour) <jrandom> 4) plans pour 0.3 <jrandom> 0.3.0 ≈ le profilage des pairs, et maintenant ça inclura aussi l’API de streaming et ce contrôleur de socket pour i2ptunnel <jrandom> mais, sans surprise, ça ne sortira pas le 1er janv <jrandom> le 15 janv. est une possibilité lointaine. on verra comment ça se passe. <jrandom> 0.3.1 ne représente pas un mois complet de travail, donc il n’aura peut-être pas besoin d’être repoussé. <jrandom> à part ça, la roadmap est toujours globalement sur les rails et représentative de là où on va <jrandom> 5) synchronisation de l’heure <jrandom> une nouvelle FAQ est publiée sur http://wiki.invisiblenet.net/iip-wiki?I2PTiming <jrandom> mihi, tu avais une suggestion à propos de la quatrième option là-bas (construire notre propre mesure du temps dans i2p) ? <jrandom> salut brawl <mihi> oui. ∙φ∙ brawl est maintenant connu sous le nom de eco_ <eco_> salut les gars <jrandom> oh salut eco <mihi> on vient de discuter de l’API de streaming / de l’API de tunnel <mihi> et ensuite bidouiller ton propre getTimeMillis qui corrige ça. <Ophite1> mihi : non, tu ne devrais pas. <jrandom> mihi> donc si un attaquant crée 1000 nœuds avec la mauvaise heure, tout le monde est foutu <jrandom> (puisque la moyenne se décalerait aléatoirement entre les deux) <mihi> si un attaquant crée 1000 nœuds, tout le monde est foutu de toute façon... ? <rsk> ce ne serait pas auto-correcteur ? <Ophite1> mihi : OK, 3. <jrandom> non, on devrait pouvoir gérer ça, mihi. <mihi> d’accord, alors n’utiliser la moyenne que si l’écart type est inférieur à ~1 s. <rsk> si tout le monde a la même heure tu es ok, même si cette heure est fausse, non ? <jrandom> rsk> si les 1000 nœuds étaient synchronisés, mais s’ils sont tous aléatoires <mihi> n’utiliser que des heures suffisamment proches. sinon, prendre 3 nouveaux nœuds. <jrandom> mihi> oui, on pourrait implémenter NTP (qui fait en gros ce que tu dis, en utilisant une série de moyennes candidates pour se rapprocher itérativement de l’heure correcte <mihi> mais on n’a pas besoin de tout gérer (comme les latences de ping), comme le fait NTP. <Ophite1> si on ne le faisait pas, mihi, l’heure reculerait lentement. ≡ mihi/#i2p pense que c’est mieux que de laisser les utilisateurs régler leur heure individuellement. <jrandom> donc quiconque choisit au hasard 3 de ces nœuds décalés est envoyé sur son propre réseau privé ? <jrandom> qu’en est-il de cette troisième option - <jrandom> i2p a un composant qui vérifie auprès d’un vrai serveur NTP via NTP ou SNTP <mihi> si tu n’as que des nœuds décalés dans ta netDB, tu es aussi sur ce réseau privé... <jrandom> plutôt que de réinventer la roue <Ophite1> même si j’aime en partie cette option... <Ophite1> NTP n’est pas signé, il est sujet à des attaques MITM. <Ophite1> ou à un empoisonnement du cache DNS pour, disons, time.nist.gov <jrandom> oui Ophite1, mais avec plus de 200 000 hôtes SNTP ou NTP, ça fait un grand ensemble à attaquer. <jrandom> on ne se synchroniserait certainement pas sur time.nist.gov. <Ophite1> des connexions depuis i2p vers le serveur de temps de la NSA pourraient faire tiquer, hein ? :) <jrandom> et si un attaquant s’en prend à time.nist.gov, tout le monde partout est affecté <jrandom> heh <mihi> alors combinons les deux. demander à un « vrai » serveur NTP et à ton voisin. si les deux disent la même chose, c’est ok. <jrandom> donc encore /plus/ de code ;) <jrandom> mais oui, c’est raisonnable. <Ophite1> C’est intéressant. Et s’ils ne sont pas d’accord ? <Ophite1> choisir un autre serveur NTP ? <jrandom> refuser le pair. <mihi> essayer un autre serveur NTP et un autre pair. <mihi> jusqu’à avoir une correspondance. puis refuser tous les pairs précédents. ≡ mihi/#i2p tape plus lentement que jrandom :( <Ophite1> correspondance dans un certain seuil, disons 1 s ? <jrandom> 1 s serait bien. <jrandom> accepter des pairs jusqu’à ~30 s (pour gérer la latence) <Ophite1> 1 seconde convient-elle sur des connexions LOURDEMENT CHARGÉES ? <jrandom> 1 s pour la synchro, 30 s pour la comm. <Ophite1> j’ai vu la latence sur de l’ADSL monter à 5 secondes quand on lui fait des choses maléfiques. <jrandom> en TCP ou UDP ? <Ophite1> mais alors, dans ce cas, cette machine n’est de toute façon peut‑être pas celle à laquelle tu veux te synchroniser ;) <jrandom> oui <Ophite1> udp. <jrandom> hmm 'k <Ophite1> on aurait pensé que ça se ferait dropper :) <i2p> <duck> je pense que le problème, c’est surtout d’informer l’utilisateur qu’il y a un problème <jrandom> duck> c’est vrai. <i2p> <duck> ce n’est qu’après avoir parcouru de gros logs qu’ils voient que leur horloge est décalée (s’ils le trouvent) <Ophite1> Peut‑être. En quelque sorte. <i2p> <duck> ou que le port est déjà utilisé <jrandom> une interface d’admin serait sympa. <i2p> <duck> le monde est meilleur si tout le monde utilise NTP connecté à leur serveur stantrum (sp) 2 local CTCP Cloaking est maintenant [Activé] <jrandom> peut‑être qu’on fera une version 0.4 avec un tas de nettoyages et des trucs orientés utilisateur final, avant de passer en 1.0 ? <jrandom> oui (stratum) <i2p> <duck> seuls les clients Windows sont peu susceptibles d’avoir ça <i2p> <duck> mais ils sont aussi peu susceptibles d’être stables <jrandom> Windows a NTP <i2p> <duck> donc on s’en fiche <Ophite1> duck : Windows XP et Windows Server 2003 incluent NTP. <jrandom> et vachement plus facile qu’avec Unix aussi <Ophite1> synchronisé par défaut sur time.windows.com iirc. <jrandom> avec des menus déroulants pour d’autres <Ophite1> c’est une partie essentielle de l’Activation de produit Windows. <Ophite1> ça ne peut pas expirer si tu ne connais pas l’heure :) <jrandom> heh <mihi> pas d’option dans mon université... toutes les horloges ont 1 à 5 heures de décalage. mais je n’ai peut‑être pas le droit d’exécuter i2p là‑bas de toute façon... <Ophite1> mihi : i2p devrait s’efforcer particulièrement de fonctionner dans une telle situation... <jrandom> mihi> génial ! tu peux aider à tester le fonctionnement caché :) <jrandom> au passage, je vais voyager un peu cet été <jrandom> je serai probablement hors ligne, sans mon portable. <i2p> <duck> pensée annexe : ntp.duck.i2p :) <Ophite1> Voyez ça comme ceci : Brianna Kazaa télécharge un nouveau client de partage de fichiers anonyme super cool que sa meilleure amie lui a dit être vraiment cool et qui te permet de discuter en secret et tout. Veut‑on lui dire qu’elle doit régler son horloge à 30 secondes près (comment va‑t‑elle y arriver ?) ? Ou veut‑on que ça marche tout simplement ? <jrandom> mais je vais m’assurer de pouvoir être quand même sur I2P avec de simples terminaux publics. CTCP Cloaking est maintenant [Désactivé] <jrandom> aucun doute, Ophite1. que ça marche, point (avec des docs pour geeks) <jrandom> duck> bootstrap ;) <jrandom> et i2p ne nécessitera /pas/ root. <Ophite1> C’est mon point. <Ophite1> jrandom : lancerais‑tu un router sur une machine où tu n’as pas root ? <jrandom> donc ouais, un mélange entre l’option 3 et 4 <Ophite1> l’option 3.5 me paraît cool ;) <jrandom> Ophite1> j’en lancerais une centaine :) <mihi> option 3.1415926... <jrandom> (et passer au labo suivant, en lancer cent de plus) <Ophite1> Oh. Pie. Miam. ;) <Ophite1> jrandom : j’ai dit que tu n’avais pas root. Amateur. :) <jrandom> lol <jrandom> donc c’est globalement là où on se dirige. <jrandom> jusqu’à ce que le truc sur l’heure soit implémenté, tout le monde devrait utiliser l’option 1 ou 2. <jrandom> pour l’option 2, si quelqu’un pouvait écrire un peu de doc, j’apprécierais <Ophite1> c’est acceptable pour l’instant car nous ne sommes Pas Encore Prêts pour Brianna Kazaa et consorts ;) <mihi> pour mémoire : je ne testerai pas le « fonctionnement caché ». mon compte d’univ a déjà été désactivé une fois et je ne veux pas qu’il soit bloqué une autre fois... <Ophite1> mihi : tu es le meilleur test qu’on puisse avoir. <jrandom> Ophite1 > pas pour tester. <jrandom> 'k mihi, on trouvera un moyen, et une fois prêt tu pourras l’utiliser. <Ophite1> OK, peut‑être pas tester. Certaines facs deviennent assez susceptibles pour t’expulser plutôt que juste te bloquer. <Ophite1> Je connais quelqu’un dans l’université la plus anti‑partage de fichiers, pro‑RIAA des USA. Il fait tourner un dumpsite à 2 Gbit. <jrandom> lol sympa <Ophite1> je reconnais que très, très peu de gens ont autant de culot. <jrandom> ok, c’est tout pour la synchronisation de l’heure. <jrandom> eco_> salut. des trucs BT dont tu veux parler ? {ou on garde ça pour la semaine prochaine} <Ophite1> mais garde à l’esprit que la majorité d’Internet va probablement devenir universitaire/entreprise à l’avenir. i2p pourrait être banni. i2p pourrait BIEN être considéré comme un abus par les grands FAI. i2p devra fonctionner quand même. <Ophite1> j’ai quelques idées intéressantes dans ce sens que je présenterai plus tard. <jrandom> bien dit <Ophite1> (transport) <rsk> i2p est considéré comme un abus par les grands FAI, lisez votre contrat <Ophite1> rsk : faire tourner un cache proxy distribué ? <rsk> faire tourner n’importe quel « serveur » <Ophite1> rsk : Pas à moins que ça relaie vers SMTP ou WWW. <jrandom> faire tourner des services de n’importe quel type <jrandom> oui <Ophite1> rsk : héhé, j’ai une solution à ça ;) <eco_> jrandom : je peux donner une brève mise à jour <jrandom> à toi la parole :) <eco_> je porte le client BitTorrent en Java snark (www.klomp.org/snark) pour me familiariser avec i2p <eco_> le premier port tourne au‑dessus d’i2ptunnel, en appelant directement les classes Java <eco_> état actuel : ça marche avec 2 pairs, ça se gâte avec > 2, les tunnels ne sont pas nettoyés, donc redémarrer est pénible <eco_> ETA : ce week‑end ≡ eco_/#i2p réalise que cela pourrait être considéré comme > 2003 <jrandom> w00t ! ≡ jrandom hacke time.nist.gov <eco_> un port « réel » réduirait probablement la surcharge des tunnels, mais c’est l’étape suivante <jrandom> cool ≡ eco_/#i2p rend la parole au mc jrandom <jrandom> 'k, je pense que c’était tout <jrandom> 6) ??? <jrandom> quelqu’un a autre chose ? ≡ eco_/#i2p aimerait exprimer ses remerciements pour l’excellent travail accompli par jrandom & co jusqu’à présent <eco_> et que le sommeil a une utilité pour homo sapiens, bien que jrandom semble prouver le contraire <jrandom> ;) <jrandom> qu’en pensez‑vous de se réunir ici plutôt que sur iip, jusqu’à ce qu’i2p soit suffisamment fiable ? <jrandom> personnellement, je suis fatigué que les réunions soient mises en pièces chaque semaine. <i2p> <anon> lilo craint ! <eco_> on risque d’exclure des gens en venant ici <jrandom> oui, je sais. <jrandom> si on peut avoir un pont iip<-->ici <i2p> <duck> IIP exclut des gens chaque jour <jrandom> ce serait bien. <jrandom> oui. <jrandom> iip est, malheureusement, inutilisable pour une communauté de développement fiable. <i2p> <duck> http://banaan.zeelandnet.nl/open/changate.html <i2p> <duck> c’est le code sur lequel eyeKon etc. est basé <jrandom> et même si j’aime bien partir coder dans mon coin, vous avez vraiment de bonnes idées et faites des choses essentielles ≡ rsk/#i2p est en train d’écrire un script de mise à jour Windows <i2p> <duck> théoriquement il pourrait se connecter à 3 serveurs et les miroiter <jrandom> bien dit, duck, peut‑être que j’essaierai d’en faire tourner un sur i2p.dnsalias.net <jrandom> déluge de pings infernal ;) <eco_> l’IRC sur duck.i2p était plutôt bon aujourd’hui, mieux que iip <jrandom> d’accord <jrandom> il m’a quand même lâché quelques fois. <jrandom> peut‑être que ce sera plus fiable la semaine prochaine <eco_> c’est entre tes mains :-) <jrandom> la fiabilité ne s’améliorera probablement pas avant 0.3, qui est dans ~2 semaines <jrandom> (1 semaine pour faire le truc tunnel/streaming, 1 semaine pour le profilage/test des pairs) <jrandom> ensuite il y aura les bugs que ça introduira :) <jrandom> cela dit, je dois dire que j’étais vraiment enthousiaste de streamer de l’audio depuis aum hier soir <jrandom> et ardvark a pu diffuser pendant 42 minutes sans mise en tampon ! <jrandom> donc peut‑être qu’on pourra être suffisamment fiables <jrandom> (mon router local est phttp uniquement, ce qui en est probablement une petite cause) <jrandom> ok, quelqu’un a autre chose ? <i2p> <duck> je ne pense à rien ≡ eco_/#i2p non plus ≡ jrandom s’échauffe... ≡ jrandom *baf* ferme la réunion