FAQ eD2k-Kademlia-de

Häufig gestellte Fragen über eD2k&Kademlia

English | Español | Italiano | Deutsche | Français | Nederlands | Polski

Was ist ED2K?

ED2k ist ein Protokoll, das ursprünglich vom P2P (Peer-to-Peer) Client eDonkey2000 verwendet wurde, der ihm auch seinen Namen gab. Es ist ein Server/Client-Protokoll mit der Möglichkeit, Quellen zwischen den Clients auszutauschen.

Das ED2k-Netzwerk ist serverbasiert, im Gegensatz zu reinen P2P-Netzwerken wie Kazaa. Nach dem Start von aMule ist also das erste, sich mit einem Server zu verbinden (entwedermanuell oder automatisch).

Sobald die Verbindung hergestellt wurde, kann der Client eine Suchanfrage an den verbundenen Server stellen oder alle Server global absuchen. Die Antworten enthalten eine Liste aller Dateien, die den gegebenen Suchkriterien entsprechen.

Wird vom Nutzer ein Download initiiert, fragt der Clients den Server nach Quellen, was dieser mit einer Liste von IP Adressen anderer Clients beantwortet, die die gesuchte Datei (oder Teile davon) haben.

Sobald der eigene Client an der Spitze der Warteschlange des Gegenübers angekommen ist (siehe auch "Was hat es mit diesem ganzen Krempel (Credits, Bewertungen, Warteschlangen usw.) auf sich?"), beginnt dieser einen Block der Datei heraufzuladen und, wenn der Block vollständig ist, den eigenen Client wieder in die Warteschlange einzureihen. Auf diese Weise werden die verschiedenen Teile im ED2k-Netzwerk verteilt, so dass, auch wenn eventuell niemand zu einem bestimmten Zeitpunkt die vollständige Datei hat, diese dennoch durch Downloads von verschiedenen Leuten vollständig erhältlich sein kann (leider gibt es eine Menge Leute, die eine Datei nicht weiter freigeben, nachdem sie vollständig heruntergeladen wurde).

Zu berücksichtigen ist, dass Clients immer nur einen Block zur gleichen Zeit zu einem anderen Client hochladen. Auch wenn der Client für zwei verschiedene Dateien in der Warteschlange steht und an der Spitze ankommt, wird trotzdem nur eine der beiden an ihn hochgeladen werden (die andere, abhängig vom verwendeten ED2k-Client, bleibt eventuell an der Spitze stehen, bis der erste Download abgeschlossen ist, wird aber keinesfalls vorher beginnen).

Haben beide Clients eine Hohe ID (siehe Was sind niedrige und hohe IDs?) läuft der Transfer direkt zwischen den beiden ab (Peer-to-Peer), hat einer aber nur eine niedrige ID, wird die Verbindung mit Hilfe des Servers (des Clients mit der niedrigen ID) aufgebaut, da eine niedrige ID bedeutet, dass der Client keine eingehenden Verbindungen annehmen kann. Daraus ergibt sich, dass zwei Clients mit niedrigen IDs keine Verbindung zwischeneinander aufbauen können.

Was ist Kademlia?

Kademlia ist die logische Weiterentwicklung des ED2k-Netzwerkes. Kademlia ist die Zukunft. Siehe Gibt es Grenzen im ED2k-Netzwerk? für weitergehende Informationen und warum Kademlia notwendig ist.

Da Kademlia ein dezentrales Netzwerk ist, entfällt der Flaschenhals der Notwendigkeit von Servern (auch wenn Lugdunum sehr viel getan hat, diesen Flaschenhals breiter zu machen). Anstatt zu einem Server verbindet man sich einfach zu einem Client (mit bekannter IP-Adresse und Port), der das Kademlia-Netzwerk unterstützt. Diesen Vorgang nennt man "Boot Strapping".

Besteht die Verbindung, bekommt man, abhängig von der Fähigkeit, eingehende Verbindungen anzunehmen, den Status "offen" oder "hinter Firewall", die den hohen und niedrigen IDs des ED2k-Netzwerkes ähnlich sind. Dann erhält man eine ID.

Im Moment werden "hinter Firewall"-Clients noch nicht von Kademlia unterstützt und erhalten daher keine ID und keine Möglichkeit, sich mit dem Netzwerk zu verbinden. Dies wird aber später noch ermöglicht werden.

Bei der Suche fungiert jeder Client als kleiner Server und bekommt die Verantwortung für bestimmte Schlüsselwörter oder Quellen. Dies macht die Suche nach Quellen sehr viel komplexer, da es keine zentralen Server zum Fragen mehr gibt, sondern die Anfrage sich durch das Netzwerk arbeiten muss.

Seit dem 26.07.05 besteht in der CVS-Version die Möglichkeit das KAD-Netzwerk zu nutzen.

