I2P-Entwicklertreffen - 31. Januar 2006

15:19 <jrandom> 0) hi 15:19 <jrandom> 1) Netzstatus 15:19 <jrandom> 2) Status zu 0.6.1.10 15:19 <jrandom> 3) ??? 15:19 * jrandom winkt 15:19 <jrandom> Statusnotizen unter http://dev.i2p.net/pipermail/i2p/2006-January/001257.html 15:20 <jrandom> ok, springen wir rein in 1) Netzstatus 15:21 <jrandom> wie in der Mail erwähnt, sollten diejenigen auf 0.6.1.9-0 (dem vollständigen Release) das Altbekannte sehen 15:21 <jrandom> allerdings könnten Nutzer auf neueren Builds (seit 0.6.1.9-5 oder neuer) Probleme haben 15:21 <jrandom> ("Probleme" ist vielleicht eine Untertreibung...) 15:21 <+Complication> CVS -8 war etwas wackelig, daher läuft -2 instad (funktioniert gut genug) 15:22 <gloin> :-) 15:22 <+Complication> =instead 15:22 <Pseudonym> in letzter Zeit scheint es instabil zu sein (ich bin auf 0.6.1.9-0) 15:22 <jrandom> cool, ich hatte überlegt, die Prozessänderungen rückgängig zu machen, aber dusts ircclient-Update und den i2ptunnel httpserver patch im Head zu behalten, doch 0.6.1.10 ist wahrscheinlich nicht mehr weit 15:23 <jrandom> hmm Pseudonym, greifst du auf eepsites, IRC oder andere Dienste zu, oder hostest du sie? 15:23 <+Complication> Instabil mit -0? Wie äußert sich das Problem? 15:23 <Pseudonym> ich merke es vor allem auf IRC (IdleRPG spielen) 15:24 <jrandom> ("spielen" ;) 15:24 <Pseudonym> außerdem spinnt der router manchmal und muss neu gestartet werden (keine aktiven Peers) 15:24 <Pseudonym> heh 15:24 <jrandom> hmm, Probleme mit der Internetverbindung? 15:24 <@frosk> -0 ist hier stabil, außer natürlich den zweimal täglichen "router hung!"-Neustarts 15:24 <jrandom> hrm frosk, echtes "router hung", oder "router hung" wegen leaseSet-Ablauf? 15:25 <Pseudonym> Internetverbindung ist ok. wenn ich den i2p router neu starte, ist alles gleich wieder da 15:25 <+Complication> Mein Cel300 hängt auch nach einer Weile, aber die Intervalle wurden länger, und ich bin nicht auf dem neuesten Stand, was den Grund angeht 15:25 <@frosk> jrandom: lease expiration, da bin ich mir ziemlich sicher 15:25 <jrandom> hmm 'k 15:26 <jrandom> so gut wie alles davon wurde für den neuen Erstellungs- und Management-Code neu geschrieben, wir werden also sehen, wie es mit 0.6.1.10 läuft 15:27 <@frosk> cool 15:27 <@frosk> ich helfe gern beim Testen 15:28 <Pseudonym> ich brauche gerade keine Fehlersuche. Wollte nur einen Datenpunkt zur Stabilität beitragen 15:28 <jrandom> wikked, sobald es lokal stabil ist, werde ich auf jeden Fall Hilfe rekrutieren müssen :) 15:28 <jrandom> cool, danke Pseudonym 15:28 <jrandom> ok, hat noch jemand etwas für 1) Netzstatus? 15:30 <jrandom> wenn nicht, springen wir rüber zu 2) Status zu 0.6.1.10 15:30 <jrandom> wie in der Mail erwähnt, statt live im Netz Tweaks auf Tweaks zu stapeln, gehen wir direkt an die Quelle 15:31 <jrandom> es wird nicht rückwärtskompatibel sein, es wird also einen ... Ruck geben, und während wir ein paar weitere rückwärtsinkompatible Änderungen mit reinpacken, besteht die Möglichkeit, dass danach noch eine weitere kommt 15:32 <jrandom> genauer gesagt, eine Idee, mit der ich spiele, ist die Migration auf 1024-Bit ElGamal für den Code zur Erstellung der tunnel, statt 2048-Bit 15:32 <jrandom> aber das ist vielleicht nicht nötig. hängt davon ab, wie hart es uns im Live-Netz trifft 15:34 <jrandom> wenn doch, hieße das einfach ein Netzwerk-Upgrade, aber alle destinations/etc. blieben gleich. 15:34 <jrandom> aber wie auch immer, das ist etwas, das wir nach dem Erscheinen von 0.6.1.10 untersuchen 15:34 <+Complication> Eine lose verwandte Frage: Hängt die Schlüssellänge irgendwie mit der Länge der Datenstruktur zur tunnel-Erstellung zusammen? 15:34 <jrandom> ja 15:35 <jrandom> direkt: Schlüssellänge * 2 * max # Hops == Größe der Datenstruktur 15:36 <jrandom> (also, 256*2*8 = 4KB, was zufällig auch die Größe vollständiger Streaming-Lib-Nachrichten ist) 15:37 <jrandom> ((ElGamal hat einen 2x-Expansion-Faktor)) 15:38 <+Complication> Aha, danke. :) 15:38 <jrandom> ah, noch etwas zur neuen Spezifikation. bei der Implementierung habe ich noch einen weiteren Datenpunkt entdeckt (eine 4-Byte-„Reply-Message-ID“), den ich lokal in die Spez aufgenommen habe, unter Verwendung einiger reservierter Bits 15:40 <jrandom> ich hoffe, in den nächsten Tagen alles zum Laufen zu bringen, vielleicht gibt es also bis zum Wochenende erste (nicht-anonyme) Tests 15:40 <jrandom> aber natürlich mehr Infos dazu, sobald es so weit ist 15:41 <jrandom> ok, hat jemand Fragen/Kommentare/Bedenken zum 0.6.1.10-Kram? 15:41 <bar> noch eine lose verwandte Frage: während des Rollouts von .10, wie wäre es, i2p.net für ein paar Tage auf .9 zu lassen, für alle mit Auto-Update? 15:41 <bar> rollout* 15:41 <jrandom> ja, definitiv 15:42 <jrandom> ich werde während der Migration wahrscheinlich zwei oder drei router auf der Kiste laufen lassen 15:42 <jrandom> und es wird mindestens 5 Tage vor dem Release laute Warnungen geben 15:42 <bar> smooth 15:42 <+Complication> So wäre es in der Tat sanfter. 15:43 <+Complication> Forum scheint ein guter Kanal zu sein. News-Box auf der Router Console auch... 15:43 * jrandom erinnert sich an die Zeiten, als jedes Release rückwärtsinkompatibel war ... wir haben damals viel geübt ;) 15:43 <jrandom> ja, Forum, News-Box, Liste, Website 15:43 <+Complication> So würden diejenigen, die auf ihre Maschinen achten, es wissen. 15:43 <tethra> heheh 15:44 <jrandom> und diejenigen noch auf 0.6.0.1, nun, die sind sowieso am Arsch ;) 15:44 <@frosk> ab mit ihren Köpfen 15:44 <+Sugadude> Völlig off-topic: Können wir öfter rückwärtsinkompatible Änderungen machen, um diese alten router rauszudrücken? 15:44 <+Complication> Ich glaube, die haben I2P einfach vergessen laufen lassen :) 15:44 <jrandom> heh Sugadude 15:45 <jrandom> nun, wenn sie kompatibel sind, können wir ihre Ressourcen nutzen, aber wenn es einen Grund gibt, warum wir das nicht können, sollten wir sie als inkompatibel markieren 15:47 <jrandom> ok, wenn es dazu nichts mehr gibt, springen wir rüber zu unserem Auffangpunkt: 3) ??? 15:47 <jrandom> hat noch jemand etwas, das er im Meeting ansprechen will? 15:48 <tethra> irgendwo auf der Router Console steht, dass Benutzer hinter symmetrischen NATs derzeit nicht unterstützt werden, ändert sich das bald? 15:48 <tethra> oder zeige ich enorme Unwissenheit 15:49 <+Complication> Zum Webcache-Code... ich bin soweit ziemlich fertig. 15:49 <jrandom> es gibt ein paar Techniken, um Benutzern hinter symmetrischen NATs zu helfen, die bar in der Liste und im Forum skizziert hat, aber ich kenne keinen unmittelbaren Fortschritt 15:49 <jrandom> oh, nice1 Complication, sag mir Bescheid, wann ich das Release pushen soll :) 15:50 <+Complication> Habe den Watchdog so weit, dass er Downloads sinnvoll abbricht, mache noch Tests und Clean-up (es loggt derzeit viel mehr als gut ist).. 15:50 <+Complication> Ich habe einen Webcache-Server am Laufen, awup hat einen anderen ... für realistischere Tests könnten wir die Begrenzungen einschalten... 15:51 <+Complication> ...wenn ich legion erwische, frage ich ihn, ob er auch einen betreiben möchte. 15:52 <jrandom> cool, selbst ein einzelner Webcache wäre ein guter Anfang 15:52 <+Complication> Und wenn jemand sonst das Script ausführen will (verfügbar von awup.i2p, Python-Script mit SAM)... ihre Referenzen können hinzugefügt werden, allerdings erfordert das Hinzufügen von Refs zu weiteren „Seed-Webcaches“ derzeit ein Recompile der Sources. 15:53 <+Complication> (nicht in einer Datei, sondern im Header von GWebCacheContainer.java) 15:53 * gloin weiß nicht, was dieser Webcache-Kram ist. 15:53 <jrandom> gloin: damit kannst du dich mit I2Phex verbinden, ohne beim ersten Mal eine i2phex.hosts-Datei herunterladen zu müssen 15:54 <+Complication> gloin: für eine einfachere Integration von I2Phex 15:55 * cervantes kommt zu spät 15:55 <+Complication> Und für spätere Wiederverbinder (z. B. Leute, denen die Live-Peer-Refs ausgegangen sind) kann er frische Refs anbieten 15:55 <gloin> ok. 15:57 <+Complication> Oh, wieder offline 15:58 <stealth> was ist mit einem automatischen Start von i2phex, nachdem I2P gestartet wurde? 15:58 <+Complication> Scheint übertrieben 15:58 <+Complication> Zumindest in der aktuellen Phase 15:58 <jrandom> stealth: du kannst den i2p router jede gewünschte Java-Anwendung starten lassen, indem du Einträge in deine client.config-Datei hinzufügst 15:59 <+Complication> Außerdem denke ich, dass I2Phex gestartet werden kann, bevor I2P läuft 15:59 <@frosk> in jeder Phase 15:59 <+Complication> Theoretisch sollte es weiter versuchen, sich zu verbinden, bis I2P hoch ist 15:59 <+Complication> (hab's allerdings nicht getestet) 15:59 <jrandom> denk aber dran: wenn du ihm sagst, i2phex zu starten, wird beim Schließen von i2phex der i2phex-Client wahrscheinlich die JVM killen (wodurch dein router neu startet) 16:00 <+Complication> Außerdem könnte man das auch ziemlich leicht scripten... 16:00 <+Complication> z. B. "cd /home/i2p; sh i2prouter start; cd /home/i2phex; sleep 100; sh run.sh;" 16:00 <+Complication> (oder wie auch immer) 16:01 <+Complication> Sorry, eher /home/user/i2p :) 16:01 <cervantes> vergiss nicht, vor dem sleep 100 /usr/games/tetris zu starten 16:02 <jrandom> verdammt richtig 16:02 <jrandom> ok, hat noch jemand etwas fürs Meeting? 16:03 <stealth> nun, ich dachte nur daran, die EXE zu starten. Die i2psnark-Lösung mit „always on“ ist besser, weil Leute vergessen, ihre Dateien zu teilen, wenn sie nicht herunterladen... 16:04 <jrandom> ja, allerdings kenne ich keinen Gnutella-Client, der dünn genug ist (um integriert zu werden) 16:05 <cervantes> wird nicht am aktuellen Phex gearbeitet, um die UI zu abstrahieren? vielleicht wird der Client am Ende schlank 16:05 <+Complication> Diesen Teil von Phex CVS habe ich nicht gelesen 16:06 <jrandom> wenn Phex als .war laufen könnte, wäre das in der Tat großartig 16:06 <cervantes> isn't the=isn't there 16:06 <cervantes> ich irre mich wahrscheinlich 16:06 <+Complication> Sirup hat definitiv an einer XML-RPC-Schnittstelle gearbeitet, aber ich bin nicht sicher, ob Gregor & Co. das auch tun 16:07 <+Complication> Also weiß ich nicht, ob sirup es integriert hat oder angefangen hat, es von Grund auf zu schreiben 16:09 <jrandom> soweit ich mich erinnere, hat er nur apaches xmlrpc-lib importiert und einige Interna von I2Phex exponiert, aber es gab daran wahrscheinlich 6–8 Monate keine Arbeit mehr, und es war afaik nie funktional 16:10 <fox_> <tethra> mutella ist ein webbasierten gnutella-Client, der ziemlich leichtgewichtig ist, iirc. weiß nicht, ob das hilft, aber könnte sich lohnen, dass es sich jemand (Talentierterer) anschaut. 16:10 <fox_> <tethra> ist vielleicht nicht das, was gesucht wird, allerdings. 16:12 <jrandom> das Portieren eines neuen ist eine Menge Arbeit, besonders eines in C/C++, leider 16:12 <+Complication> Ich werde persönlich kaum mit XML-RPC basteln. Versuchen, verschiedene Bugs zu erwischen... ist allerdings in meinen kurzfristigen Plänen. 16:13 * Complication will den Rehash-Effekt endgültig loswerden, da er so eine Zeitverschwendung ist 16:13 <jrandom> ooh, vielleicht wird das durch eine Zeitzonenverschiebung ausgelöst? 16:14 <jrandom> wenn sich das I2P SDK mit dem router verbindet, holt es sich die aktuelle I2P-(NTP-)Zeit und zwingt die JVM des SDK in UTC 16:14 <+Complication> Klingt unwahrscheinlich... aber in diesem Stadium kann ich nicht viel ausschließen 16:15 <jrandom> (und wenn das Rehash von Reihenfolge und Dateizeitstempeln abhinge, könnte die Verschiebung um ein paar Stunden das ändern) 16:15 <jrandom> ja, du hast dich da in vieles reingewühlt, wollte nur eine Möglichkeit erwähnen 16:15 * jrandom weiß nichts darüber außer deinen Bugreports :) 16:16 <+Complication> Es passiert gelegentlich und scheint mit etwas zusammenzuhängen, das passiert, wenn die "sharedlibrary"-Konfigdatei geladen/neu geschrieben wird 16:16 <+Complication> Hm, interessante Möglichkeit... 16:16 <+Complication> Ich habe nicht genug gegraben, um das auszuschließen 16:18 <jrandom> ok, hat noch jemand etwas fürs Meeting? 16:19 <jrandom> wenn nicht... 16:19 * jrandom macht Schluss 16:19 * bar wünscht jrandom viel Glück mit .10 und überreicht ihm ein glänzendes baf 16:19 <jrandom> gracias :) 16:19 * jrandom *baf*t das Meeting zu