Socket programming Practice (10)-5 I/O models

blocking I/O

Illustration 1: When the upper application Application1 calls the RECV system call, if the peer does not send data (there is no data in the Linux kernel buffer), the upper application Application1 will block [default: Blocked by the Linux kernel]

Illustration 2: When the peer sends the data, the Linux kernel recv-side buffer data arrives and the kernel will copy the data to the user space. Then the upper application Application1 unblocked and performs the next steps.

non-blocking I/O

Illustration 1: The upper-level application Application2 the socket to non-blocking mode.

Illustration 2: The upper-level application Application2 polling calls the Recv function to accept the data. If the buffer does not have data, the upper program Application2 will not block, the recv return value is-1, the error code is ewouldblock.

Illustration 3: The upper-level application constantly polls for no data coming. cause upper application busy waiting. Consumes CPU heavily. rarely used directly. Small application range, general and select io multiplexing is used in conjunction with.

 I/OMulti-ChannelMultiplexing[Focus]

Illustration 1: The upper-level application Application3 calls select (the mechanism is supported by the Linux kernel, avoids Application3 busy waiting), and polls the state of the file descriptor changes.

Illustration 2: When the Select managed file descriptor has no data (or the state does not change), the upper-level application Application3 also blocks.

Illustration 3: The advantage is that the select mechanism can manage multiple file descriptors

Note 4:select can be seen as a manager, with Select to manage multiple IO.

Once an I/O or multiple IO is detected, the SELECT function returns the number of detected events when the event occurs. You can then use select-related API functions to manipulate specific events.

Description 5:select function can set the wait time, avoid the upper application Application3 long-term zombie.

Illustration 6: Compared to the blocking IO model, the SELECTI/O multiplexing model is equivalent to early blocking. When there is data coming, the call to Recv will not block.

Signal-driven I/O

Illustration 1: The upper-level application Application4 establishes the SIGIO Signal processing program. When the buffer has data coming, the kernel sends a signal to tell the upper application to Application4.

Illustration 2: The upper-level application Application4 receives the signal, calls the RECV function, because the buffer has data, the RECV function generally does not block.

Note 3: This is used for the model is relatively small, belonging to the typical "pull mode (upper application passive to the Linux kernel space pull data)". That is: the upper application Application4, need to call the RECV function to pull the data in, there will be time delay, we can not avoid the delay, there will be a new signal generation.

asynchronous I/O[Focus]

Illustration 1: The upper-level application APPLICATION5 calls the Aio_read function, and commits an application-tier buffer buf; After the call is complete, it is not blocked . The upper-level application Application5 can continue other tasks.

Illustration 2: When the TCP/IP protocol buffer has data, Linux actively copy the kernel data to the user space. Then sends the signal to the upper application Application5, tells the Application5 data arrives, needs to deal with!

Illustration 3: A typical "push mode"

Illustration 4: One of the most efficient modes , the upper-level application Application5 has the ability to process asynchronously (with the support of the Linux kernel , can also support IO communication while other tasks are being handled .

What does asynchronous I/O mean?

The upper-level application Application5, while doing other tasks, can also receive data (accept asynchronous communication events). and the upper-level application does not need to call the RECV function

Socket programming Practice (10)-5 I/O models