I2P-Entwicklertreffen - 29. November 2005

15:25 <jrandom> 0) hi 15:25 <jrandom> 1) Netzwerkstatus und 0.6.1.6 15:25 <jrandom> 2) Syndie 15:25 <jrandom> 3) I2P Rufus 0.0.4 15:25 <jrandom> 4) ??? 15:25 <jrandom> 0) hi 15:25 * jrandom winkt 15:25 <jrandom> wöchentliche Statusnotizen online @ http://dev.i2p.net/pipermail/i2p/2005-November/001234.html 15:26 * bar reicht jrandom einen baf 15:26 <c3rvantes> noch nicht! 15:26 * jrandom holt aus 15:26 <jrandom> äh... 15:26 <jrandom> gehen wir zuerst die ersten paar Tagesordnungspunkte an :) 1) Netzwerkstatus und 0.6.1.6 15:27 <jrandom> In den letzten Releases wurde vieles aktualisiert, aber das Netzwerk wirkt weiterhin einigermaßen stabil. 15:28 <jrandom> wir hatten auf einigen router deutliche Ausreißer, das ist aber ziemlich harmlos 15:28 <+legion> cool, ich stimme zu, der Netzwerkstatus wird besser. Außerdem ja, warum nicht tcp für 0.6.1.7 fallenlassen 15:28 <jrandom> (äh, Spitzen bei der tunnel-Teilnahme, also) 15:29 <@cervantes> kein Witz 15:29 <jrandom> nicht sicher, legion. Es könnte da draußen ein paar Nutzer geben, die auf tcp beschränkt sind, aber ich meine mich zu erinnern, dass es davon nur einen oder vielleicht zwei gab 15:29 <+legion> Mir ist bei 0.6.1.5 aufgefallen, dass der router manchmal von selbst neu startet. 15:29 <+Complication> Bei mir schwankte es in vertretbaren Grenzen, 100 bis 250 teilnehmende tunnel 15:29 <jrandom> Mir fällt kein guter Grund ein, es zu behalten, und mir fallen ein paar ein, es zu entfernen 15:30 <jrandom> cool, Complication 15:30 <jrandom> (diese Zahlen sind ziemlich durchschnittlich, laut stats.i2p/, aber denkt daran: Solche Zahlen können die Anonymität schädigen, also sollte man sie nicht wirklich herausgeben, besonders nicht in protokollierten Meetings ;) 15:30 <+Complication> Mein alter Celeron startet immer noch etwa alle 10 Stunden automatisch neu 15:30 <+Complication> Ansonsten ist er besser verbunden als je zuvor 15:30 <Pseudonym> Was sind die Gründe, es zu entfernen? 15:31 <+Complication> TCP ist teuer 15:31 <@cervantes> mein router ist völlig im Eimer 15:31 <+Complication> In Bezug auf Threads pro Verbindung 15:31 <@cervantes> Complication: multipliziere das mit 10 und du hast die aktuelle Spanne meines router ;-) 15:31 <+legion> Bei mir schwankt es zwischen 200–400 teilnehmenden tunnel, wirkt also besser als je zuvor. 15:32 <+Complication> cervantes: autsch autsch 15:32 <+Complication> Ich habe mal einen seltsamen Unfall gesehen, der 2000 teilnehmende tunnel verursachte, aber das war im Sommer 15:32 <jrandom> Pseudonym: Leistung (cpu/memory, besseres Scheduling aufgrund unserer semireliable-Anforderungen), Wartbarkeit, effektiveres Blacklisting 15:32 <+Complication> Ein einzelner Ausschlag, der nie wieder auftrat 15:32 <+legion> Ja, mit einigen früheren Versionen gab es solche Ausschläge 15:32 <jrandom> Complication: wir hatten> 2000 tunnel-Spitzen mit dieser letzten Revision 15:33 <jrandom> aber hoffentlich kümmert sich 0.6.1.7 darum 15:33 <+legion> Nun, das sind ein paar gute Gründe, tcp zu entfernen :) 15:33 <jrandom> aber nochmal: die Spitzen bei der tunnel-Teilnahme sind in Ordnung, da die meisten davon nicht genutzt werden 15:34 <@cervantes> Pseudonym: Es scheinen nur noch ein oder zwei routers im Netzwerk tcp zu verwenden 15:34 <jrandom> Es könnte auch eine gute Idee sein, tcp in dieser Revision ebenfalls zu entfernen, da sie keine anderen großen Änderungen hat. So können wir ziemlich klar sehen, wie sich das auswirkt 15:34 <jrandom> (und es bei Bedarf wieder aktivieren) 15:35 <Pseudonym> Wenn es nur zwei routers gibt, die es nutzen, kann ich mir nicht vorstellen, dass es in die eine oder andere Richtung viel ausmacht 15:35 <Pseudonym> (außer dass es zwei routers weniger im Netzwerk wären) 15:35 <@cervantes> 2 verärgerte Kunden 15:35 <jrandom> Nun, der Transport taucht in einigen seltsamen Situationen auf, was einer der Gründe ist, warum ich ihn deaktivieren möchte :) 15:35 <+Complication> Ich hoffe, sie nehmen das nicht allzu persönlich 15:36 <+Complication> Es ist echt fies von manchen ISPs, UDP zu filtern. 15:36 <+Complication> Fies und völlig sinnlos. 15:36 <jrandom> (z. B. wenn ein router kaputt ist, markieren Leute ihren SSU transport als fehlerhaft, und dadurch fallen sie auf den tcp transport zurück) 15:36 * Pseudonym liebt seinen ISP. keine Einschränkungen 15:37 <+Complication> Also würde man ohne TCP sehen, wie UDP das alleine handhabt? 15:37 <+Complication> „ohne Stützräder“ :P 15:37 <+legion> hm, wie umgehen wir solch fieses Filtern ohne tcp? 15:38 <jrandom> genau, Complication :) 15:38 <jrandom> legion: gar nicht 15:38 <jrandom> (restricted routes (eingeschränkte Routen)) 15:38 <+Complication> Nun, gibt es nicht eine Reihe nützlicher Anwendungen außer Filesharing-Programmen, die ebenfalls UDP-Pakete verwenden, die größer sind als DNS-Pakete? 15:39 <+legion> :( klingt nicht gut 15:39 <+Complication> In etwa so groß wie die kleinste Paketgröße, die I2P verwendet? 15:39 <jrandom> äh, legion, das ist kein Problem 15:39 <jrandom> Complication: Streaming-Protokolle 15:39 <+Complication> Man kann UDP niemals direkt blockieren, ohne DNS lahmzulegen. 15:39 <+Complication> Man kann die Paketgröße begrenzen. 15:40 <+legion> ok, klang so, als könnte es eins sein 15:40 <+Complication> VoIP? 15:40 <jrandom> Es wäre ein Problem, wenn es weit verbreitet wäre – wenn die Internet-Community allgemein udp verbieten würde 15:40 <+Complication> Hmm, benutzt VoIP große oder kleine Pakete? 15:40 <jrandom> aber wenn es nur ein paar ISPs sind, können wir sie wie restricted routes behandeln 15:40 <+Complication> Oder meintest du eher ... Video-Streaming? 15:40 <+legion> Ich denke, es nutzt eine Mischung aus beidem 15:41 <jrandom> beides, Complication, RTSP läuft über UDP, und Real läuft über RTSP, iirc 15:41 <+Complication> s/p/s 15:42 <+legion> Dann weiter zum nächsten Punkt? 15:42 <+Complication> cat /etc/services | grep -c udp 15:42 <+Complication> 227 15:43 <jrandom> Ich bin mir noch nicht sicher, ob wir tcp in 0.6.1.7 rauswerfen, aber wahrscheinlich. 15:43 <jrandom> aye, hat noch jemand etwas zu 1)? Wenn nicht, springen wir weiter zu 2) Syndie 15:43 <+Complication> Heißt, es gibt mindestens 227 Apps (einige möglicherweise veraltet oder LAN-Apps), die UDP verwenden 15:44 <jrandom> bah, das ist das Intarweb. Alles, was du brauchst, ist proxied HTTP-Zugang 15:44 <jrandom> Zu 2) habe ich nicht viel über das hinaus hinzuzufügen, was in der Mail steht (und was auf Syndie steht) 15:44 <+legion> Ich bin überzeugt, ja, weg damit. :) 15:44 <jrandom> Hat jemand etwas bzgl. syndie, das er ansprechen möchte? 15:45 <+legion> Zu 2) habe ich auch nichts zu sagen. 15:45 * Complication liest gerade „how Syndie works“ 15:46 <+Complication> Ein kleiner UI-Effekt überrascht mich immer wieder. :D 15:46 <+Complication> Wenn ich einen Thread von Nachrichten aufklappe, überrascht es mich immer wieder, dass die aktive Nachricht nach oben in der Liste springt. :P 15:47 <+Complication> Aber das könnt ihr wahrscheinlich getrost ignorieren. Ich bin nur sehr pingelig und ein Gewohnheitstier. :P 15:47 <@cervantes> Über das Threading-Modell wird gerade ausführlich diskutiert 15:47 <@cervantes> ;-) 15:47 <+Complication> Ich werde mich daran gewöhnen. :) 15:48 <+Complication> cervantes: in Syndie? Ich muss diesen Thread finden. :) 15:48 <@cervantes> Das mag ich auch nicht – aber das könnte sich durchaus ändern 15:48 <jrandom> ja, das ist irgendwie schräg, schätze ich 15:48 <+legion> ja 15:48 <@cervantes> "subject: syndie threading" 15:49 <+Complication> Außerdem müsste die aufgeklappte Nachricht ohnehin verschoben werden, wenn sie die unterste wäre. 15:49 <+Complication> Denn sonst bliebe sie dort hängen. 15:50 <jrandom> Nun, die Navigation unten zeigt jeweils 10 *threads* an, nicht 10 Nachrichten. Also könnte sie den untersten Thread aufklappen 15:50 * cervantes testet gerade einige unterschiedliche Threading-UI-Stil-Implementierungen zurzeit 15:51 <jrandom> wikked 15:51 <jrandom> ja, idealerweise werden wir sie in css umschalten können, oder wenn nicht, serverseitig 15:52 <@cervantes> oder vielmehr „threading navigation styles“ 15:53 <@cervantes> hmm, meine Tests verwenden standardmäßig reine HTML-verschachtelte ungeordnete Listen 15:53 <@cervantes> du kannst so viel css und JavaScript darüberlegen, wie du brauchst oder willst 15:53 <jrandom> Gibt es eine ETA, wann wir ein paar Mockups sehen können? 15:53 <@cervantes> (allerdings ist es nur ein Proof of Concept, keine echte UI-Implementierung) 15:54 <@cervantes> Ich erledige den Großteil meines Codings während der I2P-Meetings ;-) 15:54 <jrandom> heh 15:54 <@cervantes> Vielleicht ist das erste Mockup heute Abend fertig 15:54 * jrandom setzt tägliche Meetings an 15:54 <jrandom> wikked 15:54 <@cervantes> verdammt :) 15:55 <jrandom> ok, hat noch jemand etwas zu 2) syndie? 15:55 <jrandom> wenn nicht, gehen wir weiter zu 3) I2P Rufus 0.0.4 15:56 <jrandom> Ich habe über das, was in der Mail steht, nicht viel hinzuzufügen – Rawn/defnax, seid ihr da? 15:56 <+legion> also, wie gut ist 0.0.4? Welche Probleme bleiben ggf. noch? 15:57 * jrandom hat keinen blassen Schimmer 15:58 <+legion> Vielleicht kann einer der Nutzer antworten. Wirkt es gut und stabil? 15:58 <jrandom> ok, scheint, als wären Rawn und defnax gerade nicht da. Wenn jemand Fragen/Kommentare/Bedenken zu I2P Rufus hat, schaut im Forum vorbei und postet sie 15:58 <+legion> verdammt, dann müssen wir wohl. 15:59 <+legion> weiter zu 4)? 15:59 <jrandom> aye, so scheint's. ok, 4) ??? 15:59 <+Complication> Ich habe I2P Rufus leider nicht ausprobiert. 16:00 <jrandom> Hat noch jemand etwas, das er ansprechen möchte? 16:00 <jrandom> (komm schon, wir müssen das in die Länge ziehen, damit cervantes noch etwas arbeiten kann!) 16:00 <+legion> ja, was für interessantes Zeug steht als Nächstes an? 16:00 <+bar> gibt es irgendwo etwas, wo ich mehr über „restricted routes“ lesen könnte? 16:00 <+bar> (ich *habe* gesucht) 16:01 <+legion> Vielleicht könnten wir sogar i2phex besprechen? 16:01 <jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD 16:01 * cervantes setzt die Maus über den Schließen-Button an 16:01 <jrandom> äh, #future.restricted 16:02 <jrandom> plus die how_* Seiten & todo 16:02 <jrandom> (im Web) 16:02 <+Complication> Heh, I2P scheint einen Build übersprungen zu haben :D 16:02 <+Complication> :D 16:02 <+bar> danke 16:02 <+Complication> - public final static long BUILD = 1; 16:02 <+Complication> + public final static long BUILD = 3; 16:03 <jrandom> legion: etwas Hacking an der netDb, Performance-Mods, restricted routes, Verbesserungen beim Streaming, eepproxy-Verbesserungen, Verbesserungen an den tunnel, etc. Viel Kram, aber noch nichts bereit 16:03 <+legion> hm, seltsam 16:03 <jrandom> gibt es etwas bzgl. i2phex, legion? 16:03 <jrandom> Complication: ja, beabsichtigt. Ich habe vergessen, es für BUILD = 2 zu erhöhen 16:03 <+Complication> (nicht dass es für irgendetwas zählt, ich frage mich nur, ob ich diesen seltenen Fall schon einmal gesehen habe :) 16:04 <+legion> nice, klingt super, danke! 16:04 <jrandom> oh, das erinnert mich ... wäre cool, wenn sich jemand darum kümmern wollte, unsere Webseite zu überarbeiten 16:05 * jrandom will nicht darüber nachdenken, aber es muss früher oder später erledigt werden 16:05 <+legion> ja, da ist was 16:05 <+legion> würde es sich lohnen, i2phex an diesem Punkt auf den neuesten phex-CVS-Code zu aktualisieren? 16:06 <+Complication> Nicht sicher, ich habe zuletzt nichts von Redzara gehört 16:06 <jrandom> Soweit ich mich erinnere, hat redzara auf gregorz’ Updates für phex gewartet 16:06 <jrandom> (damit wir ein ziemlich sauberes Update/eine Erweiterung haben) 16:08 <+legion> hm, warum dann i2phex haben? 16:08 <+Complication> Für alle Fälle? 16:08 <jrandom> hmm? 16:08 <jrandom> i2phex ist eine Erweiterung von phex 16:08 <+legion> Scheint, als wollten sie einfach phex mit einer i2p-Erweiterung 16:09 <jrandom> Erweiterung, im Sinne von Änderungen an einer sehr kleinen Anzahl von Komponenten 16:09 <jrandom> äh, s/bits/components/. sodass wir den Code leicht aktualisieren können, wann immer die phex-Devs etwas fixen 16:10 <+legion> Wenn dem so ist, sollte es nicht viel Arbeit sein, es auf den neuesten CVS-Code zu aktualisieren – obwohl ich weiß, dass es das sein wird. 16:10 <jrandom> Zuletzt habe ich im Forum gehört, dass der Plan ist, I2Phex und Phex als separate Anwendungen zu haben, die aber den Großteil des Codes teilen 16:10 <jrandom> aye, legion, das wäre großartig, aber zuletzt hörte ich, dass Gregor die Änderungen an Phex noch nicht abgeschlossen hatte 16:11 <jrandom> (worauf redzara gewartet hat) 16:11 <+legion> ah, verstehe 16:11 <jrandom> Die Alternative ist also, entweder Gregor zu helfen oder die bestehende I2Phex-Codebasis weiter zu modifizieren 16:12 <+legion> nun, wenn ich nicht warte und i2phex einfach mit neuem Code aktualisiere, müsste redzara nicht weitermachen 16:12 <jrandom> nun, nicht wirklich. 16:12 <jrandom> I2Phex auf den aktuellen Phex-Code zu bringen, wäre großartig, ja 16:13 <jrandom> aber sobald die Phex-Entwickler ihren Phex-Code aktualisieren, sind wir wieder out of sync 16:13 <+legion> ok, ich werde mich wahrscheinlich heute Abend oder in den nächsten paar Tagen darum kümmern. 16:13 <jrandom> wikked 16:13 <+legion> Das ist in Ordnung. 16:14 <+legion> Ich will i2phex wirklich nicht zwangsläufig mit dem phex-Code in Sync halten; es klingt nur so, als ob das CVS Fixes enthält, die i2phex gut gebrauchen könnte. 16:15 <+legion> Außerdem möchte ich phex-Code und Features herauswerfen, die i2phex nicht braucht. 16:15 <jrandom> cool 16:16 <+legion> Was neue Features und das Fixen von Dingen angeht, die noch nicht funktionieren, wie die Upload-Queues... Nun, ich habe mir bereits angesehen, wie man die Webcaches zum Laufen bringt, aber es gibt noch viel zu tun. 16:17 <jrandom> word. Ja, phex hatte früher funktionierende gwebcache-Unterstützung, aber sirup hat sie deaktiviert, da sie anfangs nicht notwendig war 16:17 <+legion> Ich plane, irgendwann jeti zu i2phex hinzuzufügen. 16:18 <jrandom> nett 16:18 * jrandom hat jeti nie benutzt, und ich hoffe, es bleibt eine optionale Komponente, aber mehr Dinge zu unterstützen, ist cool 16:19 <+legion> Ja, kann optional sein, Nutzer werden ein jeti2phex herunterladen können ;) 16:19 <jrandom> word 16:19 <+legion> Es gibt noch viel, was wir mit i2phex machen können, obwohl es schon großartig funktioniert, wie es ist. 16:20 <+legion> Bislang ist es möglich und einfach, einen Client 24/7 verbunden und am Laufen zu halten. 16:21 <jrandom> ja, ich hatte damit guten Erfolg ... „Sicherung meiner lizenzierten Aufnahmen“ 16:21 <+legion> heh :) 16:22 <jrandom> ok, hat sonst noch jemand etwas fürs Meeting? 16:23 * cervantes rollt den chinesischen Gong herein 16:23 <+legion> Scheint, als vergesse ich etwas ... hmm 16:24 <+legion> Oh ja, irgendwelche Ideen, wie wir den Speicherverbrauch von i2p und i2phex reduzieren können? 16:25 <+Complication> Nun, der TCP-Transport nimmt etwas weg 16:25 <jrandom> man könnte beide in derselben JVM laufen lassen 16:25 <+Complication> Wenn der wegfällt, wird das etwas freigeben 16:26 <@cervantes> Nimm ein paar RAM-Riegel aus deiner Maschine heraus 16:26 <cat-a-puss> hat jemand Erfahrung mit Javolution und weiß, ob es helfen würde? http://javolution.org/ 16:26 <jrandom> (clients.config im i2p-Installationsverzeichnis definiert die Main-Class und Argumente zum Starten der Clients) 16:26 <+legion> Wenn wir also beide in derselben jvm laufen lassen und tcp wegfällt, könnten wir es auf unter 50mb bringen? 16:27 <jrandom> Keine Ahnung, legion. Hängt auch davon ab, was du mit 50MB meinst. RSS/VSS/etc 16:27 <jrandom> Ich würde allerdings nicht empfehlen, beide in einer JVM laufen zu lassen, es sei denn, du hältst beide die ganze Zeit am Laufen, da das Beenden des einen den anderen mit abschießen würde 16:27 <@cervantes> legion: Bandbreite begrenzen und Teilnehmer deckeln könnte auch helfen 16:27 <jrandom> aye, was cervantes sagte 16:28 <cat-a-puss> Mir scheint, wenn wir genau wissen, wie viele Objekte eines Typs wir voraussichtlich verwenden, würde das helfen, übereifrige JVM-Allokation zu verhindern 16:28 <+Complication> Genau, sie macht diese unterschiedlichen Allokationen, mit denen ich nie so recht zurechtgekommen bin 16:28 <jrandom> aye, davon machen wir einiges, cat-a-puss (siehe net.i2p.util.ByteCache) 16:29 <+Complication> (aber wie gesagt, Java ist für mich etwas sehr Neues) 16:29 <jrandom> Ich habe mir Javolution früher schon einmal angesehen, aber es scheint große Fortschritte gemacht zu haben. ich schaue es mir nochmal an 16:30 <cat-a-puss> jrandom: Ich weiß, einige Leute bei mir auf der Arbeit nutzen es und sind zufrieden damit, obwohl ihnen Speicherallokation egal ist 16:31 <jrandom> Nun, es würde wirklich keinen Speicher sparen, aber es würde helfen, den GC-Churn zu reduzieren 16:31 <+legion> Nun, mir persönlich ist Speicherallokation nicht so wichtig, vielen Leuten aber schon. 16:31 <jrandom> ooh, und es ist auch unter BSD lizenziert 16:31 <cat-a-puss> genau 16:31 <jrandom> legion: Speicherallokation bedeutet Performance 16:32 <+legion> äh, oh, dann Speicherverbrauch 16:33 <+legion> Viele Leute sind sehr glücklich mit utorrent wegen seines sehr kleinen Speicher-Footprints. 16:33 <jrandom> ah, oh, ja. Wir können das mit der Zeit optimieren, aber da i2p innerhalb der Standard-JVM-Größen läuft, bin ich nicht allzu besorgt (wir haben viel Spielraum zum Tweaken) 16:34 <jrandom> ok, hat noch jemand etwas fürs Meeting? 16:35 <+legion> nee, ich bin gut... 16:37 * jrandom holt aus 16:37 * jrandom *baf*s das Meeting zu