Python Network programming Advanced Chapter II

In the previous article, we explored the 11 states of the TCP/IP protocol, understanding these states is very helpful when we write the server, but the general write server uses the C/java language, because these languages are particularly good for high concurrency support. The simple servers we wrote were primarily designed to learn more about the TCP/IP protocol, IO operations, and the principle of the co-process in Python. The concept of non-blocking is also mentioned in the previous article, in which we continue to delve into the IO model, because understanding IO operations can be very helpful in learning asynchronous programming in depth. So in this section we mainly consider what happens to the IO operation from the level of Linux kernel and User Configuration, and what the Linux kernel does.

I. Common 5 types of IO models

1. Blocking IO Model

The blocking IO Model diagram is as follows:

　

Description

(1). When the upper-level application invokes the RECV system call, the process switches from the user state to the kernel state, and if no data is sent at this time (the kernel buffer has no data), then the application will be blocked (default behavior, blocked by the Linux kernel).

(2). When the data is sent to the other side, the Linux kernel automatically copy the data to the buffer in the user space, then the process resumes execution and performs the next step!

2. Non-blocking IO model

　　The non-blocking IO Model diagram is as follows:

Description

(1). The socket must be set to non-blocking mode in the process;

(2). The process will always call the recv () function to receive data, if there is no data in the buffer, then the process will not be blocked, just recv () will return an error code (EWOULDBLOCK)

(3). The process will constantly poll for no data coming. This causes the process to be busy waiting. Consume CPU resources heavily. It is therefore rarely used, and is generally used in conjunction with select or Epoll mechanisms.

3.IO multiplexing Model

　　The IO multiplexing model diagram is as follows:

　

Description

(1). The process uses the select mechanism (which is supported by the Linux kernel and avoids process busy waiting) in order to poll the state changes of the file descriptor ;

(2). When the file descriptor for select management does not change, the process is blocked, but using Select to manage multiple file descriptors increases efficiency. This is not like a non-blocking model, to poll recv ().

(3). Select can be viewed as a housekeeper, using Select to manage multiple IO.

Once one or more of the IO has been detected that we are interested in, the Select function returns and the return value is the number of events detected.

(4). The Select function can set the time-out period, which prevents the process from being in a dry wait state, long-term zombie

(5). The Select IO multiplexing model is equivalent to blocking earlier than the nonblocking IO model. When there is data coming, you can call recv () directly to get the data.

4. Signal-driven IO

　The signal-driven IO Model diagram is as follows:

Description

(1). A handler for the Sigio signal is established in the upper-level application. When the buffer has data coming, the kernel sends the data to the upper-level application.

(2). When the upper-level application receives a signal, call the recv () function, because the buffer has data, and the recv () function is generally not blocked.

(3). This model is less used and belongs to the typical "pull model", where the upper-level application needs to call the recv () function to pull the data in.

5. Asynchronous IO Model

The asynchronous IO Model diagram is as follows:

Description

(1). The upper-level application calls the Aio_read function and submits an application-tier buffer to the kernel to write data to, and after the call is complete, the application is not blocked and can continue to perform other tasks.

(2). When the data comes in, the Linux kernel actively copies the data from the kernel space to the user space, and then sends a signal to the application that the process data has been copied, and you quickly process the data.

(3). This is a "push mode", the efficiency is very high, the application has the ability of asynchronous processing (with the help of the Linux kernel, the process can handle other tasks, but also the IO communication). The application does not need to call recv () to receive data compared to the signal-driven IO model!

(4). What is asynchronous IO?

The application can also receive data while processing other things.

Summary: By comparing the five IO models, we can clearly find their differences and efficiency, generally in the development of IO multiplexing models and asynchronous IO models are the most commonly used models!

Comparison chart of five models:

　　　

Python Network programming Advanced Chapter II