The difference between socket blocking and non-blocking __socket

To put it more simply:

Obstruction is not the end of the work, no return,
Non-group games you do it first, I'll see if there's anything else. Tell me when it's over.

Let's take the most commonly used send and recv two functions ...
For example, you call the Send function to send a certain byte, in the system sent to do the work is actually just the data transfer (COPY) to the TCP/IP protocol stack output buffer, and its success does not mean that the data has been successfully sent out, if the tcp/ The IP protocol stack does not have enough buffers available to hold the data you copy. This shows the difference between blocking and non-blocking: The socket send function for blocking mode will not return until the system buffer has enough space to return the data copy you are sending. For a non-blocking socket, send returns immediately wsaewoulddblock tells the caller, "the send operation is blocked!!! You find a way to deal with it ... "
For the RECV function, the internal working mechanism of the function is actually waiting for the TCP/IP protocol stack to be notified by the receiving buffer: Hi, your data is coming. For blocking-mode sockets, if the TCP/IP protocol stack's receive buffer does not notify a result to it it does not return: Consumes the system resources .... For a non-blocking-mode socket The function will return immediately, and then tell you: Wsaewoulddblock---"There is no data now, look back."

Extended:

When doing network programming, we often see four ways of calling synchronous, asynchronous, blocking, and non-blocking. These approaches are not well understood by each other. Here is my understanding of these terms.
Synchronous
Synchronization is when a function call is issued, and the call does not return until the result is obtained. By this definition, most functions are synchronous calls (such as sin, isdigit, etc.). But generally speaking, when we say synchronous, asynchronous, especially those who need other parts to collaborate or need a certain amount of time to complete the task. The most common example is SendMessage. The function sends a message to a window that does not return until the other person finishes processing the message. This function returns the LRESULT value returned by the message handler function to the caller when the other party has finished processing it.
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. Take the Casycsocket class as an example (note that the CSocket is derived from CAsyncSocket, but the function has been converted from asynchronous to synchronous), and the caller thread can run down immediately after a client makes a connection request by calling the Connect function. When the connection is really established, the bottom of the socket sends a message to notify the object. It is mentioned here that the execution part and the caller return results in three ways: status, notification, and callback. You can use which depends on the implementation of the execution part, unless the execution part provides a variety of choices that are not controlled by the caller. If the executing part is notified by state, then the caller needs to check every time, and the efficiency is very low (some beginners of multithreaded programming, always like to use a loop to check the value of a variable, which is actually a very serious error). If you are using notifications, the efficiency is high because the execution part requires little extra action. As for the callback function, there is not much difference between the notice and the notification.
Blocking
A blocking call is the current thread is suspended until the call result returns. 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 receive function in CSocket, 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. If the main window and the calling function are in the same thread, unless you call in a special interface operation function, the main interface should still be refreshed. Another function of the socket receiving data recv is an example of a blocking call. When the socket is working in blocking mode, if the function is called without data, the current thread is suspended until there is data.
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 through a certain API to polling 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.

Blocking traffic

--------------------------------------------------------------------------------

Through overlapping communication and computation in many systems can improve performance. A system that performs communication automatically by an intelligent communication controller is true. Light-weight cues are a mechanism for achieving this overlap. An optional mechanism that leads to good performance is the use of non-blocking traffic. A blocking send start call initializes the send operation, but does not complete it. This send start call will be returned before this message is copied from this send cache. A separate "Send complete" call is required to complete this communication, for example, to verify data that is copied from the Send cache. With appropriate hardware, data conversions from the sender's storage can be performed concurrently with the computation performed by the sender, after the sending is initialized and before it completes. Similarly, a non-blocking "Receive start call" Initializes the receive operation, but does not complete it. This call is returned before a message is stored in this receive cache. A separate "receive complete" call is required to complete this receive operation and to verify the data received for this receive cache. With the appropriate hardware, the data conversion to the recipient store can be performed concurrently with the computation, after the receive operation has been initialized and before it completes. The use of non-blocking reception, while information is provided earlier in the receiving cache location, avoids system caching and storage to memory copies.

Non-blocking send start calls can use the same four modes as blocking forwarding: standard, cache, sync, and ready mode. These have the same meaning. If a matching receive is logged in, it can begin sending all modes except "ready" and start a non-blocking "ready" Send as soon as a matching receipt has been logged in. In all cases, the Send start call is Local: it returns immediately, regardless of the state of the other process. If this call causes some system resources to run out, it will fail and return an error code. High-quality MPI implementations should ensure that this happens only in "morbid" situations. That is, a MPI implementation will be able to support a large number of pending non-blocking operations.

When the data has been copied from the Send cache, this send completion call is returned. It can have additional meaning, depending on the send mode.

If the send mode is "synchronized", then only one matching receive has started this send to complete. That is, a receive has been logged in and has been matched with this send. At this point, the send completion call is non-local. Note that before receiving the completion call, it can be completed if a synchronous, non-blocking send and a non-blocking receive match. (Sender One "knows" the conversion will end, it can complete, but before the receiver "knows" the conversion will end).

If the send mode is "cached" and there is no pending reception, the message must be cached. At this point, the send completion call is local, and it must succeed regardless of the status of a matching receive.

If the send mode is standard and the message is cached, the send end call can be returned before a matching receive occurs. On the other hand, the send completes until a matching receive occurs, and the message is copied to the receiving cache.

Non-blocking send can be matched with blocking reception, which can be reversed.

Advice to the user. The completion of a send operation, which can be deferred for standard mode, must be deferred for the same pattern until a match receives login. In both cases, the use of non-blocking sending allows the sender to proceed ahead of the receiver so that the computation is more tolerant of fluctuations in the speed of both processes.

Non-blocking delivery in the cache and ready mode has a more limited impact. One possibility is that a non-blocking send will return, and a blocking send will be returned after the data is copied from the sender's store. The use of non-blocking sending has advantages as long as the data copy energy and computation are simultaneous.

Message sending mode implies that the sender initiates the communication. When the sender initiates the communication (the data is moved directly to the receiving cache and does not require a pending send request), the communication will generally have a lower additional burden if a receive is logged in. However, a receive operation can be completed only after a matching send has occurred. When non-blocking reception waits to be sent, there is no blocking reception, and its use allows for a lower burden of communication.