系列三：游戏服务器的邮局服务器

 

QQ: 2#4#2#1#0#6#7#6#4    #表示为空  
Mail: lin_style#foxmail.com    #替换成@ 

行为
难点
邮局服务器流程图
邮局服务器详细图
安全

 

 

行为
邮局服务器控制着两个对象，客户端和bin程序。

接收客户端的协议，根据协议中的信息找到bin，把信息转发向该bin
接收bin的协议，根据协议中的信息找到客户端，把信息转发向该客户端

难点
       首先是连接对应。需要有3方的连接通讯
自己作为服务器(完成端口模型): 接受游戏客户端的连接,接受bin的连接
作为客户端：连接邮局路由，提供信息

那何BIN程序之间的通讯呢？我这里把BIN程序当成一个游戏客户端来通讯。原因有2

• 虽然BIN和邮局服务器的通讯时双向的，但是邮局服务器是作为一个主要的中转站，有在其处登记过的才算是一个签约客户的关系，这样比较符合逻辑上的理解和功能的归纳
• 如果将邮局服务器作为客户端进行发起连接，除了BIN服务器外，可能还有其他类型的服务器程序(比如一些全局的服务器)，还要额外的对这些套接字和线程进行维护。

       其次是数据的对应。客户端和BIN都需要一个编号标识。需要知道当前客户端在那个BIN程序里。如果是做成实时的表示BIN里用户的集合情况。比如收到一个信息，获取用户名，然后再去查找这个用户在那个BIN里，接着找到BIN的套接字，最后发送。必然会非常的繁琐和复杂，其中还涉及到许多增删的动作。
       最后采取如下：(保留套接字信息)
       在三方( 客户端，邮局，BIN )中，客户端做为独立，不参与信息冗余。邮局对连接至的BIN建立起套接字数组，客户端发送时，带上该数组索引信息，邮局进行查询后直接转发给BIN；在转发中带上客户端套接字的值和ip,port。
BIN发送时，将邮局发送的客户端原样转发，邮局收到后进行验证客户端IP是否变动，如果一致则转发。

Struct
{
    int         nBinIndex;               //发给哪个bin
    unsigned  int        nPlaySocket;  //客户端套接字
    unsigned  int     nPlayIP;         //客户端IP
    int         nPlayPort;             //客户端port;
};

 简单示例图如下：

客户端向邮局服务器发送的

 

 

bin服务器向邮局服务器发送的

 

邮局服务器流程图

邮局服务器详细图

安全

在接受内部的连接时，需要进行IP绑定等“写死”操作
客户端来源防劫持(bin中处理，这里略提):需验证每个协议体中的IP+PORT信息