Difference between revisions of "FAQ eD2k-Kademlia-de"

Revision as of 14:00, 24 September 2008

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 (entweder manuell 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 Chunk der Datei heraufzuladen und, wenn dieser 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 Chunk 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 "Bootstrapping".

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, und ab Version 2.1.0 ist die Kademlia-Unterstützung offizieller Bestandteil des Clients.

Sind Kademlia und Overnet gleich?

Kurz 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 Chunk?

Im eD2k-Protokoll wird jede Datei in mehrere Teilstücke, auch "Chunks" genannt, zerlegt, und dann deren jeweils eigene Prüfsumme (Dateihash) ermittelt, um die Weitergabe schadhafter Dateien zu vermeiden (man beachte dazu auch Was ist ein Hash?). Jeder dieser Chunks ist 9.28MB groß, was bedeutet, daß eine 15MB große Datei in zwei Chunks (9.28MB + 5.72MB) aufgeteilt wird, eine Datei von 315KB in einem Stück bleibt, und eine Datei von 100MB wiederum in 11 Teile (10x9.28MB + 7.2MB).

(Anm.: Diese Teilstücke wurden früher auf Deutsch auch "Block" genannt, was aber zu Verwechslungen führen konnte, da ein Block wiederum ein 180KB grosses Teilstück eines Chunks ist. - Man beachte dazu auch diesen Beitrag.)

Was ist ein Hash?

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

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

Aber nicht nur für die Chunks 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 Chunks 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 Chunkprüfsummen 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 Stellige hexadezimale Zahl.

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üssen keine speziellen Ports für aMule geöffnet werden.

Abgesehen davon sollten, um eine optimale Transferleistung zu erreichen, Port 4672 geöffnet werden. Für ausgehende Verbindungen sollte der Router dynamische Regeln erstellen um eingehende TCP/UDP-Pakete einzulassen. Die meisten modernen Router/Firewalls machen das schon in der Standardkonfiguration.

ab Version 2.1.0: Für eine komplette Kademliaunterstützung sollte sichergestellt werden, dass Port 4672 für ausgehende Pakete vom Router nicht geändert wird. Ansonsten kann es sein, dass 'Kad: firewalled' angezeigt wird. Das passiert vor allem, wenn NAT (Network Address Translation) genutzt wird, d.h. der Rechner eine eigene private Adresse hat (meist 10.?.?.? oder 192.168.?.?).

D.h. mit /sbin/ifconfig herausfinden, welche IP der Rechner hat und diese im Setup des Routers eintragen, wenn dort die entsprechenden Ports freigegeben werden.

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 Beschränkungen 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 untereinander austauschen) und zweitens, obwohl ED2k ein Peer-to-Peer-Protokoll ist, werden Server benötigt, um die P2P-Verbindung aufzubauen. Daraus resultieren viele Probleme, bezogen auf Flaschenhälse, Datenschutz, und Skalierbarkeit (wenn ein einziger Server wegbricht, wird mit ihm ein großer Teil des Netzes ebenfalls getrennt). 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.

Es gibt noch eine weitere Begrenzung: Die maximale Dateigröße im Netz beträgt 256GB (274877906944 bytes). Die ältere Begrenzung (bis zu eMule 0.46 und aMule 2.1.0) lag etwas unter ca. 4GB (genauer: 4294967295 bytes, obwohl aMule nur Dateigrößen bis zu 4290048000 bytes unterstützte).

Zusätzlich, und zwar nicht als eD2k-Beschränkung, sondern als Begrenzung durch die Server, liefern diese nur 300 Ergebnisse pro Suchanfrage, von daher sollte man auch nicht mehr als 300 Ergebnisse erwarten.

Vom Client her werden Dateinamen normalerweise auf 161 Zeichen begrenzt.

Gibt es Beschränkungen im Kademlianetzwerk?

• Weil es sich aus dem eD2k-Netz ableitet, gilt auch im Kademlianetzwerk zur Beibehaltung der Kompatibilität bei der einheitlichen Dateienbestimmung die Begrenzung der Dateigröße auf höchstens 256GB.
• Gleiches gilt für die Begrenzung auf 161 Zeichen.

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 Chunk einer Datei anbietet, die in der eigenen Downloadliste steht. Je mehr Quellen man für eine Datei bekommt, desto 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 Bewertung gebremst.

Verbannte Clients bekommen keine Bewertung (bzw. ihre Bewertung 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, 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 Chunks 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.