C + + server design (0): Overall design

This series affixed the part of the graduation thesis to save a souvenir. The whole series is divided into three parts, of which the first chapter to the third chapter is the introduction of the server system layer design, design ideas refer to Libevent and Muduo and other open source code implementation; The fourth chapter to the sixth chapter is the service layer design of the server, the design ideas refer to their own Khala realization The seventh chapter introduces how to use the server framework to implement a chat system similar to QQ. The full text mainly refer to Aboutspeaker's "Linux Multithreading Server Programming", "UNIX Network Programming Volume 1".

System Introduction

This system is a TCP network server framework implemented by C + + design. The low-level I/O part of the system employs a non-blocking model based on reactor mode, and the thread part uses the event loop+ thread pool model. The service layer of the system has the functions of time-out detection management, multi-type device and multi-event message management, and connection lifecycle management. At the same time, the whole system realizes the multi-threaded network framework which separates the network implementation from the business logic through encapsulation.

The framework for network business developers, the entire network server development process to provide a higher level of encapsulation, can greatly reduce the difficulty of business development. Through this framework, developers do not have to care about the implementation of the underlying network I/O and the concurrent connections under multi-threading, simply write the business logic as a message response event based on the type of business-specific device, and optionally use the service-tier-provided services as business support.

This framework is applicable to the business scenarios based on TCP long connections within the LAN. such as the smart home under the multi-device management, LAN, multi-user chat tools. In these scenarios, by using the system framework, developers only need to write a few business-related code to accomplish the service-side functionality.

System Requirements Analysis

This server system mainly from the high efficiency and easy to use two aspects as the core of the design.

High efficiency refers to the reasonable design of the bottom of the system I/O and threading model, make full use of CPU and memory resources, to achieve the highest possible high connectivity and high concurrency requirements. Only the use of server hardware performance is considered here, regardless of the Ethernet bandwidth limitations.

Ease of use is considered from two aspects. The first is to separate the network details from the business logic, so that the developer of the framework is freed from the trivial details of the underlying, focusing on the writing of the business logic, and the second is providing a layer of service to support developers who have special needs in specific situations such as connection timeouts, multi-device and life-cycle support.

The basic requirements of this server system are analyzed as follows:

• Environmental requirements: This system is only considered in the safe and controllable LAN internal use, the network data using clear text transmission, the local area network client may be due to failure or the crash and other anomalies caused the server to disconnect. However, it does not consider scenarios where the server may be maliciously attacked by some users. Therefore, this system does not make special enhancements for security. It is not safe to use this server system in a public network environment.
• L Operating System requirements: Because the server system involves a large number of processes interacting with the underlying operating system, such as I/O and network processing, the system calls from different operating systems are not identical. For example, on I/O multiplexing, although most systems provide select as a system call, the call has an O (n) time complexity and is inefficient. Therefore different systems each implement different similar system calls as optimizations, such as the Linux system provided under the EPOLL,BSD system provided under the Kqueue,windows provides the IOCP. Although these system features can be encapsulated through the adapter mode, abstracting a layer of cross-platform unified interface, but this will greatly increase the overall design implementation of the workload, and this is not the focus of the system design. Therefore, this server system only supports Linux under X86-64, regardless of portability, does not support other platforms such as Windows.
• L Network requirements: Because the server system involves the network programming process based on TCP/IP protocol, there are many choices in TCP/IP. In the transport layer, there are TCP and UDP two protocols, where TCP is a reliable byte-stream protocol, and UDP is unreliable datagram protocol. As the server system is mostly used in local area network, and there is no transmission requirement of large data such as audio and multimedia applications in native business, and because the design of the life cycle of the connection will be the focus of the system design. Therefore, we prefer to use the reliability-based and ordered, connection-oriented TCP protocol, does not support the UDP protocol. At the same time, due to the relationship between development times and costs, the system only currently supports IPV4, regardless of compatible IPv6.
• L Performance requirements: As a server system, you should be able to take full advantage of CPU and memory resources. At the same time can play multi-core processor performance, native support multi-core multi-threading, and ensure thread security, and not like Libevent itself only support single-threaded, need to post-threading modification.
• L Data Transfer requirements: The TCP protocol is a borderless byte stream protocol, but the read and write data processing is in a full message unit. Therefore, the server needs to be able to distinguish the message boundary, can solve the "currently received data does not constitute a complete message" and "once received multiple messages data" and so on. At the same time in the multi-threaded environment needs to ensure that the message is correct and orderly, that is, a message can not be mixed with another message in the data, and each message in the order of receipt waiting to be processed. At the same time the above details can not be exposed to the user, the user should only pay attention to receive a complete message processing, and each send out a complete message.

