Total
The client program is generally relatively simple, and the server program is more complicated because the design of the server program must take into account the performance factor such as response speed and response capability. This paper mainly discusses the connection-oriented server program design method.
Overall server programs can be divided into two categories: concurrent server, and a serial server (iTERATIVE SERVER). The former is primarily targeted by real-time client / server mode, and the latter is primarily a small customer / server mode.
2 TCP serial server program
Serial server programs are like this: Each time it can only provide services to a client program, only after the request is completely processed, in response to the request of the next customer, that is, according to FIFO's principles. This method can generally use the serial server program, but the server programs such as time / date are small and real-time requirements. From the perspective of process control, the speed of this method is the fastest because it does not perform process control, and the system overhead is small.
3 Traditional TCP process concurrent server programs
In this way, after receiving the client request, the concurrent server program is derived from a child process to serve the client, then returns to the waiting state, ready to receive the next client program, the child process is completed After exiting. Among them, the concurrent server program as a parent process becomes the master server (MASTER), and the child process for processing the customer request is from the server (slave).
Figure 4 Traditional TCP Process Concurrent Server Program Framework
The problem with concurrent servers is that the CPU is consumed many times when the Fork () operation) is consumed, which is extremely unfavorable to the system where the server process that needs to be responsive to the number of client processes, such as the web server.
3.4 TCP pre-seizures child process concurrent server program
Based on the traditional TCP process concurrent server program, some modifications can be made. The conventional TCP process concurrent server program responds to the response is the derived child process. This way is now changed to: After the server program is started, it will be a few sub-process for response, and these sub-process constitute a serial process group, while the parent process has a monitoring process.
Fork
Available sub-process group
. . .
Parent process
Sub process 1
Sub-process 2
Sub process 3
Customer 2
Customer 1
Sub-process N
Figure
5 TCP
Pre-sect a child process
The problem that needs to be resolved here is: How to maintain a certain amount of available sub-process; how to wake up the child processes when the service request arrives, and how the parent process will pass the necessary information to the child process.
The parent process monitors the number of available sub-processes. When the number is below a certain threshold, some child processes are derived, and some available sub-processes are terminated when the number is higher than a threshold. Of course, the total number of sub-processes should also have an upper limit to prevent system resource consumption. This allows the number of available sub-processes and the total number of processes to remain within a certain range.
The predecessor has obtained a child process to enter a sleep state after each call accept (). Since these sub-processes share a Socket structure, when a household request arrives, it will cause the Thundering Herd - Wake all the child processes. Of course, only the child's process that is first scheduled will get the customer's connection, and the other child processes will enter sleep. This situation will lead to a decrease in system performance. The method of solving this problem is to lock the Accept, that is, the atomicity of the Accept operation. Some UNIX systems have solved this problem in the kernel, there is no need to lock the Accept.
If the child process is just a copy of the parent process, there is basically no need to consider the process communication. If you transform the parent process into a daemon similar to the inetd (call the fork () generated sub-process, you must solve the communication problem between the parent process synopsis through the EXEC system to call the execution service handler. There are a variety of mechanisms for process communication under UNIX, such as Pipes, Named Pipes, IPC Messages, and the like. Here we use the IPC message queue to deliver the Socket description word to the child process. Figure 6 TCP pre-dynasty child process method using IPC message mechanism
5 TCP thread concurrent server program
The performance of thread is 10 to 100 times higher than the process. Write a thread function must pay attention to the thread security of the function. It is not all the different versions of all UNIX systems or the same UNIX support threads. Since the method of thread server program is similar to the process server program, it is not described here.
(Forgot to see where it is, it feels good in mybase, thank the original author)
