Design of underlying communication model for high-performance Servers Based on win platform (1)

Author: sodimethyl
Source: http://blog.csdn.net/sodme
Disclaimer: This article can be reproduced without the consent of the author, but please keep the author, source and declaration information before the beginning of the article. Thank you.

Due to my personal work, I have been engaged in R & D of high-performance servers for some time. Before I got started with this topic, I thought that the server design was nothing more than using Winsock, it is easy to call a function. When I completed a test model that could carry tens of thousands of connections on the win platform, I realized that it was so challenging to create a high-performance server. You not only need to elaborate on the model in detail, but also need to make a trade-off between the overall architecture. These two aspects will affect the normal performance of your server. For details, refer to my previous series of articles titled "optimizing port performance ". The series of articles starting from this article will introduce a complete high-performance server model, and will not discuss the architecture of Server clusters in this series, that will be what I will do in the next few weeks. A friend told me that I hope I can provide the complete code of the underlying model or dynamic link library and Lib files that can be used. I am still considering this requirement. Indeed, with the code, you need to learn faster, but because the model involves copyright issues, I will consider making necessary modifications to it, then consider whether to provide the source code to everyone. However, it is certain that I will submit the lib and DLL requirements as soon as possible.

The so-called "High Performance" is nothing more than two aspects:
1. Handle as many concurrent requests as possible, as shown in the number of clients simultaneously connected at the same time;
2. the throughput of data packets should be as large as possible, as shown in the data volume received and sent by the server per unit time.

In Windows, iocp (completion port) is the best solution for handling a large number of concurrent connections. Therefore, the article discussed later is based on this model. For how an independent iocp model works, please download the Microsoft SDK. In that example, there is a basic iocp example. However, this is just an example. In actual application, you still need to do a lot of work. When reading the following content, it is best to have the following conditions: know the basic concepts of iocp, and use of several necessary functions (create, get, post, and so on) It calls. Note: This is too troublesome. I use simple names for these functions. For the complete function name, see relevant information about port completion.

In order to give everyone a grasp of the macro concept, I will first introduce the underlying model of server communication based on a three-tier structure. For the software architecture, it is not best to say that the performance may vary widely in different application environments. Therefore, I do not guarantee that this architecture can make everyone look comfortable. I only guarantee that, in my current project application, this architecture fully considers both "performance" and "scalability", allowing me to easily develop new servers, you can still enjoy good performance.

I. Three-layer architecture and simple description

The three-tier architecture diagram is as follows:
Ciocpserver
|
|
Ccutomhpserver
|
|
Ctestserver

In the future, we will discuss this seemingly complex three-layer architecture diagram. Below we will briefly describe the main classes in this architecture diagram.

Ciocpserver:
Complete the basic communication class of the port server. It uses the special port feature of WINNT/2000/XP platform to encapsulate the communication model, provides the following basic extension interfaces (virtual functions that can be overloaded) to its derived classes ):

1. processing interface for client connection;
2. processing interface when the client is disconnected;
3. processing interface after receiving data from the client;
4. processing interface after sending data to the client;
5. interfaces for handling errors in network communication and server processing.

Ccustomhpserver:
Ciocpserver is one of the typical high-performance server classes? Is there another base class? The answer is: Of course, haha, don't worry, I will introduce it later). This class encapsulates three data queues and three processing threads on the basis of ciocpserver, introduction:

1. receive data packet queue and receiving thread: used to store the received data packet. This data packet has not been split logically. The receiving thread extracts data packets from this queue, and add a complete logical data packet to the "processing data packet queue;

2. processing data packet queues and logic processing threads: data packets in the logic sense have been disassembled. The logic processing thread parses such data packets logically. Here is the main logic part of the server, some data packets may need to return the processing result to the client after processing is completed. In this case, the logic thread needs to put the data packets returned in the "send data packet queue" after processing is complete;

3. Send data packet queue and sending thread: The data packet queue to be sent, which is sent by the sending thread to a specific client based on the client socket in the data packet.

Ctestserver:
This class is a test class used to demonstrate how to derive a real application server based on ccustomhpserver, and to demonstrate which important virtual functions of ccustomhpserver need to be reloaded.

Based on the above structure, our server communication model can be implemented layer by layer and tested layer by layer. In ciocpserver, ciocpserver does not contain any data queues. All network data is processed as soon as possible, and no data is saved, so real-time response is implemented. There are two important threads in ciocpserver: acceptthread and workerthread. The accetpthread uses the accept or acceptex function to receive client connection requests and bind the client socket to the complete port handle, the "processing interface when a client is connected" is encapsulated here, while the workerthread thread is the "Worker thread" we often say in completing the port, which is triggered by the get function, other interfaces except the "processing interface for client connection" are encapsulated here.

When implementing a high-performance server model, we may need to implement it layer by layer. First, it is easier to test, second, we can clearly understand the efficiency of each layer when implementing layer-by-layer, which helps us find a breakthrough to improve efficiency. You can start with the ciocpserver class to implement a simple echo server, that is, the echo server. No need to maintain the data packet queue. The data sent from the client is immediately returned to the client. After this layer is completed, the port is basically completed. It includes the maintenance of the client connection queue when a large number of clients are connected, event Processing and thread synchronization when the client connects, disconnects, sends, and receives data. Based on my experience, it is difficult to deal with the underlying client disconnection event. New users often release the current client object directly when receiving the disconnection event, however, it is better to use the reference counting mechanism instead of releasing it directly. In addition, I also have my own opinion on "release", that is, it is best not to release the client object, but to put it in an idle queue or close the original socket, re-generate a new socket to associate it with the original client object and use it as a new client object. This avoids frequent creation and release of client objects. Of course, the premise is that it is best to use the acceptex function instead of accept to accept client connections.

This article only introduces the overall structure of the model. The specific implementation and fragment code of these three classes will be introduced in the next article, if you are interested, please give your feedback on my blog.

<To be continued>