Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about what the IO model refers to in Linux network programming, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

Based on the two stages of IO access, five IO models generated by Linux are introduced in detail.

Synchronous and asynchronous

Synchronization means that when the completion of one task depends on another task, the dependent task can be counted as completed only after waiting for the dependent task to be completed.

Asynchronism means that you do not need to wait for the dependent task to complete, but just inform the dependent task what to do, and the dependent task is executed immediately, as long as you have completed the whole task. Async generally uses status, notification and callback.

Blocking and non-blocking

Blocking means that before the result of the call is returned, the current thread will be suspended, waiting for the message to be notified, and cannot execute other business.

Non-blocking means that the function does not block the current thread but returns immediately until the result is not immediately available.

Five IO models

For an IO access, the data is copied into the kernel buffer before it is copied from the kernel buffer to the application's address space. You need to go through two stages:

1) prepare data

2) copy data from the kernel buffer to the process address space

As a result of these two phases, Linux produces the following five IO models.

Blocking IO

When the user process calls the recvfrom call, the kernel enters the first stage of IO: preparing the data (the kernel needs to wait for enough data to be copied), this process needs to wait, the user process will be blocked, wait for the kernel to prepare the data, and then copy it to the user address space, the kernel returns the result, the user process goes from the blocked state to the ready state.

In Linux, all socket are blocked by default.

Non-blocking IO

When the user process issues a read operation, if the data in the kernel is not ready, it does not block the user process, but immediately returns an error. When the user process determines that the result is an error, it knows that the data is not ready, so it can send the read operation again. Once the data in the kernel is ready and the system call of the user process is received again, it immediately copies the data into the user's memory and returns.

In non-blocking IO mode, the user process needs to constantly ask the kernel if the data is ready.

Under Linux, you can change it to non-blocking by setting socket.

IO multiplexing

Through a mechanism, a process can monitor multiple file descriptors (socket descriptors), and once a file descriptor is ready (usually read-ready or write-ready), it can notify the program to read and write accordingly. This eliminates the need for every user process to keep asking if the kernel data is ready.

The commonly used IO multiplexing methods are select, poll and epoll.

Select

Kernel will "monitor" all the socket that select is responsible for, and when the data in any socket is ready, select will return. At this time, the user process invokes the read operation to copy the data from the kernel to the user process.

Int select (int n, fd_set * readfds, fd_set * writefds, fd_set * exceptfds, struct timeval * timeout)

The file descriptors monitored by the select function fall into three categories: writefds, readfds, and exceptfds. After the call, the select function blocks until the description is ready (data is readable, writable, or except), or timeout (timeout specifies the wait time, if the immediate return is set to null), the function returns. When the select function returns, you can find the ready descriptor by traversing the fdset.

One disadvantage of select is that there is a maximum limit on the number of file descriptors that a single process can monitor, which is typically 1024 on Linux.

Poll

Poll is implemented using a pointer to pollfd.

Int poll (struct pollfd * fds, unsigned int nfds, int timeout)

The pollfd structure contains the event to be monitored and the event that occurs

Struct pollfd {int fd; / * file descriptor * / short events; / * requested events to watch * / short revents; / * returned events witnessed * /}

Like the select function, after poll returns, you need to traverse the pollfd to get the ready descriptor. Poll does not have a maximum number of listeners.

Epoll

Epoll uses one file descriptor to manage multiple descriptors, stores the events of file descriptors that users care about in a kernel event table, and uses the mechanism of listening for callbacks, so that copy in user space and kernel space is only needed once, avoiding traversing the list of ready file descriptors again.

The operation of epoll requires three interfaces:

Int epoll_create (int size); int epoll_ctl (int epfd, int op, int fd, struct epoll_event * event); int epoll_wait (int epfd, struct epoll_event * events, int maxevents, int timeout)

Int epoll_create (int size):

Create a handle to epoll, and size is used to tell the kernel how many listeners there are.

Int epoll_ctl (int epfd, int op, int fd, struct epoll_event * event):

Performs an op operation on the specified descriptor fd.

-epfd: is the return value of epoll_create ().

-op: indicates the op operation and is represented by three macros: add EPOLL_CTL_ADD, delete EPOLL_CTL_DEL, and modify EPOLL_CTL_MOD. Add, remove, and modify listening events for fd, respectively.

-fd: the fd (file descriptor) that needs to be monitored

-epoll_event: tells the kernel what to listen for. The struct epoll_event structure is as follows:

Struct epoll_event {_ _ uint32_t events; / * Epoll events * / epoll_data_t data; / * User data variable * /}; / / events can be a collection of the following macros: EPOLLIN: indicates that the corresponding file descriptor can be read (including the corresponding SOCKET is normally closed); EPOLLOUT: indicates that the corresponding file descriptor can be written EPOLLPRI: indicates that the corresponding file descriptor has emergency data to read (here it should mean that out-of-band data has arrived); EPOLLERR: indicates that the corresponding file descriptor has an error; EPOLLHUP: indicates that the corresponding file descriptor has been hung up; EPOLLET: sets EPOLL to Edge Triggered mode, which is relative to horizontal trigger (Level Triggered). EPOLLONESHOT: only listen for one event. After listening to this event, if you need to continue listening to the socket, you need to add the socket to the EPOLL queue again.

Int epoll_wait (int epfd, struct epoll_event * events, int maxevents, int timeout):

Wait for io events on epfd, and a maximum of maxevents events will be returned.

The parameter events is used to get a collection of events from the kernel. Maxevents tells the kernel how big the events is. The value of this maxevents cannot be greater than the size when epoll_create () is created. The parameter timeout is the timeout (millisecond, 0 will be returned immediately,-1 will be uncertain, and it is also said to be permanent blocking). This function returns the number of events that need to be processed. A return of 0 indicates that it has timed out.

Two working modes of epoll

LT (level trigger) mode: when epoll_wait detects that the descriptor is ready and notifies the application of this event, the application can not deal with the event immediately. The next time epoll_wait is called, the application responds again and this event is notified. LT mode is the default working mode.

LT mode supports both blocking and non-blocking socket.

ET (edge trigger) mode: when epoll_wait detects that the descriptor is ready, notifies the application of this event, and the application must process the event immediately. If not, the next time epoll_wait is called, the application will not respond again and this event will not be notified.

ET is a high-speed operation mode and only supports non-blocking socket. ET mode reduces the number of times epoll events are triggered repeatedly, so it is more efficient than LT mode.

Asynchronous IO

As soon as the user process initiates the read operation, it can immediately start doing other things. As soon as the kernel receives an asynchronous IO read, it returns without blocking the user process. The kernel waits for the data to be ready, then copies the data to the user's memory, and when this is done, the kernel sends a signal to the user process telling it that the read operation is complete.

Signal driven IO

After the kernel file descriptor is ready, the user process is notified by the signal, and the user process reads the data through the system call. This is a synchronous IO because the actual reading of data into the user process cache is still the responsibility of the user process itself.

After reading the above, do you have any further understanding of what the IO model refers to in Linux network programming? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.