EMule is a free of charge peer-to-peer file posting program for Microsoft Glass windows. Were only available in May 2002 instead of eDonkey2000, eMule now connects to both the eDonkey network and the Kad network. The distinguishing features of eMule will be the immediate exchange of sources between clients nodes, fast recovery of corrupted downloads, and the use of the credit system to praise recurrent up loaders. Furthermore, eMule transmits data in zip-compressed form to save lots of bandwidth.
Each eMule client is pre-configured with a list of servers and a list of shared data files on its local data file system. A client uses a solitary TCP connection to an eMule server for logging in to the network, getting information about desired data and available clients. The eMule customer also uses several hundreds of TCP contacts to other clients which are used to publish and download documents. Each eMule consumer sustains an upload queue for every single of his shared files. Getting clients become a member of the queue at its lower part and advance little by little until they reach the very best of the queue and commence downloading his record. A customer may download the same document from other eMule clients, getting different fragments from each on. A client may also upload chunks of any file which it hasn't yet completed downloading. Finally, eMule extends the eDonkey features and allows clients to exchange information about servers, other clients and documents. Note that both client and server communication is TCP based mostly. The server employs an internal data source where it stores information about clients and data files. An eMule server doesn't store any documents, it acts as a centralized index for storing information about the location of files. Yet another function of the server, which is becoming deprecated, is to bridge between clients that hook up through the firewall and are not able to accept incoming associations. The bridging operation increases significantly the server weight. EMule utilizes UDP to improve the client's capabilities against both the server and other clients. The client's ability to receive and send UDP messages is not essential for the client's correct daily operation and it could function flawlessly when a firewall prevents it from sending and acquiring UDP information.
Figure 1. 1: eMule advanced network diagram
1. 1. 1 Customer to server connection
Upon startup your client links using TCP to an individual eMule server. The server provides the client with a client Identification (section 1. 3) which is valid only through the client-server connection's life (remember that when the client has high ID it will receive the same ID from all servers until its Ip changes). Following the connection establishment your client delivers the server his set of shared data. The server stores the list in its inner database which usually includes several hundred thousand of available documents and lively clients. The eMule client also directs his download list which contains the files so it hopes to download. Section 2 offers a detailed information of the eMule customer and server TCP note exchange. After the connection is made, the eMule server delivers the client a list of other clients that posses data files which the connecting client needs to download (these clients are called 'options'). From this point on, the eMule customer begins to determine links with other clients as described in section 1. 2. 2 below.
Note that the consumer/server TCP connection is kept wide open during the whole client's session. Following the initial handshake trades are prompted mainly by individual activity: From time to time, the client directs file search requests that happen to be replied by the search results, a search purchase is usually followed by a query for sources for a particular document, this query is replied with a set of options (IP and slot) that the requester can download the data file from. UDP is utilized for communication with servers apart from the server to that your client is currently connected. The purpose of UDP emails is file search advancement, source search advancement and lastly, keep-alive (ensure that all the eMule servers in the client's server list are valid).
1. 1. 2 Client to client connection
An eMule client connects to some other eMule customer (a source) in order to download a record. A record is divided to parts that are further fragmented. A client may download the same file from several (different) clients getting different fragments from each one.
When two clients connect they exchange ability information and then discuss the beginning of a download (or upload, depends on point of view). Each customer has a download queue which holds a list of clients that are waiting around to download files. Once the eMule client's download queue is empty a download need will most probably lead to a download start (unless, for example, if the requester is prohibited). If the download queue isn't clear a download get ends in adding the asking for client to the queue. There is absolutely no attempt to serve more than a few clients in a given moment providing the very least bandwidth of 2. 4 Kbytes / sec for each. A downloading consumer may be preempted by way of a waiting customer with an increased queue position than his, in the first 15 minutes of the a download procedure the queue position of the downloading eMule customer is boosted to prevent thrashing. When a downloading client reaches the head the download queue, the uploading customer initiates a connection to be able to send him his needed file parts. An eMule client may be on the waiting around queue of other clients, signed up to download the same data file parts in each one. When the waiting consumer actually completes downloading it the parts (in one of them) it generally does not notify all the others they can remove him from their queues, it will simply reject their upload try out when it grows to the head of their queue. EMule employs a credit system (see section 1. 4) in order to encourage uploads, to avoid impersonation eMule secures the credit system using RSA public-key cryptography. Consumer connections might use a couple of messages not defined by the eDonkey protocol, these concept are called the extended protocol. The extended protocol is utilized for the credit system implementation, for general information exchange (like updates of the lists of servers and sources) and improve performance by mailing and acquiring compressed file fragments. The eMule customer interconnection uses UDP in a restricted manner to occasionally check the client's position on the upload queue of his peer clients although it is waiting to begin downloading a data file.
1. 2 Consumer ID
The client ID can be an a 4 byte identifier provided by the server at their connection handshake. A customer Identification is valid only through the lifetime of a client-server TCP connection although in the event your client has a high ID it will be allocated the same ID by all servers until its Ip changes. Customer IDs are divided to low IDs and high IDs. The eMule server will typically assigns a client with a low ID when your client can't accept incoming connections. Having a minimal Identification restricts the client's use of the eMule network and may result in the server's rejecting the client's interconnection. A high Identification is calculated based on the client's IP address as defined below. This section represents the client Identification assignment and value from the eMule process point of view. A high Identification is given to clients that allow other clients to widely hook up to eMule's TCP slot on their host machine (the default interface quantity is 4662). A customer with a higher ID has no limitations in its use of the eMule network. If the server can't open up a TCP link with the client's eMule port the client is given a minimal ID. This happens mainly with clients that create a firewall on the machine denying incoming connections. A client might also receive a low Identification when it the next cases:
When your client is connected via a NAT or proxy servers.
Once the server is too busy (resulting in the server's reconnection timer to expire).
1. 3 User ID
EMule facilitates a credit system in order to encourage users to talk about files. The more files a user uploads to other clients, the more credit it gets and the faster it'll progress in their ready queues. The user ID is a 128 little bit (16 byte) GUID created by concatenating arbitrary numbers, the 6th and 15th bytes are not randomly generated, and their principles are 14 and 111 respectively. While the client Identification is valid only by having a client's time with a specific server an individual ID (also called user hash) is exclusive and can be used to identify a customer across periods (an individual ID identifies the workstation). An individual ID performs an important part in the credit system, this provides inspiration for 'hackers' to impersonate to other users to be able to get the privileges granted by their credits. EMule helps an encryption scheme which was created to prevent fraud and consumer impersonation.
1. 4 Data file ID
File IDs are used both to distinctively identify data in the network and for file corruption recognition and recovery. Note that eMule doesn't rely on the file's name in order to distinctively identify and catalog it, a document is identified by way of a globally unique ID computed by hashing the file's content. You can find two varieties of document IDs - the first is employed mainly for producing the unique data file ID, the second is useful for problem detection and restoration.
1. 4. 1 Data file hash
Files are uniquely identified by a 128 bit GUID has determined by the client and based on the file's details. The GUID is computed through the use of the MD4 algorithm on the file's data. When determining the record ID the data file is divided in parts each 9. 28MB long. A GUID is determined separately for each and every part and then all the hashes are mixed in to the unique record ID. When a downloading consumer completes downloading a data file part it calculates the part hash and compares it up against the part hash dispatched by its peer, if the part be found corrupted, the client will try to recuperate from the problem by gradually replacing pieces (180kb each) of the part before hash is calculated.
1. 4. 2 Root hash
The main hash is computed for each part using the SHA1 algorithm, predicated on blocks sized
180kb each. It offers a higher level of reliability and mistake recovery.
1. 5 eMule protocol extensions
Although eMule is completely appropriate for eDonkey it implements several extensions which allow two eMule clients to provide additional operation with their users. The extensions are focused in the client to customer communication especially in the areas of security and UDP usage.
1. 6 Soft and hard limits
The server construction includes two kind of restrictions on the number of lively users - soft and hard. The hard limit is higher equal to the very soft limit. When the amount of active users grows to the soft limit the server stops recognizing new low ID client associations, when the user count reaches the hard limit the server is full and doesn't acknowledge any client interconnection.
2 Customer server TCP Communication
Each client links to exactly one server using TCP connection. The server assigns the client an ID which will be used for to recognize your client in the others of his procedure your server (A higher ID client is usually assigned with his Ip). The eMule GUI client requires that a server connection will be proven in order to perform. Your client can't be linked to several machines at the same time and nor can't it dynamically change servers without user treatment.
2. 1 Connection establishment
Figure 2. 1: High Identification login sequence
When establishing connection to a server your client may make an effort to connect to many machines in parallel, abandoning basically upon a successful login sequence.
There are several possible interconnection establishment use circumstances:
1. High Identification connection - the server assigns a high Identification to the connecting client
2. Low ID connection - the server assigns low ID to the connecting client
3. Rejection period - the server rejects the client
Figure 2. 1 details the message series that leads to a high ID connection. In cases like this, the client establishes a TCP link with the server and then sends a login communication to the server. The server connects using another TCP link with the client and performs a client-to-client handshake to make sure that the connecting client has the capability to recognize links from other eMule clients. After concluding the client handshake the server closes the second connection and completes the client-server handshake by mailing the Identification change subject matter.
Figure 2. 2: Low Identification login sequence
Figure 2. 2 identifies the message collection that causes a Low ID connection. In this case, the server fails to connect to the requesting client and your client is given with a low ID.
The server meaning usually has a caution like "Warning [server details] - You have a minimal ID. Please review your network construction and your adjustments. "
Both low and high Identification handshakes filled with the Identification change concept which assigns the client with a client ID for its next coming session with the server.
Figure 2. 3: Reject session sequence
Figure 2. 3 describes the rejected treatment sequence. Servers might reject trainings due to the client's having a minimal Identification or when achieving their hard capacity limit. The server meaning will include a short string describing the rejection reason.
2. 2 Interconnection startup meaning exchange
Figure 2. 4: Connection startup sequence
After a successful connection establishment your client and server exchange several setup messages. The goal of these information is to update both parties regarding their peer's talk about. The client starts off by offering the server his list of shared documents (see section 6. 2. 4), and then he asks to upgrade his set of machines. The server directs his status and version (parts 6. 2. 6 and 6. 2. 2) and then transmits his set of known eMule servers and provides even more self recognition details. Finally your client asks for resources (other clients that may be reached to download the data in his download list) and the server replies with some messages, one for each and every file in the client's download list, until all the options list has been downloaded to your client.
2. 3 File search
Figure 2. 5: File search sequence
The data file search is set up by the user. The operation is simple, a search get (see section 6. 2. 9) is delivered to the server which is then clarified by the search result (section 6. 2. 10). Whenever there are many results, the search result note is compressed. Next, an individual chooses to download one or more files, the client then requests options for the chosen data files and the server replies with a set of sources (see 6. 2. 12) for each and every of the wanted data files. An optional server position concept may be sent by the server right before the found resources reply. The position communication (section 6. 2. 6) includes information about the existing quantity of users and data files recognized by the server. An important note is that there is a complementary series of UDP concept which enhances the ability of the client to locate resources for his search list for more details see section 3. After verifying that options are new, the eMule customer initiates an association attempt and brings those to its options list. The order in which sources are contacted is the order where these were received by the eMule consumer.
The eMule customer connects to options by the order they were added to its list. There is certainly no
priority mechanism to choose to which source for connecting. There is a complicated mechanism to solve situations where the same source can be wanted for getting several data on the client's download list (Remember that eMule allows only a single upload interconnection between clients). The choice algorithm is dependant on user priority standards and defaults to alphabetical buying when no main concern is specified. A details explanation of the handling a source which can upload greater than a single record is defined in the web site.
2. 4 Callback mechanism
Figure 2. 6: Callback sequence
The callback mechanism was created to overcome the shortcoming of low ID clients to accept incoming connections and therefore share their files with other clients. The system is simple, in the event a clients A and B are connected to the same eMule Server and A takes a file that is situated on B but B has a low Identification, A can send the server a callback submission (see section 6. 2. 13), requesting the server to ask B to call him again. The server, which already comes with an open TCP link with B, sends B a callback requested (section 6. 2. 14) concept, providing him with A's IP and slot. B may then connect into a and send him the file without further overhead on the server. Clearly, only a high ID client can ask low ID clients to call back (a minimal ID customer is not capable of accepting inbound relationships).
