5 Kinds of IO models in Network programming __ programming

blocking I/O

Illustration 1: When the upper application App1 calls RECV system calls, if the peer does not send data (the buffer has no data), the upper application App1 will block (the default behavior, blocked by the Linux kernel); Description 2: When the peer sends the data, the Linux kernel recv the end buffer, and after the data, The kernel will copy the data to user space. The upper layer then applies app1 to unblock and performs the next steps. non-blocking I/O

Illustration 1: The upper application APP2 sets the socket to non-blocking mode. Illustration 2: Upper application APP2 Polling calls the RECV function to accept data. If the buffer does not have data, the upper program APP2 will not block, recv return value is 1, the error code is ewouldblock. Illustration 3: The top application keeps polling for any data to come. Will cause the upper application to be busy waiting. Consumes a lot of CPU. Rarely used directly. The application scope is small, the general and the Selectio multiplex uses together. I/O multiplexing

, note 1: The upper application APP3 invokes the select mechanism, which has the Linux kernel support to avoid app3 busy waiting. ) to poll the file descriptor for changes in state. Illustration 2: When a select-managed file descriptor has no data (or the state does not change), the upper application app3 is blocked. Illustration 3: Benefits Select mechanism can manage multiple file descriptor Descriptions 4:select can be viewed as a manager, with Select to manage multiple IO.
Once an I/O is detected or multiple IO, there is a sense of our event, occurs, the Select function returns, and the return value is the number of events detected. You can then use the Select-related API function to manipulate specific events. Description 5:select function can set wait time, avoid the upper application app3, long-term zombie. Illustration 6: Compared to the blocking IO model, the SELECTI/O reuse model is equivalent to blocking in advance. When there is data coming, the call to Recv will not block. Signal-driven I/O

Illustration 1: Upper application APP4 establish Sigio signal processing program. When data arrives in the buffer, the kernel sends a signal telling the upper application to APP4. Illustration 2: Upper application APP4 receives the signal, calls the RECV function, because the buffer has the data, the RECV function generally does not block. Note 3: This model is used for a relatively small number of typical "pull mode". namely: the upper application app4, need to call the RECV function to pull the data in. asynchronous I/O

Illustration 1: The upper application APP5 calls the Aio_read function and submits a buffer buf for the application layer, which is not blocked after the call is completed. The upper application app5 can continue with other tasks. Illustration 2: When the TCPIP protocol buffer has data, Linux actively to the kernel data copy to user space. And then to the upper application app5 send a signal, tell APP5 data have, quickly deal with it. Illustration 3: Typical "push mode" Illustration 4: One of the most efficient forms, where the upper application app5 the ability to handle asynchronous processing (with the support of the Linux kernel, the implication is that it can also support IO communication while other tasks are being processed). What the asynchronous I/O refers to.
The upper application APP5 can receive data (accept asynchronous communication events) when it can also do other work. = = =) Asynchronous command source. With the signal-driven IO model, the upper application app5 does not need to invoke the RECV function.

Conclusion: IO multiplexing and asynchronous Io are the key points.