Network IO Model under Linux environment

This article discusses the background of network IO in a Linux environment.

The objects and steps involved when IO occurs:

For a network IO (here we read for example), it involves two system objects, one that calls the IO process (or thread), and the other is the system kernel (kernel). When a read operation occurs, it waits for the kernel to go through two phases :

1 Kernel Data Preparation (Waiting for the data is ready)
The 2 kernel copies the data from the kernel space to the user space (Copying the data from the kernel to the process)
It is important to remember these two points because the difference between these IO model is that there are different situations in both phases.

Network IO partitioning in Linux environments: Asynchronous IO classes, and synchronous IO classes

First, asynchronous IO model classification

. Blocking IO

. Non-blocking IO

. IO multiplexing (listening for multiple connections)

. Asynchronous IO

1. Blocking IO:

When the user process invokes the Recvfrom system call,

Phase 1:

Kernel begins the first phase of IO: Preparing the data. For network IO, there are times when the data has not arrived at the beginning (for example, a full UDP packet has not been received), and kernel waits for enough data to arrive. On this side of the user process, the entire process is blocked.

Phase 2:

When kernel waits until the data is ready, it copies the data from the kernel space to the user's memory, and then kernel returns the result, and the user process removes the block state and re-runs it.
Therefore, the blocking IO is characterized by block in both phases of IO execution.

2. Non-blocking IO

Inux, you can change it to non-blocking by setting the socket. This is what the process looks like when performing a read operation on a non-blocking socket.

Summary: The kernel prepares the data stage non-blocking, the kernel prepares the data to send the data from the kernel space to the user space stage to block;

Excellent: The program in the nuclear preparation data phase is non-blocking, you can do something else, periodically send system calls to the kernel to request data;

Inferior: The process of nuclear preparation data in the program continues to initiate system calls to the kernel waste system resources

Import TimeImportSocketsk=Socket.socket (Socket.af_inet,socket. Sock_stream) Sk.setsockoptsk.bind (('127.0.0.1', 6667)) Sk.listen (5) sk.setblocking (False) whileTrue:Try:        Print('waiting Client Connection ....') connection,address= Sk.accept ()#Process Active Polling        Print("+++", address) Client_messge= CONNECTION.RECV (1024)        Print(Str (CLIENT_MESSGE,'UTF8') ) Connection.close ()exceptException as E:Print(e) time.sleep (4)############################ #clientImport TimeImportSocketsk=Socket.socket (Socket.af_inet,socket. SOCK_STREAM) whileTrue:sk.connect (('127.0.0.1', 6667))    Print("Hello") Sk.sendall (bytes ("Hello","UTF8")) Time.sleep (2)     Break

3, IO multiplexing (monitoring multiple connections, to achieve concurrency phenomenon)

The word IO multiplexing may be a bit unfamiliar, but if I say select,epoll, I'll probably get it. Some places also call this IO mode for event driven IO. As we all know, the benefit of Select/epoll is that a single process can simultaneously handle multiple network connections of IO. Its basic principle is that select/epoll this function will constantly polling all sockets responsible, when a socket has data arrives, notify the user process;

When the user process invokes select, the entire process is blocked, and at the same time, kernel "monitors" all select-responsible sockets, and when the data in any one socket is ready, select returns. This time the user process then invokes the read operation, copying the data from the kernel to the user process.
This figure is not much different from the blocking IO diagram, in fact, it's even worse. Because two system calls (select and Recvfrom) are required, blocking IO only invokes one system call (Recvfrom). However, the advantage of using select is that it can handle multiple connection at the same time. (Say one more word.) Therefore, if the number of connections processed is not high, Web server using Select/epoll does not necessarily perform better than the Web server using multi-threading + blocking IO, and may be more delayed. The advantage of Select/epoll is not that a single connection can be processed faster, but that it can handle more connections. ）
In the IO multiplexing model, the actual, for each socket, is generally set to become non-blocking, but, as shown, the entire user's process is actually always block. Only the process is the block of the Select function, not the socket IO.

Note that if a file is readable in the return result of the 1:select function, the process can let kernel copy the data that is in the kernel to the user area by calling accept () or recv ().

Note The advantage of 2:select is that it can handle multiple connections, not a single connection

Code:

#***********************server.pyImportSocketImportSelectsk=socket.socket () Sk.bind ("127.0.0.1", 8801)) Sk.listen (5) Inputs=[SK,] whiletrue:r,w,e=select.select (inputs,[],[],5)    Print(Len (r)) forObjinchr:ifobj==Sk:conn,add=obj.accept ()Print(conn) inputs.append (conn)Else: Data_byte=OBJ.RECV (1024)            Print(Str (Data_byte,'UTF8')) InP=input ('Answer%s customer >>>'%inputs.index (obj)) obj.sendall (bytes (INP,'UTF8'))    Print('>>', R)#***********************client.pyImportSocketsk=socket.socket () Sk.connect ('127.0.0.1', 8801)) whileTRUE:INP=input (">>>>") Sk.sendall (bytes (INP,"UTF8")) Data=SK.RECV (1024)    Print(Str (data,'UTF8'))

Network IO Model under Linux environment