eDonkey2000 (network)

Files on the eDonkey network are identified by using the root MD4 hash of the sum of the MD4 sum of the parts of the file. This allows you to consider the same file with different names, but the same content, and to distinguish files with different contents, but the same name.

Searching for files on the eDonkey network is carried out by keywords included in the file names and some additional characteristics, such as file size, its extension, bit rate, etc. The search result returned by the server is a list of file names with a corresponding MD4 root name the sum of the found file, the IP address and port of the client for which at least one part of this file is available for download.

Each client is associated with one of the network servers. The client tells the server what files it shares with (these files include both files explicitly shared by the user through the client program interface and files that the client itself downloads or has already downloaded from other clients, but not deleted a user from the client program’s download list. Each file downloaded by the client is automatically shared as soon as at least one part of it is received). Each server maintains a list of all shared client files connected to it. When a client searches for something, it sends a search request to its main server. In response, the server checks all the files that it knows, and returns to the client a list of files that satisfy its request.

You can search multiple servers at once. Such requests and their results are transmitted via the UDP protocol in order to reduce the channel load and the number of connections to the servers. This function is especially useful if a search on the server to which the client is currently connected gives a low result.

To simplify file searches, some websites publish MD4 sums of files as an ED2K link . Some of these sites also contain lists of active servers for updating lists by users.

File download is based on the principles of the network protocol of the application layer MFTP and occurs without the participation of the server. A client who wants to download a file receives information about the availability of parts of this file in the public domain from other clients using the search results on the server, and connects to such clients directly by the received IP address and port. To identify the requested file, the root MD4 hash is the sum of the file also contained in the search results. In addition to the hash amount, the download request includes the initial and final offset of the required part of the file. The client sends requests to download parts of the file that it does not have to other clients that have these parts until it collects the complete file from these parts. Contacting other clients independently of each other so that different parts of the file can be downloaded from different clients at the same time, which speeds up the file download. Upon the initial receipt of any part of the file, the downloading client informs the search server that this file is partially available from other clients for downloading. This property of the protocol is one of the fundamental principles of decentralized download-distribute networks and serves the purpose of increasing the number of available file sources for other clients. When deleting a file from the list of downloaded files, parts of such a file are no longer available for download to other clients.

Periodically, the servers communicate with each other for a short time. During this communication session, the server, announcing its existence, sends a list of all other servers known to it. Thus, the servers maintain a list of other active servers. When a client connects to a server, the server can give it a list of servers known to it.

The hash algorithm used to calculate the identifier (root MD4 sum) of the file:

1. Files are divided into equal pieces of 9,728,000 bytes (9500 KB) and the remainder.
2. For each piece, a 128-bit MD4 hash is computed.
3. If the file size is a multiple of 9,728,000 bytes, that is, the size of the remainder is 0, the amount for this empty remainder is still calculated.
4. Then, all calculated amounts are combined into one single array (hash list) and the MD4 hash is calculated as the sum of this entire array. This sum is the root MD4 sum of the file — and the identifier on the eDonkey network.
5. If the file size is less than 9 728 000 bytes, then the hash list is not compiled, and the file identifier is the MD4 hash sum of the entire file.

There is a second version of the algorithm for calculating the checksum of files that give a different result for files that are a multiple of the size of the section, that is, with sizes of 9 728 000 bytes, 19 456 000 bytes, etc. The original algorithm (used in eDonkey2000 up to version v0.5.0 ) contains an error (feature) due to which the checksum of an empty section is added for files with sizes that are multiples of 9 728 000 bytes. Not all programs take this feature into account in calculations (for example, eMule takes into account, but Shareaza does not). In eDonkey2000 from version v0.5.0 to version v1.4.3, this "feature" is fixed.

Differences from the original algorithm are as follows:

1. If the file size is less than or equal to 9,728,000 bytes, then the MD4 sum of the entire file is used as an identifier.
2. If the file size is a multiple of 9,728,000 bytes, then the checksum of the "empty" balance is not added .

