1. Conceptual understanding
In the case of network programming, we often see synchronous (Sync)/asynchronous (Async), blocking (block)/non-blocking (Unblock) Four ways to invoke:
Sync:
synchronization is when a function call is issued, and the call does not return until the result is obtained. It is
necessary to do one thing, and so on before the next thing is done.
For example, common B/S mode (sync): Submit request-> wait for server processing-> processing complete return This period client browser cannot do anything
Asynchronous:
Asynchronous Concepts and synchronizations are relative. When an asynchronous procedure call is issued, the caller cannot immediately obtain the result. When the part that actually handles this call is completed, the caller is notified by status, notification, and callback.
For example, Ajax request (asynchronous): The request is triggered by the event-> server processing (this is the browser can still do other things ) - > processing Completed
Blocking
A blocking call is when the call result returns before the current thread is suspended (the thread enters a non executable state in which the CPU does not allocate a time slice to the thread) , that is, the thread is paused). The function is returned only after the result is obtained.
Someone might equate a blocking call with a synchronous call, and in fact he is different. For a synchronous call, the current thread is still active, but logically the current function does not return. For example, we call the recv function in Socket , and if there is no data in the buffer, the function waits until the data is returned. At this point, the current thread will continue to process a wide variety of messages.
Non-blocking
The concept of non-blocking and blocking corresponds to a function that does not block the current thread and returns immediately before the result is immediately available.
Blocking mode and blocking function calls for objects
The object is in blocking mode and the function is not a blocking call has a strong correlation, but it is not one by one corresponding. Blocking objects can have non-blocking calls, we can use a certain API to poll the state, at the appropriate time to call the blocking function, you can avoid blocking. For Non-blocking objects, calling special functions can also go into blocking calls. The function Select is one such example.
1. Sync, that is, I call a feature that does not end before I Deng the results.
2. Asynchronous, that is, I call a function, do not need to know the result of the function, the function has a result of the notification to me (callback notification)
3. Blocking is called me (function), I do not receive data or do not get the result, I will not return.
4. Non-blocking, that is, call me (function), I (function) immediately return, through Select to notify the caller
The difference between synchronous IO and asynchronous IO is that the process is blocked when the data is copied!
The difference between blocking IO and non-blocking io is whether the application call returns immediately!
Sync: Submitting requests-> waiting for server processing-> processing finished returning the client browser cannot do anything
Asynchronous: Request to trigger-> server processing via event (this is something that the browser can still do)-> processing complete
Both synchronous and asynchronous are only for native sockets.
Synchronous and asynchronous, blocking and non-blocking, some mixed, in fact they are completely not the same thing, and they are decorated with different objects.
Blocking and non-blocking refers to whether the process needs to wait when the data accessed by the process is not ready, simply saying that this corresponds to the implementation difference within the function, that is, if it is not ready to return directly or wait for it to be ready;
Synchronous and asynchronous refers to the mechanism of accessing data, synchronization generally refers to the active request and wait for I/O operations completed in the way, when the data is ready to read and write when the must block (the difference is ready and read and write two phases, synchronous read and write must be blocked), asynchronous refers to the active request data can continue to process other tasks, and then wait The operation is completed, which allows the process to not block when data is read or written. (Wait for "notification")
1. Linux Five kinds of I/O models
1 Blocking I/O (blocking I/O)
2 non-blocking I/O (nonblocking I/O)
3 I/O multiplexing (SELECT and poll) (I/O multiplexing)
4 Signal-driven I/O (signal driven I/O (Sigio))
5 Asynchronous I/O (asynchronous I/O (the POSIX aio_functions))
The first four are synchronized, and only the last one is asynchronous IO.
Introduction: The process will remain blocked until the data copy is complete
The application calls an IO function, causing the application to block and waiting for the data to be ready. If the data is not ready, wait .... The data is ready, copied from the kernel to the user space, and the IO function returns the success indicator.
blocking I/O model diagram: when calling the Recv ()/recvfrom () function, the process of waiting for and replicating data in the kernel occurs.
when the recv () function is invoked, the system first checks for prepared data. If the data is not ready, then the system is in a waiting state. When the data is ready, copy the data from the system buffer to the user space, and the function returns. In a socket application, when the recv () function is invoked, the data is not necessarily in user space, then the recv () function is in the waiting state.
When you use the socket () function and the WSASocket () function to create a socket, the default socket is blocked. This means that when the Windows Sockets API is not immediately complete, the thread waits until the operation completes.
Not all Windows Sockets APIs will block with blocking sockets for parameter calls. For example, when the bind (), listen () function is called by a socket in blocking mode, the function returns immediately. The Windows Sockets API calls that may block sockets are grouped into the following four categories:
1. Input actions: recv (), Recvfrom (), WSARecv (), and WSARecvFrom () functions. Calls the function to receive data with a blocking socket as a parameter. If no data is readable within the socket buffer at this time, the calling thread sleeps until the data arrives.
2. Output operations: Send (), sendto (), WSASend (), and WSASendTo () functions. The function is called with a blocking socket to send data. If there is no free space in the socket buffer, the thread sleeps until there is room.
3. Accept connection: Accept () and wsaacept () functions. Call the function with a blocking socket, waiting to accept the other's connection request. If there is no connection request at this time, the thread will go to sleep.
4. Outgoing connection: Connect () and WSAConnect () functions. For TCP connections, the client invokes the function to initiate a connection to the server, with a blocking socket as a parameter. The function does not return until it receives a reply from the server. This means that the TCP connection always waits for at least one round-trip time to the server.
Using blocking-mode sockets, developing a network program is simpler and easier to implement. When you want to be able to send and receive data immediately, and the number of sockets handled is relatively small, it is appropriate to use blocking mode to develop network programs.
The problem with blocking-mode sockets is that it is more difficult to communicate with a large number of established socket threads. When developing a network program using the producer-consumer model, assigning a read thread to each socket, a processing data thread, and an event for synchronization will undoubtedly increase the overhead of the system. The biggest drawback is that when you want to handle a lot of sockets at the same time, it will not be possible, its scalability is very poor
Introduction : non-blocking io calls the IO function repeatedly through the process (multiple system calls and returns immediately); In the process of copying data , the process is blocked;
We have a socket interface set to non-blocking is to tell the kernel, when the requested I/O operation can not be completed , do not sleep the process, but return an error. So our I/O operation function will constantly test whether the data is ready and, if not ready, continue testing until the data is ready. During this continuous testing process, the CPU time will be heavily occupied.
Setting the socket to non-blocking mode informs the system kernel that when you invoke the Windows Sockets API, you should not let the thread sleep, but you should let the function return immediately. When returned, the function returns an error code. As shown in the figure, a non-blocking-mode socket calls the RECV () function multiple times. The kernel data was not ready when the recv () function was called the first three times. Therefore, the function immediately returns the WSAEWOULDBLOCK error code. The fourth time the recv () function is called, the data is ready to be copied into the application's buffer, and the recv () function returns a successful indication that the application starts processing the data.
When you create a socket using the socket () function and the WSASocket () function, the default is blocked. After the socket is created, the socket is set to non-blocking mode by calling the Ioctlsocket () function. The functions under Linux are: Fcntl ().
When the socket is set to non-blocking mode, the calling function returns immediately when the Windows Sockets API function is invoked. In most cases, these function calls will call "failed" and return the Wsaewouldblock error code. Indicates that the requested operation does not have time to complete during the call period. Typically, the application needs to call the function repeatedly until a successful return code is obtained.
It is necessary to note that not all Windows Sockets APIs are invoked in Non-blocking mode and return wsaewouldblock errors. For example, the bind () function is not returned when a socket with a non-blocking pattern is invoked as a parameter. Of course, the error code is not returned when the WSAStartup () function is invoked, because it is the first function called by the application and certainly does not return such an error code.
to set the socket to non-blocking mode, you can use the WSAAsyncSelect () and WSAEventSelect () functions in addition to the ioctlsocket () function. When the function is called, the socket is automatically set to non-blocking.
A wsaewouldblock error is often returned when a function is invoked using a non-blocking socket. So at all times, you should carefully review the return code and prepare yourself for failure. The application continuously calls this function until it returns a successful instruction. In the above list, the recv () function is continuously called in the while loop to read 1024 bytes of data. This practice is a waste of system resources.
To do so, someone uses the MSG_PEEK flag to invoke the recv () function to see if there is data readable in the buffer. Similarly, this method is not good. Because the overhead of this approach to the system is very large, and the application must call the recv () function at least two times to actually read the data. It is a good practice to use the socket's "I/O model" to determine whether a non-blocking socket is readable or writable.
non-blocking-mode sockets are not easy to use compared to blocking-mode sockets. Using non-blocking-mode sockets, you need to write more code to handle the Wsaewouldblock errors that are received in each Windows Sockets API function call. Therefore, non-blocking sockets appear to be somewhat difficult to use.
However, non-blocking sockets in the control of the establishment of multiple connections, in the data received and received uneven, time is uncertain, obviously has the Advantage. This socket is difficult to use, but as long as it eliminates these difficulties, it is still very powerful in function. In general, consider using the "I/O model" of sockets to help your application manage the communication of one or more sockets asynchronously.
Introduction: mainly select and Epoll; for an IO port, two calls, two returns, have no advantage over blocking IO; The key is to be able to monitor multiple IO ports simultaneously;
The i /O multiplexing model uses the Select, poll, and Epoll functions, which also block processes, but unlike blocking I/O, these two functions can block multiple I/ O operation. It is also possible to detect multiple read operations and multiple write I/O functions at the same time until the data is readable or writable, and the I/O operation function is actually invoked.
Synopsis: Two times call, two times return;
First We allow the socket to signal-drive I/O, and install a signal-processing function, and the process continues to run without blocking. When the data is ready, the process receives a sigio signal that calls the I/O operation function in the signal processing function to process the data.
Introduction : The process is not blocked when copying data.
When an asynchronous procedure call is issued, the caller cannot immediately obtain the result.
When the part that actually handles this call is finished, it notifies the caller of the input and output operation through the state, the notification, and the callback
Synchronous IO causes the process to block until the IO operation completes.
Asynchronous IO does not cause the process to block.
Io multiplexing is first blocked by a select call.
Comparison of 5 I/O models:
1. Brief introduction to select, poll, Epoll
Both Epoll and select provide multiple I/O multiplexing solutions. In the current Linux kernel is able to support, where Epoll is unique to Linux, and select should be POSIX requirements, the general operating system is implemented
Select is essentially the next step by setting up or checking the data structure that holds the FD flag bits. The disadvantages of this are:
1, a single process can monitor the number of FD is limited, that is, the size of the monitoring port is limited.
in general this number and system memory relationship is very large, the specific number can be Cat/proc/sys/fs/file-max. The 32-bit machine defaults to 1024. The 64-bit machine defaults to 2048.
2, the socket for the scan is linear scan, that is, the use of polling methods, low efficiency:
when more sockets are used, each select () is fd_setsize by traversing the socket to complete the dispatch, regardless Which socket is active, go through it all over again. This can waste a lot of CPU time. If you can register a callback function with the socket, and when they are active, automatically complete the relevant operation, then avoid polling, which is epoll and Kqueue do.
3, the need to maintain a large number of FD data structure, which will make user space and kernel space in the delivery of the structure when the replication overhead
Poll is essentially the same as SELECT, which copies the incoming array of the user to the kernel space and then queries each FD for the corresponding device state and, if the device is ready, adds an entry in the device wait queue and continues traversing, suspending the current process if no ready device is found after all the FD has been traversed, Until the device is ready or the active timeout is awakened, it again traverses the FD. This process has undergone many meaningless traversal.
It does not have the maximum number of connections, because it is stored based on a linked list, but there is also a disadvantage:
1, a large number of FD arrays are replicated in the whole between the user State and the kernel address space, regardless of whether such replication is meaningful. 2, poll also has a feature is "horizontal trigger", if the FD has been reported, has not been processed, then the next poll will report the FD again.
Epoll supports both horizontal and edge triggers, with the greatest feature being the Edge trigger, which only tells the process which FD has just changed to the desired state and only notifies once. Another feature is that Epoll uses the "event" ready notification method to register the FD via Epoll_ctl, and once the FD is ready, the kernel uses a similar callback callback mechanism to activate the fd,epoll_wait to receive notification
1, without the maximum concurrent connection restrictions, can open the upper limit of FD is much larger than 1024 (1G of memory can monitor about 100,000 ports);
2, efficiency promotion , not polling way, not with the increase in the number of FD efficiency. Only active FD will call the callback function;
the biggest advantage of Epoll is that it does not have to do with the total number of connections, so the efficiency of the epoll is much higher than that of select and poll in the actual network environment.
3, memory copy , using mmap () file Mapping memory acceleration and kernel space message delivery, that is, epoll use mmap to reduce replication overhead.
Select, poll, Epoll difference summary:
1, support a process can open the maximum number of connections
Select
|
The maximum number of connections that a single process can open has a Fd_setsize macro definition, the size of which is 32 integers (on a 32-bit machine, the size is 32*32, fd_setsize on 64-bit machines is 32*64), and of course we can modify and recompile the kernel, However, performance may be affected, which requires further testing.
|
Poll
|
Poll is essentially the same as a select, but it does not have the maximum number of connections because it is stored based on a linked list
|
Epoll
|
Although the number of connections are capped, but very large, 1G memory machine can open about 100,000 of the connection, 2G memory machine can open about 200,000 of the connection
|
2. The IO efficiency problem brought by the increase of FD
Select
|
Because the connection is traversed linearly each time the call is made, the increase in FD can cause a "linear descent performance problem" that is slow to traverse.
|
Poll
|
Ditto
|
Epoll
|
Because the implementation in the Epoll kernel is based on the callback function on each FD, only active sockets will actively invoke callback, so in the case of fewer active sockets, using the Epoll does not have a linear descent performance problem with the preceding two, But with all the sockets active, there may be a performance problem.
|
Select
|
The kernel needs to pass messages to user space and requires kernel copy action
|
Poll
|
Ditto
|
Epoll
|
Epoll through the kernel and user space to share a piece of memory to achieve.
|
In summary, the choice of Select,poll,epoll should be based on the specific use of the occasion and the three ways of their own characteristics.
1, on the surface to see the best performance of Epoll, but in fewer connections and are very active connection, select and poll performance may be better than the Epoll, after all, Epoll notification mechanism requires a lot of function callback.
2. Select is inefficient because it requires polling every time. But low efficiency is also relative, depending on the situation, but also through good design to improve
