About boost network programming (1)-Problems with the old system

Some time ago, the company's old code was completely replaced by one breath. In this process, we mainly use boost ASIO and other boost library components (such as thread and bind ). I have gained a lot from this development.

First, it is technological growth. When I first joined the company, I was responsible for maintaining outdated Code. However, due to my limited vision, I didn't think it was too old. Later, with the development of technology and open vision, the decision to restructure the system was made. Now that we are talking about the old system, let's talk about where the old system is:

1) multi-threaded and multi-connection server.

2) multi-threaded Multi-Connection Client.1st) and 2nd) the disadvantage is obvious. The thread and connection binding will not only bring about expansion problems, but also cause performance loss. In the old system, the number of threads has reached more than 300. In fact, the online running system has a maximum of 12 cores, and the number of threads is much larger than the number of CPU cores, resulting in: most threads are running falsely; unnecessary context switching is required.

3) the client and server adopt the parent-child process. There was no error in the parent-child process communication mechanism, but from the business logic of the system, it is unnecessary to use the parent-child process communication mechanism. Switching to a process not only reduces unnecessary task data copies (threads can share data structures), but also facilitates preliminary development and maintenance.

4) There are also unnecessary task copies, redundant log printing, and so on, which will not be described in detail here.

"

You stand on the bridge to see the scenery,

The scenic person looks at you upstairs.

Moon decorated your window,

You decorated others' dreams.

"

By using this poem, I just want to say that since there is a problem with the old system, I must not have discovered it alone. Yes, our excellent R & D personnel have actually developed a good alternative product. This good alternative product adopts the following designs:

1) epoll is used to process network events. However, epoll does not support the receipt and transmission of pure streaming data, and only encapsulates HTTP clients.

2) The round-robin algorithm is used to process all events: large tasks are subdivided into small tasks and FIFO is supported. However, during actual operation, it was found that the round-robin algorithm they used was not very perfect. For example, the previous test: continuous sending of large batches of tasks to the program causes the task feedback to get stuck.

3) inter-department communication is difficult. As the company is too big, communication between departments becomes very difficult. This is first manifested in the inability to share codes between departments. As a result, we hope to customize the log file size, and the client that supports socket stream (and also supports protobuf) will continue to fail.

In various restrictions and deficiencies, I finally decided to develop new alternative products.

About boost network programming (1)-Problems with the old system