Design method of Unix socket server program

  1 general statement <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office"/>

The client program is generally simpler, and the server program is more complex, because the server program design, must take into account its response speed and responsiveness and other service performance factors. This article mainly discusses the connection-oriented server programming method.

In general, server programs can be divided into two categories: Concurrent Server (Concurrent server) and serial server (iterative server). The former focuses on the real-time client/server model, which is focused on the client/server model with small service volumes.

2 TCP Serial Server program

Serial Server program is this: each time it can only for a connected client program to provide services, only after the full processing of a customer's request, to respond to the next customer's request, that is, in accordance with the principle of FIFO response request. The serial server program is rarely used, but it can be used by server programs that have small service volumes such as time/date and are not demanding in real time. From a process-controlled standpoint, the speed of this approach is the fastest because it does not process control and has little overhead.

3 the traditional TCP Process Concurrent Server program

In this way, the concurrent server program, after receiving a client request, derives a child process to serve the client, returns to the waiting state, prepares to receive the next client request, and the child process exits after the service completes. Where the concurrent server program that is the parent process becomes the primary server (master), the child process that handles the client request becomes the from server (slave).

Figure 4 The traditional TCP process Concurrent Server program framework

The problem with concurrent servers is that the derivation process (fork () operation) consumes a lot of CPU time, which is extremely detrimental to the system on which the server process needs to respond to a large number of customer processes, for example, for Web servers.

3 . 4 TCP Pre-derivation child process concurrency server program

On the basis of traditional TCP process Concurrent server program, the response mode can be reformed. The traditional TCP process Concurrent server program responds in the form of a response that is a derived child process. Now change this way: The server program starts with a few child processes in place to respond, which form the service subprocess group, and the parent process becomes the monitoring process.

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml"/>

Fork

Available child process groups

．．．

Parent process

Child Process 1

Child Process 2

Child Process 3

Customer 2

Customer 1

Child process N

Figure 5 TCP Pre-derivation subprocess

The question to be solved here is how to keep a certain amount of available subprocess, how the mechanism that wakes the subprocess should be when the service request arrives, and how the parent process passes the necessary information to the child process.

The parent process monitors the number of child processes available and, when the number is below a threshold, derives some child processes, terminating some available child processes when the number is higher than a certain threshold value. Of course, the total number of child processes should also have a maximum value to prevent system resources from being exhausted. This allows the number of child processes available and the total number of child processes to remain within a certain range.

Pre-generated subprocess enters the sleep state after each call to accept (). Because these sub processes share a socket structure, when an accessible request arrives, a panic group (thundering Herd) is created--all child processes are awakened. Of course, only the first scheduled subprocess will get the client's connection, and the other child processes will go to sleep again. This situation can lead to a decrease in system performance. The solution to this problem is to lock the accept, that is, to ensure the atomic nature of the accept operation. Some UNIX systems have solved this problem in the kernel, so there is no need to lock the accept.

If the child process is just a copy of the parent process, there is no additional consideration for process communication. If the parent process is transformed into a daemon similar to inetd (the first call to fork () to generate a subprocess and then the service handler through the exec system call), the communication problem between the parent process and the subprocess must be resolved. There are several mechanisms for process communication under UNIX, such as pipelines (pipe), Named pipes (named pipe), IPC messages (interprocess communication message), and so on. Here we use IPC Message Queuing to pass the socket descriptor to the subprocess.

Figure 6 TCP Pre-derivation Subprocess method using the IPC message mechanism

5 TCP Thread Concurrent Server program

The

Thread executes 10 to 100 times times more efficiently than the process. You must be aware of the thread safety of a function when writing a thread function. Not all UNIX systems or different versions of the same UNIX support threads. Since the method is similar to the design of the process server program, there is no more description.