I2P Entwicklertreffen - 18. Oktober 2005

16:10 <jrandom> 0) hi 16:10 <jrandom> 1) 0.6.1.3 16:10 <jrandom> 2) Freenet, I2P und Darknets (oh je) 16:10 <jrandom> 3) Bootstrap-Angriffe auf tunnel 16:10 <jrandom> 4) I2Phex 16:10 <jrandom> 5) Syndie/Sucker 16:10 <jrandom> 6) ??? 16:10 <jrandom> 0) hi 16:10 * jrandom winkt 16:10 <jrandom> die wöchentlichen Statusnotizen sind online unter http://dev.i2p.net/pipermail/i2p/2005-October/001017.html 16:10 <dust> yay, funktioniert jetzt. danke Gregor 16:10 <cervantes> hallo 16:11 <+fox> <blx> heloa 16:11 <jrandom> ok, springen wir zu 1) 0.6.1.3 16:11 <jrandom> ihr habt alle ziemlich flott aktualisiert, danke! 16:12 <jrandom> sieht alles in vernünftigem Zustand aus, aber ich habe nicht viel hinzuzufügen über das hinaus, was in den Statusnotizen steht 16:12 <jrandom> hat jemand Fragen/Kommentare/Bedenken zu 0.6.1.3? 16:13 <jrandom> ok, wenn nicht, springen wir weiter zu 2) Freenet, I2P und Darknets (oh je) 16:13 <cervantes> 609 bekannte Peers! 16:14 <cervantes> (w00t) 16:14 <jrandom> ja, das Netzwerk ist gewachsen 16:14 <+fox> <blx> oh my! 16:14 * cervantes veranstaltet eine Wette, wie lange es bis zur großen 1000 dauert 16:14 <jrandom> heh 16:14 <tethra> heheh 16:15 <tethra> wetten wir mit digitalem Bargeld? ;) 16:15 <cervantes> aber es zeigt, wie solide der i2p-Kern in letzter Zeit geworden ist, dass die Nutzeraufnahme zulegt 16:16 <cervantes> nee... jrandom hat bereits unwissentlich sein ganzes Biergeld für dieses Jahr gespendet 16:16 <jrandom> hehe 16:16 <jrandom> ok, zu 2) bin ich nicht sicher, ob ich noch etwas hinzuzufügen habe (ich glaube, wir haben das Thema zu Tode geritten). hat jemand Fragen/Kommentare/Bedenken dazu? 16:18 <cervantes> wie du sagtest, wenn schon sonst nichts, hat es einige interessante halb-bezogene Sicherheitsdiskussionen angestoßen, siehe 3) 16:18 <jrandom> wenn nicht, können wir flott weiter zu 3) Bootstrap-Angriffe auf tunnel 16:18 <jrandom> ja, hat es 16:19 <jrandom> das Thema, das Michael angesprochen hat, quantifiziert eine allgemeine Sicht, die ich hatte, aber es ist schön, das explizit zu machen 16:20 <jrandom> heute Abend wird es noch eine weitere Diskussion über den neueren Angriff geben (sobald ich eine Antwort schreiben kann), aber der frühere scheint kein großes Problem zu sein 16:21 <jrandom> ergibt das für euch Sinn, oder gibt es Fragen oder Bedenken dazu? 16:22 <cervantes> heh... das heißt entweder, alle sind einverstanden, oder sie verstehen die Fragestellung überhaupt nicht 16:23 <cervantes> Ich ordne mich mal in die Kategorie „Unwissenheit ist ein Segen“ ein 16:23 <jrandom> heh, im Wesentlichen ist es ein Angriff, bei dem die Bösen zufällig der ausgehende Endpunkt jedes von dir jemals gebauten tunnel sind 16:23 <jrandom> wenn du gerade erst startest, ist „jeder tunnel, den du je gebaut hast“ eine sehr kleine Zahl (z. B. 0, 1, 2) 16:24 <jrandom> aber nach ein paar Sekunden wird die Zahl groß genug, um (c/n)^t in eine sehr, sehr kleine Zahl zu verwandeln 16:25 <tethra> (c/n)^t ist... 16:25 <jrandom> (das ist einer der Gründe, warum wir den i2cp-Listener – und damit i2ptunnel/etc – erst eine Weile nach dem Start hochfahren) 16:25 <jrandom> c == Anzahl der kolludierenden Peers (die Bösen), n == Anzahl der Peers im Netzwerk, t == Anzahl der von dir gebauten tunnels. 16:25 <cervantes> richtig... 16:25 <tethra> ah 16:26 <jrandom> je größer t wird, desto kleiner wird die Erfolgswahrscheinlichkeit des Angriffs 16:26 <cervantes> damit das überhaupt praktikabel ist, müsstest du deinen router innerhalb von ein paar Minuten nach dem Start für sensible Aufgaben verwenden? 16:26 <jrandom> (oder jedenfalls kleiner als die Wahrscheinlichkeit, alle Hops in einem tunnel zu übernehmen) 16:26 <tethra> ahh, ich sehe 16:27 <jrandom> cervantes: sofort, bevor der 3. tunnel gebaut ist 16:27 <jrandom> (angenommen, du verwendest 3 hop tunnels) 16:27 <cervantes> das ist ziemlich unwahrscheinlich 16:28 <cervantes> allein aus Nutzungssicht 16:28 <jrandom> exakt. 16:28 <jrandom> und da wir beim Start mehr als 3 tunnels bauen, bevor irgendwelche Clients laufen dürfen, ist es nicht nur eine Frage der Wahrscheinlichkeit 16:28 <jrandom> aber es ist gut, den Angriff trotzdem zu quantifizieren 16:29 <cervantes> lohnt es sich, den router etwas länger kurbeln zu lassen, um gegen jede Wahrscheinlichkeit abzusichern? 16:30 <cervantes> oder stärker kurbeln... 16:30 <jrandom> vielleicht. wenn wir sowohl die Verbindungsaufbauzeit als auch nicht-zufällige Peer-Auswahl ignorieren, hat es keine Wahrscheinlichkeit 16:31 <tethra> das ist dann wohl ein Grund für ein „woot!“, nehme ich an? 16:32 <jrandom> ja, obwohl wir aus Ingenieursperspektive diese Eigenschaften nicht ignorieren sollten ;) 16:32 <jrandom> also, für 0.6.2 sollten wir uns das im Zuge der überarbeiteten tunnel-Peer-Auswahl/-Reihenfolge ansehen, um sicherzustellen, dass es sich vernünftig verhält 16:34 <jrandom> ok, wenn es zu 3) nichts weiter gibt, weiter zu 4) I2Phex 16:34 <jrandom> sirup ist nicht hier, und ich habe striker nicht auf IRC gesehen – redzara, bist du da? 16:36 <+redzara> ja 16:36 <+redzara> Erster Durchgang ist fast fertig: Sirups Mod auf das neueste Phex-CVS portieren. 16:36 <jrandom> nice1! 16:36 <+redzara> als Nächstes: Zweiter Durchgang: Diff vom Sirup-Code zum Basis-Phex-Code der Initialversion, um sicherzugehen, dass ich nichts vergesse :) 16:37 <+redzara> vielleicht bis dieses WE abgeschlossen 16:37 <jrandom> wow, das wäre großartig 16:37 <+redzara> Dritter Durchgang: Refactoring der Kommunikationsschicht mit GregorK 16:37 <+fox> <GregorK> hoffe, dir ist klar, dass im neuesten Phex-CVS der Download-Code nicht stabil ist und die Download-Datei nicht mit früheren Releases kompatibel ist 16:38 <jrandom> Das ist i2p, wir sind Instabilität gewohnt :) 16:38 <+fox> <GregorK> :) 16:38 <+redzara> Für den letzten Durchgang, da ich derzeit keinen Kontakt mit GregorK habe, dürfte das ziemlich hart werden :( 16:38 <jrandom> GregorK: Was würdest du für die Integration empfehlen? 16:39 <+fox> <GregorK> nun hast du Kontakt mit mir ;) 16:39 <jrandom> ah ok, redzara, die ersten beiden sind ohnehin groß genug :) 16:39 <+redzara> GregorK : hi man 16:40 <+redzara> GregorK : Ich habe mir alle Codes sorgfältig durchgelesen 16:40 <+fox> <GregorK> ich habe eine Idee, wie man eine Schicht baut... ich kann versuchen, sie so gut wie möglich vorzubereiten, und dann sehen wir, wie gut es passt und was geändert werden muss 16:40 <+fox> <GregorK> alle?? wow... 16:40 <+redzara> Gregork : ja, alles!! 16:41 <cervantes> er kennt sogar deine Unterwäschegröße 16:41 <Rawn> :D 16:41 <+fox> <GregorK> großartig... nächstes Mal beim Einkaufen frage ich einfach dich... 16:43 <+fox> <GregorK> schön wäre, wenn vielleicht jemand vom I2Phex-Team auch im Phex-Team wäre.. 16:43 <jrandom> redzara: glaubst du, wir bekommen eine I2Phex-0.1.2-Release mit den Ergebnissen deines zweiten Durchgangs hin, bevor wir alles in eine Plugin-Schicht im Mainline-Phex mergen? oder wird das alles in einem Rutsch? 16:43 <+redzara> Sorry, aber ich verstehe / spreche / lese / schreibe Englisch nicht gut genug, um über das zu lachen, was du geschrieben hast 16:43 <+fox> <GregorK> das würde auch helfen, Bugs zu lösen, die auf beiden Seiten auftreten 16:44 <jrandom> GregorK: hoffentlich finden wir einen Weg, dass die I2P-Seite nur ein dünnes Plugin in Phex ist, oder? 16:44 <jrandom> oder sollten die beiden getrennt bleiben? 16:44 <+redzara> jrandom : Ich denke, wir könnten ein Phex 2.6.4 über I2P haben; für mich ist I2Phex down 16:45 <jrandom> down? 16:45 <+fox> <GregorK> ich bin nicht sicher, ob wir das gleich am Anfang so hinbekommen, aber ich denke, der Großteil ließe sich in ein Plugin auslagern. 16:45 <jrandom> cool, ja, es ist sicher eine Menge Arbeit 16:46 <jrandom> besonders bei Dingen wie java.net.URL (die schon bei der Instanziierung DNS-Anfragen leakt, etc.) 16:46 <+redzara> jrandom : down, beendet 16:46 <+Ragnarok> grr 16:47 <jrandom> ok, richtig, redzara, sobald wir alles in Phex 2.6.4 über I2P zum Laufen gebracht haben, stimme ich zu, dass es wohl kaum noch Bedarf für ein I2Phex gäbe 16:47 <+fox> <GregorK> stimmt... ich glaube, Phex verwendet an manchen Stellen die Apache-URI-Klasse als Workaround... aber nur wenn nötig 16:48 <jrandom> ah richtig, ich erinnere mich, mit der Bibliothek gespielt zu haben, sieht gut aus 16:49 <jrandom> wir werden vor dem Push für Endnutzer über i2p auf jeden Fall ein bisschen beim Audit für Anonymität/Sicherheit helfen 16:49 <jrandom> (nicht, um zu suggerieren, dass es Probleme in Phex gibt – es gibt Probleme in jeder App, und hoffentlich können wir helfen, sie zu sortieren) 16:50 <+fox> <GregorK> für manches wie Socket-Nutzung und solche Dinge habe ich eine Idee, wie man es sauber integriert... aber bei anderem wie verschiedenen Features, UDP und so... weiß ich noch nicht, wie wir das am besten lösen 16:50 <+fox> <GregorK> oh, ich bin sicher, es gibt viele Probleme in Phex. :) 16:50 <jrandom> ah, ja, Sockets werden einfach, aber anderes müssen wir vielleicht deaktivieren. wofür wird UDP genutzt – schnelle Queries? 16:51 <+fox> <GregorK> derzeit nur Bootstrapping 16:51 <+fox> <GregorK> UDP Host Cache.. ein Ersatz für GWebCache 16:52 <jrandom> ahhh, ok. 16:52 <+redzara> Also brauchen wir es nicht, wenn wir einen ordentlichen GWebCache haben? 16:53 <+fox> <GregorK> ja... aber der Standard-GWebCache hat auch seine Sicherheitsprobleme... 16:53 <+redzara> GregorK : nicht innerhalb von I2P, denke ich 16:54 <jrandom> oh, das ließe sich überwinden – I2PSocket ist authentifiziert – du kennst die 'destination' (I2P‑Zieladresse) des Peers am anderen Ende, sie könnten also nicht sagen „Ich bin, äh... whitehouse.gov.. ja!“ 16:54 <jrandom> aber du hast recht, das muss überprüft werden 16:54 <+fox> <GregorK> auch Firewall-zu-Firewall-Transfers wären ein UDP-Thema, das wir gern implementieren wollen, sobald wir einen Freiwilligen finden :) 16:54 <jrandom> ah, nun, I2P braucht keine Firewall-zu-Firewall-Transfers – I2P stellt einen vollständig offenen End‑zu‑End‑Adressraum bereit :) 16:55 <jrandom> aber... ooh, das könnte nützlich sein 16:55 <jrandom> wenn Phex-Nutzer „0 hop tunnels“ hätten, bekämen sie kostenloses NAT-Traversal/Firewall-zu-Firewall-Transfers mit ziemlich ordentlicher Geschwindigkeit 16:55 <+fox> <GregorK> ein weiteres wären LAN-Broadcasts von Anfragen und so... für einfacheres Teilen von Inhalten in privaten Netzen 16:56 <jrandom> (0 hop tunnels bieten eine gewisse plausible Abstreitbarkeit, ohne dass zwischengeschaltete Peers den Traffic tragen müssen) 16:57 <jrandom> hmm, LAN-Broadcast ist gut, aber ich bin nicht sicher, ob i2p das wirklich braucht (da es ein Anonymitätsrisiko ist, zu wissen, wo der andere Peer ist :), also könnte dieses Feature beim Einsatz des I2P-Plugins vielleicht deaktiviert werden? 16:58 <cervantes> *standardmäßig deaktiviert 16:58 <+fox> <GregorK> nun, es ist noch nicht verfügbar.. aber in diesem Fall kennen sich die Nutzer ohnehin, um dieses private Netzwerk aufzubauen.. 16:58 <jrandom> oh richtig, cervantes 16:58 <jrandom> genau, GregorK 16:59 <+fox> <GregorK> gibt es irgendwelche Änderungen an der Benutzeroberfläche?? 17:00 <+bar> nun, wir brauchen keine Flaggen :) 17:00 <jrandom> zumindest wäre es nützlich, ein paar Konfigurationsoptionen in Bezug auf I2P zu haben. 17:01 <jrandom> ich glaube, sirup konnte in Teilen der Anzeige I2P-‚destinations‘ statt IP+Port-Nummern verwenden, daher war das glaube ich ok 17:01 <+redzara> Und was ist mit bitzyNot im Moment, aber Flaggen und Länder werden nicht benutzt 17:01 <jrandom> bitzy? 17:01 <+redzara> sorry, falsches Copy/Paste :( 17:02 <+fox> <GregorK> kannst du eine Liste der Konfigurationsoptionen und optionalen Features bereitstellen, die ihr braucht? 17:03 <jrandom> Ich bin sicher, das bekommen wir hin. ein Host+Port, auf dem I2P läuft, und ein paar Dropdowns zu Performance/Anonymitäts‑Tweaks sollten genügen 17:03 <jrandom> Details liefern wir dir 17:02 <cervantes> [x] Super-Transfergeschwindigkeitsmodus 17:02 <+fox> <GregorK> nun, Bitzi wird zur Identifizierung von Dateien verwendet.. ist das ein Anonymitätsproblem? 17:03 <vulpine> <redzara> GregorK : Ich bereite es vor, aber grundsätzlich gibt es keine Änderungen 17:03 <+fox> <GregorK> :) frag deinen Provider, cervantes... 17:03 <redzara> GregorK : vielleicht, ich arbeite daran 17:04 <cervantes> GregorK: heh, UK-Resident....keine Chance ;-) 17:04 <+fox> <GregorK> wenn du Dateien zwischen zwei Phex-Instanzen auf demselben PC überträgst.. sind die Transfers blitzschnell ;) 17:05 <cervantes> cool... ich habe viele coole Filme, die ich mit mir selbst teilen kann :) 17:05 <cervantes> * das bitte aus dem Protokoll streichen * 17:06 <bar> jrandom hat das Thema schon angeschnitten, aber hier ist die verrückte Idee nochmal: 17:06 <+bar> wie wär's, i2p in Phex zu integrieren, so dass normale Nutzer 0-hop tunnels haben? 17:07 <+fox> <GregorK> ich denke, Anzeige von Flaggen und IP+Port kommt vom HostAddress-Objekt.. das würde in der neuen Schicht verborgen... sodass ihr etwas anderes anzeigen könnt 17:07 <+bar> (für plausible Abstreitbarkeit und UDP-Firewall-Hole-Punching) 17:08 <+fox> <GregorK> bin nicht sicher, ob ich wirklich verstehe, was das bedeutet ;) 17:08 <+bar> wahrscheinlich ich auch nicht ;) 17:09 <jrandom> GregorK: im Wesentlichen heißt das, dass Phex-Nutzer direkt miteinander sprechen würden, aber plausible Abstreitbarkeit hätten, da sie auch indirekt sprechen könnten 17:09 <+bar> jrandom, du verstehst sicher, worauf ich hinaus will – könntest du das ausführen? 17:09 <jrandom> sie bekämen außerdem I2Ps NAT-Traversal gratis dazu, sowie Datensicherheit und Schutz vor Sniffing durch ISPs/etc 17:09 <+redzara> GregorK : also musst du allen Code entfernen, der sich auf host+port + IsLocalIP + Is PrivateIP + ... bezieht 17:10 <jrandom> auf der anderen Seite (einer GROSSEN anderen Seite) könnte es nicht mit Gnutella-Clients sprechen, die nicht auf I2P laufen 17:10 <jrandom> (auch wenn es am Ende alle tun werden ;) 17:10 <+fox> <GregorK> Ich denke, der erste Schritt ist – und der ist schon groß genug –, i2p und Phex näher zusammenzubringen. 17:10 <jrandom> einverstanden 17:10 <+bar> (verdammt, daran habe ich nicht gedacht) 17:11 <+bar> ja, definitiv. 17:11 <jrandom> das ist fliegendes-Pony-Zeug. lass uns erst die praktischen Dinge machen 17:11 <+fox> <GregorK> und wenn wir sehen, wie gut das funktioniert hat, können wir entscheiden, wie wir weitergehen.. 17:11 <jrandom> genau 17:12 <+fox> <GregorK> redzara: Ich hätte gern zwei Implementierungen von HostAddress: eine für i2p und eine wie die aktuelle. 17:14 <+redzara> Gregork : kein Problem, ich habe in meinem Mod den ganzen Code kommentiert, ihr könnt leicht zwei Implementierungen bauen. Lasst mich nur bitte die Anfangsarbeit fertigstellen 17:14 <+fox> <GregorK> klar.. kein Problem.. 17:14 <jrandom> :) ok, also redzara, denkst du, wir können nächste Woche irgendwann einen Alpha-Test der neuen auf Phex‑2.4.2 basierenden Version machen? 17:15 <jrandom> (für den Phase‑2‑Teil. Phase 3 wird mehr Arbeit kosten, um sie in den Mainline zu integrieren) 17:15 <+redzara> jrandom : nächste scheint ok für mich 17:16 <jrandom> ok, super 17:16 <+redzara> s/next/next week/ 17:16 <jrandom> ok, das ist ziemlich aufregend, es wird wunderbar, wenn es reibungslos läuft 17:17 <jrandom> hat noch jemand etwas zu 4) I2Phex, oder sollen wir kurz zu 5) Syndie/Sucker weiter? 17:17 <cervantes> I2P wird von solchen Killer-Apps sicher profitieren 17:18 <+fox> <GregorK> btw es gibt eine Phex-CVS-Mailingliste für alle CVS-Änderungen in Phex... falls das hilft 17:18 <jnymo> *ehem*.. aber hallo 17:18 <jrandom> ok super, danke GregorK 17:18 <jrandom> definitiv, cervantes 17:19 <jrandom> ok, zu 5) habe ich eigentlich nichts hinzuzufügen außer dem, was da steht 17:19 <jrandom> dust: bist du da? 17:19 <+redzara> GregorK : Danke, aber eine Version zu handhaben ist für mich genug :) 17:19 <jrandom> hehe, redzara 17:19 <dust> Ich hatte in letzter Zeit nicht viel Freizeit, aber wenn doch, denke ich, dass ich versuche, dieses addresses.jsp-Ding in den Griff zu bekommen, 'RSS' in das Protokoll-Dropdown dort hinzuzufügen und dann einen Pfad durch Updater, Sucker zum BlogManager zu bauen. 17:20 <dust> außer jemand hat eine bessere Idee 17:20 <jrandom> hammer 17:20 <jrandom> das klingt perfekt. 17:21 <jrandom> obwohl, hmm, vielleicht bräuchte es ein zusätzliches Feld (das „in welchen Blog posten“ und „welches Tag-Präfix“)... 17:21 <jrandom> vielleicht würde ein separates Formular/Tabelle Sinn machen, vielleicht aber auch nicht 17:22 <dust> oh, ich dachte, addresses.jsp wäre nur für einen Blog (da man sich einloggen muss, um hinzukommen?) 17:22 <jrandom> ah, stimmt, guter Punkt 17:23 <jrandom> der Updater-Teil ist etwas schwammig, aber du hast recht 17:23 <dust> (wir klären das, wenn wir so weit sind) 17:23 <jrandom> ja 17:24 * jnymo meint, www.i2p.net könnte so etwas wie ein „Merchandise-Café“ starten 17:24 <jnymo> mit eyetoopie-Shirts mit der Aufschrift „Ich bin Jrandom“ ;) 17:24 * mrflibble hängt noch in der „Flamewar“ hinterher, die sich wohl zu einer echten Flamewar auswächst :) 17:24 <jrandom> heh, jnymo 17:25 <jrandom> ja, da ist eine Menge Inhalt in dem Thread 17:25 <jrandom> ok, vielleicht bringt uns das zu 6) ??? 17:25 <jrandom> hat noch jemand etwas fürs Meeting? 17:25 <+bar> ja, nur eine kurze Anmerkung zum Symmetric‑NAT-Thema (habe ein bisschen geschnüffelt): 17:25 <+nickless_head> jrandom: Ich kenne die Wahrheit! 17:25 <+fox> <blx> kaffe? 17:25 <mrflibble> ups, sorry jr 17:26 <jnymo> aber im Ernst.. jedes Open-Source-Projekt mit einer gewissen Größe hat seinen eigenen Merchandise-Bereich 17:26 <+nickless_head> jrandom: Ich habe eindeutige Beweise, dass du die last.fm-Homepage gehackt hast! 17:26 <+nickless_head> (im Abschnitt „was du bekommst, wenn du dich anmeldest“ stand „a pony“) 17:26 <jrandom> jnymo: ich denke, du hast recht, das sollten wir prüfen, könnte auch eine gute Methode zum Fundraising sein 17:27 <jnymo> jrandom: genau 17:27 * mrflibble würde das T‑Shirt kaufen 17:27 <+bar> richtig, zu Symmetric NAT, 17:27 <+bar> soweit es das wert ist, denke ich, dass es im Gegensatz zu den bereits unterstützten NATs keinen Zaubertrick gibt. Der einzig saubere Weg ist, das Verhalten jedes einzelnen Symmetric NAT zu studieren/untersuchen und für das Probing Introducer zu verwenden. 17:28 <jrandom> blx: das neueste Kaffe-CVS ist völlig kaputt. die Crypto-Packages sind nicht im Source, der PRNG lässt sich nicht initialisieren, und die URL-Handler können nicht mit file:// umgehen :( 17:28 <jnymo> Man würde es vermutlich nicht in der Öffentlichkeit tragen wollen, bis i2p ein paar Tausend Nutzer hat ;) 17:28 <+bar> (ich glaube, so machen z. B. Hamachi und Skype UDP-Hole-Punching hinter Symmetric NATs) 17:28 <+nickless_head> jnymo: Tassen wären der Hammer :) 17:28 <+bar> basierend auf dem, was ich bisher im Netz gelesen habe, taugen Vorhersage-Algorithmen für Symmetric NAT ziemlich wenig. 17:28 <jrandom> hmm, bar 17:28 <mrflibble> hehe, ich würde meinen Nick nicht draufschreiben. oh, und ich lebe noch/unger verhaftet, obwohl ich ein IIP T‑Shirt habe 17:28 <jrandom> ja, das habe ich auch gelesen 17:29 <+bar> ich versuche, noch mehr gutes, relevantes Lesematerial dazu zu sammeln. 17:29 <+redzara> Kleine Frage: Wie hoch war der durchschnittliche Prozentsatz erneut übertragener Bytes in 0.6.1.3? 17:29 <jrandom> danke, bar 17:29 <+fox> <jme___> bar, sind die Vorhersagen, die sie erhalten, konsistent? 17:29 <+fox> <jme___> bar, lass es mich umformulieren :) 17:29 <+fox> <blx> jrandom, das macht mich traurig 17:30 <jrandom> redzara: leider habe ich das nicht ins netDb gepackt. Ich sehe aber gerade 2.6 und 3.8 17:30 <jrandom> blx: ich auch :( 17:30 <+fox> <jme___> bar, wenn du das NAT-Box-Verhalten analysierst und eine Formel findest, um es vorherzusagen – funktioniert das dann immer für diese NAT-Box? oder klappt es mal und mal nicht? 17:30 <jrandom> blx: ich weiß, sie machen gerade ein Merge mit Classpath, also hoffentlich, sobald das durch ist 17:30 <+fox> <blx> heißt wohl, ich werde nicht zur Party stoßen 17:30 <jrandom> blx: bist du kaffe-spezifisch oder OSS/DFSG-spezifisch? 17:31 <+fox> <blx> freie Software 17:31 <+fox> <blx> DFSG, könnte man sagen 17:31 <jnymo> falls ein i2p-Nutzer einen gehosteten Server für i2p verwenden möchte, welcher liberale, günstige Hoster wäre geeignet? 17:31 <+bar> jme___: Hamachi kann Berichten zufolge 97% aller Verbindungsversuche vermitteln. Ich schätze, es gibt NATs, die bei der Portvergabe ein fast zufälliges Verhalten zeigen 17:32 <jrandom> ok, wir kriegen da sicher was hin, blx. Kaffe hat früher funktioniert, und wir sind nicht von irgendetwas Sun-Spezifischem abhängig 17:32 <jrandom> jnymo: ich nutze sagonet.net, aber die haben ihre Preise von 65/Monat auf 99/Monat angezogen (aber auf einer schnellen Leitung mit 1250GB/Monat) 17:32 <jrandom> ich weiß, in Deutschland gibt’s auch ein paar günstige 17:33 <+fox> <jme___> bar, 97% wäre großartig 17:33 <jrandom> redzara: was siehst du bei der Retransmissionsrate? 17:33 <+bar> jme___: ja, also denke ich, die meisten Symmetric NATs sind vorhersagbar 17:33 <+fox> <blx> jrandom, ich bin wirklich an dem Kram interessiert :) 17:33 <+fox> <jme___> bar, was würdest du tun? Relay, UDP-Hole-Punching, Verbindungsumkehr.. gibt es andere Techniken? 17:33 <jnymo> sind 99 im Durchschnitt teuer? 17:34 <+redzara> jrandom zwischen 3;8 und 4.2 17:34 <jrandom> jme___: wir sind UDP, keine Notwendigkeit für Verbindungsumkehr :) 17:35 <+bar> jme___: ich bin kein Experte, vielleicht habe ich nächste Woche fürs Meeting mehr Infos (aber es riecht stark nach Profiling + UDP-Hole-Punching ;) 17:35 <jrandom> jnymo: für 1250GB nicht wirklich. ich habe 60–120 USD/Monat für 50–100GB/Monat gesehen 17:35 <jrandom> bar: vielleicht wäre UPnP der bessere Weg? 17:35 <+fox> <jme___> jrandom, auch mit UDP ist es nützlich :) 17:35 <+redzara> jrandom : aber nur einige Knoten hatten großen Einfluss, vielleicht einige ältere 17:35 <+fox> <jme___> vulpine: ok 17:35 <jrandom> obwohl das nur denen hilft, die ihr NAT kontrollieren können 17:36 <+fox> <jme___> UPnP muss unterstützt werden, aber es schließt andere Mittel nicht aus 17:36 <jrandom> nun, alles, was wir jetzt tun, machen wir ohne jegliches UPnP 17:36 <+fox> <jme___> weil UPnP nicht von allen NATs unterstützt wird, weit gefehlt 17:36 <jrandom> genau, z. B. ein NAT beim ISP 17:36 <+bar> jrandom: wenn es keine Sicherheitsprobleme mit UPnP gibt, kann es wohl nicht schaden. Hamachi verwendet allerdings kein UPnP 17:36 <+fox> <jme___> hier bedeutet „muss“: um maximale Konnektivität zu bieten 17:37 <+fox> <jme___> ok, zurück zu meinem C++ :) 17:38 <jrandom> richtig, jme___, aber wenn wir Symmetric-Hole-Punching zusätzlich zu Cone/Restricted-Hole-Punching schaffen, sind wir sehr gut aufgestellt 17:38 <jrandom> bis später, jme___ 17:38 <jrandom> ja, ideal wäre, wenn wir es nicht bräuchten 17:39 <jrandom> ok, hat noch jemand etwas fürs Meeting? 17:41 <jrandom> wenn nicht... 17:41 * jrandom bereitet sich vor 17:41 * jrandom *baf*t das Meeting zu Ende