I2P Entwicklertreffen - 27. März 2007

16:02 <jrandom> 0) hi 16:02 <jrandom> 1) Netzstatus 16:02 <jrandom> 2) zzzs NTCP/SSU-Vorschläge 16:03 <jrandom> 3) Syndie-Entwicklungsstatus 16:03 <jrandom> 4) DNS/Registrar-Status 16:03 <jrandom> 5) ??? 16:03 <jrandom> 0) hi 16:03 * jrandom winkt 16:03 <jrandom> wöchentliche Statusnotizen veröffentlicht unter http://dev.i2p.net/pipermail/i2p/2007-March/001342.html 16:04 <jrandom> springen zu 1) Netzstatus 16:04 <jrandom> Sieht ziemlich gut aus, und wie erwähnt gibt es zu den neuesten Änderungen noch mehr Forschung zu tun 16:05 <+Complication> Ich wollte mich ein wenig über die IRC-Konnektivität beschweren (alles andere scheint recht ordentlich), aber im letzten Tag hatte ich nur etwa 6 Disconnects, was gar nicht so schlecht ist 16:05 <cervantes> /mute Complication 16:05 <jrandom> heh 16:05 <+Complication> :D 16:06 <+Complication> Die Erfolgsrate beim Tunnel-Aufbau ist allerdings sehr schön 16:06 * Complication prüft noch einmal, sicherheitshalber 16:06 <jrandom> ja, ich habe etwas Disconnect-Churn gesehen (ehrlich gesagt lese ich meinen Backlog mit grep -v -\!- und sehe die Disconnects daher nie ;) 16:06 <cervantes> es gab in letzter Zeit verschiedene ISP-Pannen an der IRC-Front - postman schaut sich alternative Hosting-Vereinbarungen an 16:06 <jrandom> die Tunnelaufbauraten in den Statistiken zeigen einen Aufwärtstrend, scheinen aber im Allgemeinen mit den Zyklen auf stats.i2p übereinzustimmen 16:06 <cervantes> hoffentlich können wir eine bessere Netzwerk-Redundanz bekommen 16:06 <jrandom> ah ok cervantes 16:07 * jrandom würde anbieten, bei dev.i2p.net zu helfen, aber ich erinnere mich nicht, wann die Last dort zuletzt unter 4 war 16:08 <jrandom> ok, hat sonst noch jemand etwas zum Netzstatus anzusprechen? 16:10 <jrandom> wenn nicht, springen wir rüber zu 2) zzzs NTCP/SSU-Vorschlägen 16:10 <jrandom> zzz scheint im Moment nicht da zu sein, und ich habe meine Syndie-Beiträge als Antwort auf den Thread zu Hause gelassen (d'oh) 16:11 <jrandom> wie auch immer, schreibt eure Gedanken in zzzs Blog (oder lest dort für mehr Infos) 16:11 <jrandom> möchte dazu jemand hier und jetzt noch etwas diskutieren? 16:12 <+Complication> Nun, ich habe dort persönlich geantwortet und meine Sorge über eine zu starke Abhängigkeit von UDP geäußert (weil UDP bei mir persönlich ziemlich hohe Neuübertragungsraten hatte) 16:12 <jrandom> ja 16:12 <+Complication> Ich habe allerdings über einen Ansatz nachgedacht... 16:12 <+Complication> Derzeit sind die Gebote vollständig deterministisch (im Gegensatz zu probabilistisch mit einer Zufallskomponente), richtig? 16:13 <jrandom> ja, vollständig deterministisch 16:13 <+Complication> Ich habe mich gefragt, ob es von Nutzen wäre (im Sinne des Vermeidens von Extremen), ihnen eine Wahrscheinlichkeitskomponente zu geben 16:14 <+Complication> Also etwa: "60% Chance auf NTCP, 40% Chance auf SSU" 16:14 <+Complication> (unter der Annahme, dass keine Vorabdaten vorliegen – wenn frühere Fehlschlags-/Erfolgsdaten vorhanden wären, müsste man die Wahrscheinlichkeit vermutlich zugunsten des besser performenden Transports für diese Verbindung verschieben) 16:15 <jrandom> Nun, das hängt davon ab, was man erreichen will – nach meinem Verständnis von zzzs Vorschlag ist das Ziel, SSU wann immer möglich zu verwenden 16:15 <+Complication> (natürlich vorausgesetzt, dass beide Transporte für eine gegebene Verbindung nutzbar sind – manchmal sind sie es ganz sicher nicht) 16:15 <jrandom> Eine Randomisierung würde dabei nicht helfen, würde aber mehr Gelegenheiten bieten, Daten über beide Transporte im Feld zu sammeln 16:16 <+Complication> Nur ein Gedanke, wie man einen Ausgleich zwischen ihnen versuchen könnte (denn wenn einer immer höher bietet, werden Router wohl nicht viel "experimentieren") 16:19 <jrandom> Das ist eine Methode, mit der wir mehr Daten sammeln könnten, sollte man im Hinterkopf behalten 16:19 <jrandom> ok, wie erwähnt, postet in den Thread für mehr Zeug :) 16:20 <jrandom> springen wir weiter zu 3) Syndie-Entwicklungsstatus 16:20 <jrandom> ich habe nicht viel hinzuzufügen über das hinaus, was in der Mail steht 16:20 <jrandom> hat jemand Fragen/Kommentare/Bedenken? 16:21 <+Complication> Noch nicht. :) 16:22 <jrandom> hehe 16:22 * Complication hegt die Hoffnung, mehr mitzuhelfen, entweder an der I2P- oder an der Syndie-Front, aber ich muss dieses Webcache-Ding zuerst rausbringen 16:22 <jrandom> w3rd, freue mich auf beides :) 16:24 <jrandom> ok, lassen wir 4 aus und springen zu 5) ??? 16:25 <jrandom> möchte sonst noch jemand etwas für das Meeting ansprechen? 16:26 <TrevorReznik> gibt es Interesse an einem Hashcash-Generator für i2p? 16:26 <TrevorReznik> also über die Browseroberfläche. 16:26 <TrevorReznik> ich dachte daran als eine Art Möglichkeit, mögliche DoS-Szenarien innerhalb i2p zu eliminieren. 16:27 <jrandom> hmm, in JavaScript oder C/Java? 16:27 <jrandom> ich glaube, es gibt da draußen ein paar Hashcash-Generatoren 16:27 <TrevorReznik> in Java. 16:28 <+Complication> nun, ein wenig Recherche zu Hashcash-Schemata wird wohl irgendwann nötig sein 16:28 <TrevorReznik> www.hashcash.org hat welche, glaube ich. 16:28 <TrevorReznik> sie sind eine Initiative, um es für E-Mail-Clients als Anti-Spam-Ding zu etablieren. 16:28 <+Complication> vielleicht nicht Forschung im eigentlichen Sinne, sondern eher in Bezug auf Implementierung und Best Practices 16:28 <+Complication> =Sinn 16:28 <TrevorReznik> sie haben eine Sammlung von Implementierungen in einer Vielzahl von Sprachen. 16:28 <TrevorReznik> dort gibt es 2 Java-Klassen und mindestens ein Applet, allerdings kenne ich die genauen Lizenzparameter im Moment noch nicht. 16:30 <+Complication> Orte, die es nutzen könnten: 1) Nym-Registrierung in Syndie 2) Namensregistrierung in I2P 16:30 <+Complication> 3) E-Mail, offensichtlich 16:30 * TrevorReznik stimmt zu. 16:30 <+Complication> 4) in weniger optimistischen Szenarien, gewöhnliche Nachrichten in Syndie 16:31 <+Complication> auf der I2P-Netzwerkebene selbst... 16:31 <+Complication> hmm 16:31 <jrandom> es ist möglich, sie in Tunnel-Erstellungsnachrichten einzubetten, aber auf der CPU-Front sind wir so schon am Limit ;) 16:39 <jrandom> ok, hat noch jemand etwas für das Meeting? 16:41 <jrandom> wenn nicht 16:41 * jrandom leitet zum Abschluss über 16:41 * jrandom *baf*s schließt das Meeting