EMule

eMule (pronounced: /ˈiːmjuːɫ/) is an exchange program of files with a P2P system using the eDonkey 2000 protocol and the Kad network, published as free software for Microsoft Windows systems. It is written in C++.

Created at first as an alternative to the eDonkey program, in a short time it surpassed it in functions, and adding the fact that it was free and free, among other reasons, they managed to surpass it in popularity in a short time to become one of the programs most used by P2P users. There are also multiple derived programs with the aim of porting it to other operating systems, such as lMule, xMule or aMule.

History

The eMule project was started on May 13, 2002 by Hendrik Breitkreuz (also known as Merkur) who was not satisfied with the original eDonkey2000 client. His name is an apocope of electronic mule , in English literally electronic mule, referring to the eDonkey from which it originates ( electronic donkey ).

Over time, seven more developers joined the project. The source code was first published as version 0.02 on SourceForge on July 6 of the same year. eMule was first released as a binary on August 4 in version 0.05a. The 'credit system' was first implemented on September 14 in version 0.19a. The project website was launched on December 8. Since then, eMule has been downloaded around 300 million times (May 2007 figures). In 2010, version 0.50a was released, which was the last stable version and which is the one maintained by the majority of current users. However, a beta of version 0.50b with minor changes was released on March 20, 2015. Subsequently, a version 0.51d has been published on the official website which is based on the latest official version and contains additional features and bug fixes made by the community.

As of mid-2006, the project consisted of sixteen people: two developers, two project coordinators (including the founder, Breitkreuz), three testers, and nine debuggers. The official site is maintained by seven developers and four moderators or administrators.

On August 14, 2020, user "fox88" posted version 0.60a beta in both its 32 and 64-bit versions on the forum. It should be noted that this beta is not a "release" official. Version 0.60c was released on May 13, 2021.

General information

The eMule network consists of hundreds of eMule servers and millions of eMule clients. In this network the clients have to connect to one of the servers to get the network services, this connection to the server will remain open as long as the client is in the system. These servers perform a centralized indexing service and do not communicate with other servers.

Example network Emule

eMule clients have the following characteristics:

• They are preset with a list of servers and a list of shared files on your local file system.
• They use a TCP connection to an Emule server to register on the network and get information about the desired files and available customers.
• Use hundreds of TCP connections to other customers to upload or download files.
• Each has a upload queue for each of the shared files. To download a file the customers join that queue at the bottom and advance slowly until they reach the top of the queue to download the file.
• You can download the same file from several eMule customers, getting different fragments(chunks) from each.
• You can upload a fragment of a file just download it even if you do not have all the other fragments to complete the file.

The server has the following characteristics:

• It uses an internal database where information about customers and files is stored.
• It does not store any file, acts as a centralized index to store information about the location of the files.

eMule extends the capabilities of eDonkey by allowing clients to exchange information about servers, other clients and files. Client and server communicate using TCP. eMule uses UDP to improve capabilities from the client to the server and other clients.

Client-server connection

When starting the connection, the client connects to the eMule server, through TCP, which provides the client with an ID that will only be valid during the connection time between them. The TCP client-server connection is kept open throughout the client session. Once this connection has been established:

• The client sends to the server:
  • Your list of shared files and the server stores it in your internal database, which will have saved those of all your active customers
  • Your list of files to download
• The server sends the client a list with clients who have the files that the client connects wants to download (they are the so-called sources).
• The eMule client begins to establish connections with other customers.

After the initial establishment, connections are activated based on user activity, from time to time the client sends file search requests and receives the results of those requests. A lookup transaction is usually followed by a query for the file's sources which in turn is responded to with a list of sources from which it can be downloaded (IP and Port). For communication with other servers (other than the one to which it is connected) the client uses UDP. UDP messages are intended to improve file lookup and ensure that all servers on the client's list are valid.

Client-client connection

An eMule client connects to another eMule client to download a file. This file is divided into parts that are fragmented. A client can download the same file from several different clients, getting different chunks from each of them.