Sind Kademlia und Overnet gleich?

Kurez und knapp: Nein. Overnet ist die natürliche serverlose Weiterentwicklung des eDonkey-Clients, während Kademlia jene der *Mule-Clients ist. Die Philosophie ist also die gleiche, aber die Regeln sind verschieden. Hier kann man mehr über die Arbeitsweise von Overnet erfahren, allerdings ist zu berücksichtigen, dass die Entwicklung von Overnet im geschlossenen Rahmen abläuft, bis es Version 1.0 erreicht, während Kademlia von Anfang an offen entwickelt wurde.

Was ist ein Block?

Um die Weiterverteilung zerstörter Dateien zu vermeiden, werden im ED2k-Protokoll Dateien in mehrere Abschnitte unterteile, sogenannte Blöcke, deren jeweils einzelne Prüfsumme erzeugt wird (siehe nächster Eintrag). Jeder Block hat eine Größe von 9.28MB, eine 15MB Datei wird also in zwei Blöcke (9.28MB & 5.72MB) aufgeteilt, eine 315KB Datei bleibt in einem Stück und eine 100MB Datei wird in 11 Teile gespalten (10*9.28MB & 7.2MB).

Was ist ein Hash?

Dateien in einzelne Blöcke aufzuteilen (siehe Was ist ein Block?) verhindert zwar, komplett zerstörte Dateien herunterzuladen, aber dafür ist es nötig, beschädigte Blöcke zu finden. Dafür werden MD4 Prüfsummen verwendet.

Eine MD4 Prüfsumme ist ein einzigartiger Wert für jeden einzelnen Block, der durch eine fortlaufende mathematische Berechnung unter Berücksichtigung jedes einzelnen Bits des Blocks entsteht. Schon durch Änderung nur eines Bits im Block ändert sich auch die Prüfsumme. Somit kann die Integrität jedes einzelnen Blocks nach dem Download überprüft werden.

Aber nicht nur für die Blöcke werden Prüfsummen errechnet, sondern, um eine Prüfsumme für die gesamte Datei zu erhalten, werden die entstehenden Prüfsummen in der Reihenfolge der Blöcke aneinandergehängt und für den entstehenden String wiederum die Prüfsumme gebildet. Auf diese Art und Weise bekommt jede Datei im ED2k-Netzwerk eine einzigartige Kennzeichnung. Die Dateiprüfsumme wird also nicht durch hashen der ganzen Datei sondern aus den einzelnen Blockhashs gebildet.

Tatsächlich benötigt man aber die Prüfsumme und die Größe einer Datei, um sie zu identifizieren. Alle diese Informationen sind in den ominösen ED2k-URIs enthalten, die überall zu finden sind.

Hier ein Beispiel:

ed2k://|file|aMule-2.0.0rc7.tar.bz2|1877051|527CE82275B39AAB5D902DD945B43425|/

Die interessanten Teile sind der fünfte Teil, "1877051", die Größe der Datei in Bytes und der letzte Teil, "527CE82275B39AAB5D902DD945B43425", was die Dateiprüfsumme der Datei ist, als 32 hexadezimale Ziffern.

Der Dateiname spielt übrigens für die Kennzeichnung einer Datei keine Rolle.

Warum erscheinen Dateien gleichen Namens als verschiedene Suchergebnisse?

Wer "Was ist ein Hash?" gelesen hat, wird das schnell verstehen. Wird eine Suche gestartet, schickt der Server dem Client die Namen und Dateihashes der Dateien, die den gegebenen Suchkriterien entsprechen. Wenn sich zwei Dateien, auch wenn sie den gleichen Namen tragen, in ihrem Inhalt unterscheiden, egal wie gering, werden sie als verschieden angesehen. Aus diesem Grund können zwei Dateien mit unterschiedlichem Namen gleich erscheinen - der Dateiname interessiert nicht, nur die Prüfsumme.

Was sind niedrige und hohe IDs?

Jeder Client bekommt eine nur ihm zugeordnete Nummer, die ihn im ED2k-Netzwerk eindeutig identifiziert und von anderen mit einem Server verbundenen Clients unterscheidet. Wenn diese ID niedriger als 16777216 (2^24) ist, dann handelt es sich um eine niedrige ID, ansonsten um eine hohe. Ob man eine hohe oder niedrige ID bekommt, hängt einzig davon ab, ob der TCP-Port 4662 (bzw. der in den Einstellungen gewählte) von außen erreichbar ist. Wer "Was ist ED2K?" gelesen hat, weiß, dass Clients mit niedriger ID sich zu bestimmten anderen (nämlich denen mit ebenfalls niedriger ID) nicht verbinden können und so niedrigere Transferraten zu erwarten haben. Daher ist Port 4662, bzw. der eingestellte, so wichtig. Außerdem verweigern manche Server Clients mit niedriger ID den Verbindungsaufbau, da sie für die Datenübertragung auf den Server angewiesen sind und große Server so überlastet werden könnten.