At the same time, the server framework provides a number of specific services that can facilitate the development of certain special operations. Developers can choose to use some of these framework service support, or they can choose to implement them separately. These service-related requirements are analyzed as follows:

• L Timeout Detection: The server should be able to detect idle connections that have not sent valid data for a long time. These connections are most likely a zombie connection caused by a machine outage, a network cable failure, or a firewall. A large number of zombie connections will consume server resources and affect server performance. Therefore, when the server detects these possible zombie connections, it should attempt to notify these connections and eventually disconnect the zombie connections and release the system resources they occupy.
• Multi-Device Management: Unlike traditional servers, the messages are only parsed back, and message events are not categorized as managed. The server system should be able to manage the device types of different connected customers and be able to manage the rights of different message messages from different types of devices. That is, a connection with one device type does not have permission to request a message event that belongs to another device type. If a message event belongs to more than one device type at the same time, the message handling mechanism for each device type's connection request for that message event is different. Users can create new device types for the system, register different message events for the device type, and write specific business processing code for each message event.
• L Connection Lifecycle Management: The process of each connection has multiple stages, such as the establishment of a connection, verification of login, processing before exiting. The server reserves different interfaces for each of the different phases of the connection and ensures thread safety of the code within those interfaces. These interfaces are managed by different device types, and users can override these interfaces for different device types to accomplish the operation management of each connection at different stages of different device types.

Overall system architecture

2-1, the entire server framework consists of the system layer, the service layer, and the user layer, running on top of the Linux operating system. The system layer and the service layer constitute the framework body and are provided to the user layer through the related interface. The user layer is implemented by the users of the framework in accordance with the specific business. The specific description of each layer is as follows.

Figure 2-1 Service Framework software architecture diagram

The system layer is the core of the entire server system framework. It interacts with the operating system, through the mechanism of I/O and threading, ensures the normal and efficient operation of the whole system, and provides the encapsulation of the details of the underlying system and network, and guarantees the separation of the specific business logic from the upper layer.

The system layer consists of four parts, the reactor mode, the multithreaded model, the connection object, and the application layer I/O buffering. In the reactor mode, the non-blocking I/O mechanism implemented by the Epoll system call in Linux realizes the management of the I/O events of different connections and forms the main body of the system layer. In the multi-threaded model, the event loop + thread pool mechanism [39] is used, and the threads communicate with each other in the form of task queues, and are guaranteed to be managed in one thread for the entire connection cycle of each connection. In the Connection object section, information such as the descriptor for each connection and connection-related operations are encapsulated. In the application layer I/O buffering, the data receiving and transmitting processing under non-blocking I/O is encapsulated by buffering mechanism, which guarantees the integrity of the data receiving and sending.

The service layer is further encapsulated on the basis of the system layer and provides more service functions. Theoretically, the entire framework can be stripped of the service layer and run separately on the system layer, but the ease of use of the framework will be compromised, and the business logic will be easily penetrated into the code of the system layer. Users can choose to use certain features of the service tier to shut down services they do not need, depending on their business needs. Therefore, in actual use should be based on the interface provided by the service layer for development work.

The service layer consists of three parts: Connection time-out management, multi-device type management, and connection life cycle management.

In connection timeout management, the service layer clocks each connection through the heartbeat mechanism, and the client needs to send valid data to the server at intervals, notifying the server that the connection is still online. When the server detects a connection timeout, it executes the processing mechanism implemented in the timeout interface and forces the connection to be disconnected and removed from the system. The user can set the time-out period and make different time-out mechanisms for different devices through the timeout interface.

In multi-device type management, the service layer provides a mechanism to develop different message events in device type and to implement specific processing for different message events. The service layer defaults to two device types, the temporary device type and the logon device type, and has a message event and processing associated with the login.

The life cycle management of a connection is primarily to provide a set of interfaces related to the lifecycle state change and error handling of the connection, and is managed in the device type. These lifecycle States include connection creation, login, timeout, and exit. Users can make different life-cycle interface implementations for different device type connections, such as counting each new connection information, or validating different types of login connections.

Figure 2-2 User-created new device type

The user layer is located on the entire server system framework and is implemented by the users of the framework according to the specific business requirements. The main work of the consumer is to create a new device type object based on the connection type, 2-2, and register the business-related message event and processing mechanism for the new device type, and implement the device type for the life cycle interface of the connection according to the requirements.

Disk File I/O and database operations are not involved in the overall server framework design, and database operations are typically involved in specific service-side business programming. If you need to connect to use the database, the server developer should implement or import the third-party database Operation class Library, such as mysql++ Library, at the user level of the system, and interact with the background database through the API of the library.

C + + server design (0): Overall design