I2P-Entwicklertreffen - 18. Mai 2004

14:07 <jrandom> 0) hi 14:07 <jrandom> 1) Testnet-Status 14:07 <jrandom> 2) SAM 14:07 <jrandom> 3) Roadmap-Updates 14:07 <jrandom> 4) MyI2P 14:07 <jrandom> 5) ??? 14:07 <jrandom> 0) hi 14:07 * jrandom winkt 14:08 <Nightblade> hi 14:08 * jteitel winkt zurück 14:08 <jar> hi 14:08 <duck> lo 14:08 <Masterboy> :P 14:08 <jrandom> wöchentliche Statusnotizen veröffentlicht bis http://dev.i2p.net/pipermail/i2p/2004-May/000239.html 14:09 <jrandom> sorry, wenn ich heute etwas neben der Spur bin, mein Schlafrhythmus ist noch mehr durcheinander als sonst 14:09 <jrandom> wie auch immer, weiter zu 1) Testnet-Status 14:10 <duck> die Diversifizierung würde mit einem größeren Netzwerk automatisch passieren, oder? 14:10 <jrandom> ja, und/oder weniger verzerrte Schwellwerte bei der Peer-Auswahl 14:11 <jrandom> zum Beispiel, wenn die Geschwindigkeitsschwelle der Median statt des Durchschnitts wäre, bekämen wir halb so viele schnelle Peers wie zuverlässige Peers 14:11 <jrandom> im Gegensatz zur heutigen Situation, wo die Geschwindigkeiten stark verzerrt sind 14:12 <Masterboy> nun, das Netzwerk hat sich erholt, das ist nicht so schlimm 14:12 <jrandom> ja, es hat länger gedauert als es sollte, und es hat Wege aufgezeigt, wie man es verbessern kann 14:13 <jteitel> hat sich das Netzwerk erholt? Ich kann mich immer noch nicht zuverlässig mit dem I2P-IRC verbinden 14:13 <jrandom> die Peer-Profile sind nicht schnell genug verfallen oder haben neue Kandidaten nicht effizient befördert 14:14 <jrandom> es hat auch eine Kette sekundärer Ereignisse ausgelöst – Router überlastet, die die Last nicht tragen konnten (aufgrund unzureichenden Profilings), wodurch einigen überlasteten Routern der Speicher ausging und sie herunterfuhren 14:15 <human> ayeee ayeee ayeee! 14:15 <jrandom> es war ein Prozess, jteitel – einige der Probleme, die wir gesehen haben, hängen mit den netDb-Ausfällen zusammen 14:15 <jrandom> heya human 14:15 <jteitel> Oh, OK 14:16 <_cervantes_> könnte ein belasteter Router nicht Tunnel an einen anderen Peer auslagern? 14:16 <ugha_node> Wow, Lebenszeit-Rate: 8,87KBps gesendet 8,35KBps empfangen. 14:16 <Nightblade> jteitel: Ich habe mich gerade nach mehreren Versuchen verbunden... warte immer noch darauf, dass mein /join durchgeht 14:16 * BrianR schaut sich um. 14:16 <jrandom> nein – ein Router kann einen Tunnel einfach verwerfen (wenn er ihn eigentlich gar nicht hätte annehmen sollen) 14:16 <ugha_node> (Und ich habe meinen Router vor einer halben Stunde neu gestartet) 14:16 <BrianR> verdammt. Ich bin zu spät. 14:17 <BrianR> jrandom: (Danke, dass du myi2p ans Ende der Agenda gelegt hast) 14:17 <jrandom> ugha> ja, ihr musstet die Lücke für diese drei schnellen schließen 14:17 <jrandom> hehe :) 14:18 <duck> ein schöner Angriff war das 14:18 <ugha_node> jrandom: Offensichtlich. 14:18 <_cervantes_> wäre es also nicht besser, rigoroser zu sein und Tunnel bei einem niedrigeren Schwellwert abzulehnen 14:19 <jrandom> ja, cervantes – die Router lehnen derzeit nie einen Tunnel ab, es sei denn, sie können den nächsten Hop nicht erreichen 14:19 <jrandom> wir wollen dort eine Art Drosselung einbauen, vielleicht basierend auf der Größe der jobQueue / der durchschnittlichen Latenz usw 14:20 <jrandom> außerdem sollten wir sicherstellen, dass wir nicht versuchen, zu viele Tunnel auf einmal zu bauen, wie es passiert ist, als ein großer Teil davon ausgefallen ist 14:20 <_cervantes_> oder einfach dem Benutzer erlauben, einen Schwellwert basierend auf der Hardware/Bandbreite festzulegen, von der er/sie weiß, dass sie verfügbar ist 14:20 <jrandom> (weil die schnellen+zuverlässigen Peers offline gegangen sind) 14:20 <_cervantes_> zumindest in dieser Phase 14:20 <jrandom> oh, das ist ein guter Punkt – den Leuten zu erlauben, explizit eine maximale Anzahl teilnehmender Tunnel festzulegen. 14:21 <jrandom> wir nehmen das in die nächste Revision auf. Gute Idee. 14:21 <ugha_node> Das klingt genau wie Fuzzy Logic. 14:21 <jrandom> wir müssen mit Überlastung umgehen, und einfach Nachrichten im Speicher zu puffern funktioniert sicher nicht 14:21 <duck> (hi fvw) 14:21 <_cervantes_> es wäre gut, eine Art zusammengefasste Statistiken zur Tunnel-Performance zu haben... die Art von Last, die sie auf einen Benchmark-Prozessor/Prozessoren ausüben könnten 14:22 <_cervantes_> btw, ich habe meinen Server offline genommen.... er bekam eine Unmenge an Tunneln und ich habe jbigi noch nicht kompiliert ;-) 14:22 <jrandom> siehe http://localhost:7655/routerStats.html#Tunnels 14:23 <jrandom> ah! ja, jbigi ist etwas, dessen Einsatz wir allen empfehlen möchten 14:23 <BrianR> Gibt es Gedanken zu einem Bandbreiten-Budgeting für Tunnel? 14:24 <jrandom> derzeit für 3.0 vorgesehen (mit einer allgemeinen Bandbreitenbegrenzung für den gesamten Router in 0.4.1) 14:24 <jrandom> aber pro-Tunnel-Bandbreitenlimits früher zu haben, würde nicht schaden 14:25 <fvw> Ist es klug, so früh Aufwand dafür zu betreiben, wenn es im Kernel der Betriebssysteme, die die meisten aktuellen Nutzer/Tester verwenden, viel einfacher und präziser gemacht werden kann? 14:25 <_cervantes_> etwas, das ich gern sehen würde, sind Einstellungen der Tiefe pro Tunnel (vielleicht ist das schon möglich) 14:25 <_cervantes_> zum Beispiel weiß ich bereits, dass ich meinem Server vertrauen kann.... also möchte ich nicht _x_ Hops durchlaufen müssen, um ihn zu erreichen 14:25 <jrandom> guter Punkt, fvw, besonders da wir derzeit nicht zu viel Bandbreite verschlingen 14:26 <jrandom> hmm cervantes – ja, jeder Client kann die Länge seiner Tunnel angeben, aber ich bin nicht sicher, dass das genau das ist, was du willst 14:26 <_cervantes_> nope 14:26 <jrandom> cervantes – ich denke, du suchst nach einem QoS, bei dem du die Verbindung für einen bestimmten Peer verkürzen kannst 14:26 <_cervantes_> zum Beispiel... 14:26 <_cervantes_> yep 14:27 <jrandom> (was für I2P 4.0 vorgesehen war, aber das ist mehr als ein Jahr entfernt == Unendlichkeit) 14:27 <_cervantes_> in diesem Fall auch die Tiefe pro I2P-Host auswählen 14:27 <BrianR> fvw: Ja, aber ein I2P muss ungefähr wissen, wie viel Bandbreite potenzielle Tunnel-Mitglieder verfügbar haben, um kluge Entscheidungen beim Tunnelbau zu treffen... 14:27 <_cervantes_> ah ok 14:27 <_cervantes_> :) 14:27 <jrandom> aber es ist eine gute Idee und technisch machbar – Patches sind willkommen :) 14:28 <_cervantes_> der Patch ist schon in der Post.... zusammen mit dem Scheck über 5000 Barren e-gold 14:28 <_cervantes_> ;-) 14:28 <jrandom> BrianR: vielleicht geht es auch halbwegs – nachhalten, an wie vielen Tunneln er teilnimmt und wie viel Bandbreite diese Tunnel nutzen, und das als Teil der Entscheidung verwenden, ob eine Tunnel-Erstellungsanfrage akzeptiert oder abgelehnt wird? 14:28 <jrandom> heh 14:30 <jrandom> ok, hat noch jemand etwas zum Testnet-Status? 14:30 <Masterboy> wie steht’s um mein Paradoxon? 14:30 <Masterboy> :) 14:30 <jrandom> mein Plan ist, bis Donnerstag oder Freitag eine 0.3.1.3 mit den Updates herauszubringen 14:31 <jrandom> Masterboy: ich hatte noch keine Zeit, deine Logs durchzugehen, aber wir werden das klären 14:31 <_cervantes_> Freitag 2005? 14:31 <_cervantes_> cool 14:31 <Masterboy> k 14:31 <jrandom> ok, weiter zu 2) SAM 14:31 <Masterboy> jetzt wissen wir, wer den veralteten Router betreibt.. 14:32 * jrandom übergibt das Mikro an unseren unerschrockenen SAM.pm-Dev 14:33 <jrandom> (das bist du, BrianR :) 14:33 <BrianR> Einen Moment.. :) 14:33 * duck jubelt 14:33 <jrandom> in der Zwischenzeit, ist dm oder firerabbit da? 14:33 -!- Irssi: #i2p: Insgesamt 26 Nicks [0 ops, 0 halfops, 0 voices, 26 normal] 14:33 * jrandom prüft die /names, nein. oh well 14:33 <jrandom> (also keine .net/C# sam lib updates dann) 14:34 <duck> ist das .py-Zeug noch aktuell? 14:34 <duck> oder durch SAM-Verbesserungen veraltet 14:34 <jrandom> nicht sicher 14:34 <BrianR> Ok. Ich bin zurück. 14:34 <Nightblade> Meine C-Bibliothek scheint zu funktionieren... ich habe jedoch noch keine Anwendung geschrieben, die sie nutzt 14:34 <jrandom> großartig, nightblade! 14:35 <Nightblade> Hat hier jemand GTK+/C unter Windows programmiert? 14:35 <human> duck: die Client-Lib braucht eine kleine Änderung für Versionsunterstützung 14:35 <_cervantes_> "hello world"? 14:35 <human> duck: der Rest sollte problemlos funktionieren 14:35 * jrandom schlägt ein Datagram wie tftp als idealen SAM-Test vor :) 14:35 <Nightblade> nun, eigentlich egal... funktioniert GTK unter Windows gut.....? 14:35 <jrandom> (oder sogar SAM-Streaming statt Datagram oder Raw) 14:36 <jrandom> cool, BrianR – wie läuft’s mit dem .pm und dem samcat? 14:36 <BrianR> Net::SAM ist im CVS in weitgehend nicht funktionsfähigem Zustand. 14:36 <BrianR> Ich hoffe, bis zum Wochenende alle Bugs ausgebügelt und Datagram und Raw zum Laufen gebracht zu haben. 14:37 <BrianR> Ein bisschen mehr Arbeit wird nötig sein, um Streams einen schönen OO-Schliff zu geben. 14:37 <Nightblade> ach ja, ich habe mich nicht um Datagram oder Raw gekümmert... nur Stream 14:37 <Nightblade> aber das ist ohnehin alles, was ich benutzen würde 14:37 <fvw> human: Hast du wxWindows in Betracht gezogen? Das ist für solche Sachen ziemlich nützlich (ich glaube allerdings nicht, dass es ein Windows-GTK-Target gibt) 14:37 <jrandom> super, BrianR 14:38 <BrianR> Meine Frau drängt mich, zum Abendessen zu kommen. Möglicherweise bin ich nicht rechtzeitig für die myi2p-Diskussion zurück. Ich habe das Bedrohungsmodell und dieses simple Fileserver-Zeug auf Node 208 gepostet 14:38 <human> fvw: den GTK-Windows-Client gibt es (The GIMP läuft auch unter Windows, too) 14:38 <jrandom> cool, nightblade, am besten implementiert man zuerst, was benötigt wird 14:38 <human> fvw: s/client/port/ 14:38 <jrandom> heh 'k, BrianR, danke 14:38 <fvw> human: Ich meine ein GTK-Windows-Target für wxWindows (das ich dir vorgeschlagen habe zu verwenden) 14:38 * fvw winkt BrianR zu. Bon Appétit. 14:38 <human> fvw: ah... nun, ich weiß nicht viel über vxWidgets (der neue Name von vxWindows :-) 14:39 <human> fvw: aber es war Nightblade, der über GTK+ sprach, nicht ich :-) 14:40 <fvw> Ups, meine Augen sind schief, ignorier mich. 14:40 <Nightblade> Ich bin mit C++ nicht so vertraut wie mit C 14:40 <Nightblade> soweit ich weiß ist GTK die einzige plattformübergreifende C-GUI-Bibliothek 14:40 <Nightblade> nicht dass ich besonders an GTK hänge 14:40 <fvw> spielt nicht wirklich eine Rolle, wxWindows ist von C aus leicht zugänglich. 14:40 <Nightblade> hmm 14:40 <Nightblade> na gut, vielleicht schaue ich es mir auch an 14:40 <Nightblade> ich kenne C++, aber ich habe keine größeren Programme darin geschrieben 14:41 * fvw ist auch kein C++-Coder, aber ich habe vor einiger Zeit einen ziemlich großen Transaktions-Viewer für ein Transportunternehmen darin aufgebaut, ohne Probleme. 14:42 <Nightblade> ich bin sicher, wxWindows hat einen reiferen Windows-Port 14:42 <Nightblade> als GTK 14:42 <fvw> ziemlich wahrscheinlich, ja. 14:43 <Nightblade> (ok, weiter mit dem Meeting) heh 14:43 <jrandom> :) 14:43 <jrandom> ok, springen zu 3) Roadmap-Updates 14:44 * jrandom war im letzten Monat nachlässig beim Aktualisieren von http://www.i2p.net/roadmap 14:44 <jrandom> aber jetzt ist es wieder aktuell 14:44 <jrandom> leider bekommen wir 0.4 nächste Woche offensichtlich nicht hin 14:44 <duck> (sind 1.1, 2.0, 3.0 auch up2date?) 14:45 <jrandom> jawohl 14:45 * Masterboy hat es gelesen, mochte es – keine Eile, wir stehen nicht in Flammen.. 14:46 <duck> jemand sollte auch Wikipedia/Infoanarchy aktualisieren :) 14:46 <jrandom> oh, ich sollte wahrscheinlich "SAM bridge and client libraries implemented and tested" aus 0.4 entfernen 14:46 <jrandom> heh ja, deshalb habe ich iA neulich !thwapped, als sie einfach die Wiki-Seite kopiert haben 14:46 <jrandom> (sie sollten einfach auf die /roadmap verweisen, nicht den Inhalt duplizieren) 14:47 <Masterboy> ist SAM fertig? 14:47 <jrandom> es ist funktional, ja, obwohl die Arbeit an zusätzlichen Client-Bibliotheken andauert 14:47 <jrandom> s/are/is/ 14:48 <jrandom> ok, sofern es keine weiteren Fragen/Bedenken zur Roadmap gibt, weiter zu 4) MyI2P 14:50 <jrandom> während ich selbst die Arbeit an myi2p eingestellt habe, haben wir das Vorhaben als Bounty ausgeschrieben - http://www.i2p.net/node/view/216 14:50 <jrandom> ein Teil davon bedeutet, dass wir die Anforderungen richtig festlegen müssen, und es gab einige Debatten darüber, wie diese aussehen sollten 14:51 <Masterboy> habe versucht, meinen Freund dazu zu bringen; er sagte, zu viel Arbeit, zu wenig Geld;P na ja, er ist Kapitalist;) 14:51 <Masterboy> naja, ich habe angeboten, es zu coden.. 14:52 <jrandom> daran zu coden ist immer willkommen :) 14:53 <jrandom> die derzeit offene architektonische Frage ist jedoch, wie man mit Leuten umgeht, die ihren I2P-Router / myi2p-Node nicht die ganze Zeit laufen lassen können 14:53 <Nightblade> man bräuchte einfach einige vertrauenswürdige I2P-ISPs 14:53 <jrandom> die beiden Vorschläge sind entweder die Nutzung gehosteter Service-Provider oder die Abspaltung des Systems, um einen verteilten Backing Store zu verwenden 14:54 <_cervantes_> Letzteres wäre langfristig die ideale Lösung 14:54 <_cervantes_> *latter 14:54 <duck> (und noch eine weitere Bounty) 14:55 <_cervantes_> oder ein Webcache-Proxy-Service... 14:55 <jrandom> genau – wenn wir den Weg über gehostete Service-Provider (oder lokal betriebene Nodes) gingen, könnten wir, sobald eine DHT/etc verfügbar ist, immer mehr Inhalte in die DHT schieben 14:55 <jrandom> _cervantes_: das ist im Wesentlichen der verteilte Backing Store – nicht vertrauenswürdige Daten-Caches 14:57 <deer> * Masterboy fragt sich, wo bogobot ist 14:57 <jrandom> der schwierige Teil ist, die benötigte Zugriffskontroll-Funktionalität zu bekommen – mit nicht vertrauenswürdigen Daten-Caches / verteiltem Backing Store sind ACLs im Wesentlichen Verschlüsselung 14:57 <jrandom> aber ein „Nebenaspekt“ zu dieser Diskussion kommt von den drei Punkten, die eine anonyme Person @ http://www.i2p.net/node/view/215#comment-105 aufgeworfen hat 14:57 <_cervantes_> und signierte Inhalte 14:58 <jrandom> genau, beide Wege werden signierte Inhalte brauchen 15:00 <_cervantes_> hier hat hypercubus' Modell seinen Wert... aber es ist keineswegs "schnelle" Lösung 15:00 <jrandom> aus den Diskussionen letzte Nacht im IRC haben wir uns auf das "LiveJournal-Bedrohungsmodell" konzentriert - welche Angriffe LJ-Nutzern wichtig sind und welche nicht 15:01 <wilde> zuerst einmal: überhaupt ein grundlegendes MyI2P hinbekommen 15:02 <jrandom> genau, und um das grundlegende myi2p zu implementieren, müssen wir die Deployment-Architektur kennen 15:03 <jrandom> mit dem LJ-Bedrohungsmodell für Nutzer, die ihre eigenen Nodes nicht betreiben können, denke ich nicht, dass wir den Weg der nicht vertrauenswürdigen Daten-Caches gehen müssen 15:03 <jrandom> und warum sollte jemand myi2p nutzen, wenn er lediglich LJs Bedrohungsmodell braucht? weil es anonym ist 15:04 <jrandom> wir könnten für ein idealisiertes System weitergehen, aber es gibt das Gesetz des abnehmenden Grenznutzens 15:04 -!- Irssi: #i2p: Insgesamt 24 Nicks [0 ops, 0 halfops, 0 voices, 24 normal] 15:05 <jrandom> deshalb tendiere ich dazu, die Bounty in den aktuellen Bahnen zu belassen – Alternativen können wir später hinzufügen, nachdem das Basissystem draußen ist 15:05 -!- duck_ heißt jetzt duck 15:06 <jrandom> wie auch immer, ich denke, das ist alles, was ich zu 4) MyI2P habe, außer jemand möchte noch etwas ansprechen 15:06 <jrandom> wenn nicht, weiter zu 5) ??? 15:07 <_cervantes_> hmm, du brauchst einen großen Richterhammer :) 15:07 <jrandom> ich habe vergessen, die neue eepsite von morph.i2p in den Meeting-Notizen zu erwähnen, und nickster.i2p hat jetzt ein öffentliches fproxy verfügbar! 15:08 <jrandom> (und sungo.i2p hat seine Webcam am Laufen :) 15:08 <_cervantes_> heh... 15:08 <_cervantes_> i2pr0n 15:08 <jrandom> hat sonst noch jemand etwas, das er ansprechen möchte? 15:10 <jrandom> wenn nicht, bringt uns das zur 70-Minuten-Marke 15:10 <deer> <Masterboy> nein 15:10 * jrandom leitet den Abschluss ein 15:10 * jrandom *baf*t das Meeting zu