游戏通信协议设计文档

游戏通信协议设计

1、概述

游戏通信协议包含两种不同的部分：客户端和服务器（C-S）之间的交互协议，游戏内部服务器（S-S）之间的交互协议。前者为了降低延迟，应该尽可能减少报文长度。同时，为了防止外挂，必须作加密处理。相反，后者在服务器之间，通信协议就可以比较灵活。

客户端和服务器的通信经过服务器的网关，经过中转分发到其他类型的服务器上或者分发给客户端。

2、客户端和服务器通信协议

协议采用分层原理，固定长度的报头把字节流分割成报文，除了基本的报文类型，应用相关的报文内容由应用自身决定，比如：对AS写的客户端用AMF编码报文内容。协议自动对报文内容做加密和解密。

Struct header {

uint32_t MsgLen; //信息包的长度，不包括固定长度的Header

uint16_t MsgSeq; // 该消息的序列号

uint8_t MsgType; //信息的类型

uint8_t MsgVersion; //信息的版本号，当前为0x1

uint16_t MsgCheck; //信息的校验码

uint8_t body[0]; //信息包的内容

};

校验码的计算：MsgCheck = (uint16_t)( MsgLen+ MsgType+ MsgSeq + MsgVersion )

网关与客户端传递的消息还需要经过xxtea的加密才可以。

序列号在连接认证的时候是0，以后递增；网关返回给客户端认证成功，序号也是从0开始。如果以后的报文序号发生错误，应该断开连接，让客户端执行重新连接。

网关根据命令类型，分解报文后，把内容转发到相应的服务器。有些报文类型对网关是透明的，网关不需要做特殊处理。有些类型的报文，网关必须知道报文内容的格式，在网关做特殊处理，主要是关系到用户（地图）位置变动的命令，比如：

1、用户连接认证。确认用户登录所在的网关。

2、用户更换房间。

3、用户更换桌子。

3、内部服务器通信

可以用多个key/Value的方式编码，比如：从客户端传过来的报文应该作为一个key/value，网关可以附加上该报文另外的信息：uid（哪个用户），用户所在位置（gateway_id,内部桌子号）。