I2P-Entwicklertreffen - 30. Mai 2006

16:00 <jrandom> 0) hi 16:00 <jrandom> 1) Netzstatus 16:00 <jrandom> 2) Peer-Filterung 16:00 <jrandom> 3) Syndie-Status 16:00 <jrandom> 4) ??? 16:00 <jrandom> 0) hi 16:00 * jrandom winkt 16:01 <jrandom> wöchentliche Statusnotizen gepostet @ http://dev.i2p.net/pipermail/i2p/2006-May/001291.html 16:01 <jrandom> (sogar eine Stunde früher online [oder ein paar Wochen zu spät, wenn ihr mich aufziehen wollt ;]) 16:02 <jrandom> ok, lasst uns gleich bei 1) Netzstatus einsteigen 16:02 <jrandom> Die Dinge sind nicht in dem Zustand, in dem sie sein sollten. Es ist besser als während des Überlastungskollapses, aber es sollte besser sein, als es jetzt ist 16:03 <jrandom> Ich habe dazu nicht viel mehr hinzuzufügen, außer jemand hat Fragen/Bedenken zu 1)? 16:03 <@frosk> ich bekomme mit .19 tagelang IRC-Verbindung, also keine Beschwerden hier 16:04 <jrandom> schön 16:04 <jrandom> ja, für manche ist es gut, nur nicht gut genug oder konsistent genug. die Statistiken in der db sehen auch nicht so toll aus 16:06 <jrandom> ok, hat noch jemand etwas zu 1) Netzstatus, oder sollen wir weiter zu 2)Peer-Filterung gehen? 16:07 <jrandom> [hier Wechselgeräusche einfügen] 16:09 <jrandom> Wie in der Mail erwähnt, geht es im Kern darum, unserer Peer-Auswahl einen kleinen Schub zu geben. Zunächst wird es etwas gefährlich sein und einige aktive Partitionierungsangriffe ermöglichen, aber wenn es so funktioniert, wie ich hoffe, können wir die vermeiden 16:10 <jrandom> (aber das zu vermeiden erfordert im Wesentlichen, alle Router-Identitäten zu löschen, was praktisch einem Netzwerk-Reset gleichkäme, daher würde ich das gerne vermeiden, außer es lohnt sich) 16:11 <bar> einmal zurücksetzen oder wiederholt? 16:11 <bar> s/reset/killing 16:11 <jrandom> mindestens einmal, aber auch bei allen anschließenden drastischen Konfigurationsänderungen 16:12 <jrandom> (aka einige Kriterien in das Zertifikat der Router-Identität packen, was wiederum bedeutet, den Ident-Hash zu ändern, damit sie nicht so tun können, als würden sie manchen Leuten eine Einstellung und anderen eine andere unterjubeln) 16:13 <bar> kapiert 16:14 <jrandom> ok, ich glaube, ich habe im Moment nichts Weiteres zu dem Thema, außer jemand hat Fragen/Kommentare/Bedenken? 16:15 <jrandom> (hoffentlich gibt es in ein bis zwei Tagen einen Build, Release dann, sobald es stabil ist) 16:17 <jrandom> ok, kurz zu 3).. 16:18 <jrandom> Syndie macht Fortschritte, und obwohl der amd64/amd32/x86/swt/gcj-Kampf nicht immer schön war, werden wir im Juni einen Build fertig haben 16:19 <jrandom> (aber sprecht mich immer noch nicht auf mingw/gcj an ;) 16:19 <jrandom> ich habe dazu im Moment nicht viel mehr hinzuzufügen, außer jemand hat irgendwelche Fragen/Bedenken bezüglich der Syndie-Überarbeitung? 16:21 <@cervantes> wie läuft die mingw/gcj-Unterstützung? 16:21 <@cervantes> *duck* 16:22 <@cervantes> bekommen wir vor dem Juni-Release ein paar Screenies? :) 16:23 <jrandom> ich werde sicher versuchen, ein paar eifrige Freiwillige zum Testen vor dem Release zu überreden ;) 16:23 <tethrar> ich bin dabei ;) 16:23 <jrandom> w3wt 16:24 <jrandom> ok, schwenken wir rüber zu dem Punkt, auf den ihr alle gewartet habt: 4) ??? 16:24 <jrandom> Wazaaaap? 16:24 <green> Gibt es irgendeinen Plan für einen „wirklich“ funktionierenden I2P router mit Via C7 ? jbigi bringt nur 30% mehr als reines Java 16:25 <jrandom> Sind 30% immer noch zu CPU-intensiv? Was macht es nicht „wirklich“? 16:25 <jrandom> aber nein, ich habe nicht das Mathe- oder C7-ASM-Know-how, um eine bessere libGMP für C7 zu machen. 16:25 <green> sicher zu CPU-intensiv bei 100% CPU-Last :P 16:26 <jrandom> 100% CPU-Last deutet darauf hin, dass das Problem nicht jbigi ist, sondern die Tatsache, dass jbigi zu oft benutzt werden muss 16:26 <jrandom> und dafür, ja, da haben wir vieles in Arbeit. 16:26 <jrandom> (z. B. weniger erneute Verbindungsaufbauten, höhere Erfolgsraten beim Tunnel-Bau, usw.) 16:27 <jrandom> ((und nicht so viele Tunnel-Anfragen erhalten, wenn der Router sie nicht bewältigen kann)) 16:29 <green> humm, das ist mit einer dedizierten Kiste mit 100Mb/s, also sollte sie das können 16:30 <jrandom> nein, Bandbreite ist hier nicht die einzige knappe Ressource, CPU ist es offensichtlich ;) 16:33 <jrandom> ok, hat noch jemand etwas für das Meeting? 16:36 <jrandom> *hust* 16:37 * jrandom holt aus 16:37 * jrandom *baf*s das Meeting ab