Design and definition of data packets in online games (preliminary discussion)

I have been in touch with the online game package design for a period of time and have some preliminary ideas. I would like to summarize this article and make a record to facilitate future updates of my own ideas.
Online Game technology R & D involves three main aspects: Server Design, client design, and database design. The game logic mediation between the server and the client is the game data packet. The server and client drive the game logic by exchanging game data packets and driving the game logic according to the analyzed data packets. The essence of online games is interaction, while interaction control is completed by collaboration between the server and the client, and collaboration must rely on data.
Packets in online games are defined in a variety of forms. However, in summary, they generally have the following elements: Packet Length, packet type, packet parameters, verification code, and so on.
The packet length is used to determine the length of the current game data packet. The reason for providing this data is that in the underlying TCP network transmission, for the sake of transmission efficiency, transmission sometimes merges several small data packets into one large data packet and sends them out. In the merge process, not all the logical and complete data packets are merged together, sometimes, because of this merge, a logically complete game data packet may be sent in two sending processes. In this way, after the current data is sent to the receiver, the data packets at the end of the game will inevitably cause a "tail disconnection" phenomenon. In order to determine the situation and the specific content of the tail disconnection, the game data packets generally provide the packet length information during design, based on this information, the recipient will know whether the received package has been terminated. If yes, then, We splice the data packet with the next packet to generate the complete data packet in the logic sense.
The package type is used to identify the type of the current package, indicating what it means.
The encapsulation parameter is a more specific description of the encapsulation type, which specifies the required parameters in this type of encapsulation description. For example, a speech packet can be represented by a numerical value. The specific speech content and speaker are used as the packet parameters.
The purpose of the Verification Code is to verify the content of the preceding packets to ensure that the content of the packets will not be changed during transmission. Based on the verification code, you can also determine whether the package is in a valid format. Verification codes are widely used in online games to improve packet security. The encapsulation design generally determines the overall structure of the encapsulation first, and then details which packets are subdivided and what content should be included in each packet, at last, the number of bytes in each part of the package and its meaning are detailed.
The specific design of data packets is generally divided and delineated Based on Game functions. For example, if a game has a chat function, you must design a chat packet between the client and the server. The client must have a packet describing the speech content and spokesman information, on the server side, a broadcast packet containing the user's speech content and spokesman information is required. Through this packet, the server side can broadcast to other nearby players to send the current players' speech content. For another example, if the game requires a transaction function, the corresponding function may have the following data packets: Apply for a transaction package, apply for a transaction information package, and allow or reject a transaction package, information packages that allow or reject transactions, submit Transaction item packages, submit Transaction item packages, confirm transaction packages, cancel transaction packages, and cancel transaction information packages, information Package for successful or failed transactions. Note that some of these packets are used by one party but not the other, while others are used by both parties. For example, to apply for a transaction package, only one party can use the package, and the other party will obtain an information package for the transaction application. The other party confirms the data package such as the transaction package and submits the transaction items, both parties must use it at the same time when deciding to make a transaction. The packaging design also follows the top-down design principle, that is, to determine the functions of the packaging, and then determine the information that should be contained in the package, finally, determine the location and length of the information. Layer-by-layer analysis and definition form a complete package definition solution. In the actual packaging design process, backtracking often occurs. Because the initial design considerations are not weekly or other reasons, it may cause modification or addition or deletion of the packaging design scheme. At this time, an important problem is to update your design documents in time. In my packaging design, I used the following packet description table for description:
The description of the corresponding class or struct name Type of the package ID function. The structure and meaning of the command and Command Parameters
Based on the features of the game, we can roughly define the approximate structure of the package and its contents. However, the packaging design also includes more content. How can we shorten the packaging design length while ensuring the concise packaging logic to improve the packet transmission speed and the game running speed, this is also an important issue that we should consider. Generally, when designing a packet, we should avoid generating packets larger than one hundred bytes. Most packets are defined to be less than 100 bytes, or even 20-50 bytes. Most of the packets I have defined are 20 bytes or less, and the packets such as the transfer server list and user list may be larger. In a word, we should use the content as short as possible to describe the function and meaning of the package as concisely and clearly as possible.
In terms of encapsulation structure design, I have another extensible idea: dynamically define the positions of each element in the package. In this way, when switching to another game or changing the current game's package structure, you only need to change the dynamic definition of these elements without completely re-designing the package structure. For example, we define the starting position and length of the packet numbers, packet types, packet parameters, and verification codes to form a dynamically Defined Packet structure, it will be of great help for future packet transplantation. A game packet that may dynamically change the packet structure will increase the difficulty of plug-in analysis of the packet structure.
When designing a package, it is best to design the package based on the differences between the client and the server. For example, the hall is designed separately from the game server package and the game server and the game client package. The package numbers indicate their differences (represented by different starting words ), in this way, the overall structure of the package will be clearer.

 

This article from the CSDN blog, reproduced please indicate the source: http://blog.csdn.net/sodme/archive/2004/06/23/22958.aspx