Some notes about network programming (server)
http://vcbear.mblogger.cn
Nine programs are given in the UNIX network program for several ways for server processing network connections, and a quantitative comparison is made to the overhead of server process / threads. From personal experience, I feel that the following methods are more practical:
1. The simplest is blocked accept, receives the Connection fork process (UNIX) or create thread. The original process / thread continues to block the Accept, the created process thread only processes the customer request on the new connection. If you ignore the overhead of the creation process / thread, and each connection must correspond to a process / thread, make this that you can meet the most simple application servers. Qmail's TCPServer is also used in this mode. It should be noted that if the child process does not listen to the connection, it is best to turn off the original Listen's socket inherited from the Father's process. Because the Fork's overhead is relatively large, if the response to the server is very demanding, this approach is not practical. In addition, a single-threaded process will be more fast than for a multi-thread process.
2. Introducing Process / Thread Pool Concepts, that is, create a bunch of process / threads, allowing these processes / threads to process connection events and client services. In multi-threaded support, implementing the thread pool is still very easy, only one thread is blocked on accept, after receiving the connection, awaken a thread that is originally blocked on a certain mutex to handle or put it Enter the queue waiting for processing. This way to deal with the client connection can be unlimited (within the system capacity range). But in process mode, because the child process is used to inherit the connection handle, the connection is processed across the connection to process the connection. (Some UNIX can implement the handle of the process, Win32 also has a process of copying handles, but this is too tight to combine the operating system, and not all operating systems support, ignore it)
VcBear.mblogger.cn3. Solving the above process issues to let all processes listen to the same port and Accept connections, you can create a Listen Socket through a process, and for the sub-process for Listen / Accept. It is necessary to consider the amplifier effect, that is to say, all the processes on the listening to the Socket may be woken up by the system, but only one process can be connected in the TCP protocol stack. The amazing effect introduced the process scheduling overhead, and the solution is to lock on accept. Only one process is invoking accept. After getting the connection, the process no longer calls Accept, but processes the client service until the client exits, re-retracting the ACCEPT. Apache1.3.x uses a similar mode that can be seen from its http_main.c. Typical code The following (true) {mutex_lock newcliet = accept (listener) mutex_unlock while (true) {/ * handle the client task until the client is open * /}} 4. These only consider a process / thread corresponding to one connection. Situation, when there is a large number of connections, a large number of threads may occur. Using SELECT allows a thread / process to process multiple connections. Below the following code
IF (Select)> 0) / *> 0 indicates that there is an event in the Select collection * / {/ * sequentially checks the effective socket * / for () {if (fd_isset (sock ...) / ** / {if (sock == serversocket) {/ * is listening to Socket, calling accept, get a new socket, add it to the SELECT collection of this process * /} else {/ * Other socket * /}}}} Combined with 3 mode, such as creating a process that can listen, each process is processes up to 10 client connections, then the process / connection ratio is reduced by 10 times. But in this case, you cannot lock the monitor Socket. It is impossible to avoid the problem. It can be seen that in SELECT, the same may take up a lot of CPUs, which may have been more than the process schedule of the system. Cases that must be handled in a single process to handle multiple connections In the case where it is possible to consider this .ps: UNIX network programming, if there are multiple processes to be blocked on the same socket, then blocking is better than blocked on the accept. 5: Sales SELECT, Suitable places are still good, especially read Socket, using SELECT can effectively achieve timeout blockage, rather than permanent clogging. Risk of clogging the process / thread in network programming is very no Therefore, it is best to set the socket into non-blocking, so that the read function can return, read data or generate an error, error code Eagain / Eintr / Einval indicates that the connection should not be disconnected, and can continue to use.
6: IOCP approach can be used on Windows (see Documents): http://blog.9cbs.net/vcbeart/archive/2001/08/29/5987.aspx). Handle multiple connections with a single process, allow the operating system to worry about the event on the network, and pick it to generate IO. This puts the details of the task schedule in the operating system kernel to avoid process / thread overhead on the application layer. It is said that there are similar epolls on Linux / UNIX, suspects Apache 2.0 uses this technology, has not been obtained. However, if the general code scheme can meet the requirements, I think it should try to avoid the use and operating system extremely related code, such as the IOCP of Win32.
7: Consider the process schedule, process restrictions, and information sharing is relatively fine. The general implementation is to make information on shared memory bulletins, process competition reading books, report their status or obtain additional information. Apache is very beautiful in this piece, which can create more processing processes or control idle processes based on a main process based on the busy level of the connection. Excessive processes / threads still affect system efficiency (quantization calculation reference Unix network programming volume chapter 27)
8: Note: Server Programming must set up Linger, otherwise the client actively Socket is turned off, the server will continue to be 2 * Time_wait, which is really disconnected, causing a large number of waste connections. RLINGER.L_ONOFF = 1; // Open the Linegr switch rlinger.l_linger = 0; // Set the delay time of 0 seconds, pay attention to TCPIP immediately shut down, but it is possible to become incarnate setsockopt (NSOCKFD, SOL_Socket, SO_Linger, (char *) & rlinger, SIZEOF (RLINGER)) Another option SO_REUSEADDR is also set to Server Socket. No matter what model is used to write the server, the problem that needs attention needs to be concerned In addition to the network event response, the process / thread scheduling, there is a capacity problem of the server itself. The shortest wooden board is actually not dealing with the model itself of the network connection, but the data processing power or network bandwidth on the server. If a server and its network bandwidth are accepted, 100 clients have been very difficult (such as FTP, MUD) , P2P, Other Application Services ...), then its Socket server does not make sense to easily handle 10,000 connections.