Eine hohe ID ist lediglich die dezimale Darstellung der IP des Clients als big-endian (aus der IP A.B.C.D wir A+2^8*B+2^16*C+2^24*D). Ansonsten dient die hohe ID nur der Identifikation, sonst nichts, es interessiert nur, ob die ID kleiner oder größer als 2^24 ist, wie groß oder klein genau, ist irrelevant. Eine hohe ID von 50000000 ist nicht besser als 49999999.

Es gibt eine Ausnahme, manchmal vergeben falsch konfigurierte oder überlastete Server eine niedrige ID, obwohl der Port des Clients erreichbar ist. Das ist selten, kommt aber durchaus vor.

Welche Ports müssen in einer Firewall oder einem Router für aMule konfiguriert werden?

Außer für eine hohe ID, die Port 4662 (bzw. den eingestellten) für einkommende Verbindungen geöffnet voraussetzt, müsen keine speziellen Ports für aMule geöffnet werden.

Abgesehen davon sollten, um eine optimale Transferleistung zu erreichen, zwei weitere Ports geöffnet werden. Zuerst UDP-Port 4672 (kann in den Einstellungen geändert werden) und zweitens TCP-Port+3 (kann nicht verändert werden), also standardmäßig 4665 (4662+3).

ab Version 2.1.0: Für Kademliaunterstützung sollte zusätzlich der Port 4673 geöffnet werden, ansonsten bleibt aMule als Kademliaclient hinter einem Firewall. (UDP oder TCP?)

Wofür sind die Ports jeweils da?

Da sich die meisten Ports einstellen lassen, werden hier die Vorgabewerte aufgeführt:

4662 TCP

Peer-to-Peer (Transfer zwischen den Clients)

4672 UDP

erweitertes *Mule-Protokoll, Warteschlange, Dateinachfrage

4661 TCP

Nur für Server notwendig, hierher verbinden sich die Clients

4665 UDP

Auf dem Server geöffnet, für die Frage nach Quellen, ist immer TCP-Port+3

4711 TCP

Port des *Mule WebServers

4712 TCP

externe Verbindungen, wird für Programme, die sich mit aMule verbinden, z.B. WebServer oder aMuleCMD, benötigt.

Obwohl der zweite UDP-Port offiziell TCP-Port+4 ist, verwenden einige (die meisten?) Implementierungen es als TCP-Port+3. Aber dieser Port wird zumeist nicht verwendet (aMule benutzt ihn nicht, eMule hat ihn nicht).

Gibt es Grenzen im ED2k-Netzwerk?

Ja, aber nicht viele. Zwei natürliche und eine "erzwungene":

Die natürlichen wurden bereits erwähnt: Zuerst die Probleme mit niedrigen IDs (sie sind auf Transfers über Server angewiesen und zwei Clients mit niedrigen IDs können keine Dateien austauschen) und zweitens, obwohl ED2k eine Peer-to-Peer-Protokoll ist, werden Server benötigt, um das Netz aufzuspannen. Letzteres wird aber durch das neue Kademlia-Protokoll gelöst.

Zur "erzwungenen" Einschränkung: Sie dient dazu, sicherzustellen, dass die im ED2k-Netzwerk teilnehmenden Clients auch zu seinem Bestehen beitragen und das Netz bestehenbleibt. Die Beschränkung wird über das Limit der Uploadbandbreite geregelt. Wenn dieses zwischen 0 und 3.99KB/s (beides inklusive) liegt, wird der Download auf das Dreifache dieses Wertes begrenzt. Liegt das Limit zwischen 4 und 9.99KB/s (ebenfalls inklusive) ist der Download auf das Vierfache beschränkt. Clients mit einem Uploadlimit von 10KB/s oder mehr unterliegen keinen Downloadbeschränkungen. Die Begrenzung wird im Clientprogramm vorgenommen, ließe sich also durch dessen Veränderung umgehen, allerdings würde dies von den Servern mit einem Rauswurf quittiert.

Außerdem bietet jeder Client mindestens drei Uploadplätze, es ist also nicht möglich, mehr als Uploadlimit/3 KB/s pro Platz einzustellen.

Eine weitere Begrenzung gibt es noch: Die maximale Dateigröße im Netz beträgt 4GB.

Für welche Dateitypen stehen jeweils die einzelnen Filter im Suchfenster?

Es ist zu beachten, dass die Filter im Suchfenster nicht nach dem tatsächlicne Inhalt, sondern nach der Dateinamenserweiterung gehen. Die Zuordnung ist folgende:

