Game Development Protocol (RPM)

Transferred from: http://erlangdisplay.iteye.com/blog/1012785

Erlang Game development-protocols

What protocol to choose?
Protocols contain communication protocols and data formats.
Communication protocols
Communication protocols are now commonly used: HTTP and TCP. It has its own characteristics according to the characteristics of the game to choose.
HTTP
HTTP is relatively mature and widely used. Has a wealth of basic software and tools.
For a simple social game you can use HTTP as the communication protocol.
This kind of game to the real-time requirements are not very high, using HTTP is also easy to achieve performance expansion, can better meet the needs.
If the game front-end uses HTML+JS development, then can only use HTTP, need good interactivity and real-time, only
Implemented using HTTP long polling. If the front-end uses flash development, the game interaction is complex, the real-time requirement is high, then the HTTP
would be inappropriate.
Tcp
HTTP is an advanced application protocol, and TCP is a relatively basic protocol. HTTP is also based on the TCP implementation.
For some web game, TCP is basically used. Its concurrency is small (web game is usually online for thousands of people), and
Real-time requirements are high, especially for ARPG games. So TCP is the perfect choice. Most of its frontend is implemented with Flash (because
HTML5, HTML+JS cannot create a TCP socket. As for non-80, non-443 port firewall problems, it seems
Can be ignored under the network environment.
Data format
Text formats, such as Xml,json or custom, can be used as data formats for transmission, and the greatest benefit of text format is readable,
Easy to debug, the disadvantage is that the data volume is large, redundant information too much. (Can be made up by compression, of course). So in the web
Text is seldom used as a data transfer format in game.

Except that the text is a binary protocol. Binary protocols are also divided into a variety of types: Protobuf,thrift and other universal binary transport protocols and
Custom binary format. The benefits of using PROTOBUF and thrift are universal, multi-lingual support, and a scale comparison
More suitable for environments with multiple development languages. As a web game, usually a studio is responsible for a product,
The technologies and languages used by client and server are relatively deterministic, so these generic binary transport protocols are not the best choice,
At the same time, it also caused some performance degradation because of the general purpose.

Most games currently use a custom binary protocol with the basic structure: a few bytes of the head represent the length of the data body, followed by
Data body. In the data body, you can divide a few bytes (for example, 2) to represent a message. We define the data for each message.
Format. Its approximate appearance is as follows: [2 bytes data length][2 byte message type, specific message body].
What to do with Erlang?
It is very simple to implement such a protocol in Erlang, and setting INET:SETOPTS/2 's packet option to 2 will support us
The agreement. Erlang automatically takes 2 bytes first, as a length, and then continues to accept the data, knowing that the packet is received,
Eliminates the pain:) of our own understanding of packages, sticky packs (Note 2 yourself using unsigned Big-endian encoding).
With the data body, the next 2-byte message type is processed, and Erlang provides a thoughtful option: {header, size} (Note that this option is only valid when the binary option is set by the socket). And here we set {header, 2}, So we receive the data body, not a whole block, but this: [Byte1, Byte2 | Binary],byte1,byte2 is the first 2 bytes of the data body that Erlang intercepts for us. For friends who are familiar with Erlang, I ask a question:
Is this data a list of formatting rules? The answer is no, the list is a "malformed" list because its last element is not a list. Some detour ...

Also, in Erlang, TCP has an active option with a value of: true, false, once. Read the book understand, it is used to control the TCP data receive mode. By using inet:setopts (Sock, [{Active, once} ], we can let the data obediently obedient, the initiative to send us a data, and then become not active, we processed the message, and then set up the active once, it continues to send us a data. The advantage of this is that we are overwhelmed by the fact that {active, true} sends us a lot of data. It doesn't make it tiring to manually gen_tcp:recv/2 data every time.

In-game protocol message type up to hundred, this process if manual coding will be very tired, should be at the beginning, and then determine the protocol format, the script to complete the protocol codec automatic generation, once and for all! Greatly reduce the possibility of debugging errors. After the protocol has been modified, You can regenerate the code with a single command. Very happy. (Some teams, more geek, directly use the erlang:term_to_binary as a binary protocol, by the flash side of Erlang term parsing, very powerful).

Finally, the first thing to do is to get the network and protocol done, and the game begins.

Game Development Protocol (RPM)