Réunion des développeurs I2P - 30 mai 2006

16:00 <jrandom> 0) salut 16:00 <jrandom> 1) Statut du réseau 16:00 <jrandom> 2) Filtrage des pairs 16:00 <jrandom> 3) Statut de Syndie 16:00 <jrandom> 4) ??? 16:00 <jrandom> 0) salut 16:00 * jrandom fait coucou 16:01 <jrandom> notes d'état hebdomadaires publiées sur http://dev.i2p.net/pipermail/i2p/2006-May/001291.html 16:01 <jrandom> (même publiées une heure plus tôt [ou avec quelques semaines de retard, si vous voulez vous moquer de moi ;]) 16:02 <jrandom> ok, allons directement au 1) Statut du réseau 16:02 <jrandom> les choses ne sont pas dans l'état où elles devraient être. elles vont mieux qu'au moment de l'effondrement dû à la congestion, mais ça devrait être mieux qu'actuellement 16:03 <jrandom> je n'ai pas grand-chose de plus à ajouter là-dessus, à moins que quelqu'un ait des questions/inquiétudes sur le 1) ? 16:03 <@frosk> j'ai des jours entiers de connexion irc avec la .19, donc aucune plainte ici 16:04 <jrandom> sympa 16:04 <jrandom> ouais, c'est bien pour certains, juste pas assez bon ni assez stable. les stats dans la base de données n'ont pas l'air géniales non plus 16:06 <jrandom> ok, quelqu'un a autre chose sur 1) Statut du réseau, ou passe-t-on à 2)Filtrage des pairs ? 16:07 <jrandom> [insérez ici des bruits de déplacement] 16:09 <jrandom> comme indiqué dans le mail, l'idée est de donner un petit coup de pouce à notre sélection de pairs. au début, ce sera un peu dangereux, permettant certaines attaques de partitionnement actives, mais si ça marche comme je l'espère, on peut éviter ça 16:10 <jrandom> (mais l'éviter nécessite essentiellement de tuer toutes les router identities, ce qui équivaudrait à une réinitialisation du réseau, donc j'aimerais éviter ça sauf si ça en vaut la peine) 16:11 <bar> les réinitialiser une fois ou de manière répétée ? 16:11 <bar> s/reset/killing 16:11 <jrandom> au moins une fois, mais aussi à chaque changement de config drastique 16:12 <jrandom> (aka en mettant certains critères dans le certificat de la router identity, ce qui implique de changer l'ident hash, afin qu'ils ne puissent pas faire semblant de pousser un réglage à certains et d'autres à d'autres) 16:13 <bar> pigé 16:14 <jrandom> ok, je ne pense pas avoir autre chose sur ce sujet pour le moment, à moins que quelqu'un ait des questions/commentaires/inquiétudes ? 16:15 <jrandom> (avec un peu de chance, il y aura une build dans un jour ou deux, sortie après stabilisation) 16:17 <jrandom> ok, on attaque le 3) brièvement.. 16:18 <jrandom> syndie avance, et même si la bataille amd64/amd32/x86/swt/gcj n'a pas toujours été jolie, nous aurons une build prête en juin 16:19 <jrandom> (mais ne me parlez toujours pas de mingw/gcj ;) 16:19 <jrandom> je n'ai pas beaucoup plus à ajouter là-dessus pour le moment, à moins que quelqu'un ait des questions/inquiétudes à propos de la refonte de syndie ? 16:21 <@cervantes> comment avance la prise en charge mingw/gcj ? 16:21 <@cervantes> *se baisse* 16:22 <@cervantes> on aura quelques captures d'écran avant la sortie de juin ? :) 16:23 <jrandom> je suis sûr que j'essaierai d'embarquer quelques volontaires enthousiastes pour des tests pré-sortie ;) 16:23 <tethrar> comptez sur moi ;) 16:23 <jrandom> w3wt 16:24 <jrandom> ok, passons au point que je sais que vous attendiez tous : 4) ??? 16:24 <jrandom> wazaaaap ? 16:24 <green> Y a-t-il un plan pour avoir un "réel" I2P router fonctionnel avec Via C7 ? jbigi n'apporte que 30% de mieux que le Java pur 16:25 <jrandom> 30%, c'est encore trop intensif pour le cpu ? qu'est-ce qui fait que ce n'est pas "réel" ? 16:25 <jrandom> mais non, je n'ai pas les compétences en maths ni en asm c7 pour faire une meilleure libGMP pour le C7. 16:25 <green> bien sûr trop intensif pour le cpu avec 100% de charge cpu :P 16:26 <jrandom> 100% de charge cpu suggère que le problème n'est pas jbigi, mais le fait que jbigi doit être utilisé trop souvent 16:26 <jrandom> et pour ça, oui, on a beaucoup de choses en route. 16:26 <jrandom> (par ex. réduire les rétablissements de connexion, améliorer les taux de réussite de construction de tunnel, etc) 16:27 <jrandom> ((et ne pas recevoir autant de demandes de tunnel si le router n'est pas capable de les gérer)) 16:29 <green> humm, c'est avec une machine dédiée à 100 Mb/s donc elle devrait être capable 16:30 <jrandom> non, la bande passante n'est pas la seule ressource limitée ici, le cpu l'est de toute évidence ;) 16:33 <jrandom> ok, quelqu'un a autre chose pour la réunion ? 16:36 <jrandom> *tousse* 16:37 * jrandom se prépare 16:37 * jrandom *baf* clôt la réunion