When two clients connect, they exchange capacity information and then negotiate the start of the download (or upload, depending on where you look at it). Each client has a download queue with a list of clients waiting to download files. When the client's download queue is empty, the download is more likely to start. If it is not, when a new download request arrives it is added to the end of the queue. When it reaches the head of the download queue, the client that has the file (source) initiates a connection to send it the parts of the file it needs. A client can be waiting in the queue of several source clients at the same time, to download the same parts of the file. When the client finishes downloading on one of them, it does not notify the others, it simply rejects their connection attempt when it reaches the head of the queue.

eMule implements a credit system to benefit clients who upload more files, to avoid spoofing eMule implements a public key system based on RSA.

The client connection may use a set of messages that are not defined in the eDonkey protocol, known as the extended protocol. It is used for the implementation of the credit system, general information exchange (update of server lists, sources) and to improve performance by sending and receiving fragments of compressed files. The eMule client connection uses UDP in a limited way to periodically check the status of the client in the upload queue of its client peers while it is waiting to start downloading a file.

Features

• Direct file exchange between your customers.
• Quick recovery of corrupt parts.
• The complementary use of a network without servers, called Kademlia, of promising expectations; also in some mods (as modified) the use of the Webcaché option has been implemented as an extra and help method to download files (see eMule MorphXT).
• The fact that, being licensed under GPL, any user can collaborate and modify it freely, is why they have proliferated a whole series of modifications (mods) of the program, such as eMule MorphXT, Xtreme, Phoenix, Plus or NeoMule. There are even independent projects based on their code as eMule clients for other operating systems, such as aMule, which runs under the GNU/Linux and Mac OS X system All this contributes to a continuous improvement of both the original program and its derivatives.
• Use a credit system that the most downloads the network, although it can also work with this deactivated system.

Credits allow you to move faster in a customer's queue, so that you can get a suitable position to unload sooner. Since the credits are registered in a decentralized way in each of the users of the network to prevent them from being falsified, we will only have credits in the users to whom we have uploaded a file (although since they only affect the progress in the queue of wait, we can download from a user to whom we have never uploaded a file). Each user downloads parts of a file (which may be being downloaded at that moment from other users) that are assembled to form the complete file. This P2P network is especially useful when the files to be downloaded are large. Another of the advantages of this network is the possibility of finding very rare files.

• Its wide implementation, as well as its decentralized nature, has been preferred by most users, ready to “share contents”. These same cases have raised the controversy over the need or not of international legislation to ensure the defence of intellectual property rights and to punish acts that might violate them.
• It has the possibility of sending messages to eDonkey 2000 users connected to current downloads and an IRC chat on the MindForge network to find information about what interests users and receive support on official help channels.

Key Features

• Protocol obscating. This function (implemented for the first time in version 0.47b) serves to prevent eMule connections from being detected and blocked by ISPs. Protocol Occination is a feature that makes eMule hide its protocol by communicating with the server or other customers. Without obscure, each eMule communication has a default structure that can be easily recognized and identified by an observer. If this feature is activated, all eMule communication appears at first sight to be composed of random data and it is no longer possible to easily perform an automated identification. This helps in situations where by identifying packages the eMule protocol is unfairly discriminated against or even completely blocked. We must not confuse it with a way of providing anonymity or "invisibility", nor does it have to fully protect against observers with sufficient means and time. Furthermore, if the network administrator has a good legal reason to block eMule (e.g. a restricted business network), jumping the restriction can cause other undesired consequences.
• Share chunks. Files can be shared even if they are not completely down. Once a user has a part of 9500 KB that has been verified, eMule puts it at the disposal of the rest of the network.
• Detection of errors. eMule uses error detection algorithms. This way it is almost impossible for the files to be corrupted. The AICH system (Advanced Intelligent Corruption Handling) uses the method Hashtree to fragment into pieces of 180 KB file, greatly decreasing the amount of data to be downloaded to correct a transmission error.
• Compressed transfers. Each time eMule transmits data, it compresses them with the zlib library to save bandwidth, in a completely transparent way to the user.
• Independence of file names. In other programs, when a file is renamed, it is no longer considered the same. eMule instead allows to change the names, because it uses a system that recognizes the files by their contents and not by the name, so you may download something that does not correspond to the name. You can consult all the names assigned to the same file.
• Credit and queue system. It rewards users who have uploaded more data by giving them more priority when making progress within the waiting line. Modifiers are calculated based on the amount of data transferred between two customers, which directly affects the valuation of customer requests and their position in the queue.
• Comments for files. eMule allows you to qualify the quality of a file and write comments about each file making other users read them. Thanks to the use of the Kad network, you can search for comments of files even before you start downloading it, thus knowing in advance if the file has good/bad quality or if it is corrupt.

