FAQ eD2k-Kademlia-de

Häufig gestellte Fragen über eD2k&Kademlia

English | Español | Italiano | Deutsch

Was ist ED2K?

ED2k ist ein Protokoll, das ursprünglich vom P2P (Perr-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 schiedenen 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.

What is 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.

Momentan wird Kademlia noch nicht von aMule unterstützt, aber das wird sich bald ändern.

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?

Each client is assigned an identifying number, an ID, which will be unique and will distinguish him from any other client on the server. If this ID is below 16777216 (16 million) then you have a LowID. If it's over, then you have a HighID. To be given a high or low ID will only depend on having TCP port 4662 (or the one set up in Preferences) opened. If you understood "What is ED2K" you might understand that chances are that clients on LowID may be unable to connect to many other clients (all those on LowID) so will have a lower transfer rate. That's why having port 4662 TCP (or the one set in Preferences) is so important. Also, some bug servers refuse clients on LowID to connect to them since LowID clients have data transfered through the server and so, those big servers could be overcharged.
For HighID clients, their ID is the result of a mathematical operation with their IP which corresponds to A + 256*B + 256*256*C + 256*256*256*D, where the IP is A.B.C.D. Also have in mind that this ID has identification purposes, nothing else, so apart from having and ID over or under the 16777216 number, it does not matter if the ID is bigger or smaller. This means a client with an ID like 50000000 isn't better than a client with an ID like 49999999.
There's still an exception. Sometimes badly configured or very busy servers give LowID to some clients although the 4662 TCP port is opened. This are rare exceptions, but it might happen sometime.

Which ports do I have to configure in a firewall or router to run aMule?

No specific ports need to be opened for aMule to work, but yes to have HighID. As mentioned above, to be given a HighID, port 4662 TCP (or the one set in Preferences) must be listening.
Apart from that port, to have an optimal ED2K experience, two more ports should be enabled too. First, the UDP port 4672 (which can be configured to any other number in Preferences too) and secondly, the secondary UDP port which can't be set in Preferences. This UDP port is your TCP port + 3 (i.e.: TCP=4662 then UDP=4665).

What does each port do?

Well, since most ports can be configured to be set to any other number, the defaults will be listed:

4662 TCP

Client to client transfers.

4672 UDP

Extended eMule protocol, Queue Rating, File Reask Ping

4661 TCP

Opened on server. Allows connection to server.

4665 UDP

Opened on server. Allows asking for sources. It is always server TCP port + 3.

4711 TCP

WebServer listening port.

4712 TCP

External Connection port. Used to communicate aMule with other applications such as aMule WebServer or aMuleCMD.

Although officially the secondary UDP port is server TCP port + 4, some (most?) implementations use it as client TCP + 3. Any way, this port is mostly not used (aMule doesn't use it, eMule doesn't have it).

Gibt es Grenzen im ED2k-Netzwerk?

Not much, but yes, there are: two natural limits and a "forced" limitation. The two natural limits have already been mentioned before. First, the issues on LowID users (their transfers involve data through the server and two LowID clients can't share between them). The second, although ED2K is a p2p protocol, it needs servers to establish the p2p connection. This latter one is solved in the Kademlia protocol.
About the "forced" limitation, it's only a limit to make sure that clients share so that the ED2K network will not disappear: clients which have an upload limit of X KBps, where X is between 0 and 3.99 (both included) can download at a maximum of X*3 KBps. Clients which have an upload limit of Y KBps, where Y is Between 4 and 9.99 (both included) can download at a maximum of Y*4 KBps. Clients with an upload limit of 10KBps or more have no downloading limitations. This restriction is set in the client application so it could be by-passed by hacking the code, but that would probably result in being banned from the servers you connect to.
Also, any client is forced to allow at least three upload slots, so it's not possible to allow more than upload_limit/3 KBps per slot.
There is one last limit: Network file limit is 4Gb.

In search window, what filter stands for which filetype?

Have in mind that the filters in the search window don't depend on the file type, but on the extensions of the filenames, in the following way:
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
Picture: .bmp .gif .jpeg .jpg .png .tif
Program: .com .exe
Video: .avi .divx .mov .mpeg .mpg .ogg .ram .rm .vivo .vob
So, a movie which's filename is "Birthday.zip" will appear in the Archive filter, but not in the Video filter.

What is a source?

A source is a client which is sharing some chunk in some file you have in your downloading queue which you still have not completed. Obviously, the more sources you can get for a given file, the more possibilities you have to download the file and the quicker you'll download it. Have in mind that there's a difference between "sources" and "available sources" if you're on LowID, since "sources"s stands for clients sharing a chunk or file you still haven't completed, while "available sources" stands for clients sharing a chunk or file you still haven't completed and from who you can download (that is, a sources who is on LowID).

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

All three concepts have to do with the way in which the ED2K network establishes the uploading queues preferences.
The score is the most important value: the client with the higher score will be the next client which you'll provide a slot to. The way in the score value is set is this: score = rate x time_waiting_in_seconds / 100 So, to understand this, we must known what rate is.
Rate is can be understood as an objective preference. This is, the preference which a client is given without caring how much time it's been waiting. When a client is added to the uploading queue, it gets a rate of 100. This value is modified following according to this:
According to the amount of credits, the rate will be multiplied by 1x to 10x. Depending on the file priority, it will be multiplied by 0.2x to 1.8x (Release 1.8x, High 0.9x, Normal 0.7x, Low 0.6x, Very Low: 0.2x).
Users on specific old clients which load too much the network traffic will get penalized by multiplying their rate by 0.5x.
Banned clients will instantly get no rate (that is, their rate will by multiplied by 0).
This multiplying values are known as "modifiers". Clients with a modifier value strictly bigger than 1 will be marked as yellow in the icon.
So we only have credits left to known. Credits are a prize you get for uploading files to a specific user. Credits are exchanged between two specific clients, they are not global, so your own credits can't be viewed, although you can know the credits any other user has on you (that is, the credits you owe that client). Since credits are managed by the uploading client, you might be uploading to some client with no credits support, so you will gain no credits on him, although that client will actually get credits on you if it uploads to you, since you do have credits support. This credits are stored in clients.met file.
The credits modifier used by rate is the lower between this to:
(upload_total x 2)/download_total or sqrt(upload_total+2) where both upload_total and download_total are measured in MBs.
If the result is lower than 1, then it is set to 1 and if it is bigger than 10, it is set to 10. In addition, if the uploaded total is less than 1MB, the modifier is set to 1 and if the downloaded total is equal to 0, then the modifier is set to 10.

What is a slot?

When uploading files, your upload bandwidth (which may vary depending on the upload limit or the natural connection-type upload limit) will be divided into slots. So, each slot is an amount of KBps which will be assigned to each client who tries to download from you.