After one year of accumulation, I will review TCP socket server programming (2)

------------------

Preface

------------------
I posted the first articleArticleAfter that, many comrades commented that socket programming is still a relatively difficult part of the software system.

The first article mainly introduces the design of the transmission protocol, which is the underlying foundation of the entire socket framework. Next, the entire socket server building will be built on the basis of this protocol design.

In this article, I mainly connect to the various server performance parameters to provide a solution.

 

-------------------

Socket server receiving module design

-------------------

When the server accept a new socket, it will encapsulate the socket and become a connection (of course, custom ). The subsequent processing will be handed over to this connection.

The data sent by the socket exists.Subcontracting,Stick packageThe connection receiving module is doomed to useReceiving queue. Of course, this so-called accept queue is not as profound and approximate as everyone thinks.CodeThe structure is as follows:

Public   Class Socketreceivequeue
{
Private Queue < Isocketreceivepackage > Queue =   Null ;
Private Memorystream receivebuffer =   Null ;
}

 

That is, the receiving queue of a queue + a stream. Processing logic:

A. receive the data and press it into receivebuffer.

B. read data from receivebuffer and obtain protocol packagesIsocketreceivepackage, There may be multiple or none.

C.After receiving, the Protocol package is sent out of the queue from the queue and handed over to the registered protocol processing handler.

 

So far, the entire receiving logic does not involve specific services or specific services. The only extra note is the length of the received packet, that is, whether the length stated in the Protocol package is too large.

 

Note that because the entire receiving module does not involve specific business logic, it should not detect any input (illegal attacks, frequencies, etc.) here ), the Code parses the Protocol package as quickly as possible and then sends it to the upper-layer handler for analysis.

 

-------------------

Client request Performance Analysis 

-------------------

When the Protocol package comes with the business-related handler, we start to perform performance testing. The first is the request frequency. The formula is as follows:

Requestinterval = (Requestinterval * Requesttimes + Interval) / (Requesttimes +   1 )

 

 

The calculated requestinterval is the request frequency of the client. It is also very simple in mathematics. It is an iteration similar to f (x) = AF (x) + B.Algorithm. This algorithm is specific to high performance. I only need to record the user's current request time and the total number of requests to fully monitor the user's request performance.

 

In addition, the number of customer errors must be recorded. In terms of design theory, the data transmitted by the customer should not be wrong unless the code is wrong. Of course, if the conversion problem between value types is false (the user enters the wrong value normally), this is not an error. The error value must be recorded in the database. Once the error value is found to be too large, the IP address is directly blocked.

 

It should also be noted that there must be a trigger on the server that traverses all connections Every X seconds. Once a long-time blank connection with no request is found, it should be actively kicked out.

 

-------------------

Socket server sending moduleDesign

-------------------

After the server completes data processing, it needs to return the processing result to the client. If you use a simple design idea, that is, directly push into the socket to send, the performance is very low; therefore, the socket to send must use the sending queue. The advantages of sending queue are:

 

A. When the data to be sent inside the server surge, the I/O processing pressure can be reduced by pressing in the sending queue. In many cases, we will find that the performance bottleneck of the entire server lies in Io processing (sending and receiving), rather than the database operations on the server. Therefore, it is designed to reduce Io processing.

B. The use of the sending queue can combine multiple reply data packets for one transmission, greatly reducing the I/O pressure.

 

The structure of the sending queue is a queue, which is roughly designed as follows: Code

Public   Class Sendmessagequeuecontroller
{
Queue < Socketconnection > Queue;
}

Public class socketconnection
{< br> private socketreceivequeue receivequeue; /// receiving queue
private socketsendqueue sendqueue; // sending queue
}

Public ClassSocketsendqueue
{
PrivateQueue<Isocketsendpackage>Queue;//Set of sending protocols
}

 

The Code logic is as follows:

 

A. Press the Protocol package to be sent into the current socketsendqueue.

B. JudgmentSocketconnectionWhether it already exists inSendmessagequeuecontroller. If it does not exist, it is included in the column. If it exists, it is returned.

C.Sendmessagequeuecontroller checks the sending queue every X milliseconds. If data is found, it enters the while loop until all socketconnections are listed and all data is sent. Then wait.

D. The so-called package merging and sending means that multiple protocol packages are written into the sent stream at a time, and then sent to the socket.

 

This design problem mainly focuses on thread conflicts. Several locks need to be added in the key areas; otherwise, thread conflicts may easily occur.

 

------------------

Postscript

------------------

 

The methods described in this article are not the best. I also believe that there are more mature ideas in the industry. However, some of the design ideas I listed in the article can at least meet the existing needs.

 

If you have better ideas, I hope you can leave more comments.

 

In the next article, we will design general logic modules for the server based on specific transmission protocols, such as re-transmission, data caching, and login/logout.