UNIX Network programming------5 Kinds of IO models __ Programming

5 I/O models under UNIX:

1. Blocking I/O

2. Non-blocking I/O

3. I/O multiplexing (select/poll/epoll)

4. Signal-driven (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 process

For an input operation above a socket, the first step is usually to wait for the data to arrive from the network, and when the waiting packet arrives, it is copied into a buffer in the kernel, and the second step is to copy the data from the kernel buffer to the corresponding application process buffer.

First. Five I/O models

The following is an example of a datagram socket (UDP) to analyze the five IO models, and TCP is not used as an example because UDP is simpler and TCP itself is more complex:

1> blocking I/O model (BLOCKINGI/O)

blocking I/O is the most popular I/O model. By default, all sockets are blocked.

As shown in Figure 6-1, the process calls Recvfrom, and its system call is not returned until the datagram arrives and is copied into the appropriate application process's buffer or an error occurs, the most common error being that the system call is interrupted by a signal. In the diagram, the process is blocked from the call Recvfrom to the time it returns.

2> non-blocking I/O model (nonblocking I/O)

A process that sets a socket to non-blocking I/O is the notification kernel: when the requested I/O operation has to put this process into sleep, do not put the process into sleep but return an error.

In the above figure, the first three times recvfrom not ready the data, at this time directly return a ewouldblock error, the fourth time already have the data ready, it is copied to the corresponding process buffer.

3> I/O multiplexing model

With I/O multiplexing, we can call select or poll, blocking one of the two system calls, rather than blocking the actual I/O system calls.

In the above figure we block on the select call, and when the datagram socket becomes readable, we call recvfrom to copy the datagram to the process buffer.

4> Signal-driven I/O model (Signal-driven I/O)

We first turn on the socket driver I/O function and install a signal processing function via sigaction system call. The system call returns immediately and the process continues to work. When the datagram data is ready, the kernel generates a Sigio signal for the process. We can call the Recefrom function in the signal processing function to read the datagram.

5> asynchronous I/O model

asynchronous I/O works by telling the kernel to start an operation and letting the kernel notify us when the entire operation, including copying data from the kernel to the process buffer, is complete.

The main difference from the signal-driven model is that signal-driven I/O is the kernel's notification of when an I/O operation can start, and the asynchronous I/O model is the kernel that notifies us when I/O is complete.





In the diagram above, we call the Aio_read function and tell the kernel to notify us when the entire operation is complete. The system call returns immediately, and the process is not blocked while waiting for I/O completion.


Second. Comparison of various I/O models

As we can see in the diagram above:

The primary difference between the first four I/O models is the same in phase one, the second phase is the same: during the data from the kernel to the process buffer, the process blocks the recvfrom call.

asynchronous I/O models are processed in both phases, different from several other models.

asynchronous I/O operations: Causes the process to block until I/O operation completes;

asynchronous I/O operations: does not cause process blocking;

blocking I/O, non-blocking i/o,i/o multiplexing model, signal-driven I/O models are synchronous I/O. The asynchronous I/O model is asynchronous I/O.