|
RunGate有三个Socket对象 一个向M2发送 一个接收客户端的连接。还有一个连接控制台(当然这个是和控制台绑定的通常手动启动是不需要的 只是在私服这方面方便私服架设 者使用) 控制台Socket会每隔一段时间向控制台发送保活包。如果没有发送 那么控制台肯定是知道rungate没反应了或者被关闭了 然后可以立马又开启。纯粹是为了私服假者简单而考 虑。 本文来自织梦
织梦好,好织梦
实际只有2个Socket对象才是最主要的。M2Sokcet和ClientSocket。 织梦内容管理系统 copyright dedecms
整个结构当然是使用的典型生产者消费者模型。 但是代码结构很不清晰.而且消息的处理是使用Timer来处理,而不是线程。 dedecms.com
copyright dedecms
程序在通过一个常量定义了在栈上的会话数量。当程序开始运行会 在栈上有一个数组 保存会话信息。 会话信息是一个结构体,内部记录了会话的信息,比如连接时间,封包大小 dedecms.com
内容来自dedecms
以及 上次移动时间 上次通讯时间等等。 本文来自织梦 copyright dedecms
当有客户端连接时候。会在预分频的数组内找到一个未使用的空间。初始化这个数组的内容 将当前的客户端连接保持在这个会话之内。 内容来自dedecms 本文来自织梦
当收到客户端的信息时候,会进行一系列合法的验证 或者保护。最终将消息生成一个消息体: 织梦好,好织梦
内容来自dedecms
ReviceMsgList.Add(UserData); //加入收到的消息列表内。 dedecms.com 织梦好,好织梦
收收到服务端的消息的时候。将消息头部 转换成如下消息格式: 本文来自织梦
本文来自织梦 copyright dedecms
- TMsgHeader = packed record
- dwCode: LongWord;
- nSocket: Integer;
- wGSocketIdx: Word;
- wIdent: Word;
- wUserListIndex: Integer;
- nLength: Integer;
- end; dedecms.com
复制代码 内容来自dedecms
记录了消息的类型 长度 和Socket句柄等消息。根据wIdent的值 本文来自织梦
- case pMsg.wIdent of
- GM_CHECKSERVER: begin //客户端需要先验证网关
- boCheckServerFail := False;
- dwCheckServerTimeMin := GetTickCount - dwCheckServerTick;
- if dwCheckServerTimeMin > dwCheckServerTimeMax then
- dwCheckServerTimeMax := dwCheckServerTimeMin;
- //dwCheckServerTick := GetTickCount();
- end;
- GM_SERVERUSERINDEX: begin //wGSocketIdx 为服务端的Socket句柄 这句主要是修改wUserListIndex。暂时没看出要干嘛
- if (pMsg.wGSocketIdx < RUNATEMAXSESSION) and (pMsg.nSocket =
- SessionArray[pMsg.wGSocketIdx].nSckHandle) then begin
- SessionArray[pMsg.wGSocketIdx].nUserListIndex := pMsg.wUserListIndex;
- end;
- end;
- GM_RECEIVE_OK: begin
- {dwCheckServerTimeMin := GetTickCount - dwCheckRecviceTick;
- if dwCheckServerTimeMin > dwCheckServerTimeMax then dwCheckServerTimeMax := dwCheckServerTimeMin;
- dwCheckRecviceTick := GetTickCount(); }
- SendServerMsg(GM_RECEIVE_OK, 0, 0, 0, 0, nil); //消息到达处理,貌似很没必要吧。应该是M2会做一些处理
- end;
- GM_DATA: begin
- ProcessMakeSocketStr(pMsg.nSocket, pMsg.wGSocketIdx, MsgBuff, pMsg.nLength);//进行编码处理后 加入到每个会话的列表(实际是string)。此时并不是发送,并将消息加入SendMsgList;
- end;
- GM_TEST: begin
- end; 织梦内容管理系统
复制代码 dedecms.com
DecodeTimerTimer 是网关处理数据的主循环。 首先此函数会更新界面显示,(这个耦合性也太大了吧。业务逻辑 跟界面扯上了关系)。 本文来自织梦
dedecms.com
然后将ReviceMsgList内所有的收到的消息发送给M2处理。(客户端发送过来的) 织梦内容管理系统
dedecms.com
接着将SendMsgList 内所有的消息 投递到客户端(每个消息包括了客户端描述 所以可以知道应该投给哪个客户端)。然后每2秒向M2发送一个保活包。 织梦内容管理系统 内容来自dedecms
本文来自织梦
copyright dedecms
总结: 网关收到客户端的包 是直接转发给M2的其中并没有解密。而M2发送给客户端的消息是要经过网关再EncodeMessage。也就是说网关并没有承担起完整的加解密。 dedecms.com
copyright dedecms
M2还要负责客户端的解密操作。可以看出传奇的源码在设计上不太理想。 本文来自织梦
dedecms.com
思考: Srv处理应该主要集中在游戏数据的处理上 而封包的加密解密 应该给游戏网关进行。同时游戏网关内,不宜开多线程进行操作。因为游戏网关面对的资源是整个计算机的 资源。过多的线程可以让单个网关获得比较好的效率。但是游戏网关在设计中并不是让自身获得更好的效率 而是让整个计算机的资源充分的利用。如果自身一个网关无 法处理用户请求的时候,应该开启多个网关协同处理。 所以在网关的设计上应该将发送和接受 编码解码 放在同一个线程内。以多进程取代多线程,以避免在多线程处理 因为生产者消费者模型 而导致两个线程实际只有一个线程在工作。 个人愚见 错误请指正。 织梦好,好织梦
|
上一篇:设置怪物的移动(巡逻)路线教程下一篇:热血传奇Tile地图绘制方法分析及平滑绘制分析
|