Five common I/O models in Network Programming

I/O model

There are five I/O models in UNIX:

1>: Blocking I/O

2>: non-blocking I/O

3>: I/O multiplexing

4>: Signal-driven I/O

5>: asynchronous I/O

The first four are synchronous I/O models, and the fifth is asynchronous.

Synchronous and asynchronous:

The synchronization here is different from the synchronization concept in the communication between two entities. The synchronization here refers to that a series of actions in this I/O must be completed by yourself, whether you are waiting for the occurrence of an event (blocking) or when an event is ready, you can complete the subsequent actions (non-blocking.

Asynchronous means to call another executor to complete the task. When the executor finds the time to process and calls you, you can finish the task again, the execution process does not involve your actions.

Blocking and non-blocking:

Blocking means waiting for an event. If it does not happen, it waits until the event occurs.

It is non-blocking and does not need to wait until it returns.

1> blocking I/O

The I/O function is used, causing program blocking and waiting for data. If the data is not ready, the program waits.

For example, when we use a blocking socket to create a socket, the call to accept/recvfrom/connect... and so on will be blocked waiting for the arrival of the connection, request or data.

650) This. length = 650; "src =" http://s2.51cto.com/wyfs02/M01/81/FC/wKiom1dGsfXDyS4kAAELa2AoTU8006.png "Title =" .png "width =" 650 "Height =" 344 "border =" 0 "hspace =" 0 "vspace =" 0 "style =" Width: pixel PX; Height: 344px; "alt =" wkiom1dgsfxdys4kaaela2aotu8006.png "/>

Blocking functions are easy to implement, but there are many problems. First, as a network server, blocking wait will waste a lot of resources and time, when the server calls the sendto function to send data to a remote client, it is obviously inappropriate to do nothing else, so subsequent actions are blocked, the solution to this problem is often to create a process or thread to solve this problem. Because the overhead of the process is far greater than the overhead of the thread, it is very feasible to use the multi-thread method.

The advantage of blocking I/O is that it is very stable. It can ensure the certainty that the connection can accept and send data. This is why most large Internet companies use multithreading, using the thread pool also greatly increases the efficiency of thread enabling.

2> non-blocking I/O

Call the socket function and set it to non-blocking mode. in Linux, call the fcntl () function.

In the non-blocking mode, the current execution stream no longer waits for the request or data to arrive in sleep mode, but uses the round-robin mode. The operation process in this mode is as follows, it is returned once every time period. If data arrives, it is returned. If no data arrives, an error code wsaewouldblock is returned. We need to continuously use a loop to wait for the successful data return, this process often occupies a large amount of CPU.

Non-blocking disadvantages, although he does not have to wait too stiff, but it can only wait for one event at a time.

3> signal-driven I/O

Sigio signals are generated when the following events occur in tcpsocket. Because there are too many reasons for this signal at the same time, we cannot tell which situation generates sigio signals, therefore, the message driver in TCP is not suitable for use. On the contrary, it is suitable for use in UDP.

650) This. length = 650; "src =" http://s5.51cto.com/wyfs02/M02/81/FC/wKioL1dGvRWSTO94AAEVwPhhXXo699.png "Title =" .png "width =" 650 "Height =" 253 "border =" 0 "hspace =" 0 "vspace =" 0 "style =" Width: pixel PX; Height: 253px; "alt =" wkiol1dgvrwsto94aaevwphhxxo699.png "/>

Shows the signal-driven working method.

650) This. length = 650; "src =" http://s2.51cto.com/wyfs02/M01/81/FE/wKiom1dGvFayufQTAAEiIK2Yzzs819.png "Title =" .png "width =" 700 "Height =" 440 "border =" 0 "hspace =" 0 "vspace =" 0 "style =" Width: 700px; Height: pixel PX; "alt =" wkiom1dgvfayufqtaaeiik2yzzs819.png "/>

4> I/O multiplexing.

This method is especially special. For example, tcpsocket puts the listen to a new link in a collection, when the socket in this set has read, we will read and write, we will write, it is a combination of non-blocking I/O and signal-driven I/O, and can wait for multiple. Common functions include select, poll, and epoll, these functions will be described in detail in later blogs.

Its disadvantage is that no matter which function is described above, each time a data is sent or received, the conversion between the kernel and the user enters two times.

The I/O multiplexing model is shown in figure

650) This. length = 650; "src =" http://s2.51cto.com/wyfs02/M01/81/FC/wKioL1dGv2aSl317AAEj_ol3zoo107.png "Title =" .png "width =" 700 "Height =" 452 "border =" 0 "hspace =" 0 "vspace =" 0 "style =" Width: 700px; Height: 452px; "alt =" wkiol1dgv2asl317aaej_ol3zoo107.png "/>

5> asynchronous I/O

When an asynchronous process is called, the caller cannot obtain the result immediately. After the call is completed, the caller's input and output operations are notified through status, notification, and callback.

650) This. length = 650; "src =" http://s1.51cto.com/wyfs02/M02/81/FE/wKiom1dGvZmDVsONAADvg-gJtTE025.png "Title =" .png "width =" 700 "Height =" 398 "border =" 0 "hspace =" 0 "vspace =" 0 "style =" Width: 700px; Height: 398px; "alt =" wKiom1dGvZmDVsONAADvg-gJtTE025.png "/>

For five I/O models

650) This. length = 650; "src =" http://s1.51cto.com/wyfs02/M01/81/FC/wKioL1dGv-3j6GmbAAGTvufwcyQ834.png "Title =" .png "width =" 700 "Height =" 427 "border =" 0 "hspace =" 0 "vspace =" 0 "style =" Width: 700px; Height: 427px; "alt =" wKioL1dGv-3j6GmbAAGTvufwcyQ834.png "/>

It can be seen that the best way is asynchronous I/O. Of course, it is more responsible for implementation, and the reliability of blocking I/O is the best.

This article is from the "trace" blog, please be sure to keep this source http://wpfbcr.blog.51cto.com/10696766/1783543

Five common I/O models in Network Programming