C + + server Design (vi): Life cycle management of device connections

Life Cycle Introduction

New connections for each server system go through multiple stages from the start of the establishment. such as connection establishment, login verification, resource release before exiting. At the same time in the specific message processing, you will also encounter an unrecognized message event, or a message processing data errors and so on. These scenarios may be experienced throughout the life of each connection, and system users will expect certain actions to be done in some scenarios. such as the statistics of each new connection information, the different types of customers to verify the process.

In a typical server system, users need to proactively maintain the current state for each connection object, then add a judgment on the status of the current connection in a specific business scenario, and perform the related lifecycle operations in each scenario that alters the connection state. This self-maintained connection to the life state of the practice, may be not separated from the business logic leads to the actual business processing part of the code confusion, which also increases the complexity of user development, so that the actual development work error rate greatly increased.

For each of the different message processing processes, it is possible to have scenarios in the business logic that deal with errors or non-knowledge of other data. These need to add a large number of actual business-agnostic error-handling code to each message-processing code. This is also not conducive to the writing of business code, increasing the workload of developers duplication.

In the design of the server system, we put forward the concept of the device life cycle, and through the system to the connection state and the management of the error, extracted the connection life cycle and error processing related interface. When a user needs to work on a connected client in a state, it is necessary to rewrite the interface function of the relevant state, and for all error actions, it can be handled in the specific business logic, or by implementing a unified error-handling process in the corresponding interface function. This greatly simplifies and facilitates the development process for server users.

In addition to the previous system support for multi-device types, the connection lifecycle interface needed to be used in the specific design is implemented in the corresponding device type object. In different device types, the interface implementations for a life cycle are not necessarily the same. At the same time, the subclass device type inherits the interfaces implemented in the parent class device type, and the interfaces implemented by the parent class can be overridden in subclasses. So we can make different life cycle interfaces for different types of devices.

Figure 4-8 Connection life cycle

4-8 shows a connection from the connection to the disconnected life cycle graph, including the lifecycle of the temporary device type and the life cycle of the login device. It identifies the relevant interfaces provided by the system in different scenarios. At the same time, the server system guarantees that callbacks for each connection's lifecycle interface will be processed in a single I/O thread assigned to the connection object, so there is no need to consider multithreading for a single connection.

Life Cycle Interface

These interfaces are described in detail below:

• L onCreate (): This interface callback will be executed whenever a new connection is established. Because each new connection is initially created as a temporary device type, the interface is implemented by default in the temporary device type object and can be modified by rewriting the temporary device type to implement the interface. You can record information about a new connection in the implementation, or count all new connection information for the system.
• L onlogincheckmsg (): This interface callback is executed whenever a logon message event is executed. This interface is implemented by default in the logon device type object and can be overridden by creating a new, specific logon device type. The login check operation can be performed in this interface implementation. For example, you can query the DB and other ways to check the login device account is legitimate, and you can assign the corresponding device ID for the connection. If the logon check fails, send a failed reply message and return directly to false. If the check succeeds and returns True, the system will further log on, and if the final login succeeds, the onloginsuccessmsg () interface will be recalled, and if the system check ID fails, the ONLOGINFAILUREMSG () interface will be recalled.
• L onloginsuccessmsg (): The interface callback will be executed whenever the logon operation is performed and the login succeeds. This interface is implemented by default in the logon device type object and can be overridden by creating a new, specific logon device type. You can implement a notification to send a successful login to a client connection in this interface. At this point, the connection enters the lifetime of the logon device and can request all message events of that device type.
• L onloginfailuremsg (): The interface callback will be executed once the connection has been successfully verified by the ONLOGINCHECKMSG, but the system's further logon operation fails. This interface is implemented by default in the logon device type object and can be overridden by creating a new, specific logon device type. This callback is typically performed to indicate that the device ID of the connection setting conflicts with a device ID that is logged on, indicating that the account is logged on or the device ID set for the connection is wrong.
• L onlogoutmsg (): This interface callback is executed whenever a logged-on connection client requests a logoff message event. This interface is implemented by default in the logon device type object and can be overridden by creating a new, specific logon device type. When the interface is called, it indicates that the connection is about to be exited and disconnected, and that the Releaseconnnode () interface is invoked to release the associated resources for the connection client request. You can reply to the connection client in the interface implementation to notify the logoff operation to be successful and will be closed.
• L Releaseconnnode (): The interface callback is executed whenever the logged-on connection client logs off successfully, or if the connection is forced to exit due to a timeout or other exception reason. This interface is implemented by default in the logon device type object and can be overridden by creating a new, specific logon device type. When the interface is called, it indicates that the connection object is about to be or has been disconnected, and if some resources were previously requested for the connection and are still not released, the release operation needs to be made in this callback. Because the connection may already be in a disconnected state, you should not attempt to send a message to the connecting client in this callback.
• L Onovertime (): The interface callback will be executed whenever a connection has not received a valid message for a period of time. This interface is implemented in the device type object and can be overridden in either the temporary device type or the newly created specific logon device type. When the interface is called, it indicates that the connection object is about to be disconnected. If it is a connected client that is already logged on, execution of the call will execute Releaseconnnode () for resource release. You can notify the connection client in this interface implementation that the connection is about to be actively disconnected due to a connection timeout.
• L Onerrtypemessage (): Every time a connection receives a message, if the handler for the message event is not found in the device type of the connection, and the handler function for the message event is not found in the temporary device type, the interface callback will be executed. This interface is implemented in the device type object and can be overridden in either the temporary device type or the newly created specific logon device type. When the interface is called, it indicates that the connection received a message event that was unrecognized or not sufficiently privileged to handle. The connection client can be notified in this interface implementation that the message event cannot be processed.
• L Onerrrunmessage (): Each time a connection receives a message, if some error occurs while processing the message, the interface callback will be executed, resulting in a parse processing error. This interface is implemented in the device type object and can be overridden in either the temporary device type or the newly created specific logon device type. When the connection is called, a message Event processing error is indicated. You can notify the connection client of this message event handling error in the interface implementation.

