I2P Entwicklertreffen - 18. April 2005

16:09 <jrandom> 0) hi 16:09 <jrandom> 1) Netzstatus und 0.6.1.16 16:09 <jrandom> 2) tunnel-Erstellung und Überlastung 16:10 <jrandom> 3) Feedspace 16:10 <jrandom> 4) ??? 16:10 <jrandom> 0) hi 16:10 * jrandom winkt 16:10 <jrandom> wöchentliche Statusnotizen veröffentlicht unter http://dev.i2p.net/pipermail/i2p/2006-April/001281.html 16:10 * frosk auch 16:10 <jrandom> (fast zwei Stunden *vor* dem Treffen, auch noch :) 16:11 <jrandom> ok, da ich sicher bin, dass ihr die Notizen schon durchgekaut habt, springen wir zu 1) Netzstatus 16:12 <+Complication> Hi :) 16:12 * Complication schnappt sich schnell die Notizen 16:12 <jrandom> Die Version 0.6.1.16 hat einen seit langem bestehenden Bug in unserem PRNG behoben, der eine beträchtliche Anzahl willkürlicher tunnel-Ablehnungen verursacht hatte 16:13 <jrandom> (die eigentliche Ursache wurde letzten Oktober eingeführt, ist jetzt aber behoben) 16:13 <+Complication> Status hier: Funktioniert erträglich mit 1 + 0..1 Hop-tunnels, verhält sich mit 2 + 0..1 oder 2 +/- 0..1 nicht 16:14 <jrandom> ja, das ist auch nachvollziehbar, besonders bei langsameren Verbindungen 16:14 <jrandom> (leider ist „langsamer“ auch gar nicht so langsam) 16:15 <jrandom> Es gibt noch viel zu tun, und 0.6.1.16 ist noch nicht da, wo wir hinmüssen, aber es ist ein Fortschritt 16:17 <+Complication> Etwas, worüber ich nachgedacht habe, in Bezug auf das, was du „congestion collapse“ (Überlastkollaps) genannt hast 16:18 <+Complication> Eine Möglichkeit, die Auswirkungen zu begrenzen, wäre, einen router tatsächlich zu *verpflichten*, ein bestimmtes Kontingent an Teilnahme-Anfragen zu akzeptieren 16:19 <+Complication> (etwas, das vom Benutzer entweder direkt oder indirekt festgelegt wird?) 16:19 <jrandom> festgelegt von welchem Benutzer? 16:19 <+Complication> (z. B. ein Teil der share percentage (Freigabeprozentsatz) oder ein zusätzlicher Parameter) 16:19 <jrandom> der lokale Benutzer oder von uns als entfernte Benutzer? 16:19 <+Complication> Von jedem für sich selbst festgelegt 16:19 <@frosk> sollen wir dann zu 2) übergehen? :) 16:20 <jrandom> ja, wir können uns ebenso gut bei 2) wähnen :) 16:20 <+Complication> Sodass ich meinem router z. B. sagen könnte: „Auch wenn du überlastet bist, route mindestens 4 KB/s weiter“ 16:21 <jrandom> Complication: Das ist nicht wirklich möglich – wenn ein router zu stark überlastet ist, werden andere Leute (hoffentlich ;) aufhören, ihn zur Teilnahme in tunnels zu bitten. 16:21 <+Complication> (das würde natürlich bedeuten, dass eine lokale Destination noch etwas länger offline sein könnte) 16:21 <jrandom> und wenn sie nicht gefragt werden, können sie /nicht/ die Daten anderer weiterleiten 16:22 <+Complication> Ah, vielleicht hätte ich es deutlich klarer formulieren sollen 16:24 <+Complication> Ich dachte, es könnte bei einem bestimmten Kontingent an Teilnahme-Traffic seine eigenen tunnel-Erstellungsnachrichten drosseln, statt teilnehmende tunnels 16:24 <+Complication> z. B.: „Ich drossele meine teilnehmenden tunnels niemals unter 4 KB/s. Falls das nötig wäre, drossle ich stattdessen meinen eigenen Traffic.“ 16:26 <jrandom> hmm, dabei gibt es Anonymitätsrisiken (allerdings ähnlich wie selektive DoS, gegen die wir ohnehin nicht verteidigen) 16:27 <jrandom> aber das Drosseln unserer eigenen lokalen tunnel-builds bei Überlastung teste ich gerade – Unterstützung hinzuzufügen, um die 4 KB/s-Untergrenze optional zu ignorieren, sollte einfach genug sein 16:28 <spinky> Derzeit bekommt man überhaupt keinen Cover-Traffic, wenn man viele Daten überträgt. 16:29 <spinky> Eine Untergrenze für Teilnahme-Bandbreite klingt gut. 16:30 <jrandom> nun, wir haben eine Untergrenze (sowohl über die share percentage als auch intern reservierte 4 KB/s, nachdem die gesamte Bandbreite verteilt ist) 16:30 <+Complication> Bah, Verbindungsabbrüche ... Ich hoffe, von dem, was ich sagte, ist nicht viel verloren gegangen, aber Antworten muss ich dann im Log nachlesen :) 16:32 <@frosk> Gibt es etwas Besonderes an 4 KB/s? 16:33 <jrandom> Ein paar Dinge – 4 KB ≈ sizeof(tunnel create message), und nach Erfahrung habe ich noch nie von einem router gehört, der mit weniger erfolgreich lief 16:33 <spinky> Vielleicht sind es die Bugs, die die share percentage am Funktionieren hindern? 16:34 <jrandom> Was lässt dich sagen, dass die share percentage nicht funktioniert? 16:34 <@frosk> verstehe 16:34 <+Complication> frosk: nee, das ist nur eine Zahl im aktuellen Code, und ich habe mich darauf bezogen, während ich zu erklären versuchte, was ich mir vorgestellt habe 16:35 <+Complication> (nicht aus sinnvollen Gründen, sondern weil das, was ich mir vorstellte, in gewissem Sinne sein exaktes Gegenteil war) 16:35 <spinky> Sie ist auf 80 % gesetzt und die Teilnahme geht auf 0, wenn lokal Daten erzeugt werden. Vielleicht verstehe ich da etwas falsch. 16:36 <jrandom> ah, ja, das ist nicht das, was die share percentage macht 16:36 <+Complication> spinky: das ist ein Maximalwert dessen, was geteilt werden darf, abhängig von der Bandbreite, die tatsächlich zum Teilen verfügbar ist 16:37 <+Complication> Wenn lokaler Traffic 70 % einnimmt, bleiben dir nur 10 % zum Teilen 16:37 <+Complication> Wenn der lokale Traffic hoch ist, bleibt 0 % übrig, und die Obergrenze von 80 % wird nie erreicht 16:37 <spinky> Ok. Ich sehe, es heißt „bis zu“... 16:38 <+Complication> Und es gibt auch die 4-KB/s-Reserve 16:38 <jrandom> ah, es ist die share percentage dessen, was du verfügbar hast 16:38 <spinky> Vielleicht eine weitere Einstellung für die Untergrenze der Teilnahme-Bandbreite, unter der der router mehr tunnels akzeptiert? 16:38 <jrandom> Wenn du 95 % deiner Bandbreite nutzt, wird er bis zu 80 % der verbleibenden 5 % teilen 16:39 <+Complication> Oh, dann habe ich es auch teilweise missverstanden 16:40 <fox> <zorglu1> wie misst i2p die Menge an Bandbreite, die andere lokale Anwendungen nutzen ? 16:40 <spinky> (Nur so: Wenn ihr Cover-Traffic für gut haltet, ist es vielleicht sinnvoll, ihn auch bei starker lokaler Bandbreitennutzung konfigurierbar zu machen) 16:40 <+Complication> Ich dachte, es wird gegen das Sustained-Limit angewendet 16:40 <jrandom> zorglu1: es misst i2p's Bandbreitennutzung und kennt i2p's Bandbreitenlimits 16:41 <jrandom> oh, hmm, im Code zurückblickend, int availBps = (int)(((maxKBps*1024)*share) - used); 16:41 <jrandom> also hast du recht, Complication 16:42 <jrandom> spinky: Cover-Traffic ist nur in einem Low-Latency-Mixnetz so nützlich 16:42 <jrandom> es schafft zwar einen Anreiz für router mit höherer Bandbreite, aber diejenigen ohne Bandbreite übrig haben wenig Spielraum 16:49 <jrandom> Wie auch immer, das Problem der tunnel-Überlastung gibt es schon eine Weile, wurde aber erst kürzlich durch die irrsinnigen tunnel-Ablehnungsraten verschärft 16:49 <jrandom> hoffentlich wird die nächste Revision das für uns klären 16:49 <jrandom> ok, hat noch jemand etwas zu 2) tunnel-Erstellung und Überlastung? 16:50 <@frosk> klingt so, als wären Änderungen am tunnel-Bau-Schema nötig 16:50 <+Complication> Ich hoffe, es wird helfen, die Dinge zu verbessern :) 16:51 <+Complication> Oh, übrigens... 16:52 <jrandom> nun, wir haben ein paar einfache Fixes, wie z. B. die maximale Parallelität zu reduzieren, unsere Build-Versuche bei Überlast zu drosseln, die Drop-Frequenz zu verringern (statt expliziter Ablehnung) und das Profiling so anzupassen, dass explizite Ablehnungen gegenüber Drops bevorzugt werden 16:52 <+Complication> ... hast du zufällig etwas gefunden, das die große Diskrepanz zwischen Rohbandbreiten-Anzeigen und tunnel-Payload-Anzeigen erklären könnte? 16:52 <+Complication> (z. B. Gesamtbandbreite 1 GB, tunnel-Payload summiert 300 MB) 16:52 <jrandom> aber es stimmt, das beeinflusst nur die Größenordnung 16:52 <+Complication> (da ich in letzter Zeit nicht im IRC war, bin ich nicht sicher, ob ihr euch das kürzlich angesehen habt) 16:54 <jrandom> habe da nicht viel gegraben, aber denk daran: tunnel-Build-Anfragen für ausgehende tunnels sind keine tunnel-Nachrichten (und davon gibt es viele, wenn nur 0,1 % erfolgreich sind. und bei 4 KB pro Stück...) 16:54 * Complication ist nicht sicher, ob es an den Anzeigen liegt oder ein realer Effekt ist 16:55 <+Complication> Oh ... ausgehende Build-Anfragen ... in der Tat 16:55 <jrandom> der kommende -1-Build fügt eine Menge Statistiken für das Monitoring pro Nachrichtentyp hinzu 16:55 <+Complication> Das könnte genau der Grund sein 16:55 <jrandom> (in diesen ausgehenden Build-Anfragen sind auch Build-Teilnahme-Anfragen enthalten – das Weiterleiten einer Antwort) 16:56 <jrandom> ((es ist also nicht nur lokales Zeug)) 17:00 <+Complication>> Danke, das erklärt eine Menge :) 17:00 <+Complication>> Dann ist es kein Voodoo, sondern ganz realer Traffic, den ich nur vergessen hatte, weil er an den Stellen, die ich geprüft habe, nicht speziell gezählt wurde 17:00 <+Complication> Das müsste tatsächlich auftreten und kostet in der Tat viele Bytes 17:00 <+Complication> Besonders bei niedrigen Erfolgsraten 17:01 <jrandom> ja, obwohl es nicht so viel kosten sollte, wie es tut, da wir eigentlich höhere Erfolgsraten haben sollten, als wir es tun :) 17:01 <jrandom> ok, noch etwas zu 2)? 17:02 <jrandom> wenn nicht, schwenken wir rüber zu 3) Feedspace 17:02 <jrandom> frosk: willst du uns ein Update geben? 17:03 <jrandom> (oder uns sagen, wir sollen uns fsck off und die eepsite lesen? ;) 17:04 <@frosk> nun, für diejenigen, die frosk.i2p oder feedspace.i2p nicht verfolgt haben: feedspace funktioniert jetzt im Grunde (nach meiner eigenen Definition von „im Grunde) 17:04 <jrandom> (w00t) 17:05 <@frosk> es gab in letzter Zeit einige schöne Ergänzungen, etwa infrastrukturelle Unterstützung für Transports jenseits von i2p (tor und nicht-anonymes tcp/ip kommen in den Sinn) 17:06 <@frosk> also planen wir, syndie (in einer anstehenden und vermutlich sehr schönen Neuimplementierung) zu erlauben, feedspace als eine seiner Syndizierungsmethoden zu nutzen 17:06 <@frosk> derzeit gibt es keine Client-Apps, die feedspace tatsächlich für etwas *nutzen* :) Ich habe mit einer extrem groben Servlet-App getestet 17:07 <jrandom> (roh + funktional)++ 17:07 <@frosk> es gibt also natürlich eine offene Stelle für einen Client-Hacker ;) 17:08 <@frosk> es gibt noch ein paar notwendige Dinge, die feedspace vor öffentlichen Tests braucht, aber es sollte nicht mehr lange dauern :) 17:08 <jrandom> nice1 17:08 <jrandom> können wir irgendetwas tun, um zu helfen? 17:08 <@frosk> außerdem habe ich etwas an der Dokumentation gearbeitet, die gefehlt hat 17:09 <spinky> Siehst du feedspace für große Dateien geeignet? 17:10 <@frosk> 1) Client-Apps, die die (noch undokumentierte) XML-RPC-API nutzen, 2) http://feedspace.i2p/wiki/Tasks, 3) bei Tests mitmachen, wenn es so weit ist 17:10 <@frosk> Unterstützung für große Dateien ist derzeit keine Priorität, vielleicht später 17:10 <@frosk> Der Fokus für „1.0“ liegt auf kleineren Nachrichten wie Blog- und Diskussionsbeiträgen und Ereignissen aller Art 17:11 <jrandom> allerdings wäre es kein Problem, .torrent-Dateien in einen RSS/Feedspace-fähigen BT-Client einzuspeisen 17:11 <@frosk> große Dateien könnten funktionieren oder auch nicht :) 17:11 <@frosk> das wäre eine supercoole Sache 17:12 <jrandom> feed2snark ;) 17:12 <@frosk> ich hoffe, wir werden allerlei solche „Adapter“-Apps sehen :) 17:12 <+Complication> Nun, ich bin sicher, Leute werden Wege finden, große Dateien über Bit- ... ähm, Seitenkanäle zu bewegen :) 17:15 <@frosk> ich habe ein bisschen ein schlechtes Gewissen, dass der feedspace-Code allerlei Java-1.5-Features nutzt. Das wäre derzeit wahrscheinlich schwer auf freiem Java zu kompilieren/zu nutzen, aber das wird sicher aufholen :) 17:15 <jrandom> oje 17:16 <jrandom> nun, es gibt Gerüchte, dass gcj ecj für 1.5-ismen übernimmt 17:16 <spinky> Complication: Ponys mit Satteltaschen voller HDDs? 17:16 <@frosk> jep 17:17 <+Complication> spinky: Drohnen, in meinem bevorzugten Fall :P 17:17 * jrandom bewegt sich immer noch gerade so zu 1.4-ismen hoch 17:17 <+Complication> Aber ich schätze, Ponys tun’s auch :P 17:17 <jrandom> obwohl 1.6 wirklich nett ist ;) 17:17 <@frosk> um gcj-kompatibel zu bleiben? 17:18 <@frosk> nun, 1.6 hat sowieso nicht viele „-ismen“ für das meiste, denke ich :) 17:18 <+Complication> (oder fliegende Igel, die Speicherkarten abwerfen) 17:18 <jrandom> gcj/classpath/etc, aber auch wegen der Performance (ich finde 1.5 etwas schwergewichtiger als 1.4) 17:19 <jrandom> stimmt, die Verbesserungen in 1.6 betreffen größtenteils VM/Bytecode 17:19 <@frosk> hm ok 17:20 * jrandom versucht nicht, dich davon abzubringen, 1.5-ismen zu verwenden. Ich bin sicher, du hast deine Gründe, und z. B. Azureus benötigt ohnehin 1.5 17:21 <@frosk> nun, es gibt kein Zurück :) hoffentlich wird’s nicht zu holprig 17:24 <jrandom> ja, ich bin sicher, es wird gut ausgehen :) 17:25 <jrandom> ok, cool, hat noch jemand etwas zu 3) feedspace? 17:25 * frosk umarmt seine Generics und java.util.concurrent ;) 17:25 <jrandom> heheh 17:27 <jrandom> ok, wenn es nichts Weiteres zu 3 gibt, gehen wir weiter zu 4) ??? 17:27 <jrandom> hat noch jemand etwas für das Treffen? 17:27 <+Complication> Eine kleine Frage, die ich unter 2) hätte stellen sollen 17:28 <+Complication> Wisst ihr, wie entstehen typischerweise idle teilnehmende tunnels? 17:28 <+Complication> Sind sie meistens ein Zeichen fehlgeschlagener tunnel-builds, bei denen nur der Ersteller wirklich weiß, dass sie fehlgeschlagen sind? 17:28 <+Complication> Oder gibt es zusätzliche Gründe? 17:28 <+Complication> (abgesehen natürlich vom Offensichtlichen – nämlich dass eine App im Leerlauf sitzt) 17:29 <jrandom> eine idle App hätte keine idle tunnels (sie würden getestet) 17:29 <jrandom> idle tunnels sind aus irgendeinem Grund fehlgeschlagen 17:29 <jrandom> (entweder wurden sie nicht vollständig erstellt oder sind im Betrieb ausgefallen) 17:30 <+Complication> Richtig, also werden alle tunnels ohnehin getestet, und tunnel-Tests sollten Traffic verursachen ... in der Tat 17:30 <+Complication> Das bringt mich eigentlich zum zweiten Teil meiner Frage: Brächte es irgendeinen Vorteil, zu bemerken, dass ein tunnel idle ist, und ihn frühzeitig zu verwerfen? 17:31 <+Complication> Gibt es dort wertvolle Ressourcen zu sparen? 17:32 <jrandom> keine – ein tunnel, der keine Daten weiterleitet, verbraucht keine Ressourcen 17:32 <jrandom> (ok, er verwendet etwas RAM, vielleicht 32 Bytes) 17:32 <+Complication> Oder könnte es einem router helfen, ein besseres Bild seiner Last und ähnlicher Parameter zu behalten ... 17:33 <jrandom> Vorhersagen zur Bandbreitennutzung basierend auf der tunnel-Historie sind sicherlich eine offene Frage 17:33 <+Complication> Oder wäre es einfach sinnlose Arbeit, und man wartet am besten, bis er natürlich abläuft? 17:33 <+Complication> (so wie jetzt) 17:34 <jrandom> früher haben wir einige Vorhersagen gemacht, aber das brachte uns keine klaren Vorteile, daher verwenden wir jetzt einen einfacheren Algorithmus 17:34 <+Complication> Aha, also kein Gewinn ... 17:34 <+Complication> Danke, das war im Grunde alles, was ich dazu fragen wollte :) 17:34 <jrandom> kein Problem, nachvollziehbare Sorge 17:34 <jrandom> ok, hat noch jemand etwas für das Treffen? 17:35 <+Complication> Ja, wenn man Vorhersagen machen würde, könnte der Prozentsatz der idle tunnels die Schätzungen verfälschen 17:35 <+Complication> (wenn er sich erheblich verändert) 17:36 <jrandom> ja, wir würden den Idle-%-Anteil als Teil der Schätzung behalten wollen 17:36 <jrandom> (früher haben wir das – siehe die Methode RouterThrottleImpl.allowTunnel) 17:37 <+Complication> Oh, wusste ich nicht :) 17:37 <jrandom> und beachte den neuen Kommentar: 17:38 <jrandom> // ok, ignore any predictions of 'bytesAllocated', since that makes poorly 17:38 <jrandom> // grounded conclusions about future use (or even the bursty use). Instead, 17:38 <jrandom> // simply say "do we have the bw to handle a new request"? 17:39 * Complication blättert sich noch zur Datei vor, aber danke :) 17:39 <jrandom> w3rd 17:40 <jrandom> ok, wenn es nichts Weiteres für das Treffen gibt... 17:40 * jrandom rundet ab 17:41 * jrandom *baf*t das Treffen ab