DHT oder wie töte ich ein perfektes Protokoll

DHT oder wie töte ich ein perfektes Protokoll
19.11.2009 02:38

In der heutigen Zeit einen Tracker zu betreiben ist nicht einfach. Die Tatsache, dass ein Tracker nichts weiter ist, als ein HTTP-Server der anhand eines beliebigen 160bit Hashes eine Liste von IP Adressen liefert, hindert Provider nicht Tracker reihenweise dicht zu machen. (Ist einem guten Freund von mir passiert, der mit seinem Tracker bei mehreren Anbietern war)
Einer der prominentesten Tracker - The Pirate Bay - hat vor ein paar Tagen nun endgültig aufgegeben. (Die Suchseite, die nach meinem Verständnis von Recht wesentlich schlimmer ist, da sie im Gegensatz zum Tracker wirklich über den Inhalt des Torrents Bescheid weiß, bleibt jedoch online.) Wie auch immer: Statt einfach zuzugeben, dass Sie vor den Richtern und ISPs dieser Welt den Schwanz einziehen faseln sie irgendein halb gares Zeug von wegen Tracker wären überholt und dank neuer Technologien im Torrent Protokoll (DHT, Magnet-links) bräuchte man keine Tracker mehr.
Doch gehen wir mal zurück an den Anfang, in die Jahre die 2001 folgten und erinnern uns warum Torrent damals so erfolgreich war und warum Torrent es fertig brachte die damals etablierten P2P Protokolle (Kazaa, E-Donkey, usw) in Null Komma Nichts abzulösen. Es waren die Tracker. Die Tracker, als zentraler aber dennoch vollkommen neutraler Punkt, wussten immer welche Peers gerade an welchen Torrents interessiert waren. Innerhalb von Sekunden konnte sich somit ein vollkommen neuer Peer eine Liste von anderen Peers besorgen und anschließend zu diesen Kontakt aufnehmen.
Und genau dieses Konzept soll jetzt, zumindest wenn man auf die Großen der Branche hört, abgeschafft werden. Und wenn wir schon einmal dabei sind schaffen wir zu allem Überfluss die Torrent Dateien ab und ersetzen sie durch Magnet Links. Doch zuerst zur DHT: Der Technologie, die Tracker überflüssig machen soll. DHT steht für Distributed Hash Table und ist im P2P Bereich nichts neues. (P2P hier nicht auf Filesharing bezogen sondern überhaupt auf Peer to Peer Computing.) Die P2P Suchmaschine Yacy speichert ihre Informationen beispielsweise in einer DHT. DHT im Falle von Torrent bedeutet jeder Client wird auch automatisch zum Tracker. Allerdings nicht zum vollwertigen Tracker, sondern nur verantwortlich für einen kleinen Teil aller möglichen Hashes (Hash = Die Zeichenkette die vorher in der Announce verwendet wurde und einen Torrent eindeutig markiert.) Da der Hash 160bit lang ist sind 2^160-1 verschiedene Torrents möglich. Jeder Peer der an der DHT teilnimmt wäre für ein paar Millionen oder Milliarden dieser 1.5 x 10^46 Hashes zuständig. Über clevere Algorithmen kann nun ein Peer der mindestens einen Nachbarn kennt, den Peer finden der für seinen gewünschten Torrent Hash zuständig ist und diesen als Ersatz-Tracker verwenden. (Über die DHT Algorithmen lest ihr am Besten mal die Wikipedia oder BEP 0005, das zu erklären würde den Rahmen dieses ohnehin schon zu langen Blog Eintrags komplett Sprengen.) Allerdings hat die Sache einen riesigen Haken. Ich habe es bereits geschrieben: "der mindestens einen Nachbarn kennt": Woher kommt der erste Nachbar? Die Torrent Spezifikation verweist hier nur müde auf einen "node" Eintrag im Torrent File (welches ja durch Magnet Links (dazu später) auch noch wegfallen soll) und meint noch dazu, dass bitte nicht alle den Node von bittorrent.org nehmen sollen. Also wo soll der Init Node. Der Node der vom Torrent Client als aller erstes Kontaktiert wird herkommen? Ein Node - also ein Client der ständig mit dem Internet verbunden ist - wird benötigt. Ein Node der beim erstellen der Torrent Datei existiert hat, und auch noch existieren wird wenn der Letzte die Torrent Datei heruntergeladen hat. Ist das nicht so was wie ein Tracker? Nein, vom Protokoll her nicht. Und auch von der Information her nicht. Der Node hat nämlich nicht die Peers direkt sondern nur Verweise zu anderen Nodes, die wiederum andere Nodes kennen, die dann die Peers zu einem Hash wissen. Durch den Wechsel von Trackern auf DHT haben wir den ganzen Prozess zwar unheimlich verlangsamt weil ein neuer Client zunächst die DHT aufbauen muss und mit unter sehr lange nach dem seiner zuständigen Tracker Node suchen muss, das Hauptproblem, dass eine zentrale, ein erste Instanz benötigt wird, hat man dadurch jedoch nicht beseitigt.
Wer hindert die Richter und ISPs die bisher Tracker abschalten liesen, daran Init Nodes abschalten zu lassen? Und zu welchem Preis erkauft man sich diesen Nicht-Vorteil? Man verlangsamt den Peer-Findungs Prozess Enorm und begibt sich somit wieder zu den alten Problemen die E-Donkey, Kazaa und Co hatten und die Torrent damals umgehen wollte.
Einziger Lichtblick ist, dass wenn ich meine eigenen Torrents anbieten möchte (Wenn ich zB eine Linux Distribution bin) den ganzen Quatsch nicht mitmachen muss und weiterhin meinen eigenen kleinen Tracker benutzen kann.
Bevor ich zum Schluss komme möchte ich der Vollständigkeitshalber noch schnell Magnet Links erklären. Magnet Links besagen einfach, dass ich meinen Torrent Client nicht mehr mit einer Torrent Datei (die, die Hashes der einzelnen Chunks, und die Dateinamen usw enthält) sondern nur noch mit dem Announce Hash und sich der Torrent Client anhand dieses Hashes die ganzen Meta Daten (Chunks, Dateinamen) aus der DHT holt. Mit ein bisschen IPC kann man es dann so hin biegen das man im Browser nur noch auf einen Link kicken muss, welches dann ein Script ausführt das den Hash in den Torrent Client wirft.
Auch im Grunde wieder komplett Schwachsinniger Overhead da ich nicht einfach anfangen kann meine Datei zu laden sondern zunächst die Metainformation mühsam aus der DHT zusammen kratzen muss.


