369棋牌游戏网络通信架构说明2ndEdition2012-11-2.docVIP

369棋牌游戏网络通信架构说明 369棋牌游戏的总体设计思路是 先设计了一个游戏框架作为游戏内核，向外暴露出接口，供游戏逻辑部分调用。 这个框架分为两部分：服务器端框架和客户端框架。下面分别描述： 服务器端框架 这部分编译好以后是一个kernelEngine.dll。这个dll向外暴露出几个Service接口。游戏的服务器端启动时，主要就是调用这几个Service接口的start()方法。先大致列举一下有哪几个Service,如下图所示： 下面那个队列服务，是不对外暴露的。它是供上面那几个引擎（也即Service）做请求排队用的。因为一个引擎，比如网络引擎，可能提交给它处理的请求同时有多个，这样就需要先放入一个队列里面。 队列服务的实现： 这个队列本身是做成一个服务的，启动该服务，会跑一个线程。该线程就是一直查询队列里的数据，发现有请求数据就调用服务的一个方法。而服务的这个方法会调用一个回调接口的方法。引擎如果要用到队列服务，就实现这个回调接口，然后初始化时把自己的指针传给队列服务。 网络引擎 启动时主要做了这几个工作： 1.因为要处理多个排队请求，它实现了队列服务的回调接口,把自己的指针传给了一个“发送队列服务”对象。 2.建立了一个IO完成端口。（IO完成端口主要就是windowsAPI的一个机制，其他平台估计也有类似机制。它主要就是把一个线程和IO操作状态关联起来。当一个IO操作完成时，windows系统把一个操作完成包放到一个队列里，和此IO完成端口关联的线程会调用一个windows API,读取该队列的操作完成包，拿到该包后，就可以根据包数据作些操作。如果队列里没有完成包，线程会挂在那里等待。） 3.这里建立的IO完成端口依次和ServerSocket也就是监听套接字，Accept进来的每一个通信Socket绑定。这样每次通过这个Socket读入数据还是写出数据，都能接收到IO完成端口的通知。以上这个绑定操作，是在一个名叫CsocketAcceptThread的“接收”线程里做的。现在网络引擎启动时，把这个线程启动了。 4.作为IO完成端口队列的消费者，还需要一个线程去拿到队列里的完成通知包。然后根据通知包，做一些操作。于是引擎也启动了这个线程。这个线程内部是这样的，它检测到这是一个读操作完成，就调用网络引擎的一个OnSocketReadEvent方法。这个SocketReadEvent方法会把一个EVENT_SOCKET_READ预定义的常数操作码，和数据buffer添加到调度引擎的操作队列里（就是用那个队列服务实现）。调度引擎里有一个switch…case结构，区分了几大类操作。其中有一类就是EVENT_SOCKET_READ（其他还有数据库操作的标识）。这个switch…case正好是放在调度引擎的队列服务的回调接口里的，供队列服务的线程调用。 网络引擎还有SendData方法，这主要就是把操作请求加到“发送”队列服务里。队列服务再调用引擎的回调方法。回调方法里就是用Accept来的保存起来的Socket发送数据。 调度引擎 该引擎就是接收其他引擎加到它的队列服务里来的操作请求数据，并进行处理。处理时呢，又向外面暴露出一个回调接口（钩子）。这个回调接口不由调度引擎自己实现，靠启动引擎时，由包装引擎的应用程序，比如游戏服务模块，传入一个实现。 游戏服务模块的这个实现就是CattemperEngineSink这个类。类里的这个OnEventTCPNetworkRead方法被调度引擎调用。这个方法也是一个switch…Case结构。该结构内有这么一段： case MDM_GF_GAME: //游戏消息 { return OnSocketMainGame(Command.wSubCmdID,pData,wDataSize,dwSocketID); }而处理客户端发来的消息，是委托给一个回调接口的。该回调接口由具体游戏比如：牛牛 来实现，名字叫CtableFrameSink的这个类。 这个类的OnGameMessage用了一个switch…case结构处理各种客户端发来的游戏消息。根据各类消息，结合GameLogic类进行处理。 客户端框架 客户端的网络通信也有一个框架。该框架相对简单，连接是在connect()方法里作的。连接后把socket句柄保存在成员变量里。然后建立了一个隐形的窗口，把socket和这个窗口关联起来。 用到了一个windowsAPI：WSAAsyncSelect。该API使得每当Socket的状态发生变化时，就会发送一个自定义的窗口消息给那个隐形的关联窗口。根据windows的消息循环机制，由窗口关联的过程来处理这个消息--又是一个switch…case 结构，对消息进行了分类：连接