Icon	Meaning
	Not commented
	Excellent.
	Okay.
	Regular
	Poor
	No Valid / Corrupt Fake

• Collection files. eMule allows you to create files in a special format named eMule collection. This file contains a set of eMule links. It is possible to download it as a set and save the entire collection of files as a set, although each download is managed independently.
• Address filter. eMule has the possibility of prohibiting any type of access by certain IP addresses. The list of these addresses can be automatically maintained by eMule. The purpose of the address filter is to prevent the download of false files (fakes) or filter addresses considered non-gratas. The use of the address filter does not improve the anonymity in the use of eMule, since it is essential that the program know the customer's address with which it makes a transfer.
• Preview multimedia files. eMule allows the viewing of various types of files, such as audio and video, although the file has not been downloaded completely. From the official website the VLC media player is recommended, although it can be configured to use any other program.
• IRC client. eMule includes a chat client on the official IRC network MindForge.
• Web server. eMule includes a web server. Once activated by the user you can control the basic functions of eMule from any web browser, from anywhere in the world.
• Multilingual. eMule can work in many different languages including Spanish. Thanks to the implementation of the Unicode, eMule can operate in any language, including the ideographic languages, and the writings from right to left.

eMule has been designed to work better with large files like ISO images, video and audio files, etc. A file is considered large if it is larger than 10 MB and small if it is less. For this reason it is better to group small files using compression programs. The most used are WinZip, 7-Zip and WinRar

It must be taken into account that if eMule is used in a configuration that includes a router, it is necessary to open the corresponding ports to improve connectivity with the rest of the nodes.

How networks work

Currently, eMule has two networks: the classic network based on eD2k servers and a decentralized network (Kad) that does not use servers and is based on Kademlia. The basic operating concepts are explained below, and later how each of the two networks achieve these objectives.

Client ID

The client ID is a 4-byte identifier provided by the server at the time the connection is established. A client ID is valid for as long as the client-server TCP connection is active. Client IDs can be high and low.

• A grant High ID to customers that allow other customers to connect to the eMule TCP port on their machine (port 4662 by default). High IDs are calculated as follows: assuming the IP address of the computer is X.Y.Z.W the ID will be X+2⁸·Y+2¹⁶·Z+2²⁴·W. A low ID is always less than 16777216 (0x1000000). If a customer has a high ID, all servers will assign the same ID until the customer changes the IP address.
• The eMule server assigns a Low ID customers who cannot accept incoming connections. When the server cannot open a TCP connection to the port that employs eMule on the client, it receives a low ID, this usually happens when the client is connected to a firewall. A customer can also receive a low ID in the following cases:
  • When the customer connects through an NAT or proxy server.
  • When the server is busy.

Having a low ID restricts the client from using the network and the server may refuse to connect to it. A client with a low ID has no public IP with which other clients can connect to it, therefore any communication has to be done through the eMule server. A low ID client cannot connect to another low ID client if both are on different servers, because the servers do not communicate with each other. To help clients with a low ID, a mechanism is used by which the client can request through the server to connect with a low ID and thus be able to exchange files.

User ID