Kommentare
Naja geht eigentlich...
kalkin (unangemeldet), Freitag, 20. November 2009 05:38:40
Ein/Ausklappen

Das Problem mit dem First Node hast du nur das allererste Mal wo du deinen Torrent Client anschaltest (theoretisch), danach speicherst du alle kennengelernte Knoten ab.

Und btw: Edonkey hatte am Anfang nichts mit DHT zu tun, es war ein von Servern abhaengiges Protokoll. Ich erriner mich noch an die Schlagzeilen, als Razorback2 offline genommen worden ist :).


Bewertung: 204 Punkte bei 17 Stimmen.
Den Beitrag bewerten: Gut / Schlecht

3298 Hits
Wertung: 123 Punkte (10 Stimmen)

Schlecht Gut

Infos zum Autor

Daniel Gultsch

Daniel Gultsch ist Student an der RWTH Aachen. Seit über 7 Jahren setzt er nun ausschließlich Linux auf seinen Rechnern ein. Zur Zeit läuft auf seinem Desktop ein Gentoo Linux mit KDE 4.4 und auf seinem Thinkpad X301 ein Gentoo mit dem Tiling WM i3. In seiner Freizeit hält er ein Netzwerk mit ~250 Benutzern am Laufen.

Zum Blog von Daniel Gultsch →