This paper introduces the implementation of a scalable TCP service based on Qt. This implementation is based on the requirements of C/S client-service cluster application. Connection monitoring, data transmission, data processing are carried out in a separate thread pool, depending on the specific tasks, can be arranged for monitoring, transmission, processing of the number of threads, in order to achieve high transmission load, high computational compliance on the trade-offs. Data processing takes the pipeline structure to avoid the intensive calculation requests of a small number of customers affecting the processing of other clients. The code corresponding to this article conforms to the LGPL protocol and can be downloaded directly from Https://github.com/goldenhawking/zpserver. can also be downloaded from http://download.csdn.net/detail/goldenhawking/7461157
First, the summary
In many industry applications, the client-service architecture is irreplaceable. Services play an important role in the client-service architecture. This article is intended to introduce a more general form of service implementation that can be flexibly configured to meet specific application requirements, thus reducing the time to repeat development. The service implementation supports at least two of the following requirements.
The first type is the forwarding service , which is mainly responsible for communication between two clients, and does not do complex processing by itself. This service typically has to withstand dense connections, and in some applications, it is subjected to heavy transmission loads. Typical includes instant messaging, two intra-intranet video communication, etc.
The second type is the computational service , which is responsible for receiving the client's raw data and returning the result after processing. This service generally runs on high-performance servers, calls back-office parallel Computing, heterogeneous computing resources, and returns the results to the client after processing. The number of clients for these services is generally limited, but in some applications the transmission load is heavy when the amount of input and output data is large.
In order to meet the above two types of requirements, service design has the following characteristics.
1. Can set the listening port flexibly
2, monitoring, transmission, processing are running in a separate thread pool.
3, can be flexibly set the number of transmission and processing threads as needed.
4. Processing of a single client does not significantly slow down the response of all clients.
5, need to support distributed cluster services, the typical situation is based on a number of physical computers composed of high-speed LAN implementation process cluster.
6, can support both SSL and ordinary TCP connection.
These characteristics determine the architecture design of the system. (i) System structure
The service consists of several modules.
1, network transmission module . Manages sockets for listening, transmitting, and controls the flow of data across different threads. The data is sent and received by a certain size thread pool, and the implementation method is fully benefited from the thread event loop of Qt. is bound to a Qobject object on a qthread, whose signal-slot event loop is the responsibility of the thread. This makes it easy to specify the thread that is used by a socket object. Similarly, a good package that benefits from QT, directly supports TCP sockets and SSL sockets, and can be dynamically adjusted at run time. ( Note: Compiling this module requires QT SSL support, i.e. adding the-OPENSSL option when configure )
2, task Pipeline module . Responsible for the data processing. In computing-intensive applications, the data processing load is heavier and needs to be separated from the network transmission. Based on the processing mode of the common thread pool, there is also the problem of queue blocking-the time-consuming operation of several client requests, blocking the response of other clients, even if the requests of other clients can be processed in a short time, they must wait in line. Using the pipelining thread pool avoids this problem. Each client takes the required action in a granular, in a circular queue, the thread pool to a single client, processing only one granular unit of task at a time. Once a single granular unit is complete, the remaining tasks for that client are reinserted into the tail of the queue. This mechanism ensures that the overall latency of the client is small.
3, service Cluster Management module. The module uses the function of Network transmission module and Task Pipelining module, and realizes the server ßà server link across the process. In high-speed LAN, the connection is fast and stable. As a result, the module is designed as a star-free hub network. Any new server node selects any node in an existing server cluster and, after access, automatically establishes a point-to-point connection to other server nodes via broadcast. This module only provides a server-to-server communication tunnel, not responsible for the interpretation of specific communication content. The control of the transmitted content is determined by the specific application.
4, database management module . This module is based on QT's plug-in database encapsulation Qtsql. The database is managed as a resource and supports the use of database resources under multi-threaded conditions.
5, Frame interface . Although the common service runtime behaves as a background process, in order to better demonstrate the functionality of the server, avoid cumbersome configuration, or need a graphical interface to display the status, set parameters. In this example, the interface is responsible for rotation each state of the server and setting the parameters. The set parameters are stored in an INI file and loaded when the service is turned on.
6, application of proprietary parts module。 The above 1-4 total of four main modules are universal. They are not linked to each other, but only as a resource in the run-time (runtime) of the program. Application of the proprietary part of the module according to the specific task requirements, flexible use of the above resources to achieve functionality. In the sample code, a point-to-point forwarding mechanism is implemented. The presenter virtual out some industrial devices, as well as some operator-used client software. The device and client software need to exchange data after successful authentication and login. Change the code of this module, you can implement your own functions. (ii) Design performance
Project |
Indicator description |
Indicator values |
Note |
Supported Connection types |
Depending on the type of support for QT |
SSL and Plain |
Both classes are supported at runtime. |
Agreement |
Ipv4 TCP, IPV6 TCP |
|
Design the number of single-process connections |
Computed under 4\8 transport thread configuration |
1024\2048 |
Depends on the actual machine performance and task form. |
Design cluster size |
The size of a star cluster is affected by the number of nodes. |
100 nodes, 9,900 cross-server connections. |
The number of connections in the LAN is node count * (Number of nodes-1). |
Design Total User Size |
100 nodes, 2048 users per node |
200,000 |
|
In the next article, we will begin to introduce the design ideas of each module. The test compilation environment for the sample code is given first:
1, Ubuntu 14.04 + Qt5.2.1 OpenSSL self-compiled version
2, Win 7 x64 + vcexpress x64, x86 + Qt 5.2.1 OpenSSL self-compiled version
3, Win XP x86 + vc2010express x86 + QT5.2.1OPENSSL self-compiled version
Main interface:
http://blog.csdn.net/goldenhawking/article/details/25921647
Http://download.csdn.net/user/goldenhawking
A scalable, fully asynchronous C/S architecture server implementation based on QT (stray puppies, six, attached)