服务器 - C＃，客户端 - 闪存，数据交换协议

Question

We are writing online multiplayer game in Flash wish .Net server side, we need duplex channel so communication is done using sockets.

Can you tell me some best practices about protocol/format of exchanging data between server and client? IMO one of good choise may be using JSON serialization.

Answer 1

I think, JSON can be the best choice and let me explain why.

Firstly, JSON-serialized game traffic is ligth-weighted, because JSON notation is like "name : val", not like "<name> val </name>" .

Secondly, JSON serialization is the most intuitive one for games. XML and XML-like notations are good for multiline data, but in-game variables' values are usually rather short (HP, mana, AP, damage, etc.) and can be discribed with one line.

Thirdly, Actionscript 3 (I hope, you won't write MMO in AS2) has got perfect tools for JSON decoding/encoding. XML-parsing tools are good too, but IMO, JSON's are better. Also, in Flash 11+, JSON operations are extremely optimized.

Fourthly, many high-load projects use cache-servers with MongoDB, and it's main format is BSON (Binary JSON), so using JSON in this case will simplify data communication between DB and everything else.

Answer 2

The good solution is a proprietary protocol because it will provide perfect performance and traffic optimization.

We have tried the different protocols to search a best one for our online poker.

The result of research is the next protocol:

The first two bytes is a package type. The second two bytes of package is size of package. The N bytes package body

1. Load the leading 4 bytes from the socket to get size and type of package.
2. Load package body
3. Send package body to process to the message type handler

Answer 3

It depends. Forget the involved technologies for a while and focus on your specific comm needs. Hope you don't mind if I explore a few related points as well.

• Point-to-point (p2p) flow : We know this one - Duplex, as you mentioned.
• p2p mode : Half- or Full-duplex? Will data be exchanged simultaneously, or it is always a message-response mechanism?
• State : You may have code that will wait for a response, even if the major part of your exchange is asynchronous. Is the exchange absolutely async? sync? mixed? This point is tightly related to the previous one.
• Transmission : Data bursts, or constant streams?
• Bandwidth : How many bytes/sec do you expect to traffic around? Is it a considerable percent of your target network (wireless? mobile? hi-speed?)
• Reliable/unreliable content : Does the loss of a data package tosses your client state in disarray? (This isn't a bad thing per se, just a spec.)

If your code needs any kind of synchronous content, then you may need a reply flow control on you code, and a Messaging structure of some sort where Messages have an ID and may have a Original Message ID to which they are a reply. This will help you control content even on async protocols. In this case, an easily maintanable protocol like JSON may be better, as @ JustLogin mentioned.

Full-Duplex mean you be staging more data on your network/interpreter layer, and it probably will have to handle asynchronous communications.

If performance is a concern, and depending on your specifics, then proposals like the one made by @ Viacheslav can be attractive. A custom protocol can be heavily optimized, at the cost of maintanability and portability (several languages have their own JSON interpreter, while custom interpreters may need to be implemented or encapsuled, adding layers to the process and thus lowering performance, or requiring code conversion.)

If you couldn't care less if a packet or two are lost, then UDP may be a viable solution. Less control than TCP means a lighter protocol, but you're never sure that the data reached the other side unless you implement your own control.

TL;DR version: I would stick to standard low-level protocols like JSON, even if they add some overhead.