Chapter 4 TCP communication between the client and the client

Translated from Yoram Kulbak and Danny Bickson The eMule Protocol Specification

Translation: lzcx

QQ: 314127985

EMail: lzcx_cn@yahoo.com.cn

For learning. For more information, see the source.

 

4 Client-to-client TCP CommunicationAfter the eMule client registers with the server and queries the file and source from the server, the eMule client needs to contact other clients to download the file. Create a dedicated TCP connection for each pair of [files, clients. If no socket activity exists in a specific period (40 seconds by default) or the other party has closed the connection, the connection will be closed. To provide a reasonable download rate until it is available (and all other download clients) At least the allowed rate (the current hard encoding constant is set to 2.4 k/s ), eMule allows the client to start downloading files. 4.1 Initial handshakeThe initial handshake is symmetric-both parties send the same information to each other. The client exchanges information from both parties, including identity authentication, version, and capacity. There are two types of messages involved: Hello Message (Section 6.4.1) and eMule message (Section 6.5.1). The first one is part of eDonkey and is compatible with the eDonkey client, the second is part of the dedicated extended client protocol of eMule. Figure 4.1 illustrates the handshake between two eMule clients. The extended information includes UDP message exchange, Security ID card, and source exchange capabilities. 4.2 Secure user Identity AuthenticationSection 1.4 briefly explains the motives for user IDs and counterfeiting of other users. Security user authentication is part of the eMule extension. If the client supports Security Authentication, It will be executed immediately after the handshake is initialized. The purpose of security authentication is to prevent users from impersonating users. When performing security authentication, perform the following steps: 1. In the initialization handshake, client B specifies that it supports and wants to use security authentication. 2. Send A Security Authentication message (see 6.5.8) to indicate whether A requires the public key of B and also contains the 4-byte query sent by B. 3. If A specifies that it requires the public key of B, B sends its public key to A (section 6.5.9 ). 4. B sends A signature message (section 6.5.10). The signature message is created by sending an inquiry and an additional dual byte. The dual byte is either the IP address of A. If B is A low ID, either it is the ID of B if it has a high ID. Figure 4.2 demonstrates the order. 4.2.1 Credit SystemThis section briefly describes the client's credit system. The credit system aims to encourage users to share files. When the client uploads a file to the other party, the downloaded client updates its credit based on the number of data transfers. Note: The credit system is not global-the transfer credit is locally saved by the downloaded client. Only when the uploaded client (the client that obtains the credit) requires downloading from this specific client, credit is considered. Credit is calculated using the following minimum values: 1. total number of uploads * 2/total number of downloads when the total number of downloads is zero, this expression is valued at 102. total number of uploads + 2 and when the total number of uploads is less than 1 MB, this expression evaluates to 1 and the number of uploads/downloads is calculated in MB. In any case, the credit is not higher than 10 or less than 1. 4.3 Request FileAs mentioned above, each pair of [client, file] creates an independent connection. After the connection is established, the client immediately sends several request messages about the files it wants to download. Section 4.3 describes a typical success scenario. 4.3.1 Basic message exchangeBasic message exchange consists of four messages: A sends A file request message, followed by the request file ID message (section 6.4.17 ). B. Use the file request to respond to the file request and the file status (section 6.4.18) to respond to the ID message of the requested file. I cannot find any reason to divide the information in these sent messages into four messages, which can be easily processed by two messages (requests and responses. Extended Protocol adds two messages to this order, the source request message (section 6.5.6) and the source Response Message (section 6.5.7 ). Use this extension to transfer B's source (assuming B is currently downloading the file) to. In details, B has no requirements to download a file before it can send the file block to other clients. B can send any file block that has been downloaded, even if it is just a small part of a file. 4.3.2 File not foundWhen A requests A file from B, but B's shared file list does not. B. Ignore the file request response message and immediately send a non-file message (section 6.4.16) after the request file ID message, as demonstrated in section 4.4. 4.3.3 Add to upload queueWhen B has a requested file but its upload queue is not empty, it means that there is a client that is downloading the file, or a client may be in the upload list. In this case, A and B perform full handshakes, as described in section 4.3. But when A requests B to start downloading files, B adds A to its upload queue and responds to A queue-level message, this message contains the location of A in the B-Location Upload queue. Figure 4.5 demonstrates the order. 4.3.4 Upload to column ManagementThe client maintains an upload priority queue for each uploaded file. The priority of each client in the queue is calculated based on the time and priority of the client in the queue. The client in the queue header has a highest level score. Scores are calculated using the following formula: score = (level * number of seconds in the queue)/100 or infinity if the downloaded client is defined as a friend. The initialization level is 100, except that the disabled user is 0 (in this way, the user is blocked before the queue. The level can be modified by the downloading client's credit (range: 1-10) or upload file priority (0.2-1.8). The Upload File priority is set by the upload client. When a client scores higher than other clients, it starts to download files. The client can continue to download files until any of the following conditions are generated: 1. the user has disabled the upload client. 2. The downloaded client obtains all the parts of the required file. 3. The downloaded client is preemptible to other clients with a higher priority than the client. To allow a client that has just started to obtain several MB of data before being preemptible, eMule adds the initial grade to 200 within 15 minutes before the client downloads. 4.3.5 Arrive at the top of the upload queueWhen A reaches the top of B's upload queue, B connects to A, performs initial handshake, and then sends A message to receive the upload request (section 6.4.11 ). A can choose to either send A request block message to continue downloading the file, or send A cancel transmission message to cancel the download (if it has obtained this part from another source ). Figure 4.6 demonstrates these options. 4.4 Data Transmission  4.4.1 Data PacketsSending and receiving file blocks are the main part of Emule's network activity. EMule can be interpreted using FTP to infer that when all other eMule can be controlled, the file block sent is suitable for data transmission. The size of the file block sent can be within the range of 5000 to 15000 bits (also based on compression. To avoid errors, file Block messages are sent in fragments, and each shard is in an independent TCP packet. In eMule 0.30e, the maximum fragment size is 1300 bits (note that this number is only related to TCP payload ). In other words, when each control message is sent in a separate TCP packet and is sometimes shared with other messages, the data message is divided into several TCP packets. The first package contains the header of the message sent from the file block (Section 6.4.3 ). The remaining package value contains data. If the size of the sent block is 1300, it is sent together with the first package (this package has a header. Figure 4.7 demonstrates the file block message. 4.4.2 Data Transmission sequenceThe Block Transmission sequence starts immediately after the file request is responded. Download Client A to send a start upload request (section 6.4.10), and then one receives the upload request message (section 6.4.11) to respond to this request. A immediately starts to request the file block (section 6.4.4). B responds by sending the requested block (Section 6.4.3. Note that a single file block request may contain up to three parts, so each file block request may receive a block-ordered response sent by up to three parts. When both clients support the extended client protocol, file blocks may be compressed and sent. The extended Protocol also supports optional file information messages (section 6.5.5), which are sent before receiving the upload request message. Figure 4.8 demonstrates the message sequence of block transmission. 4.4.3 Select block downloadTo maximize the throughput and sharing of the entire network, eMule carefully selects the download sequence of the selected block. Each file is divided into MB blocks, and each part is divided into kb slices. The order of block downloads is determined by the download client that sends the request file block message (section 6.4.4. The download client can download a separate file block from each source at any given time. All the parts requested from the same source are in the same block. The following principle (in this Order) applies to the download block level: 1. (available) the frequency of blockbusters, as soon as possible to download very rare blockbusters to form a new source. 2. block Used for Preview (initial + final blockbuster), preview or check files (such as movies and mp3) 3. request status (download in process), and try to ask each source for other large movies. Spread requests between all sources. 4. completion (not completed to some extent). When you start downloading the other, you should complete the acquisition of part of the blockbuster frequency standard defined in three areas: Very rare, rare, and general. In each region, the standard has a specific weight to calculate the block level. Download lower-level blocks first. The following list specifies the file level range based on the above principle: l 0-9999-blocks with no requests and very few requests l 10000-19999-blocks with no requests and previews l 20000-29999-blocks with most of the requests not completed l 30000- 39999-request scarcity and preview of block l 40000-49999-request incomplete general block this algorithm usually selects the first and most scarce block. However, partially completed blocks that are close to completed may also be selected. For general blocks, the download is spread across different sources. 4.5 Browse shared files and foldersThere are two message flows to process the browsing of shared files and folders between each client. The first is to browse the shared file message (section 6.4.21), which is sent immediately after the initial handshake. A shared file browsing Response Message (6.4.22) is usually used to respond to the message. When the responding client wants to hide its shared file list, the response contains zero files (instead of sending a message indicating access rejection ). Figure 4.9 demonstrates the message order. The second message flow starts with a request to browse the shared folder column (section 6.4.23) and respond to the message through the shared folder list. Then, for each folder in the response, send messages to browse shared folder content. When a message arrives, each response message contains a content list. Figure 4.10 demonstrates the message order. If the client that receives the shared file/folder blocking request is set, it requests the shared denial message to respond, as shown in Figure 4.11. 4.6 Swap slice hash setTo obtain the hash of a slice, a hash set request is sent. This request is responded to by a hash set containing each part of the file. Figure 4.12 demonstrates this. 4.7 Get File PreviewThe client can request the other party to obtain a preview of the downloaded file. Previewing is an independent application that varies with file types. EMule 0.30e only supports image preview. This message exchange 4.13 description contains only two types of messages: preview request (section 6.5.11) and preview response (section 6.5.12 ).