教你从头写游戏服务器框架

在协议层面，最基本的需求有“分包”“分发”“对象序列化”等几种需求。如果要支持“请求-响应”模式，还需要在协议中带上“序列号”的数据，以便对应“请求”和“响应”。另外，游戏通常都是一种“会话”式的应用，也就是一系列的请求，会被视为一次“会话”，这就需要协众需要有类似 Session ID 这种数据。为了满足这些需求，设计一个层次为：Protocol。

拥有了以上两个层次，是可以完成最基本的协议层能力了。但是，我们往往希望业务数据的协议包，能自动化的成为编程中的对象，所以在处理消息体这里，需要一个可选的额外层次，用来把字节数组，转换成对象。所以我设计了一个特别的处理器：ObjectProcessor ，去规范通信模块中对象序列化、反序列化的接口。

Transport

此层次是为了统一各种不同的底层传输协议而设置的，最基本应该支持 TCP 和 UDP 这两种协议。对于通信协议的抽象，其实在很多底层库也做的非常好了，比如 Linux 的 socket 库，其读写 API 甚至可以和文件的读写通用。C# 的 Socket 库在 TCP 和 UDP 之间，其 API 也几乎是完全一样的。但是由于作用游戏服务器，很多时候还会接入一些特别的“接入层”，比如一些代理服务器，或者一些消息中间件，这些 API 可是五花八门的。另外，在 html5 游戏(比如微信小游戏)和一些页游领域，还有用 HTTP 服务器作为游戏服务器的传统(如使用 WebSocket 协议)，这样就需要一个完全不同的传输层了。

服务器传输层在异步模型下的基本使用序列：

1. 在主循环中，不断尝试读取有什么数据可读
2. 如果上一步返回有数据到达了，则读取数据
3. 读取数据处理后，需要发送数据，则向网络写入数据

根据上面三个特点，可以归纳出一个基本接口：

class Transport { 
public:    
   /** 
    * 初始化Transport对象，输入Config对象配置最大连接数等参数，可以是一个新建的Config对象。 
    */    
   virtual int Init(Config* config) = 0; 
 
   /** 
    * 检查是否有数据可以读取，返回可读的事件数。后续代码应该根据此返回值循环调用Read()提取数据。 
    * 参数fds用于返回出现事件的所有fd列表，len表示这个列表的最大长度。如果可用事件大于这个数字，并不影响后续可以Read()的次数。 
    * fds的内容，如果出现负数，表示有一个新的终端等待接入。 
    */ 
   virtual int Peek(int* fds, int len) = 0; 
 
   /** 
    * 读取网络管道中的数据。数据放在输出参数 peer 的缓冲区中。 
    * @param peer 参数是产生事件的通信对端对象。 
    * @return 返回值为可读数据的长度，如果是 0 表示没有数据可以读，返回 -1 表示连接需要被关闭。 
    */ 
   virtual int Read( Peer* peer) = 0; 
 
   /** 
    * 写入数据，output_buf, buf_len为想要写入的数据缓冲区，output_peer为目标队端， 
    * 返回值表示成功写入了的数据长度。-1表示写入出错。 
    */ 
   virtual int Write(const char* output_buf, int buf_len, const Peer& output_peer) = 0; 
 
   /** 
    * 关闭一个对端的连接 
    */ 
   virtual void ClosePeer(const Peer& peer) = 0; 
 
   /** 
    * 关闭Transport对象。 
    */ 
   virtual void Close() = 0; 
 
} 

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!