2005年08月31日

本文作者:sodme
本文出处:http://blog.csdn.net/sodme
声明:本文可以不经作者同意任意转载、复制、引用。但任何对本文的引用,均须注明本文的作者、出处以及本行声明信息。

  提笔注:扫地只是偶的表面工作,偶的真实身份是作MMORPG。^_^

  之前,我分析过QQ游戏(特指QQ休闲平台,并非QQ堂,下同)的通信架构(http://blog.csdn.net/sodme/archive/2005/06/12/393165.aspx),分析过魔兽世界的通信架构(http://blog.csdn.net/sodme/archive/2005/06/18/397371.aspx),似乎网络游戏的通信架构也就是这些了,其实不然,在网络游戏大家庭中,还有一种类型的游戏我认为有必要把它的通信架构专门作个介绍,这便是如泡泡堂、QQ堂类的休闲类竞技游戏。曾经很多次,被网友们要求能抽时间看看泡泡堂之类游戏的通信架构,这次由于被逼交作业,所以今晚抽了一点的时间截了一下泡泡堂的包,正巧昨日与网友就泡泡堂类游戏的通信架构有过一番讨论,于是,将这两天的讨论、截包及思考总结于本文中,希望能对关心或者正在开发此类游戏的朋友有所帮助,如果要讨论具体的技术细节,请到我的BLOG(http://blog.csdn.net/sodme)加我的MSN讨论。

  总体来说,泡泡堂类游戏(此下简称泡泡堂)在大厅到房间这一层的通信架构,其结构与QQ游戏相当,甚至要比QQ游戏来得简单。所以,在房间这一层的通信架构上,我不想过多讨论,不清楚的朋友请参看我对QQ游戏通信架构的分析文章(http://blog.csdn.net/sodme/archive/2005/06/12/393165.aspx)。可以这么说,如果采用与QQ游戏相同的房间和大厅架构,是完全可以组建起一套可扩展的支持百万人在线的游戏系统的。也就是说,通过负载均衡+大厅+游戏房间对游戏逻辑的分摊,完全可以实现一个可扩展的百万人在线泡泡堂。

  但是,泡泡堂与斗地主的最大不同点在于:泡泡堂对于实时性要求特别高。那么,泡泡堂是如何解决实时性与网络延迟以及大用户量之间矛盾的呢?

  阅读以下文字前,请确认你已经完全理解TCP与UDP之间的不同点。

  我们知道,TCP与UDP之间的最大不同点在于:TCP是可靠连接的,而UDP是无连接的。如果通信双方使用TCP协议,那么他们之前必须事先通过监听+连接的方式将双方的通信管道建立起来;而如果通信双方使用的是UDP通信,则双方不用事先建立连接,发送方只管向目标地址上的目标端口发送UDP包即可,不用管对方到底收没收到。如果要说形象点,可以用这样一句话概括:TCP是打电话,UDP是发电报。TCP通信,为了保持这样的可靠连接,在可靠性上下了很多功夫,所以导致了它的通信效率要比UDP差很多,所以,一般地,在地实时性要求非常高的场合,会选择使用UDP协议,比如常见的动作射击类游戏。

  通过载包,我们发现泡泡堂中同时采用了TCP和UDP两种通信协议。并且,具有以下特点:
  1.当玩家未进入具体的游戏地图时,仅有TCP通信存在,而没有UDP通信;
  2.进入游戏地图后,TCP的通信量远远小于UDP的通信量

  以上是两个表面现象,下面我们来分析它的本质和内在。^&^

  泡泡堂的游戏逻辑,简单地可以归纳为以下几个方面:
  1.玩家移动
  2.玩家埋地雷(如果你觉得这种叫法比较土,你也可以叫它:下泡泡,呵呵)
  3.地雷爆炸出道具或者地雷爆炸困住另一玩家
  4.玩家捡道具或者玩家消灭/解救一被困的玩家

  与MMORPG一样,在上面的几个逻辑中,广播量最大的其实是玩家移动。为了保持玩家画面同步,其他玩家的每一步移动消息都要即时地发给其它玩家。

  通常,网络游戏的逻辑控制,绝大多数是在服务器端的。有时,为了保证画面的流畅性,我们会有意识地减少服务器端的逻辑判断量和广播量,当然,这个减少,是以“不危及游戏的安全运行”为前提的。到底如何在效率、流畅性和安全性之间作取舍,很多时候是需要经验积累的,效率提高的过程,就是逻辑不断优化的过程。不过,有一个原则是可以说的,那就是:“关键逻辑”一定要放在服务器上来判断。那么,什么是“关键逻辑”呢?

  拿泡泡堂来说,下面的这个逻辑,我认为就是关键逻辑:玩家在某处埋下一颗地雷,地雷爆炸后到底能不能炸出道具以及炸出了哪些道具,这个信息,需要服务器来给。那么,什么又是“非关键逻辑”呢?

  “非关键逻辑”,在不同的游戏中,会有不同的概念。在通常的MMORPG中,玩家移动逻辑的判断,是算作关键逻辑的,否则,如果服务器端不对客户端发过来的移动包进行判断那就很容易造成玩家的瞬移以及其它毁灭性的灾难。而在泡泡堂中,玩家移动逻辑到底应不应该算作关键逻辑还是值得考虑的。泡泡堂中的玩家可以取胜的方法,通常是确实因为打得好而赢得胜利,不会因为瞬移而赢得胜利,因为如果外挂要作泡泡堂的瞬移,它需要考虑的因素和判断的逻辑太多了,由于比赛进程的瞬息万变,外挂的瞬移点判断不一定就比真正的玩家来得准确,所在,在玩家移动这个逻辑上使用外挂,在泡泡堂这样的游戏中通常是得不偿失的(当然,那种特别变态的高智能的外挂除外)。从目前我查到的消息来看,泡泡堂的外挂多数是一些按键精灵脚本,它的本质还不是完全的游戏机器人,并不是通过纯粹的协议接管实现的外挂功能。这也从反面验证了我以上的想法。

  说到这里,也许你已经明白了。是的!TCP通信负责“关键逻辑”,而UDP通信负责“非关键逻辑”,这里的“非关键逻辑”中就包含了玩家移动。在泡泡堂中,TCP通信用于本地玩家与服务器之间的通信,而UDP则用于本地玩家与同一地图中的其他各玩家的通信。当本地玩家要移动时,它会同时向同一地图内的所有玩家广播自己的移动消息,其他玩家收到这个消息后会更新自己的游戏画面以实现画面同步。而当本地玩家要在地图上放置一个炸弹时,本地玩家需要将此消息同时通知同一地图内的其他玩家以及服务器,甚至这里,可以不把放置炸弹的消息通知给服务器,而仅仅通知其他玩家。当炸弹爆炸后,要拾取物品时才向服务器提交拾取物品的消息。

  那么,你可能会问,“地图上某一点是否存在道具”这个消息,服务器是什么时候通知给客户端的呢?这个问题,可以有两种解决方案:
  1.客户端如果在放置炸弹时,将放置炸弹的消息通知给服务器,服务器可以在收到这个消息后,告诉客户端炸弹爆炸后会有哪些道具。但我觉得这种方案不好,因为这样作会增加游戏运行过程中的数据流量。
  2.而这第2种方案就是,客户端进入地图后,游戏刚开始时,就由服务器将本地图内的各道具所在点的信息传给各客户端,这样,可以省去两方面的开销:a.客户端放炸弹时,可以不通知服务器而只通知其它玩家;b.服务器也不用在游戏运行过程中再向客户端传递有关某点有道具的信息。
  
  但是,不管采用哪种方案,服务器上都应该保留一份本地图内道具所在点的信息。因为服务器要用它来验证一个关键逻辑:玩家拾取道具。当玩家要在某点拾取道具时,服务器必须要判定此点是否有道具,否则,外挂可以通过频繁地发拾取道具的包而不断取得道具。

  至于泡泡堂其它游戏逻辑的实现方法,我想,还是要依靠这个原则:首先判断这个逻辑是关键逻辑吗?如果不全是,那其中的哪部分是非关键逻辑呢?对于非关键逻辑,都可以交由客户端之间(UDP)去自行完成。而对于关键逻辑,则必须要有服务器(TCP)的校验和认证。这便是我要说的。

  以上仅仅是在理论上探讨关于泡泡堂类游戏在通信架构上的可能作法,这些想法是没有事实依据的,所有结论皆来源于对封包的分析以及个人经验,文章的内容和观点可能跟真实的泡泡堂通信架构实现有相当大的差异,但我想,这并不是主要的,因为我的目的是向大家介绍这样的TCP和UDP通信并存情况下,如何对游戏逻辑的进行取舍和划分。无论是“关键逻辑”的定性,还是“玩家移动”的具体实施,都需要开发者在具体的实践中进行总结和优化。此文全当是一个引子罢,如有疑问,请加Msn讨论。

本文作者:sodme
本文出处:http://blog.csdn.net/sodme
声明:本文可以不经作者同意任意转载、复制、传播,但任何对本文的引用均须注明本文作者、出处及本行声明信息。谢谢!

  封包分析的手段,说简单也挺简单的,那就是:比较!要不断地从不同的思维角度对封包进行对比分析,要充分发挥你的想象力不断地截取自己需要的包进行比较。不仅要作横向(同类)的比较,还要作纵向(不同类)的比较。即时对于同一个包,也要不断地反复研究。

  初涉封包分析的新手,一般会不知道封包分析究竟该从何入手。基于经验,本文将告诉你一般会从哪些类型的包入手进行分析以及应该怎样对封包进行初步的分析。需要指出的是:封包分析是一件非常有趣但同时也非常考验耐心的事,通常,半天的封包分析下来,会让你眼前全是诸如“B0 EF 58 02 10 72….”之类的网络数据,而且附带有头疼、头晕症状,所以,没有充分的心理准备,还请不要轻易尝试。呵呵。

  从事封包分析的基本前提是:应该了解和熟悉TCP协议,并知道数据包“粘合”是怎么一回事。当然,我们平常截获到的包,从数量上来看,只有一小部分是属于“粘合”的情况。但如果不了解它,将可能会对你的分析思路产生误导和困惑。关于“粘包”的更详细解释,请参考我的另外一篇文章“拼包函数及网络封包的异常处理(含代码) (http://blog.csdn.net/sodme/archive/2005/07/10/419233.aspx)”。

  上一篇有关魔兽世界封包分析的文章(http://blog.csdn.net/sodme/archive/2005/06/18/397371.aspx)中,我根据客户端与服务器端连接及断开事件的处理流程以及登录过程中的一些数据包分析了魔兽的架构和登录逻辑。这篇文章中,我将结合聊天数据包的分析,来阐述魔兽世界封包的大体结构。  

  首先解释一下我们的目标:封包的大体结构。封包的大体结构包含哪些内容呢?一般情况下,封包的大体结构至少包括两方面的信息:
  1、一个封包是如何表示它的长度的?封包长度是由哪个字段表示的?(或者说:如何表示封包的开始和结束的)
  2、各种不同的封包类型是通过哪个字段表示的?

  是不是所有游戏的封包都必然会有表示“长度”信息的“字段”呢?答案是否定的。有的游戏确实没有采用这种方式,它们的作法设定特殊的包开始和包结束标志。但是,从应用的角度来看,偶推荐使用“长度”这样的方法,因为不管在网络底层的处理效率以及上层应用的处理便捷性来说,使用“长度”字段标识一个完整的逻辑包都是比较好的办法。在确定了封包的大体结构后,我们才方便分析具体类型包(比如聊天、行走等)的详细结构。

  作数据包分析,在单纯采用黑箱分析的阶段,我们选取的数据包,须要是具有这种性质的,即:在数据包发送前客户端未进行加密等处理时,这个数据包中的部分内容,我们是已经知道的。这样的包,就可以作为封包分析的突破口。这样看来,我们拿“聊天封包”作为第一个分析对象也就不难理解了,因为我们说的话,打上去的字,我们自己是知道的,但是我们说的话经过客户端的处理后,发到网络上的可能就是已经加了密的或者加了校验码的。站在黑箱分析的角度,我们能作的,就是不断截取各种“聊天包”进行对比、判断和总结。

  OK,打开你的commview。让我们从“聊天封包”开始。

  分析“聊天包”的前提,是我们能够正常判断哪种类型的数据包是属于聊天的,不要误把行走或其它的数据包当作了聊天数据包。为了减小分析难度,建议新手到游戏中人少或周围没有玩家的地方进行封包分析。这样一来没人打扰,二来你的网络通信量会相对小得多,比较容易进行一些封包判定。

  第一步,我们需要确定客户端与服务器通信所用的端口,然后在commview的rules->ports中设定服务器端口,截获与该端口通信的所有数据包。服务器端口的确定方法:不要使用其它网络通信工具,打开commview,进游戏,截包,观察其通信端口。进行封包分析时,特别是初期的封包分析时,你的网络通信应该尽可能是单一的,即:除了游戏,其它的通信软件尽可能不要开。但当你确定了服务器的IP和端口后,就可以照常使用其它网络软件了。

  第二步,如前面述,在游戏中找个人少或没人的地方,开始“自言自语”,呵呵。说话的内容,建议以字母和数字为宜,不要说中文。因为中文是双字节的,而字母和数字是单字节的,对于单字节的信息内容,截包软件会以单字节的文本信息显示,但对于双字节的汉字而言,截包软件在对其进行显示时由于换行等原因会造成部分中文显示有乱码,不容易直接看出中文内容。如果执意要说中文,偶也不拦你,给你推荐一个工具:String Demander(下载地址:http://www.cnxhacker.com/Download/show/395.html),这个软件,可以查询中文所对应的编码。

  第三步,设定好commview的rules并使之生效,开始截包。

  观察通过以上的过程所截的包,可以发现,魔兽世界的聊天封包的说话内容是明文的!这一点,用不着大惊小怪,呵呵。聊天封包本身并不会对游戏的关键逻辑造成损害,所以,即使让其明文显示也不足为奇。但是,我们还是不太相信自己的眼睛,于是再截若干个包,发现包中的说话内容确实是明文的!但是,包的其它字段却是我们一时看不懂的“密文”。

  看来,下面的事情就是对这些包里的“密文”进行研究了。一般情况下,这种“密文”的加密方法,通过封包分析是分析不出来的,但,我们仍然可以通过封包分析来推论一些与“密文”生成算法有关的问题。我们可以作以下的对比分析:
  1、连续三次输入“a”,并分别观察及保存封包数据;
  2、连续三次输入“aa”,并分别观察及保存封包数据;
  3、连续三次输入“aaa”,并分别观察及保存封包数据。

  输入的封包用例,我们选择了字母"a",它的ASCII码是61。输入的规律是:每种情况连续输入三次,然后逐次增加a字母的个数。于是,我们发现这样一个有趣的现象:
  1、包中有关说话的内容是明文的;
  2、即使针对于同样的说话内容,比如“a”,客户端所发出去的包也是不一样的;
  3、当一次说话的字母个数增加1时,封包的总体长度也随之增加1;
  4、除每个封包的前面6个字节以及说话的字节外,其余的封包内容每次都一样;
  5、每个聊天封包的结尾字节都是0。

  于是,我们可以试着得出如下结论:
  1、包是没有压缩的,它所使用的加密算法应该是按字节进行的,并没有改变封包的长度使之看上去使用统一的长度;
  2、包是以0结尾的(尽管我们不知道它是以什么表示开头的,呵呵);
  3、封包加密算法中所使用的密钥是可变的,即针对于相同的数据包内容由于加密的密钥不同,所以产生的密文也不同。由于客户端的数据传到服务器端后,服务器端还要对数据进行解密。所以,客户端的加密算法与服务器端的解密算法应该共用了前6字节中的某些内容,以此作为解密算法的密钥。如果这6字节中没有包含有关封包加、解密所需要的同步数据,那客户端和服务器之间应该会通过其它的方式同步这样的数据。不过,偶倾向于前者,即:这6字节中应该含有加、解密所需要的密钥信息。

  回头看我们上面观察到的有趣现象,针对于第2点,反过来想,这应该也是最起码的功能了。就是说,即使客户端作出的是同样的动作,在客户端发出的包中,包的内容也是不一样的。这样,外挂就不能靠单纯的重复发相同的包而达到其目的了。

  分析来分析去,我们还是没能确定魔兽封包的大体结构。其实,到现在,我觉得我此文的目的已经达到了,即向大家展示封包分析的思维角度和思维方式。至于具体结果,偶觉得倒真的不重要的了。可以肯定地告诉大家的是,魔兽的封包结构偶大致已经掌握了。偶仅在此公布我的分析结果:
  1、魔兽的封包长度字段是每个封包的前两字节,它的表示方式是:前两字节的数值+2。之所以加这个2,是因为封包长度字段本身占用了两个字节的长度。
  2、魔兽的封包类型偶推断是第三和第四字节,其中普通聊天的类型标识是“95 00”。

  请不要来信向我询问任何有关魔兽封包破解的内容,偶能说的都已经在文章里说了,偶之所以写这个系列的文章不是想破解魔兽,而是想以这样优秀的一款游戏作为案例来向大家展示它在封包设计方面值得我们学习和讨论的地方,同时向更多的朋友普及有关封包分析的常识、工具以及思维方式,仅此而已。

  ps:由于每次封包分析的内容都很多,所以,一有了点结论后,要及时记录和总结,并与之前取得的总结进行对比,及时更新相关的记录文档。

本文作者:sodme
本文出处:http://blog.csdn.net/sodme
声明:本文可以不经作者同意任意转载,但任何对本文的引用都须注明作者、出处及此声明信息。谢谢!!

  特别声明:
  本人非常欣赏暴雪及他们的游戏,之所以写这个文章,是想让大家了解一些网络封包分析方面的常见方法以及学习暴雪游戏在网络处理方面的经验,偶认为作为一个网络编程者,熟练掌握封包分析的工具和方法应该是其基本功之一。本文所列的所有封包分析内容,全部是采用普通黑箱方式即可得来的,并未涉及对魔兽世界可执行程序的逆向工程。同时,除此文涉及的内容外,本人拒绝向任何人透露更详细的关于魔兽世界封包方面的更多内容,有兴趣者请自己进行相关的试验,本人在此文中也将尽量避免公开敏感的封包内容及相关加解密算法。谨以此文献给忠爱的暴雪!

  一、登录模块流程及封包分析

  我们先看登录流程。从封包流程来看,魔兽的登录流程是这样的:

  1.由Client向登录/账号服务器(Login Server)发送用户名及密码等信息。此数据包的最后部分是用户名(明文表示,未加密),在用户名的前一个字节表示的是用户名的长度。登录/账号服务器向Client返回登录成功及后续连接到游戏服务器服务器所必备的信息等。这中间的两个来往数据包,我还没有看出具体有什么作用。在这个交互过程中,由登录/账号服务器向Client发送所有的游戏服务器列表,服务器列表数据包的内容包括:ip, port, 服务器上所拥有的角色个数等信息,因服务器列表内容过多,被客户端分为两次接收完毕。

  2.Client收到Login Server的服务器列表后,根据最近访问的服务器标识(这个信息应该是包含在那个服务器列表数据包中),连接到最近游戏的那个游戏服务器(Game Server)。连接成功后,Game Server首先向Client发送一个8字节的数据包,据以往的常识判断,这个数据包的内容很可能是以后客户端与服务器通信的加密密钥。

  3.Client向Game Server再次发送自己的账号信息。Game Server与Client经过两个数据包的交互后,向Client发送角色数据包,此包中包括了玩家在该Game Server所创建的所有角色信息,当然这个信息只是部分的,并不是该角色的所有信息。

  4.在此后的通信过程中,Client每隔30秒向Game Server发送一个保持连接的包,该包长度为10字节,包的最后四字节是一个递增数字,前面6字节暂时未看出规律。

  5.只要Client没有点击某个角色进入最终的Game Server,则Client要始终与Login Server保持连接。当Client点击角色进入Game Server时,Client才与Login Server断开连接。在以后的游戏过程中,Client始终与且仅与该Game Server进行数据通信。

  通过对登录流程中的数据包初步分析,可以得出以下几个结论:
  1.Client向Login Server发的第一个数据包,用户名部分是采用明文的,且该数据包的内容,每次登录都一样,并没有因时间的不同而发生改变。由此可以推算:针对于此数据包中的密码加密算法是固定不变的,换句话说,密码的加密算法是比较容易通过逆向工程被找到的。偶认为,针对于此处,服务器也应该先向客户端发送一个加密密钥,以后的通信可以用该密钥作为安全验证的依据。但暴雪没有这样作,最大的可能是为了提高服务器的效率,在登录服务器上,如果每个客户端一旦连接成功,登录服务器都得向客户端广播一个数据包的话,可能这个量还是比较大的,这可能延长了玩家的登录等待时间,所以他们没有在这块作。

  2.Client在登录Login Server的地址,每次Login Server的登录地址都可能是不一样的。偶没有在客户端目录里找到这些地址,只在客户端目录里找到了四个大区的四个域名,我猜想,魔兽世界是用的DNS解析的简单方法来实现Login Server的简单动态均衡的。不知道这个猜想是否正确。

  3.“根据玩家最近在玩的哪个游戏,由客户端和服务器自动为玩家选择进入这个游戏服务器”,这一项设定充分体现了暴雪一贯的风格:为玩家着想,最大限度地提高游戏的舒适度。再次对暴雪的态度予以肯定!

  4.一旦玩家进入了游戏世界,客户端与服务器的通信端口会一直保持不变。即:魔兽世界的游戏世界服务器群设计结构采用的是带网关的服务器集群。

  5.偶觉得在整个的登录流程中,让我产生最大疑问的就是Login Server与Client的连接保持逻辑。当Client与Game Server连接了之后,Client并未与Login Server断开,是一直保持连接的。后来,经进一步的抓包分析,Client之所以要与Login Server保持这样的连接,是为了当Client重新选择服务器时,不至于重新连接Login Server。当Client点击了"选择服务器"按纽后,Login Server会每隔5秒向Client发一个当前所有的服务器列表数据包。要知道,这个服务器列表数据包的内容可是非常大的,如果有玩家就打开了这个窗口不关闭,Login Server向这种情况的所有玩家每5秒钟就发一个服务器列表数据包,这个广播量可是很大的哦(2k左右,这可是一个用户是2k哦)。偶认为这里的逻辑设计是相当不合理的。Login Server如果为了给客户端提供一个最新的全局服务器列表,可以保持连接,但也没必要每隔5秒就向客户端发一个服务器列表,最多只在客户端在某个服务器上创建了不同的角色后再更新这个列表也是可以的,但只用更新这个列表中的变化内容即可,不用发全部的完整包,这样,在通信量上就小了很多。据说,魔兽刚开始的时候,产生DOWN机的原因就是登录模块没有处理好,偶不知道现在的这个情况是不是已经经过改良的了。但偶还是认为每隔5秒就向客户端发送一个2K的包,这一点是不可以被接受的。

  以上只是针对于魔兽世界登录流程的简单分析,没有多少技术含量,拿出来跟大家相互讨论讨论,看看有没有可以借鉴的地方,后面还会有其它部分的封包分析。欢迎继续关注偶的Blog: http://blog.csdn.net/sodme

  偶在文章前面部分说过,作为一个网络编程人员,熟练使用截包软件和掌握基本的封包分析方法是其基本能力之一,发此文的目的一个原因也是希望向正在作网络编程的兄弟介绍一下相关工具的使用和常见的分析方法。下面补充一下关于封包分析的基本方法和相关工具:

  1.你需要一个截包工具,偶推荐:commview,小巧但功能强大,支持自定义的封包分析插件以DLL形式装载,也就是说只要你愿意,你可以写个DLL对某类特殊形式的包进行显示、记录、解密等特别处理。

  2.如何查看真正的封包数据。在commview里,会详细列出自网卡级别以上的各层封包数据,包括Ethernet层,IP层和TCP层。而我们作封包分析时,只需要关注TCP层。但TCP层里也有很多内容,对于我们的分析需求来说,我们需要关注的是其Data字段(在协议目录里可以看到"data length标识,点击即可查看data段")的内容。

  3.TCP的几个状态对于我们分析所起的作用。在TCP层,有个FLAGS字段,这个字段有以下几个标识:SYN, FIN, ACK, PSH, RST, URG.其中,对于我们日常的分析有用的就是前面的五个字段。它们的含义是:SYN表示建立连接,FIN表示关闭连接,ACK表示响应,PSH表示有DATA数据传输,RST表示连接重置。其中,ACK是可能与SYN,FIN等同时使用的,比如SYN和ACK可能同时为1,它表示的就是建立连接之后的响应,如果只是单个的一个SYN,它表示的只是建立连接。TCP的几次握手就是通过这样的ACK表现出来的。但SYN与FIN是不会同时为1的,因为前者表示的是建立连接,而后者表示的是断开连接。RST一般是在FIN之后才会出现为1的情况,表示的是连接重置。一般地,当出现FIN包或RST包时,我们便认为客户端与服务器端断开了连接;而当出现SYN和SYN+ACK包时,我们认为客户端与服务器建立了一个连接。PSH为1的情况,一般只出现在DATA内容不为0的包中,也就是说PSH为1表示的是有真正的TCP数据包内容被传递。TCP的连接建立和连接关闭,都是通过请求-响应的模式完成的。

  <未完待续>

本文作者:sodme
本文出处:http://blog.csdn.net/sodme
声明:本文可以不经作者同意任意转载、复制、传播,但任何对本文的引用均须保留本文的作者、出处及本行声明信息!谢谢!

  完成端口模型,针对于WIN平台的其它异步网络模型而言,最大的好处,除了性能方面的卓越外,还在于完成端口在传递网络事件的通知时,可以一并传递与此事件相关的应用层数据。这个应用层数据,体现在两个方面:一是单句柄数据,二是单IO数据。

  GetQueuedCompletionStatus函数的原型如下:
  WINBASEAPI
  BOOL
  WINAPI
  GetQueuedCompletionStatus(
      IN  HANDLE CompletionPort,
      OUT LPDWORD lpNumberOfBytesTransferred,
      OUT PULONG_PTR lpCompletionKey,
      OUT LPOVERLAPPED *lpOverlapped,
      IN  DWORD dwMilliseconds
     );
  其中,我们把第三个参数lpCompletionKey称为完成键,由它传递的数据称为单句柄数据。我们把第四个参数lpOverlapped称为重叠结构体,由它传递的数据称为单IO数据。

  以字面的意思来理解,lpCompletionKey内包容的东西应该是与各个socket一一对应的,而lpOverlapped是与每一次的wsarecv或wsasend操作一一对应的。

  在网络模型的常见设计中,当一个客户端连接到服务器后,服务器会通过accept或AcceptEx创建一个socket,而应用层为了保存与此socket相关的其它信息(比如:该socket所对应的sockaddr_in结构体数据,该结构体内含客户端IP等信息,以及为便于客户端的逻辑包整理而准备的数据整理缓冲区等),往往需要创建一个与该socket一一对应的客户端底层通信对象,这个对象可以负责保存仅在网络层需要处理的数据成员和方法,然后我们需要将此客户端底层通信对象放入一个类似于list或map的容器中,待到需要使用的时候,使用容器的查找算法根据socket值找到它所对应的对象然后进行我们所需要的操作。

  让人非常高兴的是,完成端口“体贴入微”,它已经帮我们在每次的完成事件通知时,稍带着把该socket所对应的底层通信对象的指针送给了我们,这个指针就是lpCompletionKey。也就是说,当我们从GetQueuedCompletionStatus函数取得一个数据接收完成的通知,需要将此次收到的数据放到该socket所对应的通信对象整理缓冲区内对数据进行整理时,我们已经不需要去执行list或map等的查找算法,而是可以直接定位这个对象了,当客户端连接量很大时,频繁查表还是很影响效率的。哇哦,太帅了,不是吗?呵呵。

  基于以上的认识,我们的lpCompletionKey对象可以设计如下:
  typedef struct PER_HANDLE_DATA
  {
    SOCKET socket;             //本结构体对应的socket值
    sockaddr_in addr;          //用于存放客户端IP等信息
    char DataBuf[ 2*MAX_BUFFER_SIZE ];  //整理缓冲区,用于存放每次整理时的数据
  }

  PER_HANDLE_DATA与socket的绑定,通过CreateIOCompletionPort完成,将该结构体地址作为该函数的第三个参数传入即可。而PER_HANDLE_DATA结构体中addr成员,是在accept执行成功后进行赋值的。DataBuf则可以在每次WSARecv操作完成,需要整理缓冲区数据时使用。

  下面我们再来看看完成端口的收、发操作中所使用到的重叠结构体OVERLAPPED。

  关于重叠IO的知识,请自行GOOGLE相关资料。简单地说,OVERLAPPED是应用层与核心层交互共享的数据单元,如果要执行一个重叠IO操作,必须带有OVERLAPPED结构。在完成端口中,它允许应用层对OVERLAPPED结构进行扩展和自定义,允许应用层根据自己的需要在OVERLAPPED的基础上形成新的扩展OVERLAPPED结构。一般地,扩展的OVERLAPPED结构中,要求放在第一个的数据成员是原OVERLAPPED结构。我们可以形如以下方式定义自己的扩展OVERLAPPED结构:
  typedef struct PER_IO_DATA
  {
    OVERLAPPED ovl;
    WSABUF           buf;
    char                    RecvDataBuf[ MAX_BUFFER_SIZE ];   //接收缓冲区
    char                    SendDataBuf[ MAX_BUFFER_SIZE ];   //发送缓冲区
    OpType              opType;                                                       //操作类型:发送、接收或关闭等
  }
  
  在执行WSASend和WSARecv操作时,应用层会将扩展OVERLAPPED结构的地址传给核心,核心完成相应的操作后,仍然通过原有的这个结构传递操作结果,比如“接收”操作完成后,RecvDataBuf里存放便是此次接收下来的数据。

  根据各自应用的不同,不同的完成端口设计者可能会设计出不同的PER_HANDLE_DATA
和PER_IO_DATA,我这里给出的设计也只是针对自己的应用场合的,不一定就适合你。但我想,最主要的还是要搞明白PER_HANDLE_DATA和PER_IO_DATA两种结构体的含义、用途,以及调用流程。

本文作者:sodme
本文出处:http://blog.csdn.net/sodme
声明:本文可以不经作者同意任意转载、复制、传播,但任何对本文的引用都请保留作者、出处及本声明信息。谢谢!

  常见的网络服务器,基本上是7*24小时运转的,对于网游来说,至少要求服务器要能连续工作一周以上的时间并保证不出现服务器崩溃这样的灾难性事件。事实上,要求一个服务器在连续的满负荷运转下不出任何异常,要求它设计的近乎完美,这几乎是不太现实的。服务器本身可以出异常(但要尽可能少得出),但是,服务器本身应该被设计得足以健壮,“小病小灾”打不垮它,这就要求服务器在异常处理方面要下很多功夫。

  服务器的异常处理包括的内容非常广泛,本文仅就在网络封包方面出现的异常作一讨论,希望能对正从事相关工作的朋友有所帮助。

  关于网络封包方面的异常,总体来说,可以分为两大类:一是封包格式出现异常;二是封包内容(即封包数据)出现异常。在封包格式的异常处理方面,我们在最底端的网络数据包接收模块便可以加以处理。而对于封包数据内容出现的异常,只有依靠游戏本身的逻辑去加以判定和检验。游戏逻辑方面的异常处理,是随每个游戏的不同而不同的,所以,本文随后的内容将重点阐述在网络数据包接收模块中的异常处理。

  为方便以下的讨论,先明确两个概念(这两个概念是为了叙述方面,笔者自行取的,并无标准可言):
  1、逻辑包:指的是在应用层提交的数据包,一个完整的逻辑包可以表示一个确切的逻辑意义。比如登录包,它里面就可以含有用户名字段和密码字段。尽管它看上去也是一段缓冲区数据,但这个缓冲区里的各个区间是代表一定的逻辑意义的。
  2、物理包:指的是使用recv(recvfrom)或wsarecv(wsarecvfrom)从网络底层接收到的数据包,这样收到的一个数据包,能不能表示一个完整的逻辑意义,要取决于它是通过UDP类的“数据报协议”发的包还是通过TCP类的“流协议”发的包。

  我们知道,TCP是流协议,“流协议”与“数据报协议”的不同点在于:“数据报协议”中的一个网络包本身就是一个完整的逻辑包,也就是说,在应用层使用sendto发送了一个逻辑包之后,在接收端通过recvfrom接收到的就是刚才使用sendto发送的那个逻辑包,这个包不会被分开发送,也不会与其它的包放在一起发送。但对于TCP而言,TCP会根据网络状况和neagle算法,或者将一个逻辑包单独发送,或者将一个逻辑包分成若干次发送,或者会将若干个逻辑包合在一起发送出去。正因为TCP在逻辑包处理方面的这种粘合性,要求我们在作基于TCP的应用时,一般都要编写相应的拼包、解包代码。

  因此,基于TCP的上层应用,一般都要定义自己的包格式。TCP的封包定义中,除了具体的数据内容所代表的逻辑意义之外,第一步就是要确定以何种方式表示当前包的开始和结束。通常情况下,表示一个TCP逻辑包的开始和结束有两种方式:
  1、以特殊的开始和结束标志表示,比如FF00表示开始,00FF表示结束。
  2、直接以包长度来表示。比如可以用第一个字节表示包总长度,如果觉得这样的话包比较小,也可以用两个字节表示包长度。

  下面将要给出的代码是以第2种方式定义的数据包,包长度以每个封包的前两个字节表示。我将结合着代码给出相关的解释和说明。

  函数中用到的变量说明:

  CLIENT_BUFFER_SIZE:缓冲区的长度,定义为:Const int CLIENT_BUFFER_SIZE=4096。
  m_ClientDataBuf:数据整理缓冲区,每次收到的数据,都会先被复制到这个缓冲区的末尾,然后由下面的整理函数对这个缓冲区进行整理。它的定义是:char m_ClientDataBuf[2* CLIENT_BUFFER_SIZE]。
  m_DataBufByteCount:数据整理缓冲区中当前剩余的未整理字节数。
  GetPacketLen(const char*):函数,可以根据传入的缓冲区首址按照应用层协议取出当前逻辑包的长度。
  GetGamePacket(const char*, int):函数,可以根据传入的缓冲区生成相应的游戏逻辑数据包。
  AddToExeList(PBaseGamePacket):函数,将指定的游戏逻辑数据包加入待处理的游戏逻辑数据包队列中,等待逻辑处理线程对其进行处理。
  DATA_POS:指的是除了包长度、包类型等这些标志型字段之外,真正的数据包内容的起始位置。

Bool SplitFun(const char* pData,const int &len)
{
    PBaseGamePacket pGamePacket=NULL;
    __int64 startPos=0, prePos=0, i=0;
    int packetLen=0;

  //先将本次收到的数据复制到整理缓冲区尾部
    startPos = m_DataBufByteCount;  
    memcpy( m_ClientDataBuf+startPos, pData, len );
    m_DataBufByteCount += len;   

    //当整理缓冲区内的字节数少于DATA_POS字节时,取不到长度信息则退出
 //注意:退出时并不置m_DataBufByteCount为0
    if (m_DataBufByteCount < DATA_POS+1)
        return false; 

    //根据正常逻辑,下面的情况不可能出现,为稳妥起见,还是加上
    if (m_DataBufByteCount >  2*CLIENT_BUFFER_SIZE)
    {
        //设置m_DataBufByteCount为0,意味着丢弃缓冲区中的现有数据
        m_DataBufByteCount = 0;

  //可以考虑开放错误格式数据包的处理接口,处理逻辑交给上层
  //OnPacketError()
        return false;
    }

     //还原起始指针
     startPos = 0;

     //只有当m_ClientDataBuf中的字节个数大于最小包长度时才能执行此语句
    packetLen = GetPacketLen( pIOCPClient->m_ClientDataBuf );

    //当逻辑层的包长度不合法时,则直接丢弃该包
    if ((packetLen < DATA_POS+1) || (packetLen > 2*CLIENT_BUFFER_SIZE))
    {
        m_DataBufByteCount = 0;

  //OnPacketError()
        return false;
    }

    //保留整理缓冲区的末尾指针
    __int64 oldlen = m_DataBufByteCount; 

    while ((packetLen <= m_DataBufByteCount) && (m_DataBufByteCount>0))
    {
        //调用拼包逻辑,获取该缓冲区数据对应的数据包
        pGamePacket = GetGamePacket(m_ClientDataBuf+startPos, packetLen); 

        if (pGamePacket!=NULL)
        {
            //将数据包加入执行队列
            AddToExeList(pGamePacket);
        }

        pGamePacket = NULL;
 
  //整理缓冲区的剩余字节数和新逻辑包的起始位置进行调整
        m_DataBufByteCount -= packetLen;
        startPos += packetLen; 

        //残留缓冲区的字节数少于一个正常包大小时,只向前复制该包随后退出
        if (m_DataBufByteCount < DATA_POS+1)
        {
            for(i=startPos; i<startPos+m_DataBufByteCount; ++i)
                m_ClientDataBuf[i-startPos] = m_ClientDataBuf[i];

            return true;
        }

        packetLen = GetPacketLen(m_ClientDataBuf + startPos );

         //当逻辑层的包长度不合法时,丢弃该包及缓冲区以后的包
        if ((packetLen<DATA_POS+1) || (packetLen>2*CLIENT_BUFFER_SIZE))
        {
            m_DataBufByteCount = 0;

      //OnPacketError()
            return false;
        }

         if (startPos+packetLen>=oldlen)
        {
            for(i=startPos; i<startPos+m_DataBufByteCount; ++i)
                m_ClientDataBuf[i-startPos] = m_ClientDataBuf[i];          

            return true;
        }
     }//取所有完整的包

     return true;
}

  以上便是数据接收模块的处理函数,下面是几点简要说明:

  1、用于拼包整理的缓冲区(m_ClientDataBuf)应该比recv中指定的接收缓冲区(pData)长度(CLIENT_BUFFER_SIZE)要大,通常前者是后者的2倍(2*CLIENT_BUFFER_SIZE)或更大。

  2、为避免因为剩余数据前移而导致的额外开销,建议m_ClientDataBuf使用环形缓冲区实现。

  3、为了避免出现无法拼装的包,我们约定每次发送的逻辑包,其单个逻辑包最大长度不可以超过CLIENT_BUFFER_SIZE的2倍。因为我们的整理缓冲区只有2*CLIENT_BUFFER_SIZE这么长,更长的数据,我们将无法整理。这就要求在协议的设计上以及最终的发送函数的处理上要加上这样的异常处理机制。


  4、对于数据包过短或过长的包,我们通常的情况是置m_DataBufByteCount为0,即舍弃当前包的处理。如果此处不设置m_DataBufByteCount为0也可,但该客户端只要发了一次格式错误的包,则其后继发过来的包则也将连带着产生格式错误,如果设置m_DataBufByteCount为0,则可以比较好的避免后继的包受此包的格式错误影响。更好的作法是,在此处开放一个封包格式异常的处理接口(OnPacketError),由上层逻辑决定对这种异常如何处置。比如上层逻辑可以对封包格式方面出现的异常进行计数,如果错误的次数超过一定的值,则可以断开该客户端的连接。

  5、建议不要在recv或wsarecv的函数后,就紧接着作以上的处理。当recv收到一段数据后,生成一个结构体或对象(它主要含有data和len两个内容,前者是数据缓冲区,后者是数据长度),将这样的一个结构体或对象放到一个队列中由后面的线程对其使用SplitFun函数进行整理。这样,可以最大限度地提高网络数据的接收速度,不至因为数据整理的原因而在此处浪费时间。

  代码中,我已经作了比较详细的注释,可以作为拼包函数的参考,代码是从偶的应用中提取、修改而来,本身只为演示之用,所以未作调试,应用时需要你自己去完善。如有疑问,可以我的blog上留言提出。

本文作者:sodme
本文出处:http://blog.csdn.net/sodme
声明:本文可以不经作者同意任意转载,但任何对本文的引用都须注明作者、出处及此声明信息。谢谢!!

  在网络应用中,“负载均衡”已经不能算是什么新鲜话题了,从硬件到软件,也都有了很多的方法来实现负载均衡。我们这里讨论的负载均衡,并不是指依靠DNS转向或其它硬件设备等所作的负载均衡,而是指在应用层所作的负载均衡。

  一般而言,只有在大型在线系统当中才有必要引入负载均衡,那么,多大的系统才能被称为大型系统呢?比如动辄同时在线数十万的网络游戏,比如同时在线数在10万以上的WEB应用,这些我们都可以理解为大型系统,这本身就是一个宽泛的概念。

  设计再好的服务器程序,其单个程序所能承载的同时访问量也是有限的,面对一个庞大且日益增长的网络用户群,如何让我们的架构能适应未来海量用户访问,这自然就牵涉到了负载均衡问题。支持百万级以上的大型在线系统,它的架构核心就是如何将“百万”这么大的一个同时在线量分摊到每个单独的服务器程序上去。真正的逻辑处理应该是在这最终的底层的服务器程序(如QQ游戏平台的游戏房间服务器)上的,而在此之前所存在的那些服务器,都可以被称为“引路者”,它们的作用就是将客户端一步步引导到这最终的负责真正逻辑的底层服务器上去,我们计算“百万级在线”所需要的服务器数量,也是首先考虑这底层的逻辑服务器单个可承载的客户端连接量。

  比如:按上篇我们所分析QQ游戏架构而言,假设每个服务器程序最高支持2W的用户在线(假设一台机子只运行一个服务器程序),那么实现150万的在线量至少需要多少台服务器呢?如果算得简单一点的话,就应该是:150/2=75台。当然,这样算起来,可能并不能代表真正的服务器数量,因为除了这底层的服务器外,还要包括登录/账号服务器以及大厅服务器。但是,由于登录/账号服务器和大厅服务器,它们与客户端的连接都属于短连接(即:取得所需要信息后,客户端与服务器即断开连接),所以,客户端给这两类服务器带来的压力相比于长连接(即:客户端与服务器始终保持连接)而言就要轻得多,它们的压力主要在处理瞬间的并发访问上。

  “短连接”,是实现应用层负载均衡的基本手段!!!如果客户端要始终与登录/账号服务器以及大厅服务器保持连接,那么这样作的分层架构将是无意义的,这也没有办法从根本上解决用户量不断增长与服务器数量有限之间的矛盾。

  当然,短连接之所以可以被使用并能维护正常的游戏逻辑,是因为在玩家看不到的地方,服务器与服务器之间进行了大量的数据同步操作。如果一个玩家没有登录到登录服务器上去而是直接连接进了游戏房间服务器并试图进行游戏,那么,由于游戏房间服务器与大厅服务器和登录/账号服务器之间都会有针对于玩家登录的逻辑维护,游戏房间服务器会检测出来该玩家之前并没有到登录服务器进行必要的账号验证工作,它便会将玩家踢下线。由此看来,各服务器之间的数据同步,又是实现负载均衡的又一必要条件了。

  服务器之间的数据同步问题,依据应用的不同,也会呈现不同的实现方案。比如,我们在处理玩家登录这个问题上。我们首先可以向玩家开放一些默认的登录服务器(服务器的IP及PORT信息),当玩家连接到当前的登录服务器后,由该服务器首先判断自己同时连接的玩家是不是超过了自定义的上限,如果是,由向与该服务器连接着的“登录服务器管理者”(一般是一个内部的服务器,不直接向玩家开放)申请仲裁,由“登录服务器管理者”根据当前各登录服务器的负载情况选择一个新的服务器IP和PORT信息传给客户端,客户端收到这个IP和PORT信息之后重定向连接到这个新的登录服务器上去,完成后续的登录验证过程。

  这种方案的一个特点是,在面向玩家的一侧,会提供一个外部访问接口,而在服务器集群的内部,会提供一个“服务器管理者”及时记录各登录服务器的负载情况以便客户端需要重定向时根据策略选择一个新的登录接口给客户端。

  采用分布式结构的好处是可以有效分摊整个系统的压力,但是,不足点就是对于全局信息的索引将会变得比较困难,因为每个单独的底层逻辑服务器上都只是存放了自己这一个服务器上的用户数据,它没有办法查找到其它服务器上的用户数据。解决这个问题,简单一点的作法,就是在集群内部,由一个中介者,提供一个全局的玩家列表。这个全局列表,根据需要,可以直接放在“服务器管理者”上,也可以存放在数据库中。

  对于逻辑相对独立的应用,全局列表的使用机会其实并不多,最主要的作用就是用来检测玩家是不是重复登录了。但如果有其它的某些应用,要使用这样的全局列表,就会使数据同步显得比较复杂。比如,我们在超大无缝地图的MMORPG里,如果允许跨服操作(如跨服战斗、跨服交易等)的话,这时的数据同步将会变得异常复杂,也容易使处理逻辑出现不可预测性。

  我认为,对于休闲平台而言,QQ游戏的架构已经是比较合理的,也可以称之为休闲平台的标准架构了。那么,MMORPG一般的架构是什么样的呢?

  MMORPG一般是把整个游戏分成若干个游戏世界组,每个组内其实就是一个单独的游戏世界。而不同的组之间,其数据皆是相互独立的,并不象QQ休闲平台一样所有的用户都会有一个集中的数据存放点,MMORPG的游戏数据是按服务器组的不同而各自存放的。玩家在登录QQ游戏时,QQ游戏相关的服务器会自动为玩家的登录进行负载均衡,选择相对不忙的服务器为其执行用户验证并最终让用户选择进入哪一个游戏房间。但是,玩家在登录MMORPG时,却没有这样的自动负载均衡,一般是由玩家人为地去选择要进入哪一个服务器组,之所以这样,是因为各服务器组之间的数据是不相通的。其实,细致想来,MMORPG的服务器架构思想与休闲平台的架构思想有异曲同工之妙,MMORPG的思想是:可以为玩家无限地开独立的游戏世界(即服务器组),以满足大型玩家在线;而休闲平台的思想则是:可以为玩家无限地开游戏房间以满足大量玩家在线。这两种应用,可以无限开的都是“具有完整游戏性的游戏世界”,对于MMORPG而言,它的一个完整的游戏地图就是一个整体的“游戏世界”,而对于休闲平台,它的一个游戏房间就可以描述为一个“游戏世界”。如果MMORPG作成了休闲平台那样的全服皆通,也不是不可以,但随之而来的,就是要解决众多跨服问题,比如:好友、组队、帮派等等的问题,所有在传统MMORPG里所定义的这些玩家组织形式的规则可能都会因为“全服皆通”而改变。

  架构的选择是多样性的,确实没有一种可以称得上是最好的所谓的架构,适合于当前项目的,不一定就适合于另一个项目。针对于特定的应用,会灵活选用不同的架构。但有一点,是可以说的:不管你如何架构,你所要作的就是--要以尽可能简单的方案实现尽可能的稳定、高效!

  <全文完>

本文作者:sodme
本文出处:http://blog.csdn.net/sodme
声明:本文可以不经作者同意任意转载,但任何对本文的引用都须注明作者、出处及此声明信息。谢谢!!

  要了解此篇文章中引用的本人写的另一篇文章,请到以下地址:
  http://blog.csdn.net/sodme/archive/2004/12/12/213995.aspx
  以上的这篇文章是早在去年的时候写的了,当时正在作休闲平台,一直在想着如何实现一个可扩充的支持百万人在线的游戏平台,后来思路有了,就写了那篇总结。文章的意思,重点在于阐述一个百万级在线的系统是如何实施的,倒没真正认真地考察过QQ游戏到底是不是那样实现的。

  近日在与业内人士讨论时,提到QQ游戏的实现方式并不是我原来所想的那样,于是,今天又认真抓了一下QQ游戏的包,结果确如这位兄弟所言,QQ游戏的架构与我当初所设想的那个架构相差确实不小。下面,我重新给出QQ百万级在线的技术实现方案,并以此展开,谈谈大型在线系统中的负载均衡机制的设计。

  从QQ游戏的登录及游戏过程来看,QQ游戏中,也至少分为三类服务器。它们是:
  第一层:登陆/账号服务器(Login Server),负责验证用户身份、向客户端传送初始信息,从QQ聊天软件的封包常识来看,这些初始信息可能包括“会话密钥”此类的信息,以后客户端与后续服务器的通信就使用此会话密钥进行身份验证和信息加密;
  第二层:大厅服务器(估且这么叫吧, Game Hall Server),负责向客户端传递当前游戏中的所有房间信息,这些房间信息包括:各房间的连接IP,PORT,各房间的当前在线人数,房间名称等等。
  第三层:游戏逻辑服务器(Game Logic Server),负责处理房间逻辑及房间内的桌子逻辑。

  从静态的表述来看,以上的三层结构似乎与我以前写的那篇文章相比并没有太大的区别,事实上,重点是它的工作流程,QQ游戏的通信流程与我以前的设想可谓大相径庭,其设计思想和技术水平确实非常优秀。具体来说,QQ游戏的通信过程是这样的:

  1.由Client向Login Server发送账号及密码等登录消息,Login Server根据校验结果返回相应信息。可以设想的是,如果Login Server通过了Client的验证,那么它会通知其它Game Hall Server或将通过验证的消息以及会话密钥放在Game Hall Server也可以取到的地方。总之,Login Server与Game Hall Server之间是可以共享这个校验成功消息的。一旦Client收到了Login Server返回成功校验的消息后,Login Server会主动断开与Client的连接,以腾出socket资源。Login Server的IP信息,是存放在QQGame\config\QQSvrInfo.ini里的。

  2.Client收到Login Server的校验成功等消息后,开始根据事先选定的游戏大厅入口登录游戏大厅,各个游戏大厅Game Hall Server的IP及Port信息,是存放在QQGame\Dirconfig.ini里的。Game Hall Server收到客户端Client的登录消息后,会根据一定的策略决定是否接受Client的登录,如果当前的Game Hall Server已经到了上限或暂时不能处理当前玩家登录消息,则由Game Hall Server发消息给Client,以让Client重定向到另外的Game Hall Server登录。重定向的IP及端口信息,本地没有保存,是通过数据包或一定的算法得到的。如果当前的Game Hall Server接受了该玩家的登录消息后,会向该Client发送房间目录信息,这些信息的内容我上面已经提到。目录等消息发送完毕后,Game Hall Server即断开与Client的连接,以腾出socket资源。在此后的时间里,Client每隔30分钟会重新连接Game Hall Server并向其索要最新的房间目录信息及在线人数信息。

  3.Client根据列出的房间列表,选择某个房间进入游戏。根据我的抓包结果分析,QQ游戏,并不是给每一个游戏房间都分配了一个单独的端口进行处理。在QQ游戏里,有很多房间是共用的同一个IP和同一个端口。比如,在斗地主一区,前50个房间,用的都是同一个IP和Port信息。这意味着,这些房间,在QQ游戏的服务器上,事实上,可能是同一个程序在处理!!!QQ游戏房间的人数上限是400人,不难推算,QQ游戏单个服务器程序的用户承载量是2万,即QQ的一个游戏逻辑服务器程序最多可同时与2万个玩家保持TCP连接并保证游戏效率和品质,更重要的是,这样可以为腾讯省多少money呀!!!哇哦!QQ确实很牛。以2万的在线数还能保持这么好的游戏品质,确实不容易!QQ游戏的单个服务器程序,管理的不再只是逻辑意义上的单个房间,而可能是许多逻辑意义上的房间。其实,对于服务器而言,它就是一个大区服务器或大区服务器的一部分,我们可以把它理解为一个庞大的游戏地图,它实现的也是分块处理。而对于每一张桌子上的打牌逻辑,则是有一个统一的处理流程,50个房间的50*100张桌子全由这一个服务器程序进行处理(我不知道QQ游戏的具体打牌逻辑是如何设计的,我想很有可能也是分区域的,分块的)。当然,以上这些只是服务器作的事,针对于客户端而言,客户端只是在表现上,将一个个房间单独罗列了出来,这样作,是为便于玩家进行游戏以及减少服务器的开销,把这个大区中的每400人放在一个集合内进行处理(比如聊天信息,“向400人广播”和“向2万人广播”,这是完全不同的两个概念)。

  4.需要特别说明的一点。进入QQ游戏房间后,直到点击某个位置坐下打开另一个程序界面,客户端的程序,没有再创建新的socket,而仍然使用原来大厅房间客户端跟游戏逻辑服务器交互用的socket。也就是说,这是两个进程共用的同一个socket!不要小看这一点。如果你在创建桌子客户端程序后又新建了一个新的socket与游戏逻辑服务器进行通信,那么由此带来的玩家进入、退出、逃跑等消息会带来非常麻烦的数据同步问题,俺在刚开始的时候就深受其害。而一旦共用了同一个socket后,你如果退出桌子,服务器不涉及释放socket的问题,所以,这里就少了很多的数据同步问题。关于多个进程如何共享同一个socket的问题,请去google以下内容:WSADuplicateSocket。

  以上便是我根据最新的QQ游戏抓包结果分析得到的QQ游戏的通信流程,当然,这个流程更多的是客户端如何与服务器之间交互的,却没有涉及到服务器彼此之间是如何通信和作数据同步的。关于服务器之间的通信流程,我们只能基于自己的经验和猜想,得出以下想法:

  1.Login Server与Game Hall Server之前的通信问题。Login Server是负责用户验证的,一旦验证通过之后,它要设法让Game Hall Server知道这个消息。它们之前实现信息交流的途径,我想可能有这样几条:a. Login Server将通过验证的用户存放到临时数据库中;b. Login Server将验证通过的用户存放在内存中,当然,这个信息,应该是全局可访问的,就是说所有QQ的Game Hall Server都可以通过服务器之间的数据包通信去获得这样的信息。

  2.Game Hall Server的最新房间目录信息的取得。这个信息,是全局的,也就是整个游戏中,只保留一个目录。它的信息来源,可以由底层的房间服务器逐级报上来,报给谁?我认为就如保存的全局登录列表一样,它报给保存全局登录列表的那个服务器或数据库。

  3.在QQ游戏中,同一类型的游戏,无法打开两上以上的游戏房间。这个信息的判定,可以根据全局信息来判定。

  以上关于服务器之间如何通信的内容,均属于个人猜想,QQ到底怎么作的,恐怕只有等大家中的某一位进了腾讯之后才知道了。呵呵。不过,有一点是可以肯定的,在整个服务器架构中,应该有一个地方是专门保存了全局的登录玩家列表,只有这样才能保证玩家不会重复登录以及进入多个相同类型的房间。

  在前面的描述中,我曾经提到过一个问题:当登录当前Game Hall Server不成功时,QQ游戏服务器会选择让客户端重定向到另位的服务器去登录,事实上,QQ聊天服务器和MSN服务器的登录也是类似的,它也存在登录重定向问题。

  那么,这就引出了另外的问题,由谁来作这个策略选择?以及由谁来提供这样的选择资源?这样的处理,便是负责负载均衡的服务器的处理范围了。由QQ游戏的通信过程分析派生出来的针对负责均衡及百万级在线系统的更进一步讨论,将在下篇文章中继续。

  在此,特别感谢网友tilly及某位不便透露姓名的网友的讨论,是你们让我决定认真再抓一次包探个究竟。

  <未完待续>

本文作者:sodme
本文出处:http://blog.csdn.net/sodme
声明:本文可以不经作者同意任意转载,但请保留文章开始前的作者、出处及声明信息。谢谢。

  由于个人工作的关系,接触高性能服务器的研发已经有一段时间了,在没有接触这个话题之前,我也和许多人一样,认为服务器的设计无非就是用一下winsock,调用调用函数那么简单。当亲自完成了一个在win平台上能承载上万连接的测试模型后,才知道,原来,作高性能服务器是这么有挑战性。你不仅需要在细支末节上对模型进行精雕细琢,更需要在总体架构方面进行权衡选择。这两方面,都会影响到你的服务器性能的正常发挥。作为对“细枝末节”方面的介绍,请参照我之前写的系列文章“完成端口之性能优化”。而从此篇文章开始的系列文章,将就一个完整的高性能服务器模型进行介绍,而对于服务器集群架构方面,则不在此系列的讨论范围,那将是未来数周我将要完成的事。有朋友跟我说,希望我能提供底层模型的完整代码或可供使用的动态链接库及LIB文件。对于这个要求,我现在还在考虑之中。确实,有了代码,要学得更快一点,但由于模型里牵涉到一定的版权问题,所以,我会考虑将其进行必要的修改,而后再考虑是否向大家提供源代码。不过,可以肯定的是,对于LIB及DLL的要求,我想我会尽快提交上来的。

  所谓的“高性能”,我想不外乎两个方面:
  1、处理的并发请求要尽可能地多,具体表现为同一时间内同时连接的客户端数量;
  2、数据包的吞吐量要尽可能地大,具体表现为单位时间内服务器的收、发数据量。

  win平台下,IOCP(完成端口)是处理大量并发连接的最佳处理方案,所以,此后讨论的文章,也是基于这个模型的。有关一个独立的IOCP模型到底是如何工作的,请大家下载微软的SDK,在那个例子里,有基本的IOCP示例。但那仅仅是个示例,于实际的应用中,还需要作很多工作。阅读以下的内容时,最好具备以下条件:知道IOCP的基本概念,以及它所调用的几个必备函数(Create、Get、Post函数等)的使用。注:为嫌麻烦,这几个函数,我采用的都是简单叫法,完整的函数名请查看完成端口相关资料。

  为了使大家能有一个宏观概念的把握,我先介绍一下基于三层结构的服务器通信底层模型。对于软件架构而言,没有最好之说,放在不同的应用环境其表现都可能千差万别,所以,我不保证这个架构是能让所有人都看着舒服的,我只保证,在我当前的项目应用中,这个架构充分考虑了“性能”和“可扩展性”两者的兼顾,让我在很容易地开发新的服务器时,仍然可以享受到很好的性能。

  一、三层架构图及简单说明

  三层架构图如下:
         CIOCPServer
         ||
         ||
      CCutomHPServer
         ||
         ||
       CTestServer

  以后我们要讨论的就是这个看上去并不复杂的三层架构图,下面就此架构图中的主要类进行简要说明。

  CIOCPServer:
  完成端口服务器基本通信类,它使用winnt/2000/xp平台特有完成端口特性,对通信模型进行封装,向它的派生类提供以下基本扩展接口(可被重载的虚函数):

  1、有客户端连接时的处理接口;
  2、客户端断开时的处理接口;
  3、从客户端收完数据后的处理接口;
  4、向客户端发送完数据后的处理接口;
  5、网络通信及服务器处理出现错误时的处理接口。

  CCustomHPServer:
  典型的高性能服务器类,CIOCPServer是其基类之一(之一?难道还有另外的基类,回答是:当然,呵呵,别急,后面会介绍),此类在CIOCPServer的基础上,封装了三个数据队列及三类处理线程,介绍如下:

  1、接收数据包队列及接收线程:用于存放刚收到的数据包,此数据包还没有进行逻辑意义上的拆解,接收线程从此队列中取出数据包,并将其形成一个逻辑意义上完整的数据包加入到“处理数据包队列”中;

  2、处理数据包队列及逻辑处理线程:已经拆解成了逻辑意义上的数据包,逻辑处理线程对此类数据包进行逻辑解析,这里就是服务器的主要逻辑部分,有的数据包在处理完成后,可能是需要向客户端返回处理结果的,此时就需要逻辑线程在处理完成后将返回结果的数据包放入“发送数据包队列”中;

  3、发送数据包队列及发送线程:待发送的数据包队列,由发送线程根据数据包里的客户端套接字发送给特定客户端。

  CTestServer:
  此类是一个测试类,主要用于演示如何在CCustomHPServer的基础上派生一个真正的应用服务器,并用于说明它需要重载实现CCustomHPServer的哪些重要虚函数。

  基于以上的结构,我们的服务器通信模型,可以一层一层地实现,一层一层的测试。在CIOCPServer中,它本身是不带有任何数据队列的,所有的网络数据都是即来即处理,没有保存数据,实现的是即时响应。在CIOCPServer里,有两类重要线程:AcceptThread线程和WorkerThread线程。其中,AccetpThread线程使用Accept或AcceptEx函数来接收客户端的连接请求,并实现客户端socket与完成端口句柄的绑定,“有客户端连接时的处理接口”就是在这里封装的;而WorkerThread线程是我们在完成端口中常说的“工作者线程”,它由get函数触发工作,除“有客户端连接时的处理接口”之外的其它接口,都在这里进行封装。

  在真正实现一个高性能服务器模型时,我们可能需要逐层地加以实现,这样作,一是因为测试起来要简单一些,二是因为在我们逐层实现时可以清楚地知道每一层在实现时的效率是什么样的,这样就有利于我们找出提高效率的突破口。可以先从CIOCPServer类开始,实现一个简单的ECHO服务器,即:回显服务器。不用维护数据包队列,对客户端发过来的数据,即时返回给客户端。作完这一层,属于完成端口该作的事基本上就作完了,它包括:有大量客户端连接时的客户端连接队列维护,客户端连接、断开、发送、接收数据时的事件处理及线程同步。根据我的经验,在处理底层的客户端断开事件时是一个难点,新手往往会在接收到断开事件时直接释放掉当前客户端对象,但比较好的作法是使用引用计数机制,而不是直接释放。另外,在“释放”这一点上,我也有自己的一个看法,即:客户端对象最好不要释放,而把它放入闲置队列或者关闭原来的socket之后,再重新生成一个新的socket让它与原客户端对象关联,把它作为一个新的客户端对象使用,这样就避免了频繁的客户端对象的建立与释放,当然,这样作的前提是在接受客户端连接方面最好使用AcceptEx函数而不是Accept。

  这篇文章里,仅就模型的总体结构进行了介绍,关于这三个类的具体实现及片段代码,会在下篇文章里介绍,请继续关注,也请有兴趣的朋友能在我的Blog里反馈你们的意见。

  <未完待续>

本文作者:sodme
本文出处:http://blog.csdn.net/sodme
声明:本文可不经作者同意,任意被转载、引用、复制,但任何对本文的引用都必须注明本文作者,出处以及本行声明信息。谢谢。

  作为WIN平台下同时管理数千个连接的最为高效的网络模型,完成端口已经被越来越多的人认识和熟悉。通常情况下,一种经典的完成端口使用模式是:
  (1)创建完成端口,并在指定端口开始监听;
  (2)创建接受连接线程,用accept或acceptEx接受客户端连接;
  (3)创建工作者线程,处理客户端的数据收发。
  
  众所周知,CreateIoCompletionPort函数,有两个作用,一是“创建”一个完成端口,二是将一个socket与已经创建的完成端口句柄相“绑定”,绑定之后,基于该socket的收、发、断开等事件都可以被完成端口感知。一般情况下,较为正常的思维状态下,CreateIoCompletionPort的绑定是选在accept函数执行以后或acceptEx函数完成之时与套接字相绑定。但是,这并不说明CreateIoCompletionPort函数就不能进行其它形式的绑定。

  事实上,CreateIoCompletionPort关心的只是一个套接字,它并不关心这个套接字到底是通过accept而来的,还是用来connect的。也就是说,它并不关心当前的这个socket是用于接受客户端连接的,还是用来连接其它服务器的。那就是说,CreateIoCompletionPort函数,也可以用来绑定一个连接到其它服务器的客户端socket。

  这个问题的提出,是我在设计网关服务器时。

  网关服务器,承担的主要工作就是两个:向内,负责客户端数据包的分发;向外,负责把内部服务器所有的返回数据包统一通过网关发送出去。网关服务器上,我创建了两个IOCP,一个用来向外接受玩家与网关的数据交换,另一个用来与内部的服务器进行数据转发。由于本人较懒,所以想在内部的那个服务器上,也采用IOCP模型来作。

  在网关上负责向内部服务器提供数据转发的这个IOCP,必须要能正确识别哪一个内部服务器使用的是哪一个套接字。这样,内部服务器与网关服务器之间的套接字确认就有两种方式。一种方式,是由内部服务器连接到网关服务器上,随后向网关服务器发送一个注册包,告诉网关服务器当前的这个socket是哪个内部服务器;另一种方式,是由网关服务器先创建若干个指定的socket,然后用这些socket去连接指定类型的内部服务器。前面,我已经说过,IOCP可以绑定的套接字,不仅是可以被accept来的套接字,也可以是connect其它服务器的套接字。所以,我选用了后一种方式。这样在网关服务器对内的IOCP的逻辑处理上,就少了一项判定和一个包的逻辑解析。当网关流量非常巨大时,每节省一项判定或一种分支,效率和资源都会得到更有效的利用,高性能从哪里来?就是从这样的一点一滴的改进中来。到目前为止,我能测试到的网关服务器流量上限是每秒10M到12M,据说,局域网的某些HUB给每台机子的带宽只分了10M左右的出口带宽,所以,我无法确定如果把局域网的交换机换成电信级的,数据交换量会不会有一个更大的提高,不久,公司会进一个这样的电信级交换机,到时可以作进一步的测试。

  过段时间,我会在我的BLOG(http://blog.csdn.net/sodme)上公布我的IOCP底层通信模型的架构设计以及一个通用的高性能服务器模型架构,希望能与各位同仁共同研究高性能服务器研发问题。

本文作者:sodme 本文出处:http://blog.csdn.net/sodme
版权声明:本文可以不经作者同意任意转载,但转载时烦请保留文章开始前两行的版权、作者及出处信息。

对于初次使用IOCP进行高性能服务器开发的朋友来说,可能会经常遇到一些莫名其妙的错误,让自己无从下手。为此,我将利用此篇文章对IOCP开发中的常见问题予以集中记录并持续添加,并附上我的处理建议,以供大家参考。

1、在程序创建监听套接字时,使用socket函数创建一个套接字时,总是报“INVALID_SOCKET”错误?
原因:出现此问题的原因,很可能是因为没有正确执行WSAStartUp函数引起的;
解决方法:请检查,是否使用WSAStartUp对winsock进行了初始化工作?如果进行了初始化,请检查初始化是否成功?

2、使用WSASend或WSARecv投递相应的发送或接收请求后,始终没有收到相应的GET函数完成返回通知?
原因:出现此问题的原因,绝大多数是因为函数参数没有进行正确的赋值。
解决方法:在执行wsasend和wsarecv操作前,请先将overlapped结构体使用memset进行清零。一个正确的调用格式如下:
发送操作
  DWORD ByteSend=0;
  DWORD Flags=0;
  int tmpResult=0;
     ……
 PPerHandleData tmpData;
 ……
 memset(&(tmpData->Overlapped), ‘\0′, sizeof(OVERLAPPED));//将overlapped结构清空
 tmpData->Statu = ssSend;
    tmpResult = WSASend(tmpData->socket, &(tmpData->WSASendBuffer), 1,
   &ByteSend,
   Flags,
   &(tmpData->Overlapped),
   NULL);

接收操作
  DWORD byteRecv=0;
  DWORD Flags=0;
  int tmpResult=0;
  ……
  PPerHandleData myHandlData; 
  …… 
  memset(&(myHandlData->Overlapped), ‘\0′, sizeof(OVERLAPPED));
  memset(myHandlData->RecvBuffer, ‘\0′, CLIENT_BUFFER_SIZE);
  myHandlData->WSARecvBuffer.buf = myHandlData->RecvBuffer;
  myHandlData->WSARecvBuffer.len = CLIENT_BUFFER_SIZE;
  myHandlData->socket = myClient->m_ClientSocket;
  myHandlData->Statu = ssRecv;

  tmpResult = WSARecv(myHandlData->socket, &(myHandlData->WSARecvBuffer), 1, (LPDWORD)&byteRecv, (LPDWORD)&Flags, (LPWSAOVERLAPPED)&(myHandlData->Overlapped), 0);


3、当投递了一个WSARecv或WSASend请求后,总是返回“ERROR_IO_PENDING”错误?
原因:“ERROR_IO_PENDING”,表示的是WSARecv或WSASend操作正在执行中,还没有执行完毕。
解决方法:此错误可以直接忽略,如果参数设置正确,当操作完成时,系统会通过GET函数返回执行的形式来通知发送或接收操作已经完成。

4、为什么投递一个WSASend操作后,在Get函数中,获得发送完成事件的通知时,截获到的发送出去的数据却不是刚刚投递的数据?
原因:在投递WSASend时,会要求你指定数据缓冲区的地址,如果你此处的地址是通过new动态分配的,并且在投递过WSASend之后随之即delete了此空间,则可能会发生你的描述的这个现象。我的理解是:当WSASend操作还没有真正完成时,如果释放了数据缓冲区,那么WSASend将会因为缓冲区的释放而造成没有正确投递缓冲区内的数据,也就是说,WSASend在投递一个数据时,并没有即刻把数据拷到投递缓冲区去,如果是在WSASend完成后再释放此空间则不会发生这种情况。以上,只是偶的猜想,除调试结果外,到现在还没有获得其它信息加以证实。