The sending data processing of game server

The concept of sending a data processing pattern:

It is believed that every person who writes the game server for the first time will send the data processing here, because it is more difficult to grasp the timing and drive of the message when compared with the processing of receiving message. Why, then? Let's look at the following socket-readable condition:

1: The number of data bytes in the socket receive buffer is greater than the receive low watermark

2: Read off of this connection

3: The socket is a listening socket and has a new connection

4: Error handling on this socket

All of the above conditions can be done by registering events, and because they are all passive triggers, it is easier to handle them.

Let's take a look at the conditions in which the socket can be written:

1: Free space in this socket send buffer is greater than sending high water mark

2: The socket is written off

3: Error handling on this socket

See the socket writable condition we were embarrassed, because we need to send, the socket is not necessarily writable, while the socket can be written, we may not have the data to send, which caused the waste of the event, but also caused the sending of data than to receive data more difficult.

This column more highlights: http://www.bianceng.cnhttp://www.bianceng.cn/Servers/zs/

We are here to place the sending and receiving of network data in a separate thread, called a network IO thread, while the other threads always handle the player logic, called the player logical thread.

Solution 1: Timed delivery.

Timed delivery is a more general treatment, but also a more convenient way to use. For each connection from the client, we just register the readable event, and do not register the writable event, for the sending process, we use the timer-triggered mode, such as each connection to bind a 30ms timer, each time the timer triggers, that is, write hunger, Do an attempt at each connection to send the processing.

When everyone sees the thought, I think the trouble will follow. Because is the 30ms timer, so each message delay is n*30ms; many sockets do not have data to send, but the timer to, causing a lot of waste; because the trigger of the timer is also rotation mode, we are not all say "rotation is rape?"

Solution 2: Register the Write event on demand

If we really understand the write event, we should register the write event on demand. Each time the player data is sent, if only part of the data is sent, the remaining data is stored in a custom buffer and the write write event is registered, and the event is triggered when the next select is fired, the remaining data is sent when the trigger is sent, and the write event is closed if the message is completed.

Here we separate the network IO thread and the game logic thread, if the network IO thread sends the data internally, then it is very simple to call the Send function. It's a bit of a hassle if you're sending data in a game logic thread. In order to ensure the security of the thread and the integrity of the data, in the game logic thread to call the interface to send data, the actual work is done in the network thread. In short, this function or task is posted to the network IO thread to execute.

We can refer to the following Muduo approach, if you are sending data in a non-network IO thread, encapsulate the socket and data that will be sent into functor, post it to the network IO thread, and wake up the network IO thread to handle the functors that needs to be performed (std::vector <Functor>).

I am modifying my own network send mode, is also this idea, but with the Java for multithreading provided by the Futuretask, if it is in the non-network IO thread to send data, will need to send the connection and data encapsulated into Futuretask, posted to the network IO thread, Wakes up IO threads to handle futuretasks (vector<futuretask>) that need to be executed.

Well, finally admit, in fact, in design, reference to the design of Mina, but see Muduo Network library and Mina design so similar, compared to Muduo design is also reference to Mina's design.

Many people may think that scenario 2 will increase system calls. Because we don't always say to reduce system calls. This is also the basis for the timer to send data patterns, but our TCP has provided the Negle algorithm, most of the Send function, just write data to the buffer, and not so much consumption. Everybody can test look down!