General game development will be designed to network traffic. Including the client side and the server side, but also yo even between servers.
Network Communication sent as data packets.
The simplest format than KLV (Key, Length, Value). Also encapsulated active and destination addresses in the top of this (for the convenience of adding the source address in response to postback). General Information Protocol address packet protocol package, conveniently forwards.
If a giant package, the situation is more complex, of course, require subcontractors, we will not consider here.
For these relative bottom (no business logic) packaging operation are generally hidden even be encapsulated.
But as to whether the data service layer needs to be encapsulated is a problem worthy of consideration.
Since the service layer data structure is more complicated, and where each data packet is relatively less than normal design (many protocols will be used only in one place). This sub-developers are accustomed to go directly into local use.
For example, go directly into a ByteBuff, or json, even a protobuf. I personally feel like protbuf library will only be used in cross-language interaction (cross-language a bit complicated, relatively high cost of building his own wheels), not that we do not need protobuf packaging functions, but we do not need protobuf. We should realize their packaged way, so that it can be more efficient communication. This article is trying to say.
demo：
void f1()
{
...
// Here we call an external interface to the
ByteBuff buff;
buff <<cmd << arg1 << arg2 << arg3;
Server :: send (buff) // underlying data transmission interface, ignoring the problem of address
...
}
This has two problems.
One caller communication protocol and protocol format too coupling.
Second, it is difficult to know at a glance which package code.
And if we carry package.
When you use a protocol like when you call a method the same.
demo:
void f1()
{
...
// Here we call an external interface to the
cmd(arg1,arg2,arg3);
...
}
void cmd(arg1,arg2,arg3){
ByteBuff buff;
buff <<cmd << arg1 << arg2 << arg3;
Server :: send (buff) // underlying data transmission interface, ignoring the problem of address
}
After the package where we can achieve a very clear agreement in the know.
When using more than one place to the agreement, changes to the protocol format without affecting the caller.
It can be compatible with a limited agreement to upgrade. For example, add a parameter, and given the default value.
On the other hand, for server-side (each protocol is always divided into client and server side)
The same is true
If the package is not like this
void server_cmd(buff)
{// cmd has been resolved
buff >> arg1 >> arg2 >> arg3;
...
}
Here there is a major problem, because the business logic and protocol analysis there is no separation, no way this business is called locally.
And after packaging
void server_cmd(buff)
{
buff >> arg1 >> arg2 >> arg3;
cmd_do(arg1,arg2,arg3);
}
void cmd_do(arg1,arg2,arg3)
{
...
}
Emergence of client and server paired agreement after packaging, place in a very convenient package and protocol. Since the function is very clean, but also help us to automate demand generation protocol code.
The client calls the agreement a logical and consistent format, easy to understand. At the same time then there is a need situation can easily switch whether to use remotely. For example, we allow the two services exist with a different process or processes. And when we find client and server in the same process, you can switch to a direct call.
As for ideas to thrift.