The user ID is 128 bits (16 bytes) created by a concatenation of random numbers, the 6th and 15th bytes are not randomly generated, their values are always 14 and 111 respectively. While the client ID is only valid during that session with a specific server, the user ID (also known as the user hash) is unique and is used to identify that user each time a new session is started (the client ID). user identifies the connecting machine). eMule relies on a credit system to encourage users to share files. The greater the number of files shared with other clients, the greater the number of credits received and the faster progress is made in their waiting queues.

The user ID plays an important role in the credit system, which encourages hackers to impersonate other users to benefit from their credits. eMule supports an encryption scheme designed to prevent fraud and user spoofing. The application is a simple challenge/response exchange that is based on RSA public/private key encryption.

File ID

eMule does not use the file name to uniquely identify and catalog it. A file is identified by a unique ID by hashing the contents of the file. There are two kinds of file ID:

• The first is mainly used to generate the unique file ID
• The second is useful for detecting and recovering corrupt files.

Hash of files

Files are uniquely identified by a 128-bit ID calculated by the client based on the content of the file. The ID is calculated by applying the MD4 algorithm to the data file. This value is called a file hash and is found on all eD2k links. This Hash is calculated by dividing the file into parts of 9.28 MB. For each of these parts a Part Hash is calculated using the same MD4 algorithm. These Hash Parts, called a hashset, are used to calculate the File Hash.

ICH (Intelligent Corruption Management)

When a downloading client finishes downloading a part of the file, it checks if the data that was downloaded matches the Part Hash. If they match, that part becomes available to other clients and thus helps their distribution. If they do not match, a corruption problem occurred and the file part has to be downloaded again. To avoid having to download the 9.28 MB, ICH downloads the 180 KB from the beginning of the part and rechecks that part to see if the Part Hash is now correct. If not, the next 180KB is downloaded and that part is checked again, that process is repeated until the Part Hash is correct. As an average ICH allows to avoid downloading again 50% of the data when a corruption occurs in the part.

AICH (Advanced Intelligent Corruption Management System)

ICH is effective, but has some limitations in that it can only check 9.28 MB chunks. If a malicious client continually sends corrupted data or even forges a Party Hash, ICH becomes ineffective. Due to this AICH arises that helps to obtain a complete data integrity, in addition to the reduction of load since the hashes that are calculated are now smaller. In this case the starting point is the 9.28 MB parts. Each of these parts is divided into 180 KB blocks, in such a way we obtain 53 blocks for each part and for each block a hash is calculated using the SHA1 algorithm. These hashes are called Block Hash. These hashes are going to be combined to obtain partial hashes, and they continue to be combined until they reach a single hash that is a combination of all the others, which is what we call the Root Hash. The set of all hashes that have been computed is the AICH Hashes Set. When eMule detects a corruption it requests a recovery package from a random client that has a complete set of AICH hashes. This packet contains the 53 Block Hashes of the corrupted party and some verification hashes. After receiving the recovery packages eMule checks the verification Hashes with its trusted Root Hash. If they match, eMule checks the 53 blocks of the corrupted part against the Block Hashes from the Recovery Package, the AICH restores all blocks that match its Block Hash and leaves only those corrupted blocks for re-downloading.

• Data download. Once a customer has found a source for downloading a certain file, they contact to order a site in their download queue. The source reserves a site in its tail, which must be kept contacting the source periodically (it is required once every half hour). When the position in the queue reaches the first place, the source opens a connection with the client to proceed to upload the file.

Credit system

The credit system is used to reward users who contribute to the network, for example by transferring to other customers. eMule's strict queuing system is based on how long a user has been waiting. eMule calls the multiplier that modifies the number that a client gets in a request queue a “modifier”. The credit system applies the modifier to this waiting time taking into account the uploaded and downloaded data between the two clients. The higher a customer goes, the faster they move up the queue. The modifier is calculated taking into account the amount of data transferred between the two clients. The values used can be seen in the customer details dialog. There are two different modifiers calculated:

 Ratio 1= (Total uploaded x 2)/(Total downloaded)

