Search information set-csearchlist
Csearchlist is the search list in eMule. It is in charge of all search requests in eMule. Csearchfile is an element in this list, representing information related to a search. Their relationships are similar to the known files described earlier and the list of known files. The main task of csearchlist is to maintain the internal variables in the csearchfile list of the list type. It is convenient to add, delete, and query the list, the interface for operations such as change. In addition, each search has an ID that is a 32-bit integer. The csearchlist records the number of files currently searched and the number of sources (m_foundfilescount and m_foundsourcescount ).
Csearchfile is another subclass of cabstractfile (cknownfile is also). It stores information related to a file and search, rather than the information of the file itself (this information has been included in cabstractfile ), the search-related information is the machine on which the file is found and the server on which the file is found. You can even add previews to a search file. In the definition of this class, two simple structures sserver and sclient are defined nested, indicating the possible sources of the search file, the server or other clients. M_aclients and m_aservers are an array of the two simple structures. csearchfile also provides interfaces for operations on this array to facilitate csearchlist usage.
Csearchlist provides an external search expression interface, that is, every time a new search is submitted, csearchlist: newsearch creates a new search item, but there is no corresponding search file yet, therefore, only create a new project in the table corresponding to the number of files and the search ID (m_foundfilescount and m_foundsourcescount. In addition, when a search result is returned, processsearchanswer or processudpsearchanswer can directly process the returned package, create the corresponding search file information csearchfile object, and add it to its own list. Of course, you need to remove duplicate search results and create a level-2 List (csearchfile: m_list_parent) for multiple sources of files in the same hash ). Now we can see that csearchlist is only responsible for storing and reading search-related information and does not search for it.
Server Information Set-cserverl
Although the KAD network is available, using the server to obtain the shared file list of each eMule user is still the primary method for obtaining resources in the eMule. Cserverlist is the class that manages the server list in eMule. Similar to the previous list class structures, cserverlist needs to provide external interfaces such as adding, deleting, searching, and modifying the list. In the cserverlist, the information of each server is a cserver class. Different from the search information, but like the list of known files, the list of server information needs to be retained for a long time, therefore, the cserverlist and cknownfilelist classes provide the ability to save all information contained in a file and read its information from the file.
The structure of cserver is relatively simple. You only need to keep the information of the server. It can be created through the IP address and port, or through a simple structure servermet_struct, where the latter is used to directly read from the file. This structure only contains the number of IP addresses, ports, and attributes. Other attributes of cserver are saved as tags when they are saved to files.
In addition to common cserver information, cserverlist also provides statistics such as the number of users of all servers and the number of shared files. These statistics are calculated based on the relevant information of each separate cserver.
EMule communication protocols-some basic conventions
Next, we will inevitably encounter the eMule protocol. EMule's communication protocol format is designed to facilitate expansion. For TCP connections, the data streams in the connections can be divided into packages one by one. In the cemsocket class, the received data is divided into packages. However, the specific processing work for each packet is transferred to its subclass. The two cemsocket subclasses cserversocket and cclientreqsocket represent the TCP connection between the client and the server, and the TCP connection between the client. The first byte in the data stream represents the cluster code of the communication protocol, such as 0xe3 as the standard edonkey protocol and 0xe4 as the kademlia protocol. The next four bytes represent the length of the Package content. All packages are sent to the TCP stream in this way, which can be distinguished. In addition, the first byte in each package content is opcode, that is, after a specific protocol is determined, this opcode determines the specific meaning of the package.
It is easier to process UDP packets, because UDP uses a packet and a package as a unit to spread on the network, therefore, you do not need to include fields that represent the length in the package content. The first byte of each UDP packet is the protocol cluster code. Other content is the packet content. The cclientudpsocket class is responsible for processing UDP packets between the client and the client, while the cudpsocket class is responsible for processing UDP packets between the client and the server. In addition, there is a kademlia: ckademliaudplistener class that specializes in processing UDP packets related to the kademlia protocol.
Finally, let's talk about the packet class, which was previously mentioned. It is the minimum unit of the communication protocol of Emule. We can see that its constructor has multiple versions to create a packet in different ways. For example, a buffer that contains only one header information, or only specifies the protocol cluster code. In addition, it implements the compression and decompression methods internally. This method directly calls the compression method in the zlib library to reduce the amount of data transmitted. Note that the protocol cluster code is not involved in compression during compression. After compression, the protocol cluster code will be changed. For example, after compression of a package whose code is standard edonkey protocol 0xe3, the protocol code is changed to 0xd4. Here, the protocol code is changed to enable the receiver to correctly identify and decompress the code.
EMule communication protocol-Overview of communication between clients and servers
All communication between the client and the server is controlled by class cserverconnect. Cserverconnect itself is not a subclass of the socket, but its member variable cserversocket type connectedsocket is. There is a list inside cserverconnect that stores several cserversocket-type pointers. However, this does not mean that it is usually connected to many servers. It can only try to connect to several servers at the same time, because the connection to the server may not succeed.
The cserversocket class is a subclass of cemsocket. It saves more States than cemsocket, such as the current server connection status. It also retains information about the server it is currently connected. By analyzing cserversocket: processpacket, you can directly understand the communication protocol between the eMule client and the server. Here is the packet sent from the server. The first packet after the TCP connection is established is sent in cserverconnect: connectionestablished, that is, the login information is sent to the server. If the login succeeds, you can obtain your ID from the server, which is a 32-bit long integer. If the number is less than 16777216, we call it lowid. A client with a lowid usually cannot be directly connected by other clients. There are many reasons for obtaining lowid, such as when you are in the NAT backend. After obtaining your own ID, you will be able to send your own shared file list to the server. This action is done by the shared file list class csharedfilelist.
It is not necessary to list all other types of packages. In the future, you can analyze other types of packages because it involves sending or receiving data to the server.
EMule communication protocol-Overview of communication between the client and the client
The TCP communication between the client and the client is completed by clistensocket and cclientreqsocket. This is also a typical way of writing network services. Clistensocket is only a subclass of casyncsocketex and is only responsible for listening to a TCP port. It only contains a list of cclientreqsocket classes. Cclientreqsocket is a subclass of cemsocket, so it can automatically complete the packet identification of Emule. It has processpacket and processextpacket to process the packages between the client and the client. The former is the package of the classic edonkey protocol, and the latter is the package of the eMule extension protocol.
The relationship between the clistensocket and cclientreqsocket classes is similar to that of the previously analyzed list class and its corresponding member classes. clistensocket provides the addition and query of elements in its cclientreqsocket list, delete. Some statistics about these members are also maintained. We noticed that clistensocket added itself to the list of clistensocket class (theapp. listensocket, the unique actual example of this class) in its constructor.
There is a correspondence between the cclientreqsocket class and the cupdownclient class. They all represent some information of another client, but the cclientreqsocket class focuses on network data, that is, it is responsible for mutual communication between the two sides, the cupdownclient class is responsible for logically expressing a client on the other side of the network. The cupdownclient class code is very long and will be discussed later.