I2P Entwicklertreffen - 6. Dezember 2005

15:26 <jrandom> 0) hi 15:26 <jrandom> 1) 0.6.1.7 und Netzstatus 15:26 <jrandom> 2) Experimentelle tunnel-Ausfälle 15:26 <jrandom> 3) SSU und NATs 15:26 <jrandom> 4) Syndie 15:26 <jrandom> 5) ??? 15:26 <jrandom> 0) hi 15:26 * jrandom winkt 15:26 <jrandom> wöchentliche Statusnotizen veröffentlicht unter http://dev.i2p.net/pipermail/i2p/2005-December/001237.html 15:26 * ailouros liest die Notizen 15:27 * jrandom ist spät dran, also gebe ich euch allen einen Moment zum Lesen :) 15:29 <jrandom> ok, dann springen wir mal zu 1) 0.6.1.7 und Netzstatus 15:29 <@cervantes> *hust* 15:29 <jrandom> Ich habe zu diesem Punkt nicht viel mehr hinzuzufügen als das, was in der Mail steht. Hat jemand weitere Kommentare/Fragen/Ideen? 15:30 <Pseudonym> Scheint, als wäre Performance-Optimierung, bevor man den tunnel-Erstellungs-Algorithmus ändert, die falsche Reihenfolge 15:30 <gott> Ich bekomme ziemlich oft "No HTTP method found in the request. 15:30 <gott> Software caused connection abort: socket write error 15:30 <gott> " 15:30 <@modulus> tunnel-Latenz ist deutlich geringer, ich weiß nicht, ob ihr etwas geändert habt oder ob mein ISP plötzlich besser ist. 15:30 <gott> vom I2PTunnel Webmanager 15:31 <jrandom> gott: das deutet auf fehlerhafte HTTP-Requests hin, oder auf Dinge, die der eepproxy nicht verstehen konnte 15:31 <jrandom> modulus: cool, wir haben viel getan, um die Dinge zu verbessern 15:31 <jrandom> Pseudonym: nun, bisher war die tunnel-Erstellung nicht unser Engpass - der Engpass lag bei deutlich höher gelagerten Dingen 15:32 <jrandom> andererseits haben die Verbesserungen der letzten paar Revs dort unten einige Probleme offengelegt 15:32 <Pseudonym> oh, also bezogen sich die Optimierungen auf andere Teile des Codes? 15:32 <Pseudonym> cool 15:33 <jrandom> ja, auf SSU-Ebene sowie auf der Ebene des tunnel-Betriebs. tunnel-Erstellung ist keine performancekritische Operation [außer wenn sie es ist ;] 15:34 <jrandom> Ich mache allerdings Live-Netz-Lasttests und sammle nicht-anonyme Laststatistiken verschiedener Peers, um das weiter einzugrenzen 15:34 <ailouros> Ich frage mich, warum ich manchmal mehr tunnel sehe, als für ein Ziel konfiguriert sind (z. B. eeProxy, inbound 7 tunnel 4 outbound) 15:34 <jrandom> also, wenn ihr in den nächsten Tagen seht, dass der router 7xgV viele Daten überträgt, nun, nicht weiter beachten ;) 15:35 <jrandom> ailouros: wenn die tunnel-Erstellung eine Weile dauert, baut er zusätzliche, nur für den Fall. 15:35 <jrandom> zzz skizziert dazu auch ein paar der seltsamen Probleme, und es wird an einem Patch gearbeitet, um die Dinge etwas zu verbessern 15:35 <ailouros> Verstehe.. aber warum laufen sie dann alle zur selben Zeit ab? 15:35 <@cervantes> jrandom: aus Neugier, wann hast du diese Tests begonnen? 15:35 <jrandom> cervantes: vor ein paar Tagen 15:36 <@cervantes> ah cool, dann ist es _nicht_ das ;-) 15:36 <jrandom> keine Ahnung, ailouros, hängt von ein paar Bedingungen ab. Aber es gibt einige... *hust* Merkwürdigkeiten im tunnel-Erstellungs-Code, an den ich mich bisher nicht herangewagt habe, da er für 0.6.2 neu geschrieben wird 15:38 <ailouros> Verstehe. Ich dachte, es wäre eine Policy-Frage... Ich würde lieber sehen, dass die tunnel zu unterschiedlichen Zeiten auslaufen, außer es gibt einen guten Grund dagegen 15:38 <ailouros> im Sinne von: die tunnel-Erstellungen sind gestreut 15:39 <jrandom> ja, für 0.6.2 wird es eine bessere Randomisierung geben, und zzz's Patch fügt auch der aktuellen Rev etwas Randomisierung hinzu 15:40 <+Complication> Ich frage mich, warum eine ansonsten vernünftige Instanz von i2phex... sich entscheidet, bei jedem zweiten Start Dateien neu zu hashen? 15:40 <jrandom> Keine Ahnung 15:40 <+Complication> Beschädigte Konfiguration klingt bislang nach der wahrscheinlichsten Ursache, aber ich habe meine Config noch nicht gelöscht. 15:40 <jrandom> vielleicht verschobene Zeitstempel? 15:42 <+Complication> Nee, die scheinen auch korrekt zu sein 15:42 * jrandom weiß es nicht. Habe mir den Teil von phex's cod nie angesehen 15:42 <jrandom> äh, code 15:42 <+Complication> Ich schaue mal, ob das Löschen alter Config-Dateien hilft 15:42 <jrandom> cool 15:43 <jrandom> ok, noch etwas zu 1) Netzstatus / 0.6.1.7? 15:43 <jrandom> wenn nicht, weiter zu 2) Experimentelle tunnel-Ausfälle 15:44 <jrandom> wir haben das schon kurz angeschnitten, und es gibt mehr dazu in den Notizen und auf zzz.i2p 15:44 <jrandom> zzz: hast du etwas, das du hinzufügen/ansprechen möchtest? 15:46 <jrandom> wenn nicht, gehen wir weiter zu 3) SSU und NATs 15:46 <jrandom> bar: möchtest du etwas hinzufügen? 15:46 <+bar> nö, außer dem, was in der Mail steht, habe ich nichts hinzuzufügen 15:47 <jrandom> cool, ja, ich muss auf einige Details noch antworten - ich denke, unsere Retransmission wird bereits einige der von dir angesprochenen Probleme abfangen 15:48 <jrandom> Der Trick wird sein, zu erkennen, welche Situation vorliegt, damit wir das richtige Verfahren automatisieren können (oder den Nutzer informieren, dass er am Arsch ist) 15:48 <+bar> alles zu seiner Zeit, keine Eile 15:49 <+bar> ja, ich habe eine manuelle Nutzereinstellung vorgeschlagen, um das Problem vorerst zu umgehen, vielleicht ist das nicht möglich, aber wir können später darüber reden 15:50 <jrandom> ja, manuelle Overrides helfen, aber meine Erfahrung mit früheren i2p Revs war, dass es jeder (*wirklich jeder*) vermasselt hat ;) daher ist Automatisierung vorzuziehen 15:50 <jrandom> (mit „jeder“ meine ich mich eingeschlossen ;) 15:52 <+bar> einverstanden 15:52 <ailouros> lol, wenn ich das auch getan habe, dann war etwas mit den Docs falsch, denn ich habe ihnen Schritt für Schritt gefolgt :D 15:53 <+bar> In der Zwischenzeit werde ich etwas Zeit damit verbringen, das Peer-Testing zu studieren 15:53 <jrandom> cool, danke bar! 15:54 <+bar> (vielleicht könnte ich diesbezüglich auch nutzlosen Spam erzeugen :) 15:54 <jrandom> :) 15:55 <jrandom> ok, wenn es zu 3) nichts Weiteres gibt, gehen wir weiter zu 4) Syndie 15:56 <jrandom> Es gab in letzter Zeit viel Fortschritt in diesem Bereich, mit ziemlich umfassenden UI-Überarbeitungen seit 0.6.1.7 erschienen ist 15:57 <jrandom> Es gibt auch ein neues Standalone-Install/Build, aber da wir alle i2p installiert haben, brauchen wir kein separates 15:57 <ailouros> Ich finde, dass das Layout von 6.1.7 schwieriger zu benutzen ist als das von 6.1.6 15:58 <jrandom> hmm, betreibst du syndie im Single-User-Modus? und/oder benutzt du den neuesten CVS-Build oder den offiziellen 0.6.1.7-Build? 15:58 <ailouros> offiziell 0.6.1.7, Single-User 15:58 <jrandom> bist du einer der Befürworter der blogartigen Oberfläche, im Gegensatz zur Threaded-Navigation? 15:58 <ailouros> Bin ich nicht, obwohl ich nicht genau weiß, welche die blogartige ist 15:58 <ailouros> persönlich hätte ich lieber eine Threaded-Navigation 15:59 <ailouros> (und auch eine Farbkennzeichnung neuer Nachrichten in der Thread-Ansicht) 15:59 <+Complication> Relativ spätes CVS, Single-User 15:59 <+Complication> Ich habe eine kleine Merkwürdigkeit gefunden (die, wie ich denke, nicht beabsichtigt sein könnte) 15:59 <jrandom> ah, in CVS gab es dazu viel Fortschritt, ailouros 15:59 <ailouros> großartig :) 16:00 <jrandom> Wir haben auch eine neue Thread-Ansicht, die cervantes' vorgeschlagenes vollständiges Traversieren nur eines Zweigs nutzt, statt aller Zweige 16:00 <@cervantes> sind diese Änderungen nach syndiemedia.i2p.net gepusht? 16:00 <+bla> Wäre es eine gute Idee, einige Standardbeispiele für die Location in http://localhost:7657/syndie/syndicate.jsp anzuzeigen? 16:00 <jrandom> syndiemedia.i2p.net ist CVS head, ja 16:00 <+Complication> Wenn du einen Thread geöffnet hast und gerade seine Beiträge liest... und dann einen Filter anwendest, auf den keine Beiträge passen (z. B. Thread "Syndie threading" öffnen, Filter "i2p.i2phex" anwenden)... 16:00 <jrandom> ja, vielleicht bla. Neue Installationen werden die drei Defaults drin haben, aber Beispiele wären gut 16:01 <@cervantes> (der Baum des eigentlichen Threads muss sich allerdings auch komplett öffnen) 16:01 <+Complication> ...es scheint die aktuellen Beiträge angezeigt zu lassen, als ob sie passen würden oder so... 16:01 <+Complication> Obwohl ich definitiv auf den "Go"-Button geklickt habe. 16:01 <@cervantes> Complication: ja, das fand ich auch verwirrend 16:02 <jrandom> hmm, Complication, die Grundidee war, dich stöbern zu lassen, während du noch einen Beitrag anschaust, aber vielleicht wäre es besser, die angezeigten Beiträge zu verwerfen 16:02 <jrandom> cervantes: ah, ja, es bis zum Blatt zu expandieren wäre gut, und sollte trivial umzusetzen sein 16:02 <+Complication> Gerade bemerkt, und weil es herausstach, dachte ich, ich sage es 16:02 <@cervantes> (oder offensichtlicher machen, dass es keine Treffer gibt) 16:03 <jrandom> nun, die Thread-Navigation sagt *no matches* :) 16:03 <ailouros> vielleicht sucht er ein Feuerzeug 16:03 <jrandom> !thwap 16:03 <@cervantes> (oder noch offensichtlicher machen, dass es keine Treffer gibt) 16:03 <jrandom> <blink>No matches</blink> 16:03 <+Complication> Ups :) 16:04 <tethra> scheint, dein !thwap hat statt dessen spaetz__ erwischt, jr! 16:04 <+Complication> Stimmt, manchmal fühlt sich der Thread-Navigator *wirklich* weit weg an :) 16:04 <jrandom> ja, wir experimentieren mit etwas css, um das optional seitlich floaten zu lassen 16:05 <@cervantes> mit Skinning-Unterstützung könntest du den Thread top buttom left right etc 16:05 <@cervantes> ah wie jr sagte 16:05 <+Complication> Der "Threads"-Link bringt einen allerdings recht schnell dorthin 16:05 <+Complication> ...wenn er sich gerade im Viewport befindet. 16:06 <+Complication> Und die, die an Tastaturnavigation gewöhnt sind, können natürlich "End" drücken 16:06 <jrandom> Natürlich ist das Zeug wirklich leicht zu ändern (wie man an den schnellen Änderungen in CVS sieht :), also wenn jemand Vorschläge hat (oder Mockups - html / png / etc), bitte, postet sie jederzeit 16:07 <jrandom> Ich erwarte, dass wir in den nächsten Tagen in cvs eine Haupt-Blog-Übersichtsseite haben werden 16:08 <jrandom> ok, es passiert noch eine Menge anderes w/ syndie, also schaut vorbei auf http://localhost:7657/syndie/ für mehr Infos :) 16:08 <jrandom> Hat noch jemand dazu etwas anzusprechen, oder sollen wir weiter zu 5) ??? 16:09 <zzz> hi, gerade reingekommen. Zu 2), ich suche Tester für meinen Patch. 16:10 <zzz> Meine Ergebnisse sind Verbesserungen bei der Job-Verzögerung und Zuverlässigkeit und eine Reduzierung von router-Hängern. Hoffe also, dass es andere ausprobieren. 16:10 <ailouros> das klingt gut genug. Was muss ich tun? 16:11 <jrandom> heya zzz, ok cool, ich werde es hier auch ein bisschen prügeln. Es hat viele verschiedene Komponenten, daher könnte es sich lohnen, es in Teile zu splitten, aber es sieht gut aus und ist auf Kurs für 0.6.1.8 16:11 <ailouros> (durchschnittliche Uptime ist hier etwa 10h :( 16:11 <zzz> Wenn du Sourcecode und ant hast, einfach den Patch anwenden - oder ich kann eine i2pupdate.zip bereitstellen, wenn du willst 16:12 <zzz> jrandom ich werde daran arbeiten, es aufzuteilen 16:12 <ailouros> Ich nehme das Update, danke 16:13 <zzz> ailouros, stelle es innerhalb einer Stunde auf zzz.i2p – danke 16:13 <jrandom> zzz: Ich würde mir darüber keine Gedanken machen, außer du hast Zeit übrig... Ich kann den Diff lesen :) 16:13 <ailouros> danke 16:14 <zzz> jrandom OK. Es gibt ein paar Verschiedenes, das entweder du oder ich leicht rausreißen können. 16:16 <ailouros> Ich schätze, wir sind jetzt bei 5) ??? 16:16 <zzz> jrandom anderes Thema waren Router OOMs mit i2phex und mögliche SAM Probleme 16:16 <jrandom> ja, ailouros 16:16 <jrandom> ah ja, zzz, es wäre großartig herauszufinden, was mit SAM los ist 16:17 <ailouros> j346, hattest du die Gelegenheit, meine App anzuschauen? 16:17 <jrandom> Was großartig wäre, ist, wenn jemand einspringen und die Wartung der SAM bridge übernehmen könnte, da ich daran nichts Wesentliches gemacht habe, und human schon eine Weile nicht da war. 16:19 <jrandom> noch nicht, ailouros, leider. War mir etwas unsicher, wie es funktioniert, daher muss ich erst den Source lesen 16:20 <ailouros> frag ruhig 16:20 <ailouros> (und viel Glück auf der Reise durch den Source, es ist eine gute Definition für das Wort "mess") 16:20 <jrandom> hehe 16:21 <zzz> Korrektur: Meine Erfahrung waren OOMs bei der Nutzung von i2p-bt, nicht i2phex. Passiert nach etwa 24 Stunden, wenn ein i2p-bt läuft, und in ein paar Stunden, wenn zwei i2p-bt laufen 16:22 <+Complication> Bei mir passierte es nach einigem nächtlichen Stresstesten. 16:22 <+Complication> (wobei, sei angemerkt, ich 5-Minuten-Durchschnitte von 50 KB/s gesehen habe) 16:22 <bar_> könntest du mich bitte daran erinnern, was deine App ist/macht, ailouros? mein Gedächtnis ist gut, aber kurz... 16:22 <+Complication> Eingehend, wohlgemerkt. 16:22 <+Complication> Ausgehend war auf 35 KB/s begrenzt 16:22 <@cervantes> Complication: Ich habe es noch nie „late-night stress testing“ genannt gehört... 16:22 <jrandom> schön, Complication 16:23 <+Complication> cervantes: nun, man könnte es dann halb-tägliches Megaleeching nennen :P 16:23 <ailouros> bar_: es ist ein funktionierender Proof-of-Concept für eine verteilte Filesharing-App, die gemeinsame Blöcke zwischen verschiedenen Dateien teilt (wie von polecat vorgeschlagen) 16:23 <bar_> ah, richtig, danke ailouros 16:24 <tethra> cervantes: heheheh ;) 16:24 <ailouros> gern geschehen (falls jemand den Source haben möchte, er ist in c/c++) 16:25 <+polecat> ailouros: Vorsicht, die Chance, dass zwei binäre Blöcke gleich sind, ist ausreichend selten; ich rede größtenteils über reine Theorie, die in der Praxis unbrauchbar wäre. 16:25 <ailouros> polecat, ich stimme zu. Meine Vermutung ist, dass es nützlich wird, wenn man verschiedene Versionen derselben Dateien bekommt 16:25 <ailouros> zum Beispiel ein Film, der einen beschädigten Block hat 16:25 <+polecat> Du könntest Blöcke aus Nullen in Lichtgeschwindigkeit übertragen! ("The next block is zeroes" "oh I have that already" "the next block is zeroes" "oh I have that already") 16:26 <ailouros> oder ein Archiv mit anderen ZIP-Dateien 16:26 <jrandom> oder z. B. modifizierte ID3-Tags, etc 16:26 <ailouros> genau 16:26 <+polecat> Stimmt. Aber eine einfache Möglichkeit, einen Film mit einem beschädigten Block zu "fixen", ist, bittorrent anzuweisen, darüber herunterzuladen. Die meisten Clients bewahren die Blöcke, deren Hashes gleich sind, und überschreiben die, die unterschiedlich sind. 16:26 <jrandom> Archive von Dateien werden wahrscheinlich nicht funktionieren, da sie an Datei-Grenzen brechen müssten 16:27 <ailouros> j636, deshalb möchte ich die LBFS-Idee implementieren, an Datenmarken zu splitten und nicht in festen Blockgrößen 16:27 <@cervantes> die DC-Community verwendete diese Methode, indem sie Dateiverteilungen in rarsets teilte 16:27 <+polecat> Nützlich könnte sein, einen allgemeinen binären Fehlerkorrektur-Algorithmus zu erstellen, dann auf riesiger Skala zu implementieren. Alle Blöcke könnten in einander "korrigiert" werden, und man müsste nur die Korrekturdaten übertragen, die kleiner sein könnten als die Übertragung des Blocks selbst. 16:29 <@cervantes> und dann basieren Suchen auf tiger hashes dieser rar parts 16:29 <+Complication> Netter Gedanke... klingt allerdings schwierig :) 16:29 <+polecat> Aber nur ein Hash-für-Hash-Äquivalent... du würdest nie zwei gleiche Blöcke finden! 16:29 <ailouros> cervantes, was ist ein "rarset"? :D (außer einer "RAR-Datei", meine ich) 16:29 <+polecat> Außer wenn beide Seiten die Datei bereits hatten, eine davon beschädigt. 16:29 <ailouros> polecat, äh? 16:29 <@cervantes> ailouros: ein geteiltes rar-Archiv, bei Bedarf mit Parity-Dateien 16:30 <ailouros> cervantes: Ich verstehe den Vorteil davon nicht 16:31 <@cervantes> Sein Hauptvorteil war, DC pseudo-Mehrquellen-Downloads hinzuzufügen 16:32 <ailouros> nun, das ist doch Teil des Blockteil-Mechanismus zwischen Dateien, oder? 16:34 <ailouros> polecat: hinsichtlich des bittorrent-Überschreibens beschädigter Dateien – das hilft dir nicht, wenn du mehrere Versionen gleichzeitig bekommen willst 16:35 <@cervantes> dein Client matched/lädt nur gültige Teile herunter, wenn du Parity-Dateien hast, kannst du beschädigte Teile auch wiederherstellen 16:35 <ailouros> mit meinem System gibt es keine beschädigten Teile (Dateien werden erst zusammengesetzt, wenn die zusammensetzenden Blöcke heruntergeladen und erneut geprüft sind) 16:36 <@cervantes> Dinge, die bittorrent standardmäßig macht, außer dass du nicht gezielt nach einzelnen Teilen suchen kannst 16:36 <+polecat> Mehrere Versionen werden wahrscheinlich nicht ein einziges Bit gemeinsam haben... weshalb sie so dumm sind. Irgendein Depp beschließt, den Film in Briefmarkenformat neu zu encodieren, und gibt ihm denselben Namen. 16:37 <+polecat> Oder ein anderer Depp nimmt Zufallsdaten und benennt sie wie die Datei, die du herunterladen willst. 16:37 <ailouros> lol, das stimmt 16:37 <@cervantes> genau, und rarset releases sind dagegen immun... 16:37 <ailouros> aber bedenke, dass Dateien aus anderen Netzwerken (emule, kazaa, was auch immer) oft beschädigt ankommen 16:38 <+polecat> rarset releases sind nicht immun... 16:38 <+polecat> Du musst immer noch herausfinden, welches rarset das richtige ist. 16:38 <ailouros> cervantes, wie sind rarsets immun gegen einen Idioten, der zufälligen Müll veröffentlicht? 16:38 <@cervantes> (vorausgesetzt, du hast eine zuverlässige Quelle) 16:39 <@cervantes> weil eine Release-Gruppe Hashes/Distributionsinformationen veröffentlicht 16:39 <ailouros> hahaha, das ist einfach :D 16:39 <@cervantes> und Zeug wird als nuked markiert, wenn es von schlechter Qualität ist, die Leute entfernen es aus Shares 16:40 <ailouros> cervantes, so viel kann mein Spielzeug schon 16:40 <@cervantes> cool 16:40 <ailouros> du holst dir den File-Descriptor von einer vertrauenswürdigen Quelle, du multi-gettest die Datei pronto 16:41 <@cervantes> klingt gut ;-) 16:41 <ailouros> du kannst nicht nach Dateien suchen, aber du kannst durch das freigegebene Verzeichnis jedes Nutzers browsen, also kannst du einen Web-Crawler verwenden und die Ergebnisse cachen 16:42 <ailouros> allerdings könnte ich irgendwann in Zukunft eine Suchfunktion hinzufügen, falls nötig 16:44 <ailouros> Ich glaube, mein Spielzeug kann, richtig zu einer App entwickelt, das Caching und die Resilienz bieten, die die freenet Leute bereitzustellen versuchen 16:44 <ailouros> also statische Inhaltsverteilung und Caching 16:45 <ailouros> du liest meinen Blog, du cachest ihn und bietest ihn anderen an, wenn sie wollen. du machst nichts weiter, als den Inhalt dort zu lassen 16:45 <ailouros> gefällt dir der Inhalt nicht? lösch ihn und alles ist gut 16:45 <jrandom> hmm, siehst du es also als einen Backing-Store, der für syndie genutzt werden könnte? 16:46 <ailouros> es KANN als Backing-Store verwendet werden 16:46 <ailouros> so wie es jetzt ist, könntest du es sogar anstelle von jetty, in i2p Default-Installationen, nutzen 16:46 <jrandom> z. B. Anhänge / Links auf [clunk hash="$foo"]my file[/clunk] 16:46 <ailouros> (nun, mit ein paar kleinen Änderungen :D ) 16:46 <jrandom> heh 16:47 <jrandom> ok, ja, ich verstehe definitiv nicht, wie clunk funktioniert... willst du darüber in syndie posten, oder eine eepsite aufsetzen? :) 16:47 <ailouros> Datei-Hashes werden bei Datei-Anfrage heruntergeladen, und daraus wird wie von Zauberhand die vollständige Datei heruntergeladen 16:48 <jrandom> richtig, aber "herunter"geladen ist die Frage von wo nach wo, etc. eine übergreifende Beschreibung der Netzwerkarchitektur wäre hilfreich 16:48 <ailouros> Ich schreibe zuerst eine ordentliche Doku, dann veröffentliche ich sie irgendwo 16:48 <jrandom> r0x0r, danke 16:48 <ailouros> heruntergeladen von wo auch immer du den Hash her hast 16:48 <ailouros> plus allen anderen, die diese Blöcke teilen 16:49 <ailouros> denk an go!zilla und download accellerator :) 16:49 <jrandom> Ich glaube, du unterschätzt, wie verwirrt ich bin 16:49 <ailouros> aber transparent und innerhalb i2p 16:49 <ailouros> lol wohl wahr :D 16:50 <jrandom> eine sehr, sehr grundlegende Erklärung, z. B. "du betreibst einen clunk client, lädst von einem clunk server herunter, bekommst Infos über clunk peers", etc 16:50 <jrandom> Benutze ich einen Webbrowser, um einen clunk client abzufragen? oder server? oder peer? 16:51 <jrandom> (so verloren bin ich) 16:51 <ailouros> Neu von 0 :) 16:51 <ailouros> du benutzt deinen Webbrowser 16:51 <ailouros> du verbindest dich mit deinem client 16:51 <ailouros> du browsest mit deinem Browser die Verzeichnisse anderer 16:51 <ailouros> du wählst mit deinem Browser aus, welche Dateien du herunterladen willst 16:51 <ailouros> dein client macht die Drecksarbeit 16:52 <ailouros> du bekommst die heruntergeladene Datei zurück 16:52 <ailouros> ist das besser? :) 16:52 <jrandom> ok super, danke - also wird das "Verzeichnis anderer browsen" dadurch erledigt, dass dein Client deren Client abfragt und mit einer HTML-Repräsentation antwortet 16:52 <ailouros> genau 16:52 <jrandom> (oder von einem Server/Superpeer/etc. gezogen) 16:53 <jrandom> cool 16:53 <ailouros> die ganze Drecksarbeit (Duplikate finden, Mehrfachdownloads und so weiter) erledigt dein (lokaler) Client transparent 16:54 <ailouros> was du siehst, ist im Grunde ein Verzeichnisbaum und einige Dateien, die du herunterladen kannst 16:54 <jrandom> cool 16:55 <ailouros> um deine Daten zu veröffentlichen, gibst du deine öffentliche (p2p) Adresse heraus 16:55 <ailouros> und um Dateien zu teilen, kopierst du sie (oder setzt Symlinks) ins pub/ Verzeichnis (oder in ein Unterverzeichnis). So einfach ist das 16:57 * jrandom wird weiter durch den Source graben, und freut sich auf mehr Infos :) 16:57 <jrandom> ok, hat noch jemand etwas für das Meeting? 16:57 <bar_> ähm.. was ist der Unterschied zwischen Veröffentlichen und Teilen, wenn ich fragen darf? schiebt Veröffentlichen die Daten in irgendeinen Datenspeicher? 16:58 <ailouros> bar_: Teilen heißt, die Blöcke zum Download bereitzustellen. Veröffentlichen heißt, der Welt mitzuteilen, was du teilst 16:58 <ailouros> Veröffentlichen ist eine Teilmenge von Teilen 16:58 <bar_> aha, verstanden, danke 16:58 <ailouros> zum Beispiel: Wenn du die Hälfte einer Datei hast, teilst du sie, veröffentlichst sie aber nicht 16:59 <jrandom> wie würden die Leute dann wissen, dass sie diese Blöcke von dir bekommen könnten? 16:59 <ailouros> und du hast die volle Kontrolle darüber, welche Dateien du veröffentlichst (anders als bei emule, wo jede heruntergeladene Datei veröffentlicht wird) 16:59 <ailouros> weil jeder Client regelmäßig Informationen ins Netzwerk sendet, welche Blöcke er anzubieten hat 17:00 <jrandom> cool 17:00 <ailouros> sendet ins Netzwerk als in Server (wie jetzt) oder DHT (Zukunft) 17:00 <jrandom> also ist es mnet-ähnlich, mit einem Block-Tracker 17:00 <ailouros> äh mnet-ähnlich? 17:01 <jrandom> ähnlich wie mnet (mnetproject.org) funktioniert 17:01 * ailouros liest mnetproject.org 17:02 <ailouros> nun, du hast nur deine persönlichen spaces, keine geteilten spaces 17:02 <ailouros> und du PUSHst keine Blöcke herum 17:02 <jrandom> ja, es ist nicht genau dasselbe wie mnet, aber strukturell ähnlich 17:03 <jrandom> es ist wie mnet, wo alle zu pleite sind, um jemanden ihre Daten hosten zu lassen ;) 17:03 <ailouros> yep 17:03 <ailouros> :D 17:03 <jrandom> ok, hat sonst noch jemand etwas anzusprechen? 17:04 <jrandom> wenn nicht... 17:04 * jrandom wickelt ab 17:04 * jrandom *baf*t das Meeting zu