Unless Total Downloaded is 0, in which case Ratio1=10

 Ratio 2= RaízCuadrada (Total subido+1)

The two calculated ratios are compared and the lower one is used as a modifier under certain conditions:

• Total subside ≤0,000 B = 2005 Modifier = 1.
• The modifier cannot be less than 1 or more than 10.

Server network

To connect to this network you need to know the IP address of the server. Once connected to a server, it can inform us of the existence of other servers. In order to keep this list up to date, the servers are connected to each other. When a node connects to a server it tells it which files it wants to share. To search for a file, the query is sent to one or more servers. Each server responds with the list of files it has. To know the sources of a given file, this information is requested from one or more servers. Each server responds with a list of nodes that share the requested file.

The list of servers presented by eMule can be updated, allowing more precise and extensive searches and finding faster servers, among other things.

There are fake servers that are dedicated to collecting information about who shares each file. For this reason it is recommended to obtain server lists from reliable sources. Downloading a list of servers can be done automatically.

Red Kad

The Kad network is a fully decentralized network where all nodes are equal. This makes it easier for eMule to survive a possible server network crash. To connect to this network you need to know the IP address of another node, but it is possible to connect from the nodes obtained from the network of servers. Each node knows a small part of the network, so the size of the network can grow as much as needed without affecting performance. When a node connects, it stores the identifiers of the files it wants to share within other nodes, chosen based on the file identifier. When you want to download a file, you locate the nodes that index it and these nodes return the list of sources for this specific file. Search by name works in a similar way, saving the file name inside other nodes chosen based on each word of the name. A search in Kad always runs on the entire network.

Client-server communication

Connection establishment

The client can try to connect to several servers in parallel, but when it establishes a connection to one it drops the others. There are several cases of connection establishment:

• High ID connection, the server assigns a high ID to the client that is connected.
• Low ID connection, the server assigns a low customer ID that is connected.
• Log down, the server rejects the client.
• There is also the case in which the server is fallen or inaccessible.

The following figure describes the message sequence that occurs on a high ID connection. The client establishes a TCP connection to the server and then sends the login message to the server.

The server connects to the client through another TCP connection and performs a client-client connection establishment to make sure that the client has the ability to accept other eMule clients. After completing the client establishment, the server closes the second connection and completes the client-server connection establishment, sending the ID change message. The following figure describes the message sequence that produces a low ID connection.

In case the connection has a Low ID, the server cannot connect to the client and assigns a low ID. The server usually responds with a warning message, telling you that it is assigned a low ID and to check your network settings.

Both establishments, with high or low IDs, are completed with the change ID message that assigns the client a client ID for its session with the server. The figure shown below would be that of a rejected session.

Servers can reject sessions if the client has a low ID or if its capacity limit is reached. The server message will contain a short description with the reason for rejection.

Exchange connection initiation messages

After a successful connection is established, the client and server exchange various configuration messages. With these messages, both parties are informed about the status of their peers. The client starts by offering the server its list of shared files, and then asks to update its list of servers. The server sends its status and version and then sends its list of known eMule servers.

Finally, the client requests sources (other clients it can access to download the files in its download list) and the server responds with a series of messages, one for each file in the download list. client downloads, until the entire font list has been downloaded to the client. The following figure shows this process.

File Search

The user initiates the file search. A search request is sent to the server and is responded to with a search result. When there are many results, the results are compressed.

The user then chooses to download one or more files, the client requests fonts for the chosen files, and the server replies with a list of fonts for each of the requested files.

Optionally you can send a message with the status of the server, indicating the number of users and the files supported by the server.

There is a complementary UDP message sequence that improves the client's ability to locate fonts from its font list. The order in which the sources are contacted is the same in which they are received by the client.

The eMule client connects to sources in the order in which they have been added to its list, there is no priority mechanism. The figure shows the sequence.

There are some complex mechanisms that deal with the situation when the same source has multiple files than are listed. The selection algorithm is based on the user's priority specification and in case of default by alphabetical order. A fine-tuned search is better, as general searches put a considerable load on the servers. For this reason, eMule only looks for a maximum of 201 results from any search, or 300 if the server and our version support gzip compression.

