记录：protobuf在网游中的用法

消息传递过程:

client ---> gated ---> zoned

CS消息结构:

message Head
{
         uint32 cmd_id;
}

message Body
{
          AuthReq auth_req;
}

message CSMessage
{
          Head head;
          Body body;
}

发送数据格式：16bits len + CSMessage。

gated--->zoned也有一套消息

message GZMessage
{
      uint32 uid;           // 账户ID
      uint32 sessionState;  // 表示client与gated的某个session的建立，传输过程和结束
}

gated发给zoned的消息格式： total_len + GZMessage_len + GZMessage + CSMessage。

gated处理过程

client连接到gated，发的第一个包是签名包。

gated收到Len + CSMessage。

gated收到第一个包时，解析CSMessage，如果签名通过，向zoned发start_GZMessage。

接下来收到的包，gated不作任何解析，直接转发给zoned。

整个的Session生命周期中，gated只做一次CSMessage encoding&decoding，其他时候都是透传。

zoned处理过程

zoned收到total_len + GZMessage_len + GZMessage + CSMessage。

total_len是分tcp stream用的， GZMessage_len是给zoned解析GZMessage用的。zoned先解析出GZMessage，然后将CSMessage传给逻辑层。

上面的过程的一个优点是，没有大量的没必要的protobuf的Message解析。

gated用到CSMessage的head信息

有的gated须要知道CSMessage head的信息，比如要知道cmd_id，以便在gated统一地控制每个命令的发包频率，怎么办？

直接的做法，解析整个CSMessage包，拿到cmd_id。这个成本高了点了。改变一下方式。

message CSMessageHead
{
         uint32 cmd_id;
}

message CSMessageBody
{
          AuthReq auth_req;
}

就是把消息体分成两部分，head和body不在一个Message里了。

发送的消息格式; total_len + msg_head_len + CSHead + CSBody。

gated只要根据msg_head_len把CSHead解析出来就可以获取头部信息了。

发给zoned的格式： total_len + GZMsg_len + GZMsg + CSHead_len + CSHead + CSBody。

gated转发数据给zoned时，没有多余的数据解析和数据拷贝。