FAQ eD2k-Kademlia-nl

Veel gestelde vragen over eD2k-Kademlia

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

Wat is ED2K?

ED2K is een protocol dat oorspronkelijk werd gebruikt door de P2P (Peer-to-Peer) client eDonkey2000, waar de naam vandaan komt. Het is een server-client gebaseerd protocol, met de mogelijkheid om bronnen uit te wisselen tussen clients.

Het ED2K netwerk is server gebaseerd, dit in tegenstelling tot P2P netwerken als Kazaa, wat betekent dat het eerste ding wat u moet doen als u aMule draait is verbinden met een server (handmatig of automatisch).

Als u verbonden bent met een server, de client kan zoeken, lokaal (de server waarmee verbinding is) of globaal (alle servers), naar elk bestand en de servers waarop gezocht wordt zullen de client een lijst sturen van alle bestanden die voldoen aan de zoekopdracht.

Als de gebruiker een download start, zal de client de server vragen om bronnen, die de server zal sturen in de vorm van een IP adres van de clients die de server hebben verteld dat ze het specifieke bestand hebben.

Dan zal de client waarmee verbonden is beginnen met het uploaden van een heel blok op het moment dat u de eerste bent in de wachtrij, lees What_is_all_that_credits,_rate_and_score_stuff_about? en, als het blok compleet verstuurd is, gaat u terug naar zijn upload wachtrij. Zo verspreiden verschillende delen zich over het ED2K netwerk, zodat, hoewel niemand op een bepaald moment het complete bestand heeft, het compleet gemaakt kan worden door de verschillende blokken van verschillende mensen te downloaden (het is bekend dat gebruikers vaak stoppen met het delen van een bestand als het compleet is).
Let op: clients uploaden slechts één blok per keer naar een andere client. Zelfs als een client in de upload wachtrij van twee verschillende bestanden van dezelfde gebruiker staat en bij beide bovenaan aankomt, zal die gebruiker maar een van de bestanden uploaden naar die client (de andere upload zal, afhankelijk van het ED2K programma die de client gebruikt, blijven staan als een hoogste prioriteit upload, maar zal niet beginnen tot het ander blok succesvol is ge-upload).

Als beide gebruikers een Hoog ID hebben (zie What is LowID and HighID?) zal de overdracht direct van client naar client verlopen (Peer-to-Peer), maar als een van de clients een Lage ID heeft, zal de verbinden verlopen via de server, omdat Lage ID geen binnenkomende verbindingen kan accepteren. Het gevolg daarvan is dat twee Lage ID clients niet met elkaar kunnen verbinden.

Wat is Kademlia?

Kademlia is een natuurlijke evolutie van het ED2K netwerk. Kademlia is de toekomst. Zie Are there any limitations on the ED2K network? voor meer informatie over waarom Kademlia nodig is.

Omdat Kademlia een gedecentraliseerd netwerk is, haalt het de bottleneck weg die eerst veroorzaakt was door de noodzaak van servers (hoewel Lugdunum goed werk heeft gedaan bij het verminderen van deze bottleneck). Nu, in plaats van verbinden met een server, verbindt u met een client (met een bekend IP-adres en poort), die het netwerk Kademlia ondersteunt. Dit wordt Boot Strapping genoemd.

Als u verbonden bent krijgt u, afhankelijk van de mogelijkheid tot het accepteren van binnenkomende verbindingen, de status "open" of "firewalled", gelijk aan Hoog ID en Laag ID van het ED2K netwerk. Dan krijgt u een ID.

Op dit moment worden "firewalled" gebruikers niet ondersteund door het het Kademlia netwerk, en krijgen dus geen ID en kunnen niet verbinden. Firewalled ondersteuning wordt later toegevoegd.

Bij het zoken, dient elke client als een kleine server en krijgt verantwoordelijkheid voor bepaalde zoekwoorden of bronnen. Dit maakt het vinden van bronnen complexer omdat er geen centrale server meer is om aan te vragen, maar een zoekopdracht moet zich nu verspreiden via het netwerk.

Op dit moment wordt Kademlia niet ondersteund door aMule, maar dat zal binnenkort veranderen.

Is Kademlia het zelfde als Overnet?