• Archive: .ace .arj .rar .tar.bz2 .tar.gz .zip .Z
• Audio: .aac .ape .au .mp2 .mp3 .mp4 .mpc .ogg .wav .wma
• CDImage: .bin .ccd .cue .img .iso .nrg .sub
• Bilder: .bmp .gif .jpeg .jpg .png .tif
• Programme: .com .exe
• Videos: .avi .divx .mov .mpeg .mpg .ogg .ram .rm .vivo .vob

Ein Film, der fälschlicherweise "Geburtstag.gz" benannnt ist, wird also unter den Archiven und nicht unter Videos einsortiert.

Was ist eine Quelle?

Eine Quelle ist ein Client, der einen noch nicht fertiggestellten Block einer Datei anbietet, die in der eigenen Downloadliste steht. Um so mehr Quellen man für eine Datei bekommt, umso mehr Möglichkeiten zum Download hat man und um so schneller wird der Download wahrscheinlich beendet sein.

Zu berücksichtigen ist aber, dass es einen Unterschied zwischen "Quellen" und "nutzbaren Quellen" gibt, wenn man nur eine niedrige ID hat: "Quellen" sind Clients, die ein Stück der Datei anbieten können, das man noch nicht hat, aber nur "nutzbare Quellen" sind solche, von denen man auch tatsächlich herunterladen kann (die also eine niedrige ID haben).

Was hat es mit diesem ganzen Krempel (Credits, Bewertungen, Ratings, Warteschlangen) auf sich?

All diese Konzepte haben mit der Art und Weise zu tun, wie im ED2k-Netzwerk die Uploadwarteschlangenprioritäten ermittelt werden.

Die Bewertung ist der wichtigste Wert: Der Client mit der höchsten Bewertung wird der nächste sein, der einen Uploadplatz bekommt. Die Bewertung wird wie folgt berechnet: Bewertung = (Rating * Wartezeit[s]) / 100

Um das zu verstehen, muss erstmal geklärt werden, was unter dem Rating zu verstehen ist:

Das Rating ist eine objektive Bewertung. Also eine Bewertung unabhängig davon, wie lange ein Client bereits in der Uploadwarteschlange wartet. Wenn sich ein Client in die Uploadwarteschlange einreiht, bekommt er eine Rating von 100 zugewiesen. Danach wird dieser Wert wie folgt verändert:

Abhängig von den Credits des Clients wird die Rating mit 1 bis 10 multipliziert. Entsprechend der Dateipriorität wird sie mit 0.2 bis 1.8 multipliziert (Release 1.8, Hoch 0.9, Normal 0.7, Niedrig 0.6, Sehr niedrig 0.2).

Sehr alte Clients, die das Netzwerk zu sehr belasten werden durch eine halbierte Rating gebremst.

Verbannte Clients bekommen keine Rating (bzw. ihre Rating wird mit Null multipliziert).

Diese Multiplikatoren werden als "Modifikatoren" bezeichnet. Clients mit einem Modifikator größer als Eins werden mit einem gelben Stern im Icon gekennzeichnet.

Bleiben also nur die Credits. Credits sind die Belohnung die man für den Upload an einen anderen Client bekommt. Credits werden jeweils zwischen zwei Clients ausgetauscht, nicht global. Die eigenen Credits kann man also nicht einsehen, wohl aber die aller anderen Clients (also die Credits, die man dem jeweiligen Client schuldet). Da Credits vom hochladenden Client verwaltet werden (sie sind in der clients.met zu finden), kann es passieren, dass man keine Credits bekommt, wenn der empfangende Client dies nicht unterstützt, dieser aber trotzdem beim eigenen Client welche bekommt, wenn er etwas hochlädt.

Der Credits Modifikator für das Rating ist der niedrigere dieser beiden Werte: (Gesamtupload[MB] * 2) / Gesamtdownload[MB] und Wurzel_aus(Gesamtupload[MB] + 2)

Ist das Ergebnis kleiner als Eins ist, wird es auf Eins gesetzt und wenn es größer als 10 ist, wird es auf 10 gesetzt. Zusätzlich wird, wenn der Gesamtupload kleiner als 1MB ist, der Modifikator auf Eins, wenn der Gesamtdownload Null ist, auf 10 gesetzt.

Was ist ein Uploadplatz?

Wird ein Dateistück hochgeladen, wird die Uploadbandbreite (die von der verwendeten Verbindung und dem eingestellten Uploadlimit abhängt) für einzelne Plätze aufgeteilt, so dass mehrere Blöcke zugleich an verschiedene Clients hochgeladen werden. Wie unter "Gibt es Grenzen im ED2k-Netzwerk?" nachzulesen, stellt jeder Client mindestens drei Uploadplätze zur Verfügung.