学步园

  知名网游架构 收藏
 http://blog.csdn.net/sodme/archive/2004/12/12/213995.aspx

类似于QQ游戏百万人同时在线的服务器架构实现 收藏
本文作者：sodme　本文出处：http://blog.csdn.net/sodme
版权声明：本文可以不经作者同意任意转载，但转载时烦请保留文章开始前两行的版权、作者及出处信息。

　　QQ游戏于前几日终于突破了百万人同时在线的关口，向着更为远大的目标迈进，这让其它众多传统的棋牌休闲游戏平台黯然失色，相比之下，联众似乎已经根本不是QQ的对手，因为QQ除了这100万的游戏在线人数外，它还拥有3亿多的注册量（当然很多是重复注册的）以及QQ聊天软件900万的同时在线率，我们已经可以预见未来由QQ构建起来的强大棋牌休闲游戏帝国。
　　那么，在技术上，QQ游戏到底是如何实现百万人同时在线并保持游戏高效率的呢？
　　事实上，针对于任何单一的网络服务器程序，其可承受的同时连接数目是有理论峰值的，通过C＋＋中对TSocket的定义类型：word，我们可以判定这个连接理论峰值是65535，也就是说，你的单个服务器程序，最多可以承受6万多的用户同时连接。但是，在实际应用中，能达到一万人的同时连接并能保证正常的数据交换已经是很不容易了，通常这个值都在2000到5000之间，据说QQ的单台服务器同时连接数目也就是在这个值这间。
　　如果要实现2000到5000用户的单服务器同时在线，是不难的。在windows下，比较成熟的技术是采用IOCP－－完成端口。与完成端口相关的资料在网上和CSDN论坛里有很多，感兴趣的朋友可以自己搜索一下。只要运用得当，一个完成端口服务器是完全可以达到2K到5K的同时在线量的。但，5K这样的数值离百万这样的数值实在相差太大了，所以，百万人的同时在线是单台服务器肯定无法实现的。
　　要实现百万人同时在线，首先要实现一个比较完善的完成端口服务器模型，这个模型要求至少可以承载2K到5K的同时在线率（当然，如果你MONEY多，你也可以只开发出最多允许100人在线的服务器）。在构建好了基本的完成端口服务器之后，就是有关服务器组的架构设计了。之所以说这是一个服务器组，是因为它绝不仅仅只是一台服务器，也绝不仅仅是只有一种类型的服务器。
　　简单地说，实现百万人同时在线的服务器模型应该是：登陆服务器＋大厅服务器＋房间服务器。当然，也可以是其它的模型，但其基本的思想是一样的。下面，我将逐一介绍这三类服务器的各自作用。
　　登陆服务器：一般情况下，我们会向玩家开放若干个公开的登陆服务器，就如QQ登陆时让你选择的从哪个QQ游戏服务器登陆一样，QQ登陆时让玩家选择的六个服务器入口实际上就是登陆服务器。登陆服务器主要完成负载平衡的作用。详细点说就是，在登陆服务器的背后，有N个大厅服务器，登陆服务器只是用于为当前的客户端连接选择其下一步应该连接到哪个大厅服务器，当登陆服务器为当前的客户端连接选择了一个合适的大厅服务器后，客户端开始根据登陆服务器提供的信息连接到相应的大厅上去，同时客户端断开与登陆服务器的连接，为其他玩家客户端连接登陆服务器腾出套接字资源。在设计登陆服务器时，至少应该有以下功能：N个大厅服务器的每一个大厅服务器都要与所有的登陆服务器保持连接，并实时地把本大厅服务器当前的同时在线人数通知给各个登陆服务器，这其中包括：用户进入时的同时在线人数增加信息以及用户退出时的同时在线人数减少信息。这里的各个大厅服务器同时在线人数信息就是登陆服务器为客户端选择某个大厅让其登陆的依据。举例来说，玩家A通过登陆服务器1连接到登陆服务器，登陆服务器开始为当前玩家在众多的大厅服务器中根据哪一个大厅服务器人数比较少来选择一个大厅，同时把这个大厅的连接IP和端口发给客户端，客户端收到这个IP和端口信息后，根据这个信息连接到此大厅，同时，客户端断开与登陆服务器之间的连接，这便是用户登陆过程中，在登陆服务器这一块的处理流程。
　　大厅服务器：大厅服务器，是普通玩家看不到的服务器，它的连接IP和端口信息是登陆服务器通知给客户端的。也就是说，在QQ游戏的本地文件中，具体的大厅服务器连接IP和端口信息是没有保存的。大厅服务器的主要作用是向玩家发送游戏房间列表信息，这些信息包括：每个游戏房间的类型，名称，在线人数，连接地址以及其它如游戏帮助文件URL的信息。从界面上看的话，大厅服务器就是我们输入用户名和密码并校验通过后进入的游戏房间列表界面。大厅服务器，主要有以下功能：一是向当前玩家广播各个游戏房间在线人数信息；二是提供游戏的版本以及下载地址信息；三是提供各个游戏房间服务器的连接IP和端口信息；四是提供游戏帮助的URL信息；五是提供其它游戏辅助功能。但在这众多的功能中，有一点是最为核心的，即：为玩家提供进入具体的游戏房间的通道，让玩家顺利进入其欲进入的游戏房间。玩家根据各个游戏房间在线人数，判定自己进入哪一个房间，然后双击服务器列表中的某个游戏房间后玩家开始进入游戏房间服务器。
　　游戏房间服务器：游戏房间服务器，具体地说就是如“斗地主1”，“斗地主2”这样的游戏房间。游戏房间服务器才是具体的负责执行游戏相关逻辑的服务器。这样的游戏逻辑分为两大类：一类是通用的游戏房间逻辑，如：进入房间，离开房间，进入桌子，离开桌子以及在房间内说话等；第二类是游戏桌子逻辑，这个就是各种不同类型游戏的主要区别之处了，比如斗地主中的叫地主或不叫地主的逻辑等，当然，游戏桌子逻辑里也包括有通用的各个游戏里都存在的游戏逻辑，比如在桌子内说话等。总之，游戏房间服务器才是真正负责执行游戏具体逻辑的服务器。
　　这里提到的三类服务器，我均采用的是完成端口模型，每个服务器最多连接数目是5000人，但是，我在游戏房间服务器上作了逻辑层的限定，最多只允许300人同时在线。其他两个服务器仍然允许最多5000人的同时在线。如果按照这样的结构来设计，那么要实现百万人的同时在线就应该是这样：首先是大厅，1000000/5000＝200。也就是说，至少要200台大厅服务器，但通常情况下，考虑到实际使用时服务器的处理能力和负载情况，应该至少准备250台左右的大厅服务器程序。另外，具体的各种类型的游戏房间服务器需要多少，就要根据当前玩各种类型游戏的玩家数目分别计算了，比如斗地主最多是十万人同时在线，每台服务器最多允许300人同时在线，那么需要的斗地主服务器数目就应该不少于：100000/300=333，准备得充分一点，就要准备350台斗地主服务器。
　　除正常的玩家连接外，还要考虑到：
　　对于登陆服务器，会有250台大厅服务器连接到每个登陆服务器上，这是始终都要保持的连接；
　　而对于大厅服务器而言，如果仅仅有斗地主这一类的服务器，就要有350多个连接与各个大厅服务器始终保持着。所以从这一点看，我的结构在某些方面还存在着需要改进的地方，但核心思想是：尽快地提供用户登陆的速度，尽可能方便地让玩家进入游戏中。

http://blog.csdn.net/sodme/archive/2005/06/18/397371.aspx

逆向思维--魔兽世界封包分析(1) 收藏
本文作者：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的连接建立和连接关闭，都是通过请求－响应的模式完成的。

http://blog.csdn.net/sodme/archive/2005/07/10/419359.aspx

逆向思维----魔兽世界封包分析(2) 收藏
本文作者：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:由于每次封包分析的内容都很多，所以，一有了点结论后，要及时记录和总结，并与之前取得的总结进行对比，及时更新相关的记录文档。

http://xiaogui9317170.javaeye.com/blog/276133

泡泡堂、QQ堂游戏通信架构分析

作者：sodme

网站：http://blog.csdn.net/sodme/archive/2005/08/31/468327.aspx

之前，我分析过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的通信量
　　3.UDP的通信IP个数，与房间内的玩家成一一对应关系(这一点，应网友疑惑而加，此前已经证实)

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

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

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

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

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

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

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

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

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

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

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/king_idea8848/archive/2009/11/05/4771806.aspx