The differences between the algorithms are so minimal (and arise only at the end of the calculation of the amount), which allows you to calculate both amounts at the same time - almost without loss of performance. The second version of the sum for such “special” files can be indicated, for example, in the comments (the avdump program does this ).

Here, for example, checksums for files consisting of the same zero codes for different "variants" of the algorithm. You can get them (files), for example, with the bash command for unix-systems:

  for i in 1 2 3; do dd if = / dev / zero of = zero $ i bs = 9728000 count = $ i; done

Used for sharing files and publishing on portals.

Example ^[2] :

  ed2k: // | file | [File name] | [File size] | [ ed2k file hash ]
 |  h = [ AICH file hash] |  p = [ Md4 hash of the 1st part]: [ Md4 hash of the 2nd part]: ...
 |  s = [ URL link to file] | / |  sources , [Source IP Address]: [Source Port ] | /

Most often there is a short look.

  ed2k: // | file | [File name] | [File size] | [ ed2k file hash ] | /

• The file name is recommended to URI -encode.
• File Size - The exact size in bytes.

h - AICH (Advanced Intelligent Corruption Handler)

Extra hash for ed2k links. Uses smaller parts to produce a hash. This allows you to examine the file in more detail to find and fix errors, and reduces the amount of data needed to restore the file.

It is recommended to publish it along with the link, then it immediately becomes a trusted hash and can immediately be used to restore the file. If you do not publish it with the link, then the client will need to get the same AICH hash from several sources before this hash is considered reliable.

AICH Hash Calculation

To obtain a hash, the standard ed2k chunk (9,728,000 bytes) is divided into 53 parts (52 to 180 KB and 1 to 140 KB). Each part is later processed by the sha1 algorithm. Next, the hash pairs again pass through the sha1 algorithm until one single hash is obtained.

p - MD4 hash set

This field lists the MD4 hashes of ed2k chunks through the colon ":". Allows you to check the parts for compliance, even if there is no way to get a set of hashes in another way, for example, if the only source file is a URL link .

s - URL

Allows you to download the file using the URL link if there are no ed2k sources. Typically, servers are constantly available, unlike ed2k sources, which are mainly personal computers connected to the Internet. Due to this, the initial download occurs from the server, and further distribution is already on the ed2k network, which offloads the server and increases the availability of the file.

Before insertion, the link must be URI- encoded.

sources - sources

Lets you specify ed2k sources that you can access to download the file. This makes it possible to start downloading the file without connecting to the ed2k server by simply connecting to the listed sources directly.

It makes sense to use this field only if the source has a constant IP address.

Collections

For publication on portals, links can be combined into collections .

• Lugdunum server - server software of the eDonkey2000 network. Most ed2k network servers run on Lugdunum . It is more scalable and efficient than the original MetaMachine eDonkey server.

• eMule is the most common free eDonkey2000 network client for Windows
• iMule - cross-platform , secure, anonymous client for I2P and Kad networks
• mlDonkey is a free, open source cross-platform client
• aMule is a cross-platform client developed on the basis of xMule, lMule and eMule
• JMule is a client for the eDonkey2000 file-sharing network written in Java .
• lphant - a free cross-platform client
• Shareaza - a free client for Windows that supports multiple P2P networks

• Official site . Closed (stopped work) (eng.)
• Description of the eDonkey Protocol at the Hydranode Project
• Description of the eDonkey protocol at the pDonkey project
• Download movies, music and programs from the Internet. Peer-to-peer networks eDonkey, BitTorrent, KaZaA, DirectConnect. Per. from Czech Rus ed. under the editorship of M.V. Finkova. St. Petersburg: Science and Technology, 2006 .-- 272 p., Ill. ISBN 5-98378-245-0 (Russian)
• Ed2k_hash Algorithm
• eDonkey make-believe closed at compulenta.ru (September 13, 2006 )
• RHash is a console Open Source program that calculates ED2K and AICH hashes and EDonkey links.