Collaborative semi-resident server program development framework-Based on Postfix Server framework Transformation

I. Overview

Now, when writing applications with Java, PHP, And. net, some mature service frameworks are used, so the development efficiency is relatively high. However, when using C/C ++ to write server programs, there are a wide variety of applications. Some people use ACE and some others use ice (claim to be much better than Ace, these types of server frameworks and libraries are rich, but the entry threshold is relatively high. Therefore, more people directly write their own server programs. At the beginning, they thought it was relatively simple, but it took a long time to write, it will be difficult to expand, with low performance and error-prone. In fact, the author of Postfix provides us with an efficient, stable, and secure server framework model. Although Postfix is mainly used as the message system's MTA, its framework design is very universal. The author of ACL (http://acl.sourceforge.net/) extracted the Server framework model of Postfix to form a more general server program development framework, so that programmers can get twice the result with half the effort when writing server programs. This article describes the design and functions of the acl_master server program (based on the postifx server program framework) in the ACL.

Ii. Frame Design Diagram

As shown in:

Figure 1-framework Diagram

The master process is a control process. When started, the master is responsible for listening to all port services. When a new client is connected, the master starts to subscribe to the process for service, while the master still monitors the server port, at the same time, it monitors the working status of sub-processes. When a sub-process that provides external services is started on the master node, the sub-process will not be started if there is no request task, only when a connection or task arrives will it be started by the master. After the sub-process of the Service finishes processing a connection service, it does not quit immediately, but will reside in the system for a period of time, wait for a possible new connection to arrive, so that when a new connection arrives, the master will not start a new sub-process, because there are already idle sub-processes waiting for the next connection request; when the idle time of the service sub-process reaches a threshold value, it will choose to exit and return all resources to the Operating System (of course, you can also configure the mode in which the service sub-process will never exit ). Therefore, this server framework can be called a collaborative semi-resident Server framework. We will further introduce the collaborative and semi-resident server frameworks.

Iii. Collaboration Methods

The Postfix Server framework is designed very cleverly because the master is a user space process after all and cannot control the running time slices of each process as the operating system does, therefore, the master process must collaborate with its sub-processes to handle the following processes:

1) when a new connection is established, the master starts a new sub-process to take over the connection or the idle sub-process directly takes over the connection.

2) When should the master start a new sub-process?

3) when a new connection arrives, how can the sub-process in the idle sub-process pool compete to take over the connection?

4) How does the master process the new connection when the sub-process exits unexpectedly?

5) how to select the exit time for idle sub-processes (idle time or service count should determine the exit time of the sub-process)

6) How does the master know the working status of each sub-process (is it dead or alive ?)

7) if the sub-process program of the service is updated online, how to add new services, and how to update the sub-process configuration online without stopping the service

8) How to reduce the number of communications between all sub-processes and the master to reduce the load on the master

Iv. Flowchart

1) Master Process Flowchart

 

Figure 2-master Process Flowchart

The IPC communication mode between the master process and each sub-process in postifx is pipeline, so the number of pipelines is proportional to the number of sub-processes. If the MPs queue is interrupted, the master determines that the sub-process corresponding to the MPs queue has exited. If the sub-process exits unexpectedly, the master also needs to mark the sub-process pool of this service class to prevent such sub-processes from exiting frequently and starting frequently (if the sub-process is started too frequently, it will cause a huge load on the operating system ); in addition, if a sub-process of a certain service unexpectedly exits when the first connection of the service, the master considers the service to be unavailable, therefore, when a new connection arrives, the sub-process of the Service will be delayed.

When there are idle sub-processes in the service sub-process pool, the master will give up the listening permission of the Service port, so that the idle sub-process of the Service receives new connections on the Service port. After a sub-process obtains a new connection, it immediately notifies the master that the sub-process is in a busy state, and the master immediately finds out that there are no idle sub-processes in the sub-process pool of the service, if yes, the master still does not take over the Listening Task of the Service port. If no, the master immediately takes over the Listening Task of the Service port. When a new connection is received, the master checks whether there are any idle processes of the service. If there is any idle process, the master gives the listening permission of the Service port. If not, the master starts a new sub-process and then gives the listening permission.

2) service sub-Process Flowchart

Figure 3-Child Process Flowchart

When the master process is started, the sub-process does not start with the master because there are no service requests. In this case, the master is responsible for monitoring all service ports, when a client is connected, the sub-process of the service is started by the master and receives the new connection. before further processing the client request, the sub-process must let the master process know that it is "busy", so that the master can decide whether to take over the monitoring task of the Service port again, therefore, the sub-process sends a "busy" message to the master before receiving and processing the client request. After the sub-process completes the request task for the client, you need to send an "idle" message to the master to indicate that you can continue to process the new client connection task. This "busy" and "idle" message reflects the collaboration between the service sub-process and the master process.

Of course, the service sub-process can choose the appropriate exit time: if your service count reaches the configured threshold, or your idle time reaches the threshold, or the IPC pipeline is interrupted between the master process (generally caused by the master stop service requiring all service sub-processes to exit or the master requires all service sub-processes to reread the configuration ), then the service sub-process should end running. This stopovers reflects the collaboration between sub-processes and master processes, and also the semi-resident feature of sub-processes, this reflects the semi-resident feature of the sub-process pool. The biggest advantage of this feature is: On-Demand allocation. When many request connections exist, many sub-processes are started and run, when there are few request connection tasks, only a few sub-processes are running, and others exit.

