I2P Entwicklertreffen - 20. Juli 2004

14:05 <jrandom> 0) hi 14:05 <jrandom> 1) 0.3.2.3, 0.3.3 und die Roadmap 14:05 <jrandom> 2) s/reliability/capacity/g 14:05 <jrandom> 3) Website-Updates 14:05 <jrandom> 4) Angriffe und Gegenmaßnahmen 14:05 <jrandom> 5) ??? 14:05 <jrandom> 0) hi 14:05 * jrandom winkt 14:05 <jrandom> wöchentliche Statusnotizen sind online @ http://dev.i2p.net/pipermail/i2p/2004-July/000358.html 14:06 <jrandom> springen wir gleich zu 1) 0.3.2.3, 0.3.3 und der Roadmap 14:07 <jrandom> (während ihr schon mal vorlest, nehme ich an ;) 14:07 <jrandom> das 0.3.2.3-Release ist draußen und scheint gut zu laufen 14:07 <jrandom> was sind die Hauptprobleme, die die Leute sehen? 14:08 <deer> <Nightblade> überhaupt keine Probleme 14:08 <deer> <duck> 4 Tage Uptime ohne Probleme 14:08 <jrandom> hmm, genau 14:08 <deer> <duck> für einige scheint IRC nicht sehr stabil zu sein 14:08 <deer> <duck> zum Beispiel wird kaji jede Minute gekickt 14:08 <deer> <duck> aber das ist nichts Neues 14:09 <jrandom> ja, das passiert ihm auch im Freenode-Netz, daher weiß ich nicht, woran es liegt 14:09 <deer> <duck> ja 14:09 <deer> <duck> connelly hatte ein paar schlechte Downloads, soweit ich weiß 14:10 <deer> <duck> aber du hörst mich nicht klagen 14:10 <jrandom> ach wirklich? hmm, ich glaube, wir haben herausgefunden, dass einiges davon mit seiner Lib zusammenhing, aber ich habe gelegentliche Ausfälle bei größeren Dateiübertragungen erlebt 14:10 <jrandom> insbesondere beim Leechen von Büchern aus Alexandria 14:10 <jrandom> (naja, nicht speziell, aber das ist die einzige Site, von der ich leeche) 14:11 <deer> <duck> :) 14:11 <jrandom> ok, also, mein Plan ist: Sobald das 0.3.3-Release draußen ist, konzentriere ich mich darauf, uns zu 0.4 zu bringen, parallel zu Bugfixes, die aufkommen 14:12 <jrandom> die für 0.4 verbleibende Arbeit ist größtenteils einfaches Web-Zeug (neue router-Konsole mit servlets, Jetty-Integration, ein servlet zur Steuerung des router und ein servlet zur Konfiguration der i2ptunnel-Instanzen) 14:13 <jrandom> vielleicht können ein paar JSP/Servlet-Leute dabei helfen, um mit dem Code warmzuwerden, obwohl ich davon schon einiges gemacht habe, daher wird die Impl nicht zu hart 14:13 <jrandom> soweit ich weiß, ist hypercubus' Installer so gut wie bereit 14:13 <jrandom> (obwohl ich ihm heute noch neue Arbeit aufgebrummt habe ;) 14:13 <deer> <duck> featurecreep++ 14:14 <jrandom> hält die Leute auf Trab :) 14:14 <jrandom> (aber mal ehrlich, jeder hasst es, für Upgrades alle JARs einzeln herunterzuladen) 14:14 <deer> <duck> ja, das ist mein größtes Problem beim Upgraden 14:14 <deer> <duck> (obwohl ich cvs benutze) 14:14 <deer> <duck> aber es wäre eins, wenn ich's nicht täte 14:15 <jrandom> heh 14:15 <mihi> jrandom: einfach alle tar-en -> 1 Download ;) 14:15 <jrandom> das wäre einfach genug, und belässt updgrade.sh/upgrade.bat == jar xf upgrade.jar 14:16 <jrandom> (nach einem wget-artigen Aufruf) 14:16 <jrandom> nun, ich denke, hypercubus hat den Code für all das im Griff, also können wir es ihm überlassen, das Richtige zu tun 14:17 <jrandom> jedenfalls, ja, wie euch vielleicht aufgefallen ist, ist unser Zeitplan nicht ganz so wie zuvor 14:17 <jrandom> die Roadmap wurde aktualisiert und laaaanngggeeezzooooggggeerrrt 14:18 <mihi> jjrraannddoomm:: cchheecckk yyoouurr dduupplleexx sswwiittcchh 14:18 <deer> <Nightblade> hah 14:18 <jrandom> heh 14:18 * mihi hat einen Fehler gemacht... wer findet ihn zuerst? 14:19 <jrandom> (\n\n) 14:19 <jrandom> aber wie auch immer 14:19 <mihi> okay, noch einer ;) 14:19 <duck> (keine doppelten Leerzeichen) 14:19 <mihi> duck++ 14:20 <jrandom> ich denke, die Roadmap ist ziemlich realistisch, zumindest bis zum 1.0-Release; je nach Nutzerakzeptanz und Feedback könnten wir 0.4.2 oder 0.4.3 umsortieren oder streichen 14:20 <jrandom> (und natürlich gilt wie immer: Die Roadmap kann sich ändern, wenn mehr Leute dazukommen :) 14:21 <modulus> vielleicht eines Tages, nachdem ich Java gelernt habe, aber i2p klingt nicht nach einem Projekt für einen Anfänger. 14:21 <deer> <Sandworm> ja, das wird länger dauern :) 14:21 <deer> * duck rechnet mit ein paar weiteren Verzögerungen auf dem Weg 14:21 <modulus> :-) 14:22 <deer> * duck kann es kaum Verzögerungen nennen, sieh dir die beeindruckende Tabelle auf http://www.i2p.net/redesign/announcements an 14:22 <jrandom> Verzögerungen können natürlich passieren, aber ich denke, die verbleibenden Meilensteine sind gut machbar 14:22 <jrandom> ja, danke, dass du zeigst, dass ich kein Leben habe, duck ;) 14:22 <deer> <duck> das ist dein Leben 14:22 <modulus> also, wann kommt 1.0 raus? :-) 14:22 <deer> <duck> sei stolz darauf 14:23 <jrandom> modulus: auch wenn einige Teile von i2p knifflig sind, gibt es viele Bausteine, die ein neuer Entwickler ziemlich leicht angehen kann 14:23 <modulus> wahrscheinlich eher langweilige Teile, oder? 14:24 <jrandom> nein, gar nicht. zum Beispiel schnell eine nette anonyme Dateiübertragungs- oder Chat-App bauen, einen Mini-Webserver, ein MUD, eine Schach-App, was auch immer 14:24 <duck> (Website-Updates) 14:24 <modulus> hmm, klingt cool. 14:24 <jrandom> (aka einfache Client-Apps, die anonym sein können) 14:24 <jrandom> und natürlich Web-Updates ;) 14:25 <modulus> was hat es mit diesen Web-Updates auf sich? 14:25 <jrandom> unsere Website braucht Arbeit (siehe http://dev.i2p.net/pipermail/i2p/2004-July/000358.html oder warte ein paar Minuten auf Agendapunkt 3) 14:25 <cat-a-puss> Wo passt myi2p da hinein? 14:25 <modulus> ah ah 14:26 <jrandom> cat-a-puss: http://www.i2p.net/redesign/myi2p :) 14:26 <modulus> ich denke, myi2p hat derzeit keine Priorität... 14:26 <jrandom> (ich habe vor ein paar Stunden gerade eine kurze Seite dazu geschrieben) 14:27 <jrandom> Nebenbei: Website-Updates werden alle auf der i2pwww-Mailingliste gepostet (http://dev.i2p.net/pipermail/i2pwww/2004-July/thread.html) 14:28 <modulus> hmm, ich könnte eine globale naming ap :-) 14:28 <jrandom> aber ich sehe die myi2p-Implementierung (zumindest das Basis-Adressbuch und Blogging) weiterhin für das 1.0-Release vorgesehen 14:28 <jrandom> (laut Roadmap für November vorgesehen) 14:28 <jrandom> ja, könntest du auf jeden Fall 14:28 <modulus> etwas Einfacheres als DNS, mit Authentifizierung und Delegation von TLDs 14:28 <jrandom> wäre auch nicht schlecht – eine einfache App, mit der man einen zentralen Nameserver abfragen kann, wäre nett 14:29 <modulus> yep 14:29 <jrandom> also, leg los mit Coden :) 14:29 <modulus> Ich fange morgen an. Tretet mich, wenn ich an anderen Dingen hänge ;-) 14:29 <jrandom> hehe cool, wird gemacht 14:29 <jrandom> ok, weiter zu 2) s/reliability/capacity/g 14:29 <duck> kleine Frage zur Site: 14:29 <duck> oh, Moment 14:29 <duck> das ist 3 14:29 <duck> sorry 14:29 <jrandom> klar, was gibt's? 14:30 <jrandom> ah, ok 14:30 <jrandom> im 0.3.3-Release wird es eine ziemlich grundlegende Änderung am Peer-Profiling und Auswahlcode geben, wie in der E-Mail und http://www.i2p.net/redesign/how_peerselection beschrieben 14:31 <jrandom> ich habe es im Moment auf einem Paar routers laufen und es wirkt recht brav (Geschwindigkeit: 25.18 (5 schnelle Peers) Kapazität: 17.50 (8 Peers mit hoher Kapazität) Integration: 37.00 (2 gut integrierte Peers)) 14:31 <jrandom> und keine negativen Werte mehr :) 14:31 <modulus> :) 14:32 <jrandom> ich werde noch ein bisschen testen, vielleicht noch ein oder zwei Tage, und es dann als 0.3.3 rausbringen 14:32 <cat-a-puss> d 14:32 <cat-a-puss> <modulus> 14:32 <cat-a-puss> ups 14:33 <duck> empfiehlst du, cvs nicht zu aktualisieren? 14:33 <cat-a-puss> to do dns look at a cache of http://www.levien.com/thesis/compact.pdf 14:33 <jrandom> nein, cvs ist im Moment ziemlich stabil 14:33 <jrandom> (aber wie immer: Sei bereit zurückzurollen, falls etwas Übles passiert) 14:35 <jrandom> sieht cool aus, cat-a-puss, danke 14:35 <cat-a-puss> (Ich habe eine Kopie des Originals, falls es jemand will) 14:36 <jrandom> der Google-Cache verunstaltet die Bilder etwas, also wenn du das rohe PDF hast, wäre das super 14:36 <jrandom> wie auch immer, wir driften gerade etwas vom Thema ab (aber wir können später darauf zurückkommen) 14:37 <jrandom> das war's im Wesentlichen zum Wechsel von reliability/capacity, also weiter zu 3) Website-Updates 14:37 <jrandom> duck: du hattest etwas, das du ansprechen wolltest? 14:38 <jrandom> während duck seine Notizen vorbereitet, hat vielleicht jemand Ideen/Vorschläge/Bedenken bzgl. der Punkte aus der E-Mail? 14:39 <deer> <Nightblade> die Website sieht gut aus 14:39 <jrandom> ja, mir gefällt die neue Navigation und das Site-Layout ist ziemlich aufgeräumt 14:40 <deer> <Nightblade> leichter, Dinge zu finden 14:40 <cervantes> _viel_ leichter, Dinge zu finden 14:40 <duck> zuerst möchte ich unserem User Advocate protocol danken, dass es nützlich geworden ist :) 14:40 <jrandom> heh 14:40 <duck> er hatte ein paar gute Vorschläge und hat gerade erst angefangen 14:40 <cervantes> hip hip hurra! 14:40 <jrandom> (Hört, hört!) 14:41 <duck> als Nächstes denke ich, es gibt kaum einen Grund, das Redesign nicht wirklich live zu schalten 14:42 <jrandom> einverstanden – vielleicht können wir news/development/documentation einfach als Nicht-Seiten-Navigationselemente markieren, die jvm- und Config-Tweaks fürs Erste weglassen und etwas Basis-Content für die I2PTunnel-Seite besorgen, ich denke, dann können wir es deployen 14:42 <jrandom> ich will nur, dass es live geht, mit allen funktionierenden Links (und allen Seiten, die nicht funktionieren) 14:43 <jrandom> es wird natürlich weitere Updates geben, nachdem es live geht ;) 14:43 <jrandom> äh, live 14:44 <jrandom> nebenbei: wilde hat auch unseren 34sp-Account eingerichtet, sodass wir die Site bei Bedarf dorthin migrieren können 14:44 <cervantes> coolio 14:44 <jrandom> was meinst du, duck? kann das menu.php-Dingsda Nicht-Seiten-Navigationseinträge handhaben? 14:44 * cervantes prüft seinen Posteingang auf Referral-Punkte 14:45 <jrandom> (oder wäre es zu viel Aufwand, das reinzumodden?) 14:45 <jrandom> hehe cervantes, das sollte unterwegs sein 14:45 <cervantes> ;-) 14:45 <cervantes> ah, der alte Trick „Der Scheck ist in der Post“ 14:47 <duck> sorry; nebenbei noch etwas anderes am Arbeiten. 14:47 <duck> ok; ja, möglich, es nur als Navigations-Abschnittstitel zu machen 14:47 <jrandom> kein Problem, wir können weitermachen und später darauf zurückkommen, wenn du magst 14:47 <jrandom> ok, cool 14:47 <jrandom> (duck++) 14:48 <jrandom> ok, noch anderes Website-bezogenes Zeug? 14:48 <duck> mit deinem Vorschlag klingt es bereit zum Hochladen. 14:48 <jrandom> wenn nicht, können wir zu 4) Angriffe und Gegenmaßnahmen übergehen 14:48 <duck> . 14:48 <jrandom> word 14:49 <jrandom> ok, ich nehme an, ihr lest die Mailingliste und habt connellys Beiträge und die verschiedenen Antworten gesehen 14:50 <cervantes> er war fleißig :) 14:50 <cervantes> (fast so sehr wie proto) 14:50 <Connelly> imo, das Netzwerk wirkt solide, außer gegenüber Traffic-Analyse (Sites mit viel Traffic), gegenüber staatlichen Angriffsformen, die Verbindungen kappen, und wenn Angreifer eine große Mehrheit des Netzes übernehmen 14:50 <jrandom> auch wenn ich denke, dass wir ziemlich gut dastehen, bin ich sicher, dass es etwas (oder Dinge) gibt, die wir übersehen haben; nehmt also bitte nicht an, dass i2p tut oder tun wird, was es verspricht – stellt die Annahmen in Frage und sagt, warum es Mist ist 14:50 <Connelly> die Verschlüsselung macht so ziemlich alle nicht-aggressiven Angriffe zunichte 14:51 <jrandom> das ist die Hoffnung 14:51 <jrandom> außerdem werden mit den Fähigkeiten von i2p 2.0 und 3.0 Abwehrmaßnahmen gegen Angriffe durch Gegner auf Regierungsniveau möglich sein 14:51 <Connelly> in der Praxis wird es natürlich Sicherheitslücken zum Flicken geben 14:52 * jrandom muss noch Dokus schreiben, wie die 3.0-Delays Segmentierungsangriffe verhindern werden 14:52 <jrandom> sicherlich, connelly 14:54 <jrandom> ok, wenn es dazu nichts Weiteres gibt, war's das von meiner Seite 14:54 <jrandom> also 5) ??? 14:55 <jrandom> ach ja, nebenbei habe ich für eine der Simulationen über einen Zeitraum von 4 Tagen die Bandbreitennutzung gegen die # teilgenommenen tunnels in einem Diagramm geplottet 14:55 <jrandom> das ist unter http://dev.i2p.net/~jrandom/4daybandwidth.webp gepostet 14:56 <jrandom> die Simulation hatte 32KB-Nachrichten alle 30 s hin und her, mit zwei routers, die auf 6KBps gedrosselt waren, und die Dinge verhielten sich genau so, wie sie es 'sollten' 14:56 <duck> (nolink-Property für die Site implementiert) 14:56 <jrandom> (z. B. Last über die schnellen zuverlässigen Peers verteilt, langsame Peers vermieden, etc) 14:56 <jrandom> w00t 14:56 <Connelly> ein Log-Plot von Bandbreite/Nutzer gegen Netzgröße wäre nett 14:57 <Connelly> damit man sagen kann: 'ja, es skaliert wirklich' 14:58 <jrandom> das bräuchte nicht einmal einen Log-Plot – die Skalierbarkeit der Client-Kommunikation ist streng O(1) [erfordert 2k*msgSize, wobei k = # Hops im tunnel] 14:58 <jrandom> aber ja, ich stimme zu, wir brauchen Dokus, die beschreiben, wie i2p skaliert 14:58 <Connelly> nun, für Kademlia ... ist das in deiner Simulation? 14:58 <jrandom> ja, die Simulation ist tatsächlich der vollwertige router-Code, alles in einer einzigen JVM ausgeführt 14:58 <jrandom> ich lasse es sogar mit den vollständigen TCP-Verbindungen laufen, statt des VM-Kommunikationssystems 14:59 <jrandom> der Kademlia-Code wird verwendet, wenn Alice Bob das erste Mal kontaktieren will – solange sie weiterreden, ist ihre Kommunikation O(1), da sie ihr LeaseSet zusammen mit der Nutzlast bündeln 14:59 <jrandom> (daher sind keine nachfolgenden netDb-Lookups nötig) 15:00 <cervantes> vl07 und onb0 sind die gedrosselten routers? 15:00 <jrandom> aber ja, wir brauchen eine Simulation, um zu zeigen, wie die netDb selbst skaliert 15:01 <jrandom> cevantes: 0jvf und onb0 15:01 <cervantes> wodurch erklärt sich vl07s Absturz nach einem Tag Uptime? 15:02 <cervantes> scheint sich mit 00u0 zu kreuzen 15:02 <jrandom> alle nicht-gedrosselten routers sind im Wesentlichen gleich – sie laufen alle auf derselben CPU, haben alle die gleiche (0 ms) Latenz, daher ist die Zuordnung eines als 'schnell' vs. 'zuverlässig' einfach willkürlich 15:04 <Connelly> erholen sich deine Bezeichnungen 'schnell und zuverlässig', 'langsam' etc. von großen Werten? 15:04 <jrandom> warum haben sich Ranking/Nutzung nach einem Tag verringert? ich bin nicht sicher, vielleicht haben vorübergehende CPU- oder I/O-Last während des Tests die Geschwindigkeit etwas reduziert 15:04 <jrandom> ja, die Rankings verwenden jetzt den Median, nicht den Mittelwert, außerdem gibt es einen ziemlich schnellen Abfall der Daten 15:05 <jrandom> s/fiarly/fairly/ 15:05 <Connelly> also wenn ich dich glauben mache, meine Zuverlässigkeit sei 1000000000, kannst du dich erholen, wenn ich beginne, Nachrichten zu verwerfen 15:06 <jrandom> sicher – wenn du 'fehlst', höre ich sofort auf, dich um Dinge zu bitten, und senke dein Ranking 15:06 <jrandom> die neue „capacity“-Berechnung ist wiederum ziemlich empfindlich gegenüber solchen Änderungen 15:06 <jrandom> (Speed ist ebenfalls schwer zu fälschen, da alle Speed-Ränge tatsächlich gemessene Werte sind) 15:07 <jrandom> ((wie es auch die reliability war und wie es die capacity-Berechnung ist)) 15:09 <jrandom> ok, hat sonst noch jemand etwas, das er ansprechen möchte? 15:10 <deer> * jrandomi2p schlägt den *baf*er vor 15:11 * jrandom stimmt zu 15:11 * jrandom holt aus 15:11 * jrandom *baf*t die Sitzung