eMule allows us to use different search options, such as the maximum or minimum size, the file types, etc. One of the options that we can select is the search method, that is, the way that eMule will use to do the searches. There are five methods:

• Automatic. Determine automatically the search type (Server or Kad network) according to the connection of the server to which it is connected.
• Server. It will only be searched on the server where the client is currently connected.
• Global (Servidor). All the servers on the list are asked, but each individual.
• Kad. It's all over the Kad network. This method will not be searched on the eD2k network. Results may take a while. If a popular search expression does not return results, then the UDP port may be blocked by a firewall or router.
• Filedonkey. Web-based search engine (no longer exists).

There are web pages with links in the format ed2k:// (commonly called elinks). Clicking the mouse button on one of these links automatically adds the download to eMule.

Callback Mechanism

This mechanism is designed to overcome the inability of low ID clients to accept incoming connections and share their files with other clients.

In case clients A and B are connected to the same eMule server and A needs a file that is located in B. If B has a low ID, A can send the server a callback request, asking it to ask B to call you back. The server, which already has an open TCP connection to B, sends a callback request message, giving A's IP and port. B can connect to A and send the file to A with no further overhead on the server.

Only a client with a high ID will be able to request a client with a low ID to call back. The following figure shows the exchange of messages.

There is also an option that allows two low-ID clients to prioritize file sharing over their connection to the server, using the server as a relay. Most servers do not support this option due to the overhead it incurs.

Status information and if the server is kept alive

The client periodically checks the status of the servers it has on its list. Such verification is done using server status and server description UDP request messages.

When checking the status of a server, the client first sends a server status request message and only once out of 2 sends a description request message, as shown in the figure.

When the client does not receive a correct response, it increments a counter, upon reaching a (configurable) limit, the server is considered dead and the client deletes it from its list of servers.

Responses with server status include the current number of users and files on the server as well as hard and soft limits.

The server description response includes the server name and a description, as shown in the figure.

Improved source file search

When the number of sources the client has, for a file, in its download list is less than a configurable limit (100), the client sends UDP packets to the servers in its list to find more sources for the file. archive.

Client-client communication

Initial setup

The initial setup is symmetrical, that is, both parties send the same information to the other. Clients exchange information about each other, including identification, version, and capability information. Two types of messages are involved:

• Message Hello
• Message the eMule info.

Secure User Identification

Secure user identification is part of the eMule extension. The purpose of secure identification is to prevent user spoofing. To apply a secure identification you must perform the following steps:

• In the initial establishment, B indicates that it supports and wants to use secure identification.
• To react by sending the secure identification message, which indicates if you need the public key of B or not, also contains a challenge of 4 bytes to be signed by B.
• In case A indicated that it needs the public key of B, then B sends its public key to A.
• B sends a signed message that is created using the challenge sent and another with the A IP address (if the client has a low ID), or next to the B ID in case of having a high ID.

Requesting files

A separate connection is created for each [client-file] pair. Immediately after connection establishment, the client sends various query messages regarding the file it wants to download. A typical scenario is shown below.

Basic message exchange

The basic message exchange is made up of four messages:

• A sends a file request message.
• Immediately afterwards send a request message for file ID.
• B responds to the file request with a file response request.
• And to the requested file ID message, with a file status message.

File not found scenario

When A requests a file from B, but B does not have this file in the shared file list. B skips the file request response message and sends a file not found message, immediately after the file ID request message.

Enroll in the upload queue

In the case where B has the requested file but its upload queue is not empty, which means that there are clients downloading files and also probably clients in the upload queue, A and B perform the full setup described in the Figure 4.3 but when A requests B to start uploading the file, B adds A to his upload queue and replies with a queue ranking message, containing A's position in B's upload queue.

Management of upload queues

