(Original) Open the fog, see the month-Analysis of proactor mode in ASIO (1)

Before using ASIO, you must first understand its design ideas. Understanding the design ideas will help us understand and apply ASIO. ASIO is based on the proactor mode. The proactor mode of ASIO is hidden in a large number of details. To find its trace, there is often a sense that the tree does not see the forest. The author will analyze the proactor mode in ASIO, it was unveiled step by step, and finally moved to the cloud to restore a complete proactor mode. Before analyzing the proactor mode of ASIO, let's take a look at the common Io design patterns. The proactor (active) mode is an important I/O design mode used to solve problems encountered in High-concurrency networks. Another mode is the reactor (reactor ), libevent is implemented based on reactor. Let's take a look at the features of these two modes.

Introduction to the mode of reactors and active generators

The reactor requires the application to register the event processor first, then start the event loop of the reactor, and constantly check whether there is a ready I/O event. When there is a ready event, the synchronous event multi-channel splitter will return to the reactor and the reactor will distribute the event to the callback functions of multiple handles to process these events. [1]

A characteristic of a reactor is that a specific processing program does not call the reactor, but is used by the reactor to notify the handling program to handle the event. This method is also known as "control reversal" and "Hollywood principles ". The following is a class diagram of the reactor mode:

The general process of the reactor mode is as follows:

1. The application registers a specific event processor on the reactor, and the processor provides an internal handle to the reactor.
2. After registration, the application starts the reactor event loop. The reactor waits for a ready event in the handle set through select.
3. When one or more handles become ready (for example, when a socket is read ready), the reactor notifies the registered event processor.
4. The event processor processes the ready event to complete user requests.

The reactor mode is relatively intuitive to use, but it cannot support a large number of customer requests or requests that take too long at the same time, because it serializes all the event processing processes. The proactor mode has been improved in this regard.

The class diagram of the active device is as follows:

 

1. The application needs to define an asynchronous operation, such as socket asynchronous read/write.
2. when an asynchronous operation is executed, the asynchronous event processor delivers the asynchronous request to the operating system and returns the result. This allows the operating system to complete the specific operation. After the operation is completed, the completion event is put into a completion event queue.
3. the asynchronous event splitter detects the completion event. When the completion event is detected, the completion event is retrieved from the completion event queue and the completed event processing function registered by the application is notified to handle the event.
4. The result of processing asynchronous operations by completing the event processing function.

The main difference between the reactor and proactor modes is who performs real operations (such as reading and writing). In the reactor mode, the application needs to read or write data by itself. In the proactor mode, the application does not need to perform the actual read/write process. The operating system reads the buffer or writes the buffer to the real I/O device. The application only needs to read or write data from the buffer. In proactor mode, the user initiates an asynchronous operation and then returns the result, asking the operating system to process the request, and then waiting for the callback to complete the event function to process the asynchronous operation result.

ASIO proactor Mode

After introducing these two IO Design modes, let's look at the proactor mode in ASIO. To understand proactor in ASIO, first understand the basic usage of ASIO and the process of asynchronous operations, and then analyze the process according to the process and the proactor mode.
Before analyzing ASIO proactor, let's take a look at a simple example of initiating an asynchronous connection. This simple example shows some important objects of ASIO.
ASIO: io_service;
TCP: Socket socket (io_service );
Boost: ASIO: async_connect (socket, server_address, connect_handler );
Io_service.run ();
Although there are only four lines of code, there are actually a lot of complicated internal tasks, blocking a lot of details to make it easy to use. First, let's take a look at the first line of code. The first line of code defines a core ASIO object, io_service. All Io object objects must be passed in for initialization, let's talk about it later. The second row creates a TCP: socket-type Io object, through which we can initiate asynchronous operations. After initiating an asynchronous operation, call the run of io_service to start the event loop and wait for the completion of the asynchronous event. With a preliminary understanding, let's take a look at what these objects do.
Let's take a look at IO objects. IO objects are io-related operation objects provided by ASIO to users. IO objects forward user-initiated operations to io_service, for example, you can use them to initiate asynchronous connections, read and write, etc. The IO objects of ASIO include the following:

Let's take a look at the specific process of initiating an asynchronous operation on Windows:

The user initiates the async_connect operation through the IO object TCP: Socket. scoket will delegate the async_connect of the internal template class basic_socket. basic_socket adopts the handle body method, which is just a forward, it also entrusts the service class stream_socket_service to call async_connect. In fact, stream_socket_service is not a specific officer. It continues to delegate the Service Class Object win_iocp_socket_service to the platform to complete the final async_connect, win_iocp_socket_service actually handed over the asynchronous request to the operating system, and then the application returned the request, allowing the operating system to complete the asynchronous request. Let's look at the third line of code:

Boost: ASIO: async_connect (socket, server_address, connect_handler );

Although it only has a simple line of code, it is complicated enough to send the asynchronous request to the operating system after it is transferred three times. Here we can refer to a specific time sequence diagram to see how the asynchronous operation is initiated:

 

Some people may see it in the cloud. Why should an asynchronous operation be transferred so many layers to the operating system. This is because the ASIO design is divided into several layers, from the application layer to the middle layer, then to the service layer, and then to the underlying operating system, after understanding this layered architecture, you can understand how many requests need to be transferred. ASIO is actually divided into three layers. The first layer is the IO objcet layer, which provides the basic Io operation interface for the basic_xxx template as the object directly used by the application. The second layer is the basic_xxx template class layer, the role of this layer is to forward specific operations to the service layer; the third layer is the service layer, which provides the underlying implementation of operations. It is divided into two layers: The receiving operation layer and the platform adaptation layer. The basic_xxx template instance in the middle layer forwards user-initiated operations to the receiving operation layer of the service layer, and the receiving operation layer forwards the operations to the specific platform adaptation layer, the Platform Adaptation Layer calls the API of the operating system to complete the operation. Let's take a look at the specific layers of ASIO:

Through this layered architecture diagram, we understand why an operation has to be forwarded so many times, because each layer has its own responsibilities, and high-level requests need to be forwarded to the bottom layer. Another important object of ASIO, win_iocp_socket_service, is invisible to the user layer because it is a service object at the bottom layer, however, most operations initiated by the user layer are performed by calling Windows APIs.

We have already completed the process of initiating and forwarding asynchronous operations to the operating system, but we have not discussed the processing after the requests forwarded to the operating system are completed, how does the operating system call back the result of the operation to the application layer? Where is the proactor tracing. In the future, we will gradually extract from these tedious details and gradually clear the proactor mode from ASIO, allowing readers to see its true nature. In the next section, I will lead the reader back to the proactor mode from the proactor mode. I believe that the reader will naturally feel enlightened after reading it. To be continued ......

Some of the illustrations in this article are from the blogs of Yanzi and lujun-CC. I would like to thank you for your reference.

 

[1] model-Oriented Software Architecture Volume 2

 

If you think this article is useful to you, click here for recommendations. Thank you.

C ++ 11 boost technology exchange group: 296561497. You are welcome to exchange technologies.