I/O (English: Input/Output), namely Input/Output, usually data Input and Output between memory (internal and external) or other peripheral devices, is the communication between an information processing system (such as a computer) and the external world (possibly a human or another information processing system). Inputs are signals or data received by the system and outputs are signals or data sent from it.

Refer to the figure above for a brief summary: any access by the processor to any data resource outside the package, such as the register and Cache, can be regarded as I/O operation, including memory, disk, video card and other external devices.

Five network I/O models defined by UNIX

To understand network I/O, let’s look at how A message gets from A to B.

Basic process: Application A passes through the corresponding send buffer of the service, network transmission, and application B’s receive buffer through TCP/IP. Application B then reads the message from the buffer.

At this point we focus on reading the data, and now we are faced with the problem of how to read the data from the buffer into the application layer.

If you don’t quite understand the technical terms, we can use a short story to illustrate.

OK, now we are going to role-play. The background of the story is that you buy something online and wait for the package to be delivered to your home……

Blocking I/O (Blocking I/O)

You were so eager to get the item that you waited outside the door until the package was delivered by the Courier.

Using system calls and blocking until the kernel is ready, and then copying the data from the kernel buffer to the user state, does nothing while waiting for the kernel to be ready.

Non-blocking I/O (I/O)

Although you are eager to get this item, you have other things to do. So, you’re going to go back and do something for a while, and then come out later to see if the package has arrived. Over and over again until the package arrives.

The kernel returns an error code when data is not ready, and instead of sleeping, the calling program constantly polls the kernel to see if the data is ready.

I/O Multiplexing

You have a package pickup robot that monitors whether packages are delivered for you. It will notify you to pick it up if there is one.

Multiplexing is similar to non-blocking, except that the polling is not performed by the user thread, but by the kernel. When the data is ready, the kernel listener calls the kernel function to copy the data to the user state.

Signal Driven I/O (SIGIO)

You have a doorbell installed at your door, and the delivery company that delivers your package will ring the doorbell when it arrives at your house, and if you are there, it will give you the package. If you happen to be away, your package is discarded.

We need to allow the Socket to be signal driven, and install a signal processing function, which will process the notification when the system sends the notification, but in a large number of I/O operations may be due to signal queue overflow or other uncontrollable factors.

Asynchronous I/O (Asynchronous I/O)

You know you get the package and you put it on the table, and then you negotiate with the Courier to put it on the table for you when it arrives. You don’t need to care when the package arrives.

Asynchronous IO is truly non-blocking, with the main process doing its own thing and processing the data through callback functions when the IO operation is complete (data is successfully copied from the kernel cache to the application buffer).

I/O multiplexing

Let’s talk about I/O multiplexing, the model most commonly used in server and network programming. Oh, and it’s also known as the event-driven model

Continue our story

You move to a new neighborhood. There is a parcel receiving station in the community, but there is no name on the parcel, only the number. You need to tell the number to the staff every time, and they will inform you to take the parcel when it arrives.

SELECT / POLL

When an express arrives, because the Courier staff does not know who told him, he can only ask door-to-door in your community until he finds someone who can receive it, or ask all of them.

In a nutshell, the mechanics of SELECT and POLL are similar, but the implementation and some minor differences, so we’ll talk about them together.

A fatal problem with this model is that it needs to poll all the streams to see whose events they are. Due to the time complexity of the query is O(n), performance is poor in the case of multiple connections.

EPOLL

When you tell the clerk to pick up your package, he will write down your contact information, so that the clerk can contact you directly when your package arrives.

EPOLL is an improvement on SELECT and POLL that avoids the problem of requiring rotation training.

But EPOLL only works on Liunx systems.

conclusion

This time we looked at five network I/O models for Unix. I didn’t go into too much depth, just to give you an idea of what this is about, and if you’re interested you can go into it. I’ll do a little bit more on operating systems when I get the chance.

Next week we will continue our discussion of regression to distribution.