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

sxlongwork 2010-01-29

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信息

相关推荐