We see TCP clients processing two inputs at a time: standard input and TCP sockets. The problem we are experiencing is that the server process will be killed when the customer is blocking the (standard input) Fgets call. Server TCP sends a FIN correctly to client TCP, but since the client process is blocking the process of reading from standard input, it will not see this EOF until the socket is read (possibly over a long time). Such a process requires a capability to inform the kernel beforehand that the kernel notifies the process once it finds that one or more of the I/O conditions specified by the process are ready (that is, the input is ready to be read, or the descriptor can take more output). This capability, called I/O multiplexing, is supported by both the Select and poll functions.
I/O multiplexing is typically used in the following network applications:
When a customer processes multiple descriptors (usually interactive input and network sockets), I/O multiplexing must be used;
If a TCP server is to process a listening socket, but also to handle connected sockets, generally use I/O multiplexing;
It is possible for a client to handle multiple sockets at the same time, but relatively rare;
If a server is to process TCP, but also processing UDP, the general need to use I/O multiplexing.
If a server is to handle multiple services or multiple protocols, I/O multiplexing is generally used.
I/O multiplexing is not limited to network programming, and many important applications need to use this technology as well.
Basic differences between the 5 I/O models available under Unix:
1. Blocking I/O;
2. Non-blocking I/O;
3.I/O multiplexing (select and poll);
4. Signal-driven I/O (Sigio);
5. Asynchronous I/O (POSIX aio_ series functions)
An input operation usually consists of two different stages:
(1) Waiting for the data to be ready;
(2) Copying data from the kernel to the city.
For an input operation on a socket, the first step usually involves waiting for the data to arrive from the network. When the waiting group arrives, it is copied to a buffer in the kernel. The second step is to copy the data from the kernel buffer to the application process buffer.
1. Blocking I/O model
The I/O model we mentioned earlier is blocking I/O, calling recv system calls, blocking waiting if there is no data, and copying the data from the kernel space (the socket buffer) to the user space (the BUF provided by the RECV function) when the data arrives, then recv back to data processing.
See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/OS/unix/