Muduo Network Library pre-knowledge points

• Three semi-Events for TCP network programming
• Application layer to use buffer in non-blocking network programming
  • Why the sender application layer uses buffers
  • Why the receiver application layer uses buffering
  • How to design the use of buffers
• What is reactor mode
• non-blocking io io multiplexing
• Muduo Recommended mode
• Impedance matching principle for thread pool size
• Reasons for EventLoop using level trigger

In front of the analysis of the source code in the Muduo/base, these are the auxiliary network library. Before analyzing the network library, first summarize the relevant knowledge points.

What are the concerns of TCP network programming? The Muduo network library is summarized as a three-half event .

Three semi-Events for TCP network programming:

1, establish the connection: the service side of the accept and the client connect. Once the connection is established, both sides of the transceiver are equal.

2. Disconnect: Includes active disconnect (close, shutdown) and passive disconnect (read returns 0).

3, the message arrives: that is, the file descriptor is readable. This is the final event, and the way the event is handled determines the style of programming. such as blocking/non-blocking, how to subcontract, how to design the application layer buffer, etc.

3.5, the message is complete, this is half an event. "Send complete" refers to the system buffer that writes data to the operating system, after which the TCP stack is responsible for sending and re-transmitting the data, and does not indicate that the receiver has received the data. For low-traffic services, you don't have to worry about this event.

In non-blocking network programming, the application layer uses the Buffer sender application layer to use the buffer.

If the application is sending 40KB data, but the TCP buffers have only 25kb of space left, what about the remaining 15kb data? If the buffer waiting for the OS is available, because you do not know when the buffer is available, the current thread is blocked. What the application layer needs to do is to cache the 15KB data, put it in the send buffer, wait for the socket to be writable and send the data immediately, so that the "send" operation will not block. If the application sends 50KB data again, then if the application layer sends buffers and data, the data should be appended to the end of the send buffer, instead of calling write for the socket, which will disrupt the order in which the data is sent.
For the application layer, it only needs to be concerned about generating data, not needing to care whether the data is sent one time or several times, which should be bothered by the network library. The application layer only needs to call Tcpconnection::send (), and the network library will send responsibility to the end. What the network library does is to put 15kb data into the output buffer of tcpconnection and then register the Pollout event to send the remaining data in the callback function of the event. If the remaining data cannot be sent at one time, continue registering for the Pollout event, and stop focusing on the Pollout event to avoid causing busy loops if the message is complete.

Why does the receiver application layer use buffering?

If the data is not enough to read a complete packet, then the read data should be staged to a place, waiting for the remaining data to be processed together. The join data is a byte interval of 10ms arrival, each byte arrives will trigger a file descriptor readable event, the program will still work?

How are buffers designed to be used?

The application layer buffer is used to hold the data that has arrived/is about to be sent. On the one hand we want the buffer to be as large as possible so that more data can be processed at once and the system calls are reduced. On the other hand, we want the buffer to be as small as possible because each connection consumes a buffer, and if it is too large, it will use very large memory, and most of the time, the buffer is inefficient to use. See Muduo::buffer Analysis in detail.

What is reactor mode?

Reactor mode Chinese translation is called reactor mode. This mode is based on synchronous I/O, we register I/O event to reactor, and set the callback function, when the corresponding event arrives, we will call the Destroy function we set. This is different from the previous let thread/process wait for an event.

As a reactor mode. Some events are registered in the reactor mode, and when the event arrives, the corresponding callback function is called through the Dispatcher (dispatch) to handle the event.
This is just a basic reactor pattern, the callback function and reactor in the same thread, in addition to a few variants. such as Reactor+threadpool, multiple reactors and so on.

Non-blocking io + io multiplexing

The translation comes from non-blocking IO plus io multiplexing. There is also a limitation to the implementation of the Muduo network library: one loop per thread. That is, each thread of the program has an event loop (that is, reactor) to handle read-write events and timed events.

EventLoop represents the main loop of a thread, and if you want that thread to work, register the timer or IO channel with the eventloop of the corresponding thread. An IO event that requires a higher level of real-time, can be used on a single thread.

Muduo Recommended mode

The Muduo recommended mode is one (event) loop per thread+ thread pool.

The event loop acts as an IO multiplexing with non-blocking io and timers.
The thread pool is used to process compute tasks, which can be a producer consumer queue.

Impedance matching principle for thread pool size

When a thread pool executes a task, if the density of the intensive computing task is P (0< p <=1), the system has a C CPU, then in order to let the C CPU run full, without overloading, then the empirical formula for the size of the thread pool is t=c/p.

Why is eventloop using level trigger?

1, compatible with the traditional poll.
2, level trigger programming easier, not prone to the bug of missing events.
3, read and write without waiting to appear eagain, reduce the number of system calls.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Muduo Network Library pre-knowledge points