Socket synchronous asynchronous, blocking, Non-blocking concept resolution set __ Network programming

The first kind of explanation:

Take the TCP transmission as an example in the socket transfer. Suppose Server a client B communicates. First, you need to establish a listening thread on machine A. Listening to a certain port, then B machine can send a communication request to a machine, B machine connected to a machine after. A listening object that a machine can take from his listening queue. The socket object can be received and sent at the end of a. Here's where the problem arises. Send a piece of data if the B-side requests a successful request at the end of a request. Then a terminal can get his information directly from the socket object. But if the B-side does not send the message directly after the connection succeeds, it is sent within a later indeterminate time. Then a will not be able to get this message. The usual practice is to use a timer to scan the data cache. It's very inefficient to see if there are any data. So how to solve this problem. We use our asynchronous transmissions. The principle of asynchronous transmission is. When the socket object is obtained from a, it is not directly to receive the data but to create a callback function. Callback functions are maintained by the system. He automatically scans the data store at the specified time. If there is data, he stores the data in the specified byte array. Without the user to care.

Second explanation:

One, to give a call example:

Blocking block is when you dial someone's phone, but the person is not there, so you take the phone and wait for him to come back, and you can't use the phone. The synchronization is probably about the same as blocking.

Non-blocking Nonblock means that you dial someone's phone number, but the person is not there, so you hang up and call later. As for the time when he did not come back, only to call to know. The so-called "polling/poll".

Asynchronous means that you dial someone's phone number, but the person is not there, so you ask the person who answered the phone to tell the man (leave a message) and call you back when he returns.

Synchronous asynchronous and blocking and non-blocking are two different concepts.
Synchronous asynchronous refers to the communication mode, while blocking and non-blocking refers to whether to wait for the action to complete before returning when receiving and sending
So we can't confuse these four concepts.
Here are some of my understanding, please give us more advice
The first is the synchronization of communication, mainly refers to the client after sending a request, must have a response to the server before sending the next request. So all requests at this time will be synchronized at the server.
The second is the asynchronous communication, when a client sends a request, it can send the next request without waiting for a response from the server, so that all the request actions will be asynchronous on the server, and the link to the request is like a request queue where all the actions are not synchronized.

Blocking and non-blocking are only applied to read and send requests.

In the implementation process, if the server is asynchronous, the client is also asynchronous, the communication efficiency is very high, but if the server on the return of the request is also returned to the requested link, the client can be synchronized, in this case, the server is compatible with synchronous and asynchronous. Conversely, if the client is asynchronous and the server is synchronized, there is no problem, but the processing efficiency is low.

Third explanation:

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. (end of recommendation to the user).