For each uploaded file the client maintains an upload priority queue. The priority of each client in the queue is calculated based on the client's time in the queue and a priority modifier. At the head of the queue are the customers with the highest score. The score is calculated with the following expression: score = (time in queue position)/100 or 1 in the case that the client that wants to download is defined as a friend. The initial value is 100 except for users who are banned who receive a 0. The score can also be modified by the download credit available to the client (1-10) or by the upload priority of the file (0.2-1.8) which is set by the client uploading the file. When a client's score is higher than all other clients in the queue, the client begins downloading the file. A client will continue to download a file until one of the following conditions occurs:

• The user stopped climbing.
• The customer download has all the pieces you need for the file,
• The customer who is downloading is advanced by another customer who has a higher priority than that of him.

In order to allow a client that has just started the download to get a few megabytes of data before being passed by another client as a higher priority, eMule increases the initial score to 200 during the first 15 minutes of downloading.

Getting to the top of the upload queue

When A reaches the top of B's upload queue, B connects to A, performs setup, and then sends an accept upload request message. A can now either download the file by sending a request parts message or cancel (in the case of getting that part from another source) by sending a cancel transfer message. The figure shows this option.

Data transfer

Data Packet

Sending and receiving parts of files is the most important part of eMule's network activity. The size of a part of the file can vary between 5,000 and 15,000 bytes (depending on the compression). In order to avoid fragmentation, a message part is sent in pieces, each piece in a separate TCP packet. The first packet contains the sending part of the file and the message header. The rest of the packets contain only data.

Data Transfer Sequence

The transfer sequence of a part can start immediately after a response to file request. Client A sends a start upload request message which is answered with an accept upload request message. Immediately after A starts requesting parts of the file and B responds by sending the requested parts. Both clients support the extended protocol by which parts can be sent compressed.

Select a part to download

eMule selectively chooses the download order of the parts in order to maximize performance and network sharing. Each file is divided into parts of 9.28 megabytes and each of these parts is divided into blocks of 180 KB. The order in which each part is downloaded is determined by the downloading client which sends the request file parts message. The downloading client can download only one part of each source at any given time, and all blocks that are requested from the same source belong to the same part of the file. The following principles apply in the order indicated for the download process of a part:

• Frequency of the part (availability), very rare parts must be downloaded as quickly as possible so that this client can become a new available source.
• The parts used for preview (first + last part), or also to check a file (a movie, mp3).
• Request for status (download in process), try to ask each source on the other hand.
• Completion, partly recovered parts must be completed before you start downloading another.

The frequency of a part can be classified into 3 ranges: very rare, rare and common. Within each rank there is a specific weight, which is used to calculate the partial rank. Parts with the lowest rank are downloaded first. This algorithm usually selects the rarest parts first. However, partially completed parts that are close to completion can also be selected. For the common parts, the downloads are distributed among the different sources.

Viewing shared files and folders

There are two types of message flows. The first is the view shared files message, which is sent immediately after the initial setup. This message is always answered with a view shared files answer. When the responding client wants to hide its shared files, the shared file list answer message will have no files. The second message flow starts with a request to see the list of shared folders, which were sent in the shared folder list, for each folder in the list a view shared folder content is sent. Each of these messages is answered with a content list. In the event that the receiving client is configured to block file/folder sharing requests, it responds with a view shared denied message.

Hashset Exchange

In order to obtain hashes of parts a Hashset request is sent, this request is responded with a hashset reply which contains a set of hashes for each part in the file.

Preview a file

Clients can ask their peers to preview the downloaded file. The preview depends on the application and is different depending on the type of files, and contains only two messages: preview request and preview answer.

Emule compared to other p2p networks

One of the main advantages of emule is its large user base currently numbering five to ten million, which makes it excellent for finding all kinds of content. It is said to be the most complete application of the ed2k protocol and its extensions. Emule uses AICH, so its handling of file corruption is comparable to BitTorrent. eMule also employs font sharing, which allows it to substantially reduce the load on servers and Kad.

Fakes (falsifications or false files)

