Blocking, non-blocking, synchronous, asynchronous concept in network programming

blocking, non-blocking, synchronous, asynchronous concepts in network programming

Network programming, we often contact blocking, non-blocking, synchronous, asynchronous concepts, some concepts may be used to cross, such as asynchronous non-blocking, synchronous non-blocking, synchronous blocking, and so on, these concepts seem similar, but often have different concepts, often very around. Just looked up some information to sum up, by combining the specific network model to make a note of these concepts. Blocking

Blocking is the easiest to understand, this is a blocking API that corresponds to a variety of blocked api,recv send and so on, and the nature of these APIs is that when the kernel's data is not ready, it blocks the entire thread until the kernel receives the data, and the kernel copies the data to the user space and returns The blocked API returns concrete results. In summary, the API for this series will return only if there is a result to be returned. non-blocking

Non-blocking is also very well understood, but combining the concept of synchronous asynchrony may be a bit confusing, and here we'll talk about the concept of non-blocking.

Non-blocking API, when the socket is set to perform a non-blocking socket, the recv send function will return immediately at the time of execution, and immediately return, assuming that the user's parameter conditions are not met, for example, when there is not enough data to read, In fact, these APIs will return a blocking error, so compared to blocking the API, non-blocking, users may need to constantly call these APIs to obtain the corresponding results, so the Non-blocking API in the absence of corresponding network model support, in fact, there is no great use. Sync

The concept of synchronization is more difficult to explain. First, the concept of synchronization, that is, the results of execution must be obtained by the user themselves, where the user must call the RECV function or the Send function to obtain the result of the operation.

The concept of synchronization, combined with non-blocking, is much like the concept of asynchrony, such as the Select model and the Epoll model, yet both models are synchronous non-blocking models. These two models will tell you exactly which socket has an event, but users have to get the data themselves, which means adding a notification mechanism on a non-blocking basis. Asynchronous

The main features of the asynchronous model, AIO and IOCP, are to tell them that I need to read or send the data, and when the data is read or sent, they return with the results, and of course, the data from the kernel space to the user space copy, The user does not need to call the Recv function again to make a copy of the data. on this issue

In fact, to see the libevent implementation of the thought, from the user's point of view, Libevent should be a proactor model, the user asked to read the data, then libevent will be stored in the corresponding buffer, the user can read the data, very much like asynchronous implementation. However, regardless of Windows IOCP encapsulation, the most common encapsulation in libevent should be select and Epoll, which are synchronous models that provide a notification mechanism. In the libevent is also encapsulates these models constantly to poll which socket has events, in the implementation point of view is actually based on reactor. So summing up the libevent, it is actually a non-blocking synchronization model.