Kort en duidelijk: Nee. Overnet is de natuurlijke serverloze evolutie van de eDonkey software, terwijl Kademlia de natuurlijke serverloze evolutie van *Mule clients is. Short and clear: No. Overnet is the natural serverless evolution of the eDonkey software, while Kademlia is the natural serverless evolution of *Mule clients. Dus, het heeft dezelfde filosofie, maar verschillende regels. Om te leren hoe Overnet werkt, kijk op http://www.edonkey2000.com/documentation/how_on.html, maar bedenk dat Overnets ontwikkeling gesloten is tot het versie 1.0 heeft bereikt, terwijl Kademlias ontwikkeling compleet open is sinds het begin.

Wat is een blok?

Om het delen van beschadigde bestanden te voorkomen in het ED2K protocol, wordt elk bestand verdeeld in meerdere delen, die bekend staan als blokken, en dan elk blok krijgt een hashwaarde (zie hieronder om te weten wat een hash is). Elk blok is 9,28MB groot, dus een bestand van 15MB wordt verdeeld in twee blokken (9,28MB + 5,72MB), een 315kB bestand is één blok en een 100MB bestand wordt verdeeld in 11 blokken (10x9,28MB + 7,2MB).

Wat is een hash?

Het opdelen van bestanden in blokken (zie What is a chunk?|Wat is een blok?) voorkomt het probleem dat een heel beschadigd bestand opnieuw gedownload moet worden omdat alleen het beschadigde blok opnieuw gedwonload hoeft te worden, maar een methode om beschadigde blokken te herkennen is nodig. Dit wordt gedaan met MD4 hashes.

Een MD4 hash is een unieke waarde die elk blok krijgt en is het resultaat van een wiskundige operatie op elke bit van het blok. Dit betekent dat het veranderen van één enkele bit in een blok een compleet verschillende hash oplevert. Daarmee is het mogelijk om te controleren of elk deel van een bestand correct is als het gedownload is.

Niet alleen de blokken worden gehashed, maar ook, om een bestandshash te krijgen, worden alle hashes van de blokken achter elkaar gezet in de volgorde van het bestand (dat wil zeggen: hash_van_blok1+hash_van_blok2+hash_van_blok3+...) en het resultaat wordt gehashed. Op deze manier krijgt elk bestand op het ED2K netwerk een unieke identificatiecode. De bestandshash wordt niet verkregen door het hele bestand te hashen, maar door het hashen van de waarde van de hashes van de blokken.

In werkelijkheid heeft u de hash van een bestand en de grootte nodig. Deze delen van informatie worden opgenomen in de ED2k URLs die op vele plaatsen te vinden zijn.

Bijvoorbeeld:
ed2k://|file|eMule0.42f-Sources.zip|2407949|CC8C3B104AD58678F69858F1F9B736E9|/

Het interesante gedeelte is het vijfde deel, "2407949", wat de grootte van het bestand is in bytes en het laatste deel, "CC8C3B104AD58678F69858F1F9B736E9", wat de hash is in hexadecimalen, 32 tekens lang.

De bestandsnaam is niet belangrijk bij het identificeren van het bestand.

Waarom verschijnen bij het zoeken sommige bestanden die gelijk zijn als verschillende bestanden in de zoekresultaten, ook al hebben ze zelfs dezelfde naam?

Als u "Wat is een hash" begreep is het makkelijk dit te begrijpen. Als een zoekopdracht begint, vertelt de server de ED2K client de bestandsnaam van de gevonden bestanden en de hash van het complete bestand voor elk bestand wat voldoet aan de zoekopdracht. Als twee bestanden, hoewel ze gelijk zijn, een verschil hebben in hun inhoud, groot of klein maakt niet uit, is de hash verschillend, dus worden ze beschouwd als een veerschillend bestand. Dat is ook de reden dat twee bestanden met verschillende bestandsnamen verschijnen als hetzelfde bestand: op het ED2K netwerk is de bestandsnaam niet belangrijk, de hash is belangrijk.

What is LowID and HighID?

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 big 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.
Check here if you have your ports opened.

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).

Are there any limitations on the ED2K network?

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).

What is all that credits, rate and score stuff about?

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 these two:
(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.