Login Process Analysis

During the life cycle of different device connections, the server system has a unified set of login mechanisms for all managed devices. The entire login process is shown in 4-9. This mechanism not only guarantees the unified management of different devices, but also provides three login-related interfaces for specific equipment implementation, to ensure the difference in the process of login between different devices.

Figure 4-9 Login Process Analysis

When a connecting user requests a logon operation to the server, the system first checks to see if the connection is already logged in, and if the connection is already logged in, it goes directly to the logon success operation. If the connection is not logged in, the system sets the device type for the connection based on the type that was passed in the request logon message. If the device type set in the message does not exist, or if the device type is not set, the system will default to the logon device type (NodeType) for that connection.

Then the login account check operation. This will enter the ONLOGINCHECKMSG () callback for the specific device type of the connection. The default implementation of this interface is to return to true without any check operation. We can override this interface implementation in different device type objects, depending on the requirements of the different devices for the login account check. For example, according to the request login message from the account and password information, query the database for verification and so on. You can also assign a login ID to the connection based on the account password information, and if not assigned, the system-assigned temporary ID will be used as the login ID. If the account check fails, the logon operation fails, returns false directly, and exits the entire logon operation. If the account check succeeds, it returns true, but this does not mean that the connection has been successfully signed in because the connection does not actually perform the logon operation.

After the account check succeeds, it will enter a true login operation, and the system will attempt to register the connection information with the connection pool of the corresponding device type and remove the connection from the connection pool of the temporary device type. However, there may still be an error that the account ID is already logged in or logged on at another client, causing the system to not complete the logon operation for that connection. If this occurs, the onloginfailuremsg () interface will be recalled. We can use this interface to notify the connection client of this login failure and possible causes. When the interface finishes executing, the entire logon operation exits.

If the system performs a successful logon operation, the ONLOGINSUCCESSMSG () interface will be recalled. When the interface is executed, the logon operation is counted as a true login success. Therefore, we can use this interface to notify the client of the success of this login message. After the interface execution is complete, the login operation ends.

Exit Process Analysis

Unlike the login process there is only a single entry, that is, through the logon message event. There are several possibilities for the exit operation of the connection. For example, the most normal way to log on to a connected user is to opt out by logout logoff message events. However, there are many other possibilities: for example, if a remote client does not send any messages that suddenly disconnects the server, or if the connection client has not sent any messages for a long time, the server detects the connection timeout, and so on. We need to establish a unified management of these exit operations, prevent abnormal exit so that the server system can not release the relevant resources in a timely manner, affecting system performance.

Figure 4-10 Exit Process Analysis

4-10, if the Logout logoff event request exits for the connecting client, the system executes the logoff handler for the event registered in the logon device type. In the logoff handler, the Onlogoutmsg interface that connects to the actual device type is called, which notifies the connecting client that the connection is about to be shut down by the system. The connection type's Releaseconnnode interface is then invoked to release the associated resources for the connection user request. Finally, the system will perform an actual exit operation on the connection, forcing the connection to be removed from the connection pool and shutting down the connection.

If the connection client does not request a logoff event, the connection to the server is disconnected directly. At this point the server system will return the read system call through the connection socket to 0 to detect that the connection has exited abnormally. Because the connection is disconnected at this time, there is no need to notify the client again, so the system will call the Releaseconnnode interface of the connection type directly, releasing the related resources requested by the connection user. and performs an actual exit operation, forcing the connection to be removed from the connection pool and shutting down the connection.

If the server detects a connection timeout through the timeout mechanism, the system will perform a time-out processing for that connection. In time-out processing, the system will ensure that the connection timeout handler is executed in the thread of the connection through the thread task queue, at which point the Onovertime interface of the connection type is called, leaving the user to handle the scenario where the connection timed out. The same Releaseconnnode interface is then released to release the associated resources for the connection user request. and performs an actual exit operation, forcing the connection to be removed from the connection pool and shutting down the connection.

The Releaseconnnode interface is called in the above three scenarios, so we should ensure compatibility of these scenarios in the implementation of this interface, only the release of related resources that connect the user request. Other specific scenario-related processing work is implemented in other related interfaces.

C + + server Design (vi): Life cycle management of device connections