I2P Entwicklertreffen - 22. Februar 2005

13:04 <jrandom> 0) hi 13:04 <jrandom> 1) 0.5 13:04 <jrandom> 2) Nächste Schritte 13:04 <jrandom> 3) azneti2p 13:04 <jrandom> 4) ??? 13:04 <jrandom> 0) hi 13:04 * jrandom winkt 13:05 <jrandom> wöchentliche Statusnotizen sind online @ http://dev.i2p.net/pipermail/i2p/2005-February/000595.html 13:05 <jrandom> (ja, nur eine Minute oder zwei vor dem Meeting, also testen wir mal dein Schnelllesen) 13:05 <+detonate> ich denke, ich warte, bis es etwas weniger buggy ist, bevor ich in dem Fall Boondock Saints hochlade 13:06 <jrandom> warum... das ist... das ist... das ist eine Urheberrechtsverletzung! 13:06 <+detonate> seltsame neue Ergänzungen zur Azureus-Beta 13:06 <+detonate> Kategorien 13:06 <+detonate> haha 13:06 <+detonate> ein DHT-Tracker 13:06 <+detonate> sweet 13:07 <jrandom> aye, es sieht sehr cool aus, aber lassen wir uns erst um 1 und 2 kümmern, bevor wir zu 3 gehen, 'eh? ;) 13:07 <+detonate> hi 13:07 <+detonate> in der Tat 13:07 <jrandom> springen wir zu 1) 0.5 13:07 <jrandom> ist sozusagen draußen und so 13:08 <cervantes> yay! 13:08 <jrandom> später am Abend gibt es eine neue Revision mit einer Menge Updates (aktueller CVS-Head ist 0.5-5, mit einer -6 in Tests auf einigen routers) 13:09 <jrandom> lief ziemlich gut, aber wir sind unterwegs über ein paar komische Bugs gestolpert. aber c'est la vie 13:09 <frosk> ich kann berichten, dass 0.5-5 sich a _lot_ freundlicher verhält als -4 (was mir oft teilnehmende tunnels in der Größenordnung von Tausenden beschert hat) 13:09 <bla> jrandom: Wird die Version 0.5.0.1 das Problem beheben, dass man 'nor' keine Ziele finden kann? 13:09 <jrandom> ah, nun, das ist wirklich eher eine Funktion der anderen Leute, der -0 Build baut tatsächlich Hunderte von tunnels 13:09 <bla> s/nor/not 13:10 <jrandom> bla: ja, das ist ein Bug in der netDb 13:10 <bla> jrandom: Großartig! 13:10 <jrandom> (genauer gesagt im leaseSet-Publishing) 13:11 <jrandom> und ja, die 0.5.0.1-Revision wird diesen gelegentlichen Bug mit dem verschwindenden Proxy beseitigen 13:12 <jrandom> es gibt noch ein seltsames Memory Leak, das ich noch nicht aufgespürt habe und das einige Nutzer betrifft 13:12 <bla> Dann scheint es insgesamt, abgesehen von diesen Bugs, dass das 0.5-Netz sehr gut läuft. Yay! 13:12 <jrandom> soweit ich weiß, betrifft es wirklich nur zwei oder drei I2PTunnel-Instanzen 13:12 <Meomia> ist es ein Zeichen von Fortschritt, wenn du seit 0.5 von 0 auf 130 teilnehmende tunnels gestiegen bist? 13:13 <jrandom> w3wt 13:13 <jrandom> Meomia: bah, ich hatte über 5000 tunnels ;) 13:13 <jrandom> aber dm hat tatsächlich geholfen, einen Bug im Exploratory-Pool-Code zu finden, daher werden wir häufiger tunnels auf 'zufälligen' Peers bauen 13:14 <jrandom> (yay) 13:14 <Meomia> ok 13:14 <bla> jrandom: Bedeutet das auch, dass jetzt, im Gegensatz zu 0.4, jeder Peer irgendwann dein inbound gateway (eingehendes Gateway) werden kann? 13:14 <jrandom> ja, für exploratory tunnels 13:15 <jrandom> client tunnels werden nur Peers in der 'fast'-Stufe verwenden 13:15 <bla> bla: Ok. Die Tatsache, dass client tunnels nur die schnellen Peers verwenden, ist gut: sonst bekommen wir das Anonymitätsproblem, das wir vorher diskutiert haben 13:16 <jrandom> und die Performance wäre sonst mies ;) 13:17 <jrandom> eigentlich bringt uns das zu 2) Nächste Schritte 13:18 <jrandom> das große, was für die 0.5-Serie noch bleibt, ist ein Haufen Strategien zum Sortieren und/oder Filtern der in tunnels verwendeten Peers 13:18 <godmode0> jrandom kann man NNTP mit i2p benutzen? 13:18 <jrandom> godmode0: es gibt zwei NNTP-Server auf i2p, ja. schau ins Forum 13:19 <godmode0> jrandom ok ich teste 13:19 <godmode0> kann ich meinen Server auch aufsetzen? 13:20 <jrandom> godmode0: wir sind gerade in einem Meeting, aber ja, du kannst einen Server betreiben 13:20 <godmode0> jrandom ok sorry 13:20 <jrandom> kein Problem 13:20 <jrandom> die vorgeschlagenen Strategien zielen im Wesentlichen darauf ab, die Anonymität zu verbessern, aber es gibt noch ein paar andere Ziele, die wir damit ausbalancieren können 13:21 <jrandom> vielleicht finden wir einen Weg, einige der AS-Pfade in die Auswahl zu integrieren, wie bla vorgeschlagen hat 13:22 <jrandom> das kann sowohl die (jurisdiktionelle) Anonymität verbessern, oder wenn wir versuchen, innerhalb eines AS (oder zweier) zu bleiben, kann das die Performance verbessern 13:22 <bla> jrandom: Das steht im Grunde im Zusammenhang mit einem Paper der Tor-Entwickler: http://theland.i2p/files/routing-zones.pdf 13:22 <jrandom> aye 13:23 <jrandom> es gibt eine ganze Reihe verschiedener Strategien, die Leute verwenden können, und neue auszuprobieren sollte ziemlich einfach sein 13:24 <jrandom> wir werden nicht Monate damit verbringen, alles zu implementieren, was uns einfällt, sondern lediglich die Grundlagen bereitstellen, die die meisten brauchen. Jeder, der neue hinzufügen möchte, ist sehr ermutigt, beim Einbauen zu helfen 13:25 <jrandom> wie auch immer, sobald die Grundlagen stehen, gehen wir weiter und konzentrieren uns auf den UDP-Transport für 0.6 13:26 <jrandom> das ist so ziemlich alles zu 2) Nächste Schritte, hat jemand Kommentare/Fragen/Bedenken? 13:26 <bla> Wer waren nochmal die Leute, die angefangen haben, sich I2P anzusehen? 13:26 <bla> Scheint, wir haben in letzter Zeit nicht viel von ihnen gehört. 13:27 <bla> s/into I2P/into UDP/ 13:27 <bla> sorry 13:27 <jrandom> ah, mule war krank, aber ich denke, detonate macht Fortschritte 13:28 <jrandom> detonate: irgendwelche Neuigkeiten? 13:29 <jrandom> oder vielleicht auch nicht ;) 13:30 <jrandom> ok, weiter zu 3) azneti2p 13:30 <+detonate> sorry 13:30 <+detonate> ich mache Fortschritte 13:30 <+detonate> ich muss noch die Reassembly-Seite fertigstellen 13:31 <+detonate> was das Aufteilen der Daten in Pakete und das geordnete Verschicken angeht, das funktioniert 13:31 <+detonate> weiter zu 3) 13:31 <jrandom> geil 13:31 <godmode0> sorry, Schritt 2) hat i2p irgendwelche Probleme mit Angriffen? 13:31 <bla> detonate: Cool! Kannst du uns alle im Forum auf dem Laufenden halten? 13:32 <+detonate> bla: klar 13:32 <tracker> Zu azneti2p, schau hier: http://sourceforge.net/forum/forum.php?thread_id=1233727&forum_id=377614 sieht so aus, als ob Download funktioniert, Seeding nicht. 13:32 <jrandom> godmode0: die unterschiedlichen Sortierstrategien sollten dem Nutzer erlauben, den Einfluss von Predecessor-Angriffen zu wählen 13:33 <microsoft> wer auch immer i2p.net betreibt, sollte mehr Enterprise-Class-Solutions-Buzzwords auf die Seite packen. 13:33 <+detonate> jemand sollte auch sicherstellen, dass der neue DHT-Tracker sich in Bezug auf das Azureus-Plugin nicht danebenbenimmt 13:33 <tracker> Meine lokalen Tests scheinen das zu bestätigen, ich kann mit Azureus herunterladen, aber nicht seeden. 13:34 <jrandom> hmm ok cool, danke tracker – ich weiß, sie haben ein paar Dinge aktualisiert und letzte Nacht b34 rausgeschoben, aber es scheint, als gäbe es noch mehr zu tun 13:34 <jrandom> detonate: guter Punkt 13:35 <tracker> Guter Punkt, detonate, ich habe DHT deaktiviert, da Azureus nach ein paar Stunden mit 100% CPU-Auslastung stirbt, wenn es aktiv ist. 13:35 * jrandom möchte noch einmal betonen, dass das azneti2p-Plugin noch recht frühe Beta ist und die Anonymitätsimplikationen von Azureus noch nicht vollständig geprüft wurden 13:36 <jrandom> während sie es sicher lieben, dass Leute es testen, sollten diejenigen, die Anonymität brauchen, vorsichtig sein 13:36 <tracker> Auf der anderen Seite funktioniert i2p-bt wirklich gut. Außer dass es die tunnels nicht schließt, aber das ist IMHO nicht so schlimm. 13:37 <jrandom> oh, das passiert bei dir immer noch, tracker? Ich konnte das nicht reproduzieren 13:37 <jrandom> du bist auf der 0.1.7-Revision, richtig? 13:37 <tracker> Ja, bin ich. 13:38 <jrandom> ok, cool, wenn das bei dir ständig passiert, würde ich mich nach dem Meeting gern mit dir zusammensetzen, um die Ursache aufzuspüren 13:39 <tracker> Vielleicht hängt es damit zusammen, dass es auf XP statt Linux oder Unix läuft. Das Schließen des tunnels funktioniert mit Azureus, daher vermute ich, es ist I2P-BT-bezogen. 13:39 <jrandom> hmm stimmt, i2p-bt verwendet SAM, während Azureus das i2p-SDK direkt verwendet 13:40 <tracker> BTW. Ich habe dir einen Bugreport im Forum geschickt. Der timestamper stirbt bei den neuesten CVS-Builds von I2P. 13:40 <jrandom> ah cool, danke, habe meine PMs dort heute nicht gecheckt 13:41 <jrandom> auf -5 oder -4? oder früher? 13:42 <jrandom> ah, -4. ok, cool 13:42 <jrandom> danke, das werde ich für 0.5.0.1 beheben 13:42 <jrandom> ok, hat jemand noch etwas zu 3) azneti2p? 13:43 <tracker> Es passiert auch auf -5 13:43 <jrandom> du hast einen SNTP-Server explizit definiert, richtig? 13:44 <tracker> Ja. Die zwei aus unserem Land. 13:44 <jrandom> ich habe gerade den Source geprüft und die Exception tritt auf, wenn die Anzahl gleichzeitiger Server (Default = 3) größer ist als die Anzahl der angegebenen Server (neuer Default ist 3) 13:44 <jrandom> ok, cool, das ist ein trivialer Fix: % # servers 13:45 <jrandom> ok, wenn es nichts Weiteres zu azneti2p gibt, weiter zu guten alten 4) ??? 13:46 <jrandom> hat noch jemand etwas für das Meeting? 13:46 <tracker> Nice. Ich habe dir gerade die Log-Fehler vom router beim Schließen von i2p-bt im Forum geschickt. 13:47 <jrandom> 'k cool, danke 13:47 <cervantes> nichts zu erwähnen außer: gute Arbeit beim 0.5-Rollout, sieht so aus, als würde es abgehen, sobald die Bugs ausgebügelt sind 13:48 <tracker> Ja, die neuesten CVS-Builds laufen hier wirklich gut. 13:48 <jrandom> danke, mit eurer Hilfe und der der übrigen 0.5-pre-Tester konnten wir eine Menge Probleme aufräumen 13:49 <jrandom> die Performance war besser als ich erwartet hatte, aber der Durchsatz ist noch nicht so hoch wie zuvor. Es bleibt jedoch noch viel zu optimieren 13:49 <cervantes> seltsamerweise waren die Pre-Versionen stabiler...für mich, aber ich habe sie auch auf einer anderen Maschine laufen gehabt ;-) 13:49 <jrandom> (und diese verdammten Bugs, um die Zuverlässigkeit dahin zu bringen, wo sie sein sollte) 13:50 <jrandom> heh nun ja, aber das -pre-Netzwerk bestand aus 5–7 routers, alle extrem zuverlässig auf wirklich, wirklich schnellen Verbindungen 13:50 <cervantes> :) 13:51 <cervantes> meld mich dann für den 0.6 Pre-Test an :) 13:51 <jrandom> heh 13:51 <tracker> Vielleicht sollte ich dann am nächsten Pre-Netz teilnehmen. Ich stelle eine sehr unzuverlässige und langsame Verbindung bereit ;). 13:51 <jrandom> die 0.6-Migration wird hoffentlich noch einfacher, da wir einfach neue router-Adressen zur routerInfo hinzufügen können (UDP-Adressen) 13:51 <jrandom> heh genau 13:51 <cervantes> ich kann meine 1TB-Freigabe online stellen... 13:52 <jrandom> wir werden definitiv viel Hilfe beim 0.6-Testing brauchen und eine ganze Vielfalt von Netzwerk-Setups einbeziehen 13:52 <hobbs> ssh '~C' command ist pfiffig 13:52 <laberhorst> wird das ein weiterer inkompatibler Schritt? 13:53 <Myo9> Weiß jemand, welche NNTP-Server up sind? 13:53 <jrandom> laberhorst: nein, 0.6 wird rückwärtskompatibel sein 13:53 <jrandom> Myo9: keine Ahnung, sie könnten up sein und nur von den 0.5-0-Bugs gebissen worden sein 13:54 <jrandom> die 0.5.0.1-Revision sollte viele Probleme beheben, und sobald sie draußen ist, wird ein Upgrade sehr empfohlen 13:54 <laberhorst> also einfach ein Test-0.6 bauen und den Testern geben 13:54 <cervantes> wir können BT-Traffic nur veraltete routers benutzen lassen...das wird die Leute zum Upgrade bewegen ;-) 13:54 <laberhorst> also große Upgrade-Party morgen 13:54 <jrandom> es wird eine Ankündigung im Forum und auf der Liste geben, wenn es fertig ist 13:54 <jrandom> genau, laberhorst 13:54 <jrandom> heh cervantes ;) 13:55 <laberhorst> *ganz heiß aufs Testen für euch* 13:55 <jrandom> die BT-Performance war auf 0.5 ziemlich gut, ich habe viele erfolgreiche große Dateiübertragungen auf den Trackern gesehen 13:55 <laberhorst> Upload-Rate: 8,85 kB/s 13:55 <jrandom> (und IRC ist nicht so betroffen wie vorher, abgesehen von den Problemen, die wir mit ducks tunnel hatten) 13:55 <tracker> Kommt darauf an, was du 'groß' nennst ;) 13:56 <jrandom> tracker: ich denke an eine bestimmte 874MB-Datei, die eine Menge erfolgreicher Downloads hat ;) 13:56 <jrandom> aber stimmt, für manche ist das klein 13:56 <laberhorst> einfach guter alter Porn 13:56 <laberhorst> nehme ich an ;-) 13:57 <laberhorst> hoffen wir, dass ab morgen mein router nicht mehr in>3000 tunnels teilnimmt 13:57 <tracker> Ok, das ist groß. 13:57 <laberhorst> oder, wenn doch, ist das Netz GROSS 13:57 <jrandom> heh laberhorst 13:58 <jrandom> ok, hat noch jemand etwas fürs Meeting? 13:58 <laberhorst> btw, ist 'in >3000 teilnehmen' ein Synonym für einen guten, zuverlässigen router in i2p mit schneller Verbindung? 13:58 <+detonate> ich stelle Boondock Saints hoch, nachdem ich heute Abend House geholt habe :) 13:59 <+detonate> das werden ordentliche 4,1 GB :) 13:59 * laberhorst möchte den Entwicklern einfach für das schnelle Bug-Squashing danken 13:59 <+detonate> scheint viel Nachfrage zu geben 13:59 <laberhorst> oh, hier sind auch ein paar DVD-Images 13:59 <hobbs> detonate: ooh, stimmt. House. :) 13:59 <tracker> cervantes, hast du schon auf phpBB 2.0.12 upgegradet 13:59 <laberhorst> aber wartet, bis 0.5.0.1 draußen ist 13:59 <+detonate> sollte 0.5.0.1 auch einen guten Härtetest geben 14:00 <+detonate> ja 14:00 <+detonate> hab ich vor 14:00 <jrandom> nur Personen, die bereits legale Kopien dieser Dateien besitzen, sollten sie natürlich herunterladen. das ist nur zum Testen 14:00 <jrandom> *hust* 14:00 <tracker> rofl 14:01 * jrandom notiert mpaa.i2p 14:01 <+detonate> heh 14:01 <laberhorst> oh, ich kann ISO-Images von Debian, Fedora, SuSE, Bildern, die ich gemacht habe,... bauen 14:01 <laberhorst> also eine Menge legales Material 14:01 <laberhorst> wenn ihr nur testen wollt, ist /dev/random SEHR groß 14:01 <Ragnarok> nicht immer 14:02 <laberhorst> btw, für einsame Wochenenden: cat /dev/random | grep linux :-) 14:02 <jrandom> heh 14:02 <frosk> /dev/random läuft dauernd leer, ich bevorzuge /dev/urandom :) 14:02 <frosk> oder das neue, verbesserte /dev/jrandom 14:02 <jrandom> nee, das dumped ständig Core 14:03 <jrandom> und braucht seinen nächtlichen Schlaf 14:03 <Ragnarok> was ist der beste Weg, Entropie für /dev/random zu erzeugen? 14:03 <laberhorst> wir sollten wirklich den „get jrandom a few beers“-Fonds aufbauen 14:03 <frosk> nenn es Ruhe oder Entropie-Sammeln :) 14:03 <hobbs> Ragnarok: Kommt darauf an, was du wirklich meinst. Sich einen Hardware-RNG zu besorgen, wäre mehr oder weniger der "beste" Weg :) 14:03 <jrandom> Ragnarok: kommt auf dein OS an (und ob du Hardware hast ;) 14:04 <tracker> dd if=/dev/urandom of=/dev/hda bs=1M count=4 Immer nett ;) 14:04 <jrandom> wir werden tatsächlich in einem der nächsten Builds eine Fortuna-Implementierung bündeln und müssen nach verschiedenen Entropiequellen suchen 14:04 <Ragnarok> ohne Hardware :P 14:04 <susi23> . o O ( ich dachte, jemand, der i2p benutzt, weiß, warum er /dev/urandom nicht verwenden sollte ) 14:05 <cervantes> tracker: die in 2.0.12 behobenen Sicherheitslücken werden durch mein mod_rocinante unbeabsichtigt gefixt, daher habe ich mir das Upgrade bisher gespart 14:05 <hobbs> susi23: wenn’s nur zum Unfug ist, denke ich, ist es ok ;) 14:05 <ant> <Nolar> wer hier macht den Python-BT-Port? 14:05 <jrandom> Nolar: das wäre duck 14:06 * duck pfeift 14:06 <ant> <Nolar> duck: warum habt ihr die Request-Blockgröße auf 128k geändert? 14:06 <susi23> . o O ( der Nächste schlägt vor: while true; do echo $RANDOM>> largefile; done ) 14:06 <ant> <Nolar> deshalb kann az nicht zu dir seeden 14:06 <tracker> cervantes: Ok 14:06 <ant> <Nolar> wir blocken Requests> 64k 14:06 <laberhorst> verdammt, ich brauche mehr MP3 14:06 <frosk> susi23: zum Greppen nach linux an einem ruhigen Abend ist /dev/urandom völlig ok :) 14:07 <jrandom> ah, habt ihr das schon immer? iirc hat i2p-bt schon eine Weile 128k verwendet 14:08 <ant> <Nolar> yup, seit Anfang an :) 14:08 <ant> <Nolar> irgendein Grund, warum 128 verwendet wird? 14:08 <ant> * duck schaut durch das CVS-Log 14:08 <jrandom> hält die Pipeline gefüllt, i2p hat etwas Lag ;) 14:08 <jrandom> mit 32KB ist das im Wesentlichen eine feste Fenstergröße von 1 14:09 <jrandom> also blockiert jede Nachricht auf ein ACK, während 128KB 4 Nachrichten erlauben, die innerhalb der RTT fliegen 14:09 <@duck> genau, maximal zulässige Slice-Größe gemäß den BT-Spezifikationen 14:09 <ant> <Nolar> nun, es gibt zwei Wege, damit umzugehen: 1) wir erhöhen das Limit auf 128k auf unserer Seite, oder 2) ihr pipelinet einfach mehr Requests 14:09 <cervantes> i2pbt ist etwas flinker als früher...vielleicht könnt ihr es euch leisten, es zu reduzieren... 14:10 <@duck> schni, schna, schnappi 14:10 <ant> <Nolar> also, statt einer einzelnen 128k-Anfrage schickt zum Beispiel zwei à 64k 14:10 <hobbs> duck: haha... das Ding ist um die Welt gegangen. 14:10 <@duck> warum blockt ihr 128k? 14:11 <cervantes> *schauder* Europop 14:11 <laberhorst> duck: bitte sei still ODER ich schieße dich ab! 14:11 <tracker> Manchmal bereue ich, dass ich vor ein paar Jahren Deutsch gelernt habe... 14:11 <laberhorst> kein Europop, wirklich kein POP 14:11 * cervantes befiehlt dem Vereinigten Königreich, die Grenzen zu verriegeln, bevor so ein Lied in die Charts kommt 14:11 <laberhorst> tracker: egal, ist ok 14:12 <ant> <duck> es ist jetzt (2^17)-13 14:12 <ant> <Nolar> duck: nun, das Limit gibt es schon eine Weile, aber ein guter Grund ist, dass 128K-Blöcke eine Weile zum Hochladen brauchen.....16KB (unser Default) erlauben feinere Request-Kontrolle 14:12 <ant> <duck> 13 Bytes sind die BitTorrent-Befehlslänge 14:12 <ant> <duck> hätte kein Problem mit (2^16)-13 14:12 <laberhorst> manche Musik ist wirklich lächerlich, aber echte Industrial-Musik, boah, nein 14:13 <ant> <duck> oder zurück zum Default? 14:13 <jrandom> es auf 64KB zu reduzieren scheint am einfachsten (ist das gerade ein CLI-Parameter?) 14:13 <ant> <duck> --download_slice_size 14:14 <ant> <Nolar> nun, meine Frage ist: Habt ihr einen triftigen Grund, an 128K-Blöcken festzuhalten? Scheint mir ein bisschen groß, besonders für i2p 14:14 <ant> <Nolar> anstatt einfach mehrere kleinere Requests zu pipelinen? 14:14 <ant> <duck> Ich habe keinen Grund. 14:14 <tracker> laberhorst: Sein vollständiger Name ist „ZDF Theater“ oder so. Und nun ja, sie sagen, sie senden ein hochkulturelles Programm. Ich hoffe wirklich, dass das, was sie senden, nicht das Beste ist, was die deutsche Kultur zu bieten hat ;) 14:15 <ant> <Nolar> ein Problem mit großen Blöcken ist: Sobald ich dich choke, muss ich trotzdem diesen 128k-Chunk zu Ende senden 14:15 <jrandom> ich erinnere mich nicht, ob das Vanilla-BT pipelinen kann, aber es sollte einfach genug sein (zumal ich es nicht mache ;) 14:15 <ant> <Nolar> was eine Weile dauern kann 14:15 <laberhorst> tracker: viva ist nur zur „Hard-Rock“-Zeit interessant, zu allen anderen Zeiten „bitte ignorieren“, und Theater, keine Ahnung 14:15 <jrandom> mit i2p sind 128KB nicht wirklich groß, da es einen inhärenten Lag in der Größenordnung von Sekunden gibt 14:15 <ant> <Nolar> was das Chunk/Unchoke durcheinanderbringen kann 14:16 <@duck> jrandom: macht es noch Sinn, die 13 Byte BitTorrent-Overhead abzuziehen, damit es in eine SAM-Nachricht passt? 14:16 <jrandom> duck: nee, da die Streaming-Lib es ohnehin weiter in 16KB-Nachrichten reduziert, stell es einfach auf 64KB 14:17 <@duck> ok, 2**16 ist es 14:17 <jrandom> (und dann zerlegen die tunnels diese 16KB-Nachrichten in 996-Byte-Fragmente..) 14:17 <ant> <Nolar> das Problem mit 128k ist: Wenn ich z. B. mit 12 k/s hochlade, brauche ich über 10 Sekunden, um diesen Block fertigzustellen 14:18 <cervantes> wow, das ist fast so lang wie der Lag auf IRC... 14:18 <jrandom> was 1–10 RTTs sind (während es im normalen Netz 10–500 sind) 14:18 <+detonate> ich war schon bereit, 512K-Blöcke zu verwenden 14:18 <ant> <Nolar> ihr könntet auch mit dem Pipelinieren von 16KB-Blöcken experimentieren 14:18 <jrandom> heh 14:18 <+detonate> also sind 64 bevorzugt? 14:19 <ant> <Nolar> alle BT-Clients, AFIAK, verwenden 16KB-Blöcke 14:19 <ant> <duck> in CVS gefixt; 14:19 <jrandom> geil, danke duck! (und Nolar!) 14:19 <ant> <duck> erwartet, dass es im 0.1.8-Release auftaucht, zusammen mit etwas SAM/I2CP-Tuning 14:19 <tracker> laberhorst: Es ist vollständiger Name ist "ZDF Theater" oder so. Und nun ja, sie sagen, sie senden ein hochkulturelles Programm. Ich hoffe wirklich, dass das, was sie senden, nicht das Beste ist, was die deutsche Kultur zu bieten hat ;) 14:19 <jrandom> ok, heh, ich habe gerade gemerkt, dass wir immer noch in einem Meeting sind 14:19 <jrandom> hat sonst noch jemand etwas fürs Meeting? 14:20 <ant> <Nolar> wenn wir also einen 128k-Chunk wollen, stellen wir einfach 8 gleichzeitige Requests 14:20 <susi23> . o O ( und die verbleibenden 448 Bytes verwerfen? ) 14:20 <jrandom> genau, genau 14:20 <laberhorst> tracker: oh, das ist ein kleiner Spartensender... arte oder 3sat ist wirklich interessanter 14:20 <laberhorst> und arte ist deutsch/französisch :-) 14:20 <ant> <Nolar> wenn der Uploader so eine Anfrage bedienen kann, sollten alle 128k in den i2p-Pipe-Stream geschoben werden 14:20 <jrandom> cool 14:21 <cervantes> . o O ( fragt sich, warum er alles hören kann, was susi denkt ) 14:21 <ant> <Nolar> also könnte es sich lohnen, mit 16KB- vs. 32KB- vs. 64KB-Blockgrößen zu experimentieren 14:21 <jrandom> aye 14:21 <jrandom> solange es gepipelined ist, ist es i2p egal 14:21 <ant> <Nolar> großartig 14:22 <jrandom> die Geschwindigkeit bei 16KB ohne Pipelines ist allerdings ziemlich schlecht, oder war es zumindest 14:22 <tracker> laberhorst: Ok, ich versuche in den nächsten Tagen mal, arte zu erwischen... 14:22 <ant> <duck> ich schlage vor, dieses Tuning für 0.2 aufzuheben 14:22 <ant> <duck> da es die BitTorrent-3.9.1-Verbesserungen enthalten wird 14:22 <jrandom> ja, DTSTTCPW 14:22 <susi23> . o O ( oh, das ist einfach... Menschen sind so vorhersehbar... ) 14:23 <ant> <duck> was den Netzcode komplett umstrukturieren könnte 14:23 <cervantes> http://www.gavelstore.com 14:24 <jrandom> ok, ich denke, das war’s fürs Erste, die Leute sollten in ein paar Stunden die Liste und die Seite checken, da die 0.5.0.1-Revision bald herauskommen wird 14:24 <ant> <Nolar> ja, ich kann sehen, warum einzelne 16KB-Requests langsam wären 14:24 * jrandom lädt einen Richterhammer herunter 14:24 * jrandom *baf*t das Meeting geschlossen