They are files downloaded through this or other programs whose titles do not correspond to their contents. Some users rename the files they share to download adult content on shared computers in a non-explicit way, to confuse downloaders for the sake of mockery or because they want to sabotage the download of certain content. Other more serious fakes are those that some users use to infect other computers, changing the name of some viruses to other programs. Fakes consisting of renaming audio files and text documents or eBooks are less common.

Emule provides several methods to prevent and combat counterfeiting. There is the possibility to download the first and the last part of the video files first, which allows previewing and therefore detecting fraud before completely downloading the file. You can also examine all the names of all the fonts in the same file before downloading it, if they are very different (for example, one font "National Geographic" and the other "Hot Lads") is possibly a forgery. Reviewing a file's comments also allows you to see if another emule user has previously reported it as impersonation. Finally, comparing between the different files found in the search list can alert us if any of them have a clearly different size or duration than the others.

In addition to fakes, there are harmful files specially designed to lure unwary people to web pages or install malicious software on computers. These programs are usually easy to distinguish by three characteristics:

1. These are ZIP, RAR or EXE files.
2. They usually occupy less than 10 MiB (actually they are links to web pages or small programs),
3. They have more than 300 sources (and a percentage of customers with it completed 100%) and are downloaded astonishingly fast.

An easy formula to detect these programs is to write in the search box WRrwrkmcnmcdls00 or any other meaningless trivial word. All the search results will be this type of malicious files, you just have to select them all and mark them as spam (unwanted files).

Bad file sharing practices

eMule is not the fastest program to download a given file, but it is very efficient in managing multiple downloads even if they are large. To avoid excessive waiting times, it is much more comfortable to share, for example, a compressed album (typically ZIP or RAR extensions) than a dozen audio files individually. The data download time will be the same but the waiting time will be twelve times less since it is the same for a large or small file.

To save long waiting times it is good to have a file with many sources (many identical copies on the eD2K network for example). That's why it's important to share exact copies of downloaded files, and not slightly modified copies. An example is files that contain metadata (such as mp3 files in which one can edit the name of the author, album or year of release. Altering this data is altering the file).

The maximum number of downloads a user can have active simultaneously depends on the overall capacity of their computer, but one of the most common limiting factors is the free space on the drive where both files are stored. temporary as downloaded files. It's not a bad idea to have the output folder on an external drive (external hard drive, USB stick) or even have a dedicated drive partition to store temporary files.

Options for commenting on downloaded files should be used to rate the quality of the file in terms of its compression level, picture and sound quality, quality of a scan, integration of subtitles or noteworthy features. Our opinion of whether a movie or song is good or bad is not relevant, because if someone wants to download the file, it is assumed that they will like it.

EMule mods

The fact that eMule is an open source program has favored the creation of programs derived from the modification of the original eMule code (mods). These modified versions, without losing compatibility with the original eMule, add functionalities that are absent from it, give it a new look or adapt it to specific uses or the needs of certain users. The development of some of these variants runs the same as that of the original eMule, in such a way that the team that maintains each mod usually keeps its program updated based on the latest versions of eMule published. Other mods, however, have been developed completely independently of the original eMule. Some of the improvements and features originally developed in these mods have been later incorporated into the original version of the program.

Some of the most popular eMule mods are:

• eMule Plus
• eMule MorphXT
• eMule ScarAngel
• Stullemule
• Dreamule

The concept of mod should not be confused with that of client. An eMule client program, or rather of the eDonkey 2000 network, is any program capable of sharing files complying with the protocols of said network, whether it is based on the eMule code or not.

Fake mods, malware and name theft

Since eMule is easily modifiable due to its freely accessible open source code, in many cases this particularity has been exploited to create programs that include limitations or damages to the user, such as advertising (adware), restricted searches and frequently various types of malware and spyware. Some websites request a payment for downloading the program, the original eMule being completely free of charge.

Several pages on the internet that offer these fake programs appear to be legitimate and even imitate the appearance of the original eMule site and include its name in its address, perhaps the most notorious of these fake pages emule.com, but also emule.es and others with a similar name.