I/O multiplexing technology can be used in the following situations: 1. The client program handles multiple sockets simultaneously. (such as non-blocking Connect technology) 2. The client program handles both user input and network connections. The 3.TCP server handles both the listening socket and the connection socket simultaneously. (I/O multiplexing is the most used occasion) 4. The server handles both TCP and UDP requests. 5. The server listens on multiple ports at the same time, or handles multiple services. (xinetd service) I/O multiplexing can listen for multiple file descriptors at the same time, but he itself is blocked, and when multiple file descriptors are ready. If no additional measures are taken, the program can only process each of these file descriptors sequentially, so that I/O multiplexing looks like a serial one, and it requires multiple processes or multithreading to achieve the art of war. Select:int Select (int Nfds, fd_set* Readfds, fd_set* Writefds, fd_set* Exceptfds, struct timecal*); Nfds: Specifies the total number of file descriptors that are being monitored. It is usually set to the maximum value in the descriptor for all files that are monitored by Select plus 1. Readfds, Writefds, Excepfds: A collection of file descriptors corresponding to readable writable and exception events, respectively. When the application invokes the Select function, it passes the three arguments to the file descriptor of interest to itself. When the select call returns, the kernel modifies them to notify the application which file descriptors are ready. The Fd_set type structure contains only an array of integers, each of which is labeled with a file descriptor. This limits the total number of file descriptors that the select can handle at the same time. Timeout: Sets the timeout time for the Select function. It is a pointer to a timeval type, and the kernel modifies it to tell the application how long the select Waits. The value of timeout should not be fully trusted after the select call is completed. File descriptor Ready Condition: In network programming, the socket is readable in the following cases: The number of bytes in the receive buffer in the socket kernel receive buffer is greater than or equal to its low watermark So_rcvlowat. At this point, we can read the socket without blocking, and the read operation returns 0. The socket communication closes the connection, at which point the read operation of the socket will return 0. There is a new connection request on the listening socket. There is an unhandled error on the socket. You can use getsockopt to clear the error. The socket can be written in the following cases: The socket kernel sends a buffer in which you give more bytes than is equal to its low water mark sO_sndlowat. The write-file descriptor for the socket is closed, and writing to the closed socket of the write operation triggers a sigpipe signal, which can be written at will. The socket uses a non-blocking connect connection after success or failure. There are unhandled errors on the socket, ditto.
Poll int poll (struct pollfd* FDS, nfds_t nfds, int timeout) is similar to select, polling a certain amount of file descriptors within a specified time to test for the presence of a ready person. FDS is an array of POLLFD types. Specifies the readable writable and exception events that occur on file descriptors that are of interest to the user. Events in the POLLFD type structure tell poll what's on the FD, which is a series of TIME's bitwise OR. Revents members are modified by the kernel to notify the application of what actually happened to FD. Gun adds a Pollrdhup event to the poll system call that is triggered when a request is received on the socket to close the connection. This allows the application to distinguish between a request to receive valid data on the socket or to close the connection, and to handle it accordingly. However, with Pollrdhup events, you need to define _gun_source at the very beginning of your code. NFDS Specifies the size of the FDS event collection to be monitored.
Epoll Linux-specific I/O multiplexing functions. Epoll uses a set of functions to complete a task, rather than a single function. Epoll the file descriptor that the user cares about in a timeline in the kernel. (The event table is implemented in the kernel is actually a red-black tree, the red-black tree lookup efficiency is high, found and placed in the kernel's ready queue). Epoll_create is the process of creating a red-black tree and a ready queue. The int epoll_wait size parameter does not work, just tells the kernel how large the event table it needs. The file descriptor returned by this function will be used as the first parameter of all other Epoll system calls, representing the kernel event table to be accessed. int epoll_ctl (int epfd, int op, int fd, struct epoll_event* event) FD is the file descriptor to manipulate, and the OP parameter specifies the type of operation. Epoll_ctl_add (add FD on the event table (EPFD), Epoll_ctl_del,epoll_ctl_mod.) The event is a struct pointer of the epoll_event type. Epoll_wait the main interface for Epoll series function calls. Waits for an event on a set of file descriptors within a set timeout period. int epoll_wait (int epfd, struct epoll_event* event, int maxevents, int timeout) timeout refers to the timeout time, maxevents specifies the maximum number of events to listen to, must be greater than 0. If an event is detected, the epoll_wait function copies all the ready time from the Kernel event table (EPFD) to the array in which the second parameter events points. This array is used only for output epoll_wait-detected readiness events. The LT and ET modes epoll have two modes of operation on the file descriptor: LT (level trigger, horizontal trigger) and ET (Edge trigger, edge trigger). LT is the default mode of operation, in which the epoll is equivalent to a highly efficient poll. When you add a Epollet event on a file descriptor to the Epoll kernel event table registration, Epoll will manipulate the file descriptor in et mode. Et mode is an efficient working mode of epoll. LT: When Epoll_wait detects that an event occurred on it and notifies the application of the event, the application can not handle the event immediately. In this way, the next time the application calls Epoll_wait, Epoll_wait will also notify the application again. Until the event is processed. ET: When Epoll_wait detects that an event occurred on it and notifies the application of the event, the application must handle the event immediately because subsequent epoll_wait calls will no longer notify the application of the event. Et greatly reduces the number of times the same Epoll event is repeatedly triggered. Therefore, et efficiency is higher than LT mode.
Prevent events on one socket from being triggered multiple times: using the Epoll Epolloneshot event implementation Even if we use the ET mode, an event on a socket may be triggered multiple times. This can cause a problem in concurrent programs. For example, a thread (process) that starts processing the data after reading the data on one of the sockets, while new data is readable on the socket while the data is being processed, is Epollin again, at which point another thread is awakened to read the new data. So there are two threads at the same time to operate a socket situation. What we expect is a socket that is handled by only one thread at any one time. The file descriptor for the Epolloneshot event is registered, and the operating system triggers up to one event registered on it, and only once, unless we reset the Epolloontshot event registered on the file descriptor with the Epoll_wait function. This way, when a thread is working on a socket, it is impossible for other threads to manipulate the socket. Once the socket that registered the Epolloneshot event has been processed by a thread, the thread should immediately reset the Epolloneshot event of this socket to ensure that the socket's epolloneshot can be triggered the next time it is readable. This gives the other worker threads the opportunity to continue processing the socket. Comparison of three kinds of I/O multiplexing functions
| System call |
Select |
Poll |
Epoll |
| Event Collection |
The user passes through 3 parameters to the interesting readable writable and exception events, and the kernel feeds the readiness events by the online modification of these parameters. This allows the user to reset the 3 parameters each time a select is called |
All event types are treated uniformly, so only one event set parameter is required. The user passes the pollfd.events to the event of interest, the kernel by modifying the pollfd.revents feedback the events that are ready |
The kernel manages all events of interest to the user directly through an event table. So every time the arguments to the epoll_wait system call events are used to feedback the ready events only |
| The time complexity of the application indexing ready file descriptor |
O (N) |
O (N) |
O (1) |
| Maximum number of supported file descriptors |
Generally has the maximum limit |
65535 |
65535 |
| Working mode |
LT |
LT |
Support et efficient mode |
| Kernel implementation and Productivity |
Polling is used to detect ready events with an O (n) complexity of the algorithm |
Polling is used to detect ready events with an O (n) complexity of the algorithm |
The callback method is used to detect the ready event, and the algorithm complexity is O (1) |
Epoll high efficiency is embodied in where. 1. The bottom layer uses a red-black tree to maintain a set of events, with a ready queue to store the ready events, and find efficiency. 2. Use MMAP (Memory mapping technology) to speed up the kernel and user space messaging, reduce the copy, improve efficiency 3. The kernel uses the callback callback mechanism to activate the file descriptor (which puts the node in the ready queue) and is notified when the epoll_wait is invoked. 4.I/O efficiency does not decrease linearly with the increase of FD number.