3) Summary

The above describes the logic flow chart of the master process and service sub-process in the Postfix Server framework model. Of course, the internal implementation points and details are far more complex than those described above, it's just that someone else has helped us block these complex aspects. What we need to do is to write our own application services on this basis, the following briefly introduces how to develop server programs in the abstract ACL Library Based on the Postfix Server framework, so that you can get started easily.

5. Introduction to five Server framework templates

To use the ACL server Framework library to develop server programs, we should first introduce two terms: acl_master server master process and server template. The master process of the acl_master server has similar functions as the master process in the Postfix. Its main function is to start and control all service sub-processes. This program does not need to be written, it is written in the ACL Server framework. The so-called server template means we need to select a server model (that is, the server template) from the ACL Server framework according to our own needs ), then, when writing a server, you can write it as the server template. Why should we select a suitable Server framework template? This is because Postfix itself provides three types of server applications (single process, single connection process pool, single process, multi-connection process pool, trigger process pool ), these three types of applications use the three server templates in Postfix respectively. In addition, two server application forms (multi-threaded process pool and single-process non-blocking process pool) are added to the ACL ). The following describes the five Server framework templates one by one:

1) single-process single-connection process pool: A process pool consists of multiple processes started by the acl_master master process to provide certain services. However, each process can only process one client connection request at a time.

2) single-process multi-connection process pool: A process pool consists of multiple processes started by the acl_master master process to provide certain services. Each process can simultaneously process connection requests from multiple clients.

3) trigger process pool: A process pool consisting of multiple processes started by the acl_master master process provides a timer Service (similar to cron in UNIX). When a timer arrives, A process starts to run the processing task.

4) multi-thread process pool: A process pool consisting of multiple processes started by the master acl_master process provides certain services. Each process is composed of multiple threads, and each thread processes a client connection request.

5) non-blocking process pool for a single process: a process pool consists of multiple processes started by the acl_master master process to provide certain services. Each process can process multiple connections concurrently (similar to nginx, Lighttpd, squid, IRCD), because the non-blocking technology is used, the model server's concurrent processing capability is greatly improved, and the system resource consumption is also minimal; of course, this model and the multi-process connection pool of a single process both adopt non-blocking technology. However, this model is used for more application encapsulation and advanced processing, making it easier to write non-blocking programs.

In the preceding five server modes, as multiple process instances can be configured as needed, multi-core systems can be fully utilized. Among them, the operating efficiency of the 5th types is the highest, of course, its programming complexity is higher than its own, and the 1st types are the lowest execution efficiency, in fact, it is also the safest (smtpd/SMTP and other processes in the Postfix belong to this type). In contrast, the 4th types are a good compromise in terms of running efficiency and writing complexity, therefore, when writing a general server, this server model is recommended by the author. In addition, there is another benefit of the 4th solutions, which can eliminate the need to occupy threads for NULL connections, this also greatly provides the concurrency (that is, the number of threads can be much smaller than the number of connections ).

Vi. Introduction

This section does not introduce the specific programming process, but introduces some configuration and use processes. Assume that the server program echo_server has been written, which can be written using any server model in 1), 2), 4), 5) above. Assume that the program uses 4th; in addition, assume that the root directory of all files such as acl_master is/opt/ACL/, the master process program acl_master and echo_server are installed in/opt/ACL/libexec /, the acl_master master configuration file is installed in/opt/ACL/CONF/, and the echo_server configuration file is installed in/opt/ACL/CONF/service /, the log file directory is/opt/ACL/var/log/, and the process number file directory is/opt/ACL/var/Pid /. For example, if you set the echo_server service port to 6601 and the service address to 127.0.0.1, it only provides simple echo services.

You can run/opt/ACL/SH/start. sh script to start the master acl_master process (use PS-Ef | grep acl_master to see that the master process exists, but PS-Ef | grep echo_server does not find it ), then you Telnet 127.0.0.1 6601 on a Unix terminal and PS-Ef | grep echo_server on another terminal will find an echo_server sub-process, then, enter some strings on the terminal of Telnet 6601 and immediately get a response. Close the telnet connection and use PS-Ef | grep echo_server to find that the process still exists, when Telnet 127.0.0.1 6601 again, the echo_server process continues to provide services for the new connection. Try to open several more terminals and telnet 127.0.0.1 6601 at the same time to see how it works?

Note that the configuration file format of the service sub-process must be consistent with the template type used; the maximum number of processes in the process pool, the maximum number of threads in the process pool, the maximum number of processes, and idle time can all be specified in the configuration file.

Personal microblog: http://weibo.com/zsxxsz

References:

1) quickly create your server program-single process Pool Model
2) server program design based on Postfix Server framework

3) develop a multi-threaded process pool server program --- ACL Server framework application

4) use the ACL library to quickly create your network program-acl_vstream usage

5) use the ACL library to develop highly concurrent semi-resident thread pool programs

Download: http://sourceforge.net/projects/acl/

SVN: SVN checkout SVN: // svn.code.sf.net/p/acl/code/trunk ACL-code

GitHub: https://github.com/zhengshuxin/acl

Collaborative semi-resident server program development framework-Based on Postfix Server framework Transformation