ID allocation of the eMule Protocol

The ID management of the eMule protocol is the focus of the entire program operation. So when the Protocol is working. How is the specific ID managed and allocated effectively? Next we will introduce the basic content of the customer ID in three aspects.

Customer ID

The customer ID is a 4-byte identifier provided by the server when they connect to the handshake. The customer ID is valid only during the client-server TCP connection lifecycle. Even if the client has a high ID, all servers will allocate the same ID until the IP address changes. Client IDs are divided into low IDs and high IDs. When a client cannot receive an input connection, the eMule server assigns a low ID to the client. Having a low ID limits the client's use of the eMule network, and can cause the server to reject a client connection. The calculation of high ids is based on the Client IP address, as described below. Describes the distribution and importance of customer IDs from the perspective of the eMule protocol. The client that allows other clients to freely connect to the eMule's TCP port on their local machine. The default port number is 4662) will be assigned a high ID. There is no restriction on the use of eMule networks for clients with high IDs. When the server cannot open a TCP eMule port connected to the client, a low ID is assigned to the client. This mainly occurs when a client with a firewall is installed on the machine and the input connection is blocked. When the following conditions occur, the client also receives a low ID: l when the client is connected through NAT or proxy server, l when the server is busy, the server reconnection timer times out) the high ID is calculated using the following method: assume that the Host IP address is X.Y. z. w, ID is X + 2 ^ 8 * Y + 2 ^ 16 * Z + 2 ^ 24 * W. Low ID is always less than 167772160x1000000). I cannot find any clue about how it is calculated and get different low IDs in different services.

The low-ID client does not have any public IP addresses that other clients can connect to. In this way, all communications must be completed through the eMule server. This increases the load on the server's computing capability and causes the server to barely receive low-ID clients. This also means that the low-ID client cannot connect to other low-ID clients not on the same server, because the eMule protocol does not support inter-server Pipeline Connection. A callback mechanism is introduced to support low-ID clients. Using this mechanism, the high-ID client requests are sent through the eMule server) and the low-ID client connects to it to exchange files.

User ID

EMule supports credit systems to encourage users to share files. The more files a user uploads to other clients, the more messages it receives, and the faster it advances in their waiting queue. User ID is 128-bit 16-byte), GUID created by connecting random numbers, 6th and 15th bytes are not randomly generated, and their values are respectively 14 and 111. The customer ID is valid for the entire client and the specified server session, but the user ID is also called the user hash) is unique and used to identify the client user ID identification workstation when session is crossed ). User ID plays an important role in the credit system, which provides motivation for hackers to impersonate other users to obtain the priority granted by their credit. Emule provides an encryption solution designed to prevent spoofing and impersonation. This implementation is a simple response exchange based on RSA public/private key encryption.

File ID

The file ID uniquely identifies files and files in the network for Damage Detection and repair. Note: The eMule protocol does not rely on the file name to uniquely identify and catalog the file, and uses the hash file content to calculate the GUID identification file. There are two types of file IDS-one is mainly used to generate a unique file ID, and the other is used to detect and repair damage.

File hash

Files are identified by the client and the 128-bit GUID hash calculated based on the file content. GUID is calculated by applying the MD4 algorithm to the file data. When calculating the file ID, the file is divided into 9.28MB in length. A guid is calculated for each part, and all the hashes are combined into a unique file ID. When the downloaded client downloads a part of the file, it calculates the hash and compares it with the sent hash. If the distribution is damaged, the client tries to fix the damaged part by gradually replacing the bits in this Part with KB) until hasch calculates OK.

Root hash

The SHA1 algorithm is used to calculate the root hash for each part. The size of each part is kb. It provides higher levels of reliability and maintainability. More information can be found on the official website of eMule.

EMule protocol Extension

Although eMule is fully compatible with eDonkey, it implements several extensions that allow the two clients of eMule to provide users with other functions. As long as the extension is concentrated on the communication between the client and the client, especially in the security and UDP usage fields. In this document, all information displayed by the information flow icon is extended by the eMule, which is displayed in gray.

Software and Hardware restrictions

There are two restrictions on the number of active users in the server configuration-software and hardware. Hardware restrictions are far greater than software restrictions. When the number of active users reaches the software limit, the server stops receiving new low-ID client connections. When the number of users reaches the hardware limit, the server is full and no client connection is received.