比如有一个玩家A向服务器发了条指令，说我现在在P1点，要去P2点。指令发出的时间是T0，服务器收到指令的时间是T1，然后向周围的玩家广播这条消息，消息的内容是“玩家A从P1到P2”有一个在A附近的玩家B，收到服务器的这则广播的消息的时间是T2，然后开始在客户端上画图，A从P1到P2点。这个时候就存在一个不同步的问题，玩家A和玩家B的屏幕上显示的画面相差了T2-T1的时间。这个时候怎么办呢？

　　有个解决方案，我给它取名叫 预测拉扯，虽然有些怪异了点，不过基本上大家也能从字面上来理解它的意思。要解决这个问题，首先要定义一个值叫：预测误差。然后需要在服务器端每个玩家连接的类里面加一项属性，叫TimeModified，然后在玩家登陆的时候，对客户端的时间和服务器的时间进行比较，得出来的差值保存在TimeModified里面。还是上面的那个例子，服务器广播消息的时候，就根据要广播对象的TimeModified，计算出一个客户端的CurrentTime，然后在消息头里面包含这个CurrentTime，然后再进行广播。并且同时在玩家A的客户端本地建立一个队列，保存该条消息，只到获得服务器验证就从未被验证的消息队列里面将该消息删除，如果验证失败，则会被拉扯回P1点。然后当玩家B收到了服务器发过来的消息“玩家A从P1到P2”这个时候就检查消息里面服务器发出的时间和本地时间做比较，如果大于定义的预测误差，就算出在T2这个时间，玩家A的屏幕上走到的地点P3，然后把玩家B屏幕上的玩家A直接拉扯到P3，再继续走下去，这样就能保证同步。更进一步，为了保证客户端运行起来更加smooth，我并不推荐直接把玩家拉扯过去，而是算出P3偏后的一点P4，然后用(P4-P1)/T(P4-P3)来算出一个很快的速度S，然后让玩家A用速度S快速移动到P4，这样的处理方法是比较合理的，这种解决方案的原形在国际上被称为（Full plesiochronous），当然，该原形被我篡改了很多来适应网络游戏的同步，所以而变成所谓的：预测拉扯。

　　另外一个解决方案，我给它取名叫 验证同步，听名字也知道，大体的意思就是每条指令在经过服务器验证通过了以后再执行动作。具体的思路如下：首先也需要在每个玩家连接类型里面定义一个TimeModified，然后在客户端响应玩家鼠标行走的同时，客户端并不会先行走动，而是发一条走路的指令给服务器，然后等待服务器的验证。服务器接受到这条消息以后，进行逻辑层的验证，然后计算出需要广播的范围，包括玩家A在内，根据各个客户端不同的TimeModified生成不同的消息头，开始广播，这个时候这个玩家的走路信息就是完全同步的了。这个方法的优点是能保证各个客户端之间绝对的同步，缺点是当网络延迟比较大的时候，玩家的客户端的行为会变得比较不流畅，给玩家带来很不爽的感觉。该种解决方案的原形在国际上被称为（Hierarchical master-slave synchronization），80年代以后被广泛应用于网络的各个领域。

　　最后一种解决方案是一种理想化的解决方案，在国际上被称为Mutual synchronization，是一种对未来网络的前景的良好预测出来的解决方案。这里之所以要提这个方案，并不是说我们已经完全的实现了这种方案，而只是在网络游戏领域的某些方面应用到这种方案的某些思想。我对该种方案取名为：半服务器同步。大体的设计思路如下：

　　首先客户端需要在登陆世界的时候建立很多张广播列表，这些列表在客户端后台和服务器要进行不及时同步，之所以要建立多张列表，是因为要广播的类型是不止一种的，比如说有local message,有remote message,还有global message 等等，这些列表都需要在客户端登陆的时候根据服务器发过来的消息建立好。在建立列表的同时，还需要获得每个列表中广播对象的TimeModified，并且要维护一张完整的用户状态列表在后台，也是不及时的和服务器进行同步，根据本地的用户状态表，可以做到一部分决策由客户端自己来决定，当客户端发送这部分决策的时候，则直接将最终决策发送到各个广播列表里面的客户端，并对其时间进行校对，保证每个客户端在收到的消息的时间是和根据本地时间进行校对过的。那么再采用预测拉扯中提到过的计算提前量，提高速度行走过去的方法，将会使同步变得非常的smooth。该方案的优点是不通过服务器，客户端自己之间进行同步，大大的降低了由于网络延迟而带来的误差，并且由于大部分决策都可以由客户端来做，也大大的降低了服务器的资源。由此带来的弊端就是由于消息和决策权都放在客户端本地，所以给外挂提供了很大的可乘之机。

　　综合以上三种关于网络同步派系的优缺点，综合出一套关于网络游戏传输同步的较完整的解决方案，我称它为综合同步法（colligate synchronization）。大体设计思路如下：

　　首先将服务器需要同步的所有消息从划分一个优先等级，然后按照3/4的比例划分出重要消息和非重要消息，对于非重要消息，把决策权放在客户端，在客户端逻辑上建立相关的决策机构和各种消息缓存区，以及相关的消息缓存区管理机构，如下图所示：

　　上图简单说明了对于非重要消息，客户端的大体处理流程，其中有一个客户端被动行为值得大家注意，其中包括对服务器发过来的某些验证代码做返回，来确保消息缓存中的消息和服务器端是一致的，从而有效的防止外挂来篡改本地消息缓存。其中的消息来源是包括本地的客户端响应玩家的消息以及远程服务器传递过来的消息。

　　对于重要消息，比如说战斗或者是某些牵扯到玩家一些比较敏感数据的操作，则采用另外一套方案，该方案首先需要在服务器和客户端之间建立一套Ping System，然后服务器保存和用户的及时的ping值，当ping比较小的时候，响应玩家消息的同时先不进行动作，而是先把该消息反馈给服务器，并且阻塞，服务器收到该消息，进行逻辑验证之后向所有该详细广播的有效对象进行广播（包括消息发起者），然后客户端收到该消息的验证，才开始执行动作。而当ping比较大的时候，客户端响应玩家消息的同时立刻进行动作，并且同时把该消息反馈给服务器，值得注意的是这个时候还需要在本地建立一个无验证消息的队列，把该消息入队，执行动作的同时等待服务器的验证，还需要保存当前状态。服务器收到客户端的请求后，进行逻辑验证，并把消息反馈到各个客户端，带上各个客户端校对过的本地时间。如果验证通过不过，则通知消息发起者，该消息验证失败，然后客户端自动把已经在进行中的动作取消，恢复原来状态。如果验证通过，则广播到的各个客户端根据从服务器获得校对时间进行对其进行拉扯，保证在该行为完成之前完成同步。

　　至此，一个比较成熟的网络游戏的同步机制已经初步建立起来了，接下来的逻辑代码就根据各自不同的游戏风格以及侧重点来写了。

　　同步是网络游戏最重要的问题，如何同步也牵扯到各个方面的问题，比如说游戏的规模，游戏的类型以及各种各样的方面，对于规模比较大的游戏，在同步方面可以下很多的工夫，把消息分得十分的细腻，对于不同的消息采用不同的同步机制，而对于规模比较小的游戏，则可以采用大体上一样的同步机制，究竟怎么样同步，没有个定式，是需要根据自己的不同情况来做出不同的同步决策的

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

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

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

　　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的连接建立和连接关闭，都是通过请求－响应的模式完成的。

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

　　初涉封包分析的新手，一般会不知道封包分析究竟该从何入手。基于经验，本文将告诉你一般会从哪些类型的包入手进行分析以及应该怎样对封包进行初 步的分析。需要指出的是：封包分析是一件非常有趣但同时也非常考验耐心的事，通常，半天的封包分析下来，会让你眼前全是诸如“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://data.gameres.com/message.asp?TopicID=27236

　　让无数中国玩家为之瞩目的“魔兽世界”，随着一系列内测前期工作的逐步展开，正在一步步地走近中国玩家，但是，“魔兽”的服务器，却着实让我们为它捏了一把汗。

造成一个网游服务器当机的原因有很多，但主要有以下两种：一，服务器在线人数达到上限，服务器处理效率严重迟缓，造成当机；二，由于外挂或其它游戏作弊 工具导致的非正常数据包的出错，导致游戏服务器逻辑出现混乱，从而造成当机。在这里，我主要想说说后者如何尽可能地避免。

　　要避免以上 所说到的第二种情况，我们就应该遵循一个基本原则：在网游服务器的设计中，对于具有较强逻辑关系的处理单元，服务器端和客户端应该采用“互不信任原则”， 即：服务器端即使收到了客户端的数据包，也并不是立刻就认为客户端已经达到了某种功能或者状态，客户端到达是否达到了某种功能或者状态，还必须依靠服务器 端上记载的该客户端“以往状态”来判定，也就是说：服务器端的逻辑执行并不单纯地以“当前”的这一个客户端封包来进行，它还应该广泛参考当前封包的上下文 环境，对执行的逻辑作出更进一步地判定，同时，在单个封包的处理上，服务器端应该广泛考虑当前客户端封包所需要的“前置”封包，如果没有收到该客户端应该 发过来的“前置”封包，则当前的封包应该不进行处理或进行异常处理（如果想要性能高，则可以直接忽略该封包；如果想让服务器稳定，可以进行不同的异常处 理）。

　　之所以采用“互不信任”原则设计网游服务器，一个很重要的考虑是：防外挂。对于一个网络服务器（不仅仅是游戏服务器，泛指所有 服务器）而言，它所面对的对象既有属于自己系统内的合法的网络客户端，也有不属于自己系统内的非法客户端访问。所以，我们在考虑服务器向外开放的接口时， 就要同时考虑这两种情况：合法客户端访问时的逻辑走向以及非法客户端访问时的逻辑走向。举个简单的例子：一般情况下，玩家登录逻辑中，都是先向服务器发送 用户名和密码，然后再向服务器发送进入某组服务器的数据包；但在非法客户端（如外挂）中，则这些客户端则完全有可能先发进入某组服务器的数据包。当然，这 里仅仅是举个例子，也许并不妥当，但基本的意思我已经表达清楚了，即：你服务器端不要我客户端发什么你就信什么，你还得进行一系列的逻辑验证，以判定我当 前执行的操作是不是合法的。以这个例子中，服务器端可以通过以下逻辑执行验证功能：只有当客户端的用户名和密码通过验证后，该客户端才会进入在线玩家列表 中。而只有在线玩家列表中的成员，才可以在登陆服务器的引导下进入各分组服务器。

　　总之，在从事网游服务器的设计过程中，要始终不移地 坚持一个信念：我们的服务器，不仅仅有自己的游戏客户端在访问，还有其它很多他人写的游戏客户端在访问，所以，我们应该确保我们的服务器是足够强壮的，任 它风吹雨打也不怕，更不会倒。如果在开发实践中，没有很好地领会这一点或者未能将这一思路贯穿进开发之中，那么，你设计出来的服务器将是无比脆弱的。

当然，安全性和效率总是相互对立的。为了实现我们所说的“互不信任”原则，难免的，就会在游戏逻辑中加入很多的异常检测机制，但异常检测又是比较耗时 的，这就需要我们在效率和安全性方面作个取舍，对于特别重要的逻辑，我们应该全面贯彻“互不信任”原则，一步扣一步，步步为营，不让游戏逻辑出现一点漏 洞。而对于并非十分重要的场合，则完全可以采用“半信任”或者根本“不须信任”的原则进行设计，以尽可能地提高服务器效率。

　　本文只是对自己长期从事游戏服务器设计以来的感受加以总结，也是对魔兽的服务器有感而发。欢迎有相同感受的朋友或从事相同工作的朋友一起讨论。

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

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

　　为方便以下的讨论，先明确两个概念（这两个概念是为了叙述方面，笔者自行取的，并无标准可言）：
　　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
声明：本文可以不经作者同意任意转载、复制、引用。但任何对本文的引用，均须注明本文的作者、出处以及本行声明信息。

　　之前，我分析过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讨论。

本文作者：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多个连接与各个大厅服务器始终保持着。所以从这一点看，我的结构在某些方面还存在着需要改进的地方，但核心思想是：尽快地提供用户登陆的速度，尽可能方便地让玩家进入游戏中。

项目开发的基本硬件配置
一台普通的pc就可以了，
安装好windows 2000和vc6就可以了，
然后连上网，局域网和internet都可以，

接下去的东西我都简化，不去用晦涩的术语，

既然是网络，我们就需要网络编程接口，
服务器端我们用的是winsock 1.1，使用tcp连接方式，

[tcp和udp]
tcp可以理解为一条连接两个端子的隧道，提供可靠的数据传输服务，
只要发送信息的一方成功的调用了tcp的发送函数发送一段数据，
我们可以认为接收方在若干时间以后一定会接收到完整正确的数据，
不需要去关心网络传输上的细节，
而udp不保证这一点，
对于网络游戏来说，tcp是普遍的选择。

[阻塞和非阻塞]
在通过socket发送数据时，如果直到数据发送完毕才返回的方式，也就是说如果我们使用send( buffer, 100.....)这样的函数发送100个字节给别人，我们要等待，直到100个自己发送完毕，程序才往下走，这样就是阻塞的，
而非阻塞的方式，当你调用send(buffer,100....)以后，立即返回，此时send函数告诉你发送成功，并不意味着数据已经向目的地发送完 毕，甚至有可能数据还没有开始发送，只被保留在系统的缓冲里面，等待被发送，但是你可以认为数据在若干时间后，一定会被目的地完整正确的收到，我们要充分 的相信tcp。
阻塞的方式会引起系统的停顿，一般网络游戏里面使用的都是非阻塞的方式，

[有状态服务器和无状态服务器]
在c/s体系中，如果server不保存客户端的状态，称之为无状态，反之为有状态，

在这里要强调一点，
我们所说的服务器不是一台具体的机器，
而是指服务器应用程序，
一台具体的机器或者机器群组可以运行一个或者多个服务器应用程序，

我们的网络游戏使用的是有状态服务器，
保存所有玩家的数据和状态，

[开发语言]
vc6
我们首先要熟练的掌握一门开发语言，
学习c++是非常有必要的，
而vc是windows下面的软件开发工具，
为什么选择vc，可能与我本身使用vc有关，
而且网上可以找到许多相关的资源和源代码，

[操作系统]
我们使用windows2000作为服务器的运行环境，
所以我们有必要去了解windows是如何工作的，
同时对它的编程原理应该熟练的掌握

[数据结构和算法]
要写出好的程序要先具有设计出好的数据结构和算法的能力，
好的算法未必是繁琐的公式和复杂的代码，
我们要找到又好写有满足需求的算法，
有时候，最笨的方法同时也是很好的方法，
很多程序员沉迷于追求精妙的算法而忽略了宏观上的工程，
花费了大量的精力未必能够取得好的效果，

举个例子，
我当年进入游戏界工作，学习老师的代码，
发现有个函数，要对画面中的npc位置进行排序，
确定哪个先画，那个后画，
他的方法太“笨”，
任何人都会想到的冒泡，
一个一个去比较，没有任何的优化，
我当时想到的算法就有很多，
而且有一大堆优化策略，
可是，当我花了很长时间去实现我的算法时，
发现提升的那么一点效率对游戏整个运行效率而言几乎是没起到什么作用，
或者说虽然算法本身快了几倍，
可是那是多余的，老师的算法虽然“笨”，
可是他只花了几十行代码就搞定了，
他的时间花在别的更需要的地方，
这就是他可以独自完成一个游戏，
而我可以把一个函数优化100倍也只能打杂的原因

[tcp/ip的理论]
推荐数据用tcp/ip进行网际互连，tcp/ip详解，
这是两套书，共有6卷，
都是国外的大师写的，
可以说是必读的，

[消息]
消息是个很常见的术语，
在windows中，消息机制是个十分重要的概念，
我们在网络游戏中，也使用了消息这样的机制，

一般我们这么做，
一个数据块，头4个字节是消息名，后面接2个字节的数据长度，
再后面就是实际的数据

为什么使用消息？？
我们来看看例子，

在游戏世界，
一个玩家想要和别的玩家聊天，
那么，他输入好聊天信息，
客户端生成一条聊天消息，
并把聊天的内容打包到消息中，
然后把聊天消息发送给服务器，
请求服务器把聊天信息发送给另一个玩家，

服务器接收到一条消息，
此刻，服务器并不知道当前的数据是什么东西，
对于服务器来讲，这段数据仅仅来自于网络通讯的底层，
不加以分析的话，没有任何的信息，
因为我们的通讯是基于消息机制的，
我们认为服务器接收到的任何数据都是基于消息的数据方式组织的，
4个字节消息名，2字节长度，这个是不会变的，

通过消息名，服务器发现当前数据是一条聊天数据，
通过长度把需要的数据还原，校验，
然后把这条消息发送给另一个玩家，

大家注意，消息是变长的，
关于消息的解释完全在于服务器和客户端的应用程序，
可以认为与网络传输低层无关，
比如一条私聊消息可能是这样的，

MsgID:4 byte
Length:2 byte
TargetPlayerID:2 byte
String:anybyte < 256

一条移动消息可能是这样的，
MsgID:4 byte
Length:2 byte
TargetPlayerID:2 byte
TargetPosition:4 byte (x,y)

编程者可以自定义消息的内容以满足不同的需求

[队列]
队列是一个很重要的数据结构，
比如说消息队列，
服务器或者客户端，
发送的消息不一定是立即发送的，
而是等待一个适当时间，
或者系统规定的时间间隔以后才发送，
这样就需要创建一个消息队列，以保存发送的消息，

消息队列的大小可以按照实际的需求创建，
队列又可能会满，
当队列满了，可以直接丢弃消息，
如果你觉得这样不妥，
也可以预先划分一个足够大的队列，

可以使用一个系统全局的大的消息队列，
也可以为每个对象创建一个消息队列，


这个我们的一个数据队列的实现，
开发工具vc.net，使用了C++的模板，
关于队列的算法和基础知识，我就不多说了，

DataBuffer.h

#ifndef __DATABUFFER_H__
#define __DATABUFFER_H__

#include <windows.h>
#include <assert.h>
#include "g_assert.h"
#include <stdio.h>

#ifndef HAVE_BYTE
typedef unsigned char byte;
#endif // HAVE_BYTE

//数据队列管理类
template <const int _max_line, const int _max_size>
class DataBufferTPL
{
public:

bool Add( byte *data ) // 加入队列数据
{
G_ASSERT_RET( data, false );
m_ControlStatus = false;

if( IsFull() )
{
//assert( false );
return false;
}

memcpy( m_s_ptr, data, _max_size );

NextSptr();
m_NumData++;

m_ControlStatus = true;
return true;
}


bool Get( byte *data ) // 从队列中取出数据
{
G_ASSERT_RET( data, false );
m_ControlStatus = false;

if( IsNull() )
return false;

memcpy( data, m_e_ptr, _max_size );

NextEptr();
m_NumData--;

m_ControlStatus = true;
return true;
}


bool CtrlStatus() // 获取操作成功结果
{
return m_ControlStatus;
}


int GetNumber() // 获得现在的数据大小
{
return m_NumData;
}

public:

DataBufferTPL()
{
m_NumData = 0;
m_start_ptr = m_DataTeam[0];
m_end_ptr = m_DataTeam[_max_line-1];
m_s_ptr = m_start_ptr;
m_e_ptr = m_start_ptr;
}
~DataBufferTPL()
{
m_NumData = 0;
m_s_ptr = m_start_ptr;
m_e_ptr = m_start_ptr;
}

private:

bool IsFull() // 是否队列满
{
G_ASSERT_RET( m_NumData >=0 && m_NumData <= _max_line, false );
if( m_NumData == _max_line )
return true;
else
return false;
}
bool IsNull() // 是否队列空
{
G_ASSERT_RET( m_NumData >=0 && m_NumData <= _max_line, false );
if( m_NumData == 0 )
return true;
else
return false;
}
void NextSptr() // 头位置增加
{
assert(m_start_ptr);
assert(m_end_ptr);
assert(m_s_ptr);
assert(m_e_ptr);
m_s_ptr += _max_size;
if( m_s_ptr > m_end_ptr )
m_s_ptr = m_start_ptr;
}
void NextEptr() // 尾位置增加
{
assert(m_start_ptr);
assert(m_end_ptr);
assert(m_s_ptr);
assert(m_e_ptr);
m_e_ptr += _max_size;
if( m_e_ptr > m_end_ptr )
m_e_ptr = m_start_ptr;
}

private:

byte m_DataTeam[_max_line][_max_size]; //数据缓冲
int m_NumData; //数据个数
bool m_ControlStatus; //操作结果

byte *m_start_ptr; //起始位置
byte *m_end_ptr; //结束位置
byte *m_s_ptr; //排队起始位置
byte *m_e_ptr; //排队结束位置
};


//////////////////////////////////////////////////////////////////////////
// 放到这里了！

//ID自动补位列表模板，用于自动列表，无间空顺序列表。
template <const int _max_count>
class IDListTPL
{
public:
// 清除重置
void Reset()
{
for(int i=0;i<_max_count;i++)
m_dwList[i] = G_ERROR;
m_counter = 0;
}

int MaxSize() const { return _max_count; }
int Count() const { return m_counter; }
const DWORD operator[]( int iIndex ) {

G_ASSERTN( iIndex >= 0 && iIndex < m_counter );

return m_dwList[ iIndex ];
}
bool New( DWORD dwID )
{
G_ASSERT_RET( m_counter >= 0 && m_counter < _max_count, false );

//ID 唯一性，不能存在相同ID
if ( Find( dwID ) != -1 )
return false;

m_dwList[m_counter] = dwID;
m_counter++;

return true;
}
// 没有Assert的加入ID功能
bool Add( DWORD dwID )
{
if( m_counter <0 || m_counter >= _max_count )
return false;

//ID 唯一性，不能存在相同ID
if ( Find( dwID ) != -1 )
return false;

m_dwList[m_counter] = dwID;
m_counter++;
return true;
}
bool Del( int iIndex )
{
G_ASSERT_RET( iIndex >=0 && iIndex < m_counter, false );

for(int k=iIndex;k<m_counter-1;k++)
{
m_dwList[k] = m_dwList[k+1];
}

m_dwList[k] = G_ERROR;
m_counter--;
return true;
}
int Find( DWORD dwID )
{
for(int i=0;i<m_counter;i++)
{
if( m_dwList[i] == dwID )
return i;
}

return -1;
}

IDListTPL():m_counter(0)
{
for(int i=0;i<_max_count;i++)
m_dwList[i] = G_ERROR;
}
virtual ~IDListTPL()
{}

private:

DWORD m_dwList[_max_count];
int m_counter;

};

//////////////////////////////////////////////////////////////////////////


#endif //__DATABUFFER_H__

我们采用winsock作为网络部分的编程接口，

接下去编程者有必要学习一下socket的基本知识，
不过不懂也没有关系，我提供的代码已经把那些麻烦的细节或者正确的系统设置给弄好了，
编程者只需要按照规则编写游戏系统的处理代码就可以了，

这些代码在vc6下编译通过，
是通用的网络传输底层，
这里是socket部分的代码，

我们需要安装vc6才能够编译以下的代码，
因为接下去我们要接触越来越多的c++，
所以，大家还是去看看c++的书吧，

// socket.h
#ifndef _socket_h
#define _socket_h
#pragma once

//定义最大连接用户数目 ( 最大支持 512 个客户连接 )
#define MAX_CLIENTS 512
//#define FD_SETSIZE MAX_CLIENTS

#pragma comment( lib, "wsock32.lib" )

#include <winsock.h>

class CSocketCtrl
{
void SetDefaultOpt();
public:
CSocketCtrl(): m_sockfd(INVALID_SOCKET){}
BOOL StartUp();
BOOL ShutDown();
BOOL IsIPsChange();

BOOL CanWrite();
BOOL HasData();
int Recv( char* pBuffer, int nSize, int nFlag );
int Send( char* pBuffer, int nSize, int nFlag );
BOOL Create( UINT uPort );
BOOL Create(void);
BOOL Connect( LPCTSTR lpszHostAddress, UINT nHostPort );
void Close();

BOOL Listen( int nBackLog );
BOOL Accept( CSocketCtrl& sockCtrl );

BOOL RecvMsg( char *sBuf );
int SendMsg( char *sBuf,unsigned short stSize );
SOCKET GetSockfd(){ return m_sockfd; }

BOOL GetHostName( char szHostName[], int nNameLength );

protected:
SOCKET m_sockfd;

static DWORD m_dwConnectOut;
static DWORD m_dwReadOut;
static DWORD m_dwWriteOut;
static DWORD m_dwAcceptOut;
static DWORD m_dwReadByte;
static DWORD m_dwWriteByte;
};


#endif

// socket.cpp

#include <stdio.h>
#include "msgdef.h"
#include "socket.h"
// 吊线时间
#define ALL_TIMEOUT 120000
DWORD CSocketCtrl::m_dwConnectOut = 60000;
DWORD CSocketCtrl::m_dwReadOut = ALL_TIMEOUT;
DWORD CSocketCtrl::m_dwWriteOut = ALL_TIMEOUT;
DWORD CSocketCtrl::m_dwAcceptOut = ALL_TIMEOUT;
DWORD CSocketCtrl::m_dwReadByte = 0;
DWORD CSocketCtrl::m_dwWriteByte = 0;

// 接收数据
BOOL CSocketCtrl::RecvMsg( char *sBuf )
{
if( !HasData() )
return FALSE;
MsgHeader header;
int nbRead = this->Recv( (char*)&header, sizeof( header ), MSG_PEEK );
if( nbRead == SOCKET_ERROR )
return FALSE;
if( nbRead < sizeof( header ) )
{
this->Recv( (char*)&header, nbRead, 0 );
printf( "\ninvalid msg, skip %ld bytes.", nbRead );
return FALSE;
}

if( this->Recv( (char*)sBuf, header.stLength, 0 ) != header.stLength )
return FALSE;

return TRUE;
}

// 发送数据
int CSocketCtrl::SendMsg( char *sBuf,unsigned short stSize )
{
static char sSendBuf[ 4000 ];
memcpy( sSendBuf,&stSize,sizeof(short) );
memcpy( sSendBuf + sizeof(short),sBuf,stSize );

if( (sizeof(short) + stSize) != this->Send( sSendBuf,stSize+sizeof(short),0 ) )
return -1;
return stSize;
}


// 启动winsock
BOOL CSocketCtrl::StartUp()
{
WSADATA wsaData;
WORD wVersionRequested = MAKEWORD( 1, 1 );

int err = WSAStartup( wVersionRequested, &wsaData );
if ( err != 0 )
{
return FALSE;
}


return TRUE;

}
// 关闭winsock
BOOL CSocketCtrl::ShutDown()
{
WSACleanup();
return TRUE;
}

// 得到主机名
BOOL CSocketCtrl::GetHostName( char szHostName[], int nNameLength )
{
if( gethostname( szHostName, nNameLength ) != SOCKET_ERROR )
return TRUE;
return FALSE;
}

BOOL CSocketCtrl::IsIPsChange()
{
return FALSE;
static int iIPNum = 0;
char sHost[300];

hostent *pHost;
if( gethostname(sHost,299) != 0 )
return FALSE;
pHost = gethostbyname(sHost);
int i;
char *psHost;
i = 0;
do
{
psHost = pHost->h_addr_list[i++];
if( psHost == 0 )
break;

}while(1);
if( iIPNum != i )
{
iIPNum = i;
return TRUE;
}
return FALSE;
}

// socket是否可以写
BOOL CSocketCtrl::CanWrite()
{
int e;

fd_set set;
timeval tout;
tout.tv_sec = 0;
tout.tv_usec = 0;

FD_ZERO(&set);
FD_SET(m_sockfd,&set);
e=::select(0,NULL,&set,NULL,&tout);
if(e==SOCKET_ERROR) return FALSE;
if(e>0) return TRUE;
return FALSE;
}

// socket是否有数据
BOOL CSocketCtrl::HasData()
{
int e;
fd_set set;
timeval tout;
tout.tv_sec = 0;
tout.tv_usec = 0;

FD_ZERO(&set);
FD_SET(m_sockfd,&set);
e=::select(0,&set,NULL,NULL,&tout);
if(e==SOCKET_ERROR) return FALSE;
if(e>0) return TRUE;
return FALSE;
}

int CSocketCtrl::Recv( char* pBuffer, int nSize, int nFlag )
{
return recv( m_sockfd, pBuffer, nSize, nFlag );
}

int CSocketCtrl::Send( char* pBuffer, int nSize, int nFlag )
{
return send( m_sockfd, pBuffer, nSize, nFlag );
}

BOOL CSocketCtrl::Create( UINT uPort )
{
m_sockfd=::socket(PF_INET,SOCK_STREAM,0);
if(m_sockfd==INVALID_SOCKET) return FALSE;
SOCKADDR_IN SockAddr;
memset(&SockAddr,0,sizeof(SockAddr));
SockAddr.sin_family = AF_INET;
SockAddr.sin_addr.s_addr = INADDR_ANY;
SockAddr.sin_port = ::htons( uPort );
if(!::bind(m_sockfd,(SOCKADDR*)&SockAddr, sizeof(SockAddr)))
{
SetDefaultOpt();
return TRUE;
}
Close();
return FALSE;

}

void CSocketCtrl::Close()
{
::closesocket( m_sockfd );
m_sockfd = INVALID_SOCKET;
}

BOOL CSocketCtrl::Connect( LPCTSTR lpszHostAddress, UINT nHostPort )
{
if(m_sockfd==INVALID_SOCKET) return FALSE;

SOCKADDR_IN sockAddr;

memset(&sockAddr,0,sizeof(sockAddr));
LPSTR lpszAscii=(LPSTR)lpszHostAddress;
sockAddr.sin_family=AF_INET;
sockAddr.sin_addr.s_addr=inet_addr(lpszAscii);
if(sockAddr.sin_addr.s_addr==INADDR_NONE)
{
HOSTENT * lphost;
lphost = ::gethostbyname(lpszAscii);
if(lphost!=NULL)
sockAddr.sin_addr.s_addr = ((IN_ADDR *)lphost->h_addr)->s_addr;
else return FALSE;
}
sockAddr.sin_port = htons((u_short)nHostPort);

int r=::connect(m_sockfd,(SOCKADDR*)&sockAddr,sizeof(sockAddr));
if(r!=SOCKET_ERROR) return TRUE;

int e;
e=::WSAGetLastError();
if(e!=WSAEWOULDBLOCK) return FALSE;

fd_set set;
timeval tout;
tout.tv_sec = 0;
tout.tv_usec = 100000;

UINT n=0;
while( n< CSocketCtrl::m_dwConnectOut)
{
FD_ZERO(&set);
FD_SET(m_sockfd,&set);
e=::select(0,NULL,&set,NULL, &tout);

if(e==SOCKET_ERROR) return FALSE;
if(e>0) return TRUE;

if( IsIPsChange() )
return FALSE;
n += 100;
}

return FALSE;

}
// 设置监听socket
BOOL CSocketCtrl::Listen( int nBackLog )
{
if( m_sockfd == INVALID_SOCKET ) return FALSE;
if( !listen( m_sockfd, nBackLog) ) return TRUE;
return FALSE;
}

// 接收一个新的客户连接
BOOL CSocketCtrl::Accept( CSocketCtrl& ms )
{
if( m_sockfd == INVALID_SOCKET ) return FALSE;
if( ms.m_sockfd != INVALID_SOCKET ) return FALSE;

int e;
fd_set set;
timeval tout;
tout.tv_sec = 0;
tout.tv_usec = 100000;

UINT n=0;
while(n< CSocketCtrl::m_dwAcceptOut)
{
//if(stop) return FALSE;
FD_ZERO(&set);
FD_SET(m_sockfd,&set);
e=::select(0,&set,NULL,NULL, &tout);
if(e==SOCKET_ERROR) return FALSE;
if(e==1) break;
n += 100;
}
if( n>= CSocketCtrl::m_dwAcceptOut ) return FALSE;

ms.m_sockfd=accept(m_sockfd,NULL,NULL);
if(ms.m_sockfd==INVALID_SOCKET) return FALSE;
ms.SetDefaultOpt();

return TRUE;
}

BOOL CSocketCtrl::Create(void)
{
m_sockfd=::socket(PF_INET,SOCK_STREAM,0);
if(m_sockfd==INVALID_SOCKET) return FALSE;
SOCKADDR_IN SockAddr;

memset(&SockAddr,0,sizeof(SockAddr));
SockAddr.sin_family = AF_INET;
SockAddr.sin_addr.s_addr = INADDR_ANY;
SockAddr.sin_port = ::htons(0);
//if(!::bind(m_sock,(SOCKADDR*)&SockAddr, sizeof(SockAddr)))
{
SetDefaultOpt();
return TRUE;
}
Close();
return FALSE;
}

// 设置正确的socket状态，
// 主要是主要是设置非阻塞异步传输模式
void CSocketCtrl::SetDefaultOpt()
{
struct linger ling;
ling.l_onoff=1;
ling.l_linger=0;
setsockopt( m_sockfd, SOL_SOCKET, SO_LINGER, (char *)&ling, sizeof(ling));
setsockopt( m_sockfd, SOL_SOCKET, SO_REUSEADDR, 0, 0);
int bKeepAlive = 1;
setsockopt( m_sockfd, SOL_SOCKET, SO_KEEPALIVE, (char*)&bKeepAlive, sizeof(int));
BOOL bNoDelay = TRUE;
setsockopt( m_sockfd, IPPROTO_TCP, TCP_NODELAY, (char*)&bNoDelay, sizeof(BOOL));
unsigned long nonblock=1;
::ioctlsocket(m_sockfd,FIONBIO,&nonblock);
}

今天晚上写了一些测试代码，
想看看flash究竟能够承受多大的网络数据传输，

我在flash登陆到服务器以后，
每隔3毫秒就发送100次100个字符的串 "0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789" 给flash，
然后在flash里面接收数据的函数里面统计数据，


var g_nTotalRecvByte = 0;
var g_time = new Date();
var g_nStartTime = g_time.getTime();
var g_nCounter = 0;

mySocket.onData=function(xmlDoc)
{
g_nTotalRecvByte += xmlDoc.length;
// 每接收超过1k字节的数据，输出一次信息，
if( g_nTotalRecvByte-g_nCounter > 1024 )
{
g_time = new Date();
var nPassedTime = g_time.getTime()-g_nStartTime;
trace( "花费时间:"+nPassedTime+"毫秒" );
g_nCounter = g_nTotalRecvByte;
trace( "接收总数:"+g_nTotalRecvByte+"字节" );
trace( "接收速率:"+g_nTotalRecvByte*1000/nPassedTime+"字节/秒" );

}
结果十分令我意外，
这是截取的一段调试信息，
//
花费时间:6953毫秒
接收总数:343212字节
接收速率:49361.7143678988字节/秒
花费时间:7109毫秒
接收总数:344323字节
接收速率:48434.800956534字节/秒
花费时间:7109毫秒
接收总数:345434字节
接收速率:48591.0817273878字节/秒
。。。
。。。
。。。
。。。
花费时间:8125毫秒
接收总数:400984字节
接收速率:49351.8769230769字节/秒
花费时间:8125毫秒
接收总数:402095字节
接收速率:49488.6153846154字节/秒
花费时间:8125毫秒
接收总数:403206字节
接收速率:49625.3538461538字节/秒

我检查了几遍源程序，没有发现逻辑错误，
如果程序没有问题的话，
那么我们得出的结论是，flash的xml socket每秒可以接收至少40K的数据，
这还没有计算xmlSocket.onData事件的触发，调试代码、信息输出占用的时间。

比我想象中快了一个数量级，
够用了，
flash网络游戏我们可以继续往下走了，

有朋友问到lag的问题，
问得很好，不过也不要过于担心，
lag的产生有的是因为网络延迟，
有的是因为服务器负载过大，
对于游戏的设计者和开发者来说，
首先要从设计的角度来避免或者减少lag产生的机会，
如果lag产生了，
也不要紧，找到巧妙的办法骗过玩家的眼睛，
这也有很多成熟的方法了，
比如航行预测法，路径插值等等，
都可以产生很好的效果，
还有最后的绝招，就是提高服务器的配置和网络带宽，

从我开发网络游戏这段时间的经验来看，
我们的服务器是vc开发的，
普通pc跑几百个玩家，几百个怪物是没有问题的，


又作了一个flash发送的测试，

网络游戏的特点是，
出去的信息比较少，
进来的信息比较多，

这个很容易理解，
人操作游戏的速度是很有限的，
控制指令的产生也是随机的，
离散的，

但是多人游戏的话，
因为人多，信息的流量也就区域均匀分布了，

在昨天接收数据的基础上，
我略加修改，
这次，
我在_root.enterFrame写了如下代码，
_root.onEnterFrame = function()
{
var i;
for( i = 0; i < 10; i++ )
mySocket.send( ConvertToMsg( "01234567890123456789012345678901234567890123456789" ) );
return;
}

服务器端要做的是，
把所有从flash客户端收到的信息原封不动的返回来，

这样，我又可以通过昨天onData里面的统计算法来从侧面估算出flash发送数据的能力，
这里是输出的数据
//
花费时间:30531毫秒
接收总数:200236字节
接收速率:6558.44878975468字节/秒
花费时间:30937毫秒
接收总数:201290字节
接收速率:6506.44858906811字节/秒
花费时间:31140毫秒
接收总数:202344字节
接收速率:6497.88053949904字节/秒
花费时间:31547毫秒
接收总数:203398字节
接收速率:6447.45934637208字节/秒

可以看出来，发送+接收同时做，
发送速率至少可以达到5k byte/s

有一点要注意，要非常注意，
不能让flash的网络传输满载，
所谓满载就是flash在阻塞运算的时候，
不断的有数据从网络进来，
而flash又无法在预计的时间内处理我这些信息，
或者flash发送数据过于频繁，
导致服务器端缓冲溢出导致错误，

对于5k的传输速率，
已经足够了，
因为我也想不出来有什么产生这么大的数据量，
而且如果产生了这么大的数据量，
也就意味着服务器每时每刻都要处理所有的玩家发出的海量数据，
还要把这些海量数据转发给其他的玩家，
已经引起数据爆炸了，
所以，5k的上传从设计阶段就要避免的，
我想用flash做的网络游戏，
除了动作类游戏可能需要恒定1k以内的上传速率，
其他的200个字节/秒以内就可以了，

我们以前讨论过，
通过消息来传递信息，
消息的结构是
struct msg
{
short nLength; // 2 byte
DWORD dwId; // 4 byte

....
data
}

但是在为flash开发的消息中，
不能采用这种结构，

首先Flash xmlSocket只传输字符串，
从xmlSocket的send,onData函数可以看出来，
发出去的，收进来的都应该是字符串，

而在服务器端是使用vc,java等高级语言编写的，
消息中使用的是二进制数据块，
显然，简单的使用字符串会带来问题，

所以，我们需要制定一套协议，
就是无论在客户端还是服务器端，
都用统一的字符串消息，
通过解析字符串的方式来传递信息，

我想这就是flash采用xml document来传输结构化信息的理由之一，
xml document描述了一个完整的数据结构，
而且全部使用的是字符串，
原来是这样，怪不得叫做xml socket，
本来socket和xml完全是不同的概念，
flash偏偏出了个xml socket，
一开始令我费解，
现在，渐渐理解其中奥妙。

在服务器端，我们为flash定义了一种msg结构，
使用语言，vc6
#define MSGMAXSIZE 512
// 消息头
struct MsgHeader
{
short stLength;
MsgHeader():stLength( 0 ){}

};
// 消息
struct Msg
{
MsgHeader header;
short GetLength(){ return header.stLength; }
};
// flash 消息
struct MsgToFlashublic Msg
{
// 一个足够大的缓冲，但是不会被整个发送，
char szString[MSGMAXSIZE];
// 计算设置好内容后，内部会计算将要发送部分的长度，
// 要发送的长度=消息头大小+字符串长度+1
void SetString( const char* pszChatString )
{
if( strlen( pszChatString ) < MSGMAXSIZE-1 )
{
strcpy( szString, pszChatString );
header.stLength = sizeof( header )+
(short)strlen( pszChatString )+1;
}
}

};

在发往flash的消息中，整个处理过后MsgToFlash结构将被发送，
实践证明，在flash 客户端的xmlSocket onData事件中，
接收到了正确的消息，消息的内容是MasToFlash的szString字段，
是一个字符串，

比如在服务器端，
MsgToFlash msg;
msg.SetString( "move player0 to 100 100" );
SendMsg( msg,............. );
那么，在我们的flash客户端的onData( xmlDoc )中，
我们trace( xmlDoc )
结果是
move player0 to 100 100


然后是flash发送消息到服务器，
我们强调flash只发送字符串，
这个字符串无论是否内部拥有有效数据，
服务器都应该首先把消息收下来，
那就要保证发送给服务器的消息遵循统一的结构，
在flash客户端中，
我们定义一个函数，
这个函数把一个字符串转化为服务器可以识别的消息，

补充：现在我们约定字符串长度都不大于97个字节长度，


var num_table = new array( "0","1","2","3","4","5","6","7","8","9" );
function ConvertToMsg( str )
{
var l = str.length+3;
var t = "";
if( l > 10 )
t = num_table[Math.floor(l/10)]+num_table[Number(l%10)]+str;
else
t = num_table[0]+num_table[l]+str;
return t;
}

比如
var msg = ConvertToMsg( "client login" );
我们trace( msg );
看到的是
15client login

为什么是这个结果呢？
15是消息的长度，
头两个字节是整个消息的长度的asc码，意思是整个消息有15个字节长，
然后是信息client login，
最后是一个0（c语言中的字符串结束符）

当服务器收到15client login，
他首先把15给分析出来，
把"15"字符串转化为15的数字，
然后，根据15这个长度把后面的client login读出来，
这样，网络传输的底层就完成了，
client login的处理就交给逻辑层，

　　要了解此篇文章中引用的本人写的另一篇文章，请到以下地址：
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及某位不便透露姓名的网友的讨论，是你们让我决定认真再抓一次包探个究竟。

    要想在修改游戏中做到百战百胜，是需要相当丰富的计算机知识的。有很多计算机高手就是从玩游戏，修改游戏中，逐步对计算机产生浓厚的兴趣，逐步成长起来 的。不要在羡慕别人能够做到的，因为别人能够做的你也能够！我相信你们看了本教程后，会对游戏有一个全新的认识，呵呵，因为我是个好老师！（别拿鸡蛋砸我 呀，救命啊！#￥%……*）

    不过要想从修改游戏中学到知识，增加自己的计算机水平，可不能只是靠修改游戏呀！ 要知道，修改游戏只是一个验证你对你所了解的某些计算机知识的理解程度的场所，只能给你一些发现问题、解决问题的机会，只能起到帮助你提高学习计算机的兴 趣的作用，而决不是学习计算机的捷径。

    一：什么叫外挂？

    现在的网络游戏多是基于Internet上客户／服务器模式，服务端程序运行在游戏服务器上，游戏的设计者在其中创造一个庞大的游戏空间，各地的玩家可以通过运行客户端程序同时登录到游戏中。简单地说，网络游戏实际上就是由游戏开发商 提供一个游戏环境，而玩家们就是在这个环境中相对自由和开放地进行游戏操作。那么既然在网络游戏中有了服务器这个概念，我们以前传统的修改游戏方法就显得 无能为力了。记得我们在单机版的游戏中，随心所欲地通过内存搜索来修改角色的各种属性，这在网络游戏中就没有任何用处了。因为我们在网络游戏中所扮演角色 的各种属性及各种重要资料都存放在服务器上，在我们自己机器上（客户端）只是显示角色的状态，所以通过修改客户端内存里有关角色的各种属性是不切实际的。 那么是否我们就没有办法在网络游戏中达到我们修改的目的？回答是"否".我们知道Internet客户／服务器模式的通讯一般采用TCP/IP通信协议，数据交换是通过IP数据包的传输来实现的，一般来说我们客户端向服务器发出某些请求，比如移动、战斗等指令都是通过封包的形式和服务器交换数 据。那么我们把本地发出消息称为SEND，意思就是发送数据，服务器收到我们SEND的消息后，会按照既定的程序把有关的信息反馈给客户端，比如，移动的 坐标，战斗的类型。那么我们把客户端收到服务器发来的有关消息称为RECV.知道了这个道理，接下来我们要做的工作就是分析客户端和服务器之间往来的数据 （也就是封包），这样我们就可以提取到对我们有用的数据进行修改，然后模拟服务器发给客户端，或者模拟客户端发送给服务器，这样就可以实现我们修改游戏的 目的了。

    目前除了修改游戏封包来实现修改游戏的目的，我们也可以修改客户端的有关程序来达到我们的要求。我们知道目前各个服务器的运算能力是有限的，特别在游戏 中，游戏服务器要计算游戏中所有玩家的状况几乎是不可能的，所以有一些运算还是要依靠我们客户端来完成，这样又给了我们修改游戏提供了一些便利。比如我们 可以通过将客户端程序脱壳来发现一些程序的判断分支，通过跟踪调试我们可以把一些对我们不利的判断去掉，以此来满足我们修改游戏的需求。 在下几个章节中，我们将给大家讲述封包的概念，和修改跟踪客户端的有关知识。大家准备好了吗？

    游戏数据格式和存储：

    在进行我们的工作之前，我们需要掌握一些关于计算机中储存数据方式的知识和游戏中储存数据的特点。本章节是提供给菜鸟级的玩家看的，如果你是高手就可以跳 过了，如果，你想成为无坚不摧的剑客，那么，这些东西就会花掉你一些时间；如果，你只想作个江湖的游客的话，那么这些东西，了解与否无关紧要。是作剑客， 还是作游客，你选择吧！

    现在我们开始！首先，你要知道游戏中储存数据的几种格式，这几种格式是：字节（BYTE）、字（WORD）和双字（DOUBLE WORD），或者说是8位、16位和32位储存方式。字节也就是8位方式能储存0~255的数字；字或说是16位储存方式能储存0~65535的数；双字 即32位方式能储存0~4294967295的数。

    为何要了解这些知识呢？在游戏中各种参数的最大值是不同的，有些可能100左右就够了，比如，金庸群侠传中的角色的等级、随机遇敌个数等等。而有些却需要 大于255甚至大于65535，象金庸群侠传中角色的金钱值可达到数百万。所以，在游戏中各种不同的数据的类型是不一样的。在我们修改游戏时需要寻找准备 修改的数据的封包，在这种时候，正确判断数据的类型是迅速找到正确地址的重要条件。

    在计算机中数据以字节为基本的储存单位，每个字节被赋予一个编号，以确定各自的位置。这个编号我们就称为地址。

    在需要用到字或双字时，计算机用连续的两个字节来组成一个字，连续的两个字组成一个双字。而一个字或双字的地址就是它们的低位字节的地址。 现在我们常用的Windows 9x操作系统中，地址是用一个32位的二进制数表示的。而在平时我们用到内存地址时，总是用一个8位的16进制数来表示它。

    二进制和十六进制又是怎样一回事呢？

    简单说来，二进制数就是一种只有0和1两个数码，每满2则进一位的计数进位法。同样，16进制就是每满十六就进一位的计数进位法。16进制有0——F十六 个数字，它为表示十到十五的数字采用了A、B、C、D、E、F六个数字，它们和十进制的对应关系是：A对应于10，B对应于11，C对应于12，D对应于 13，E对应于14，F对应于15.而且，16进制数和二进制数间有一个简单的对应关系，那就是；四位二进制数相当于一位16进制数。比如，一个四位的二 进制数1111就相当于16进制的F，1010就相当于A.了解这些基础知识对修改游戏有着很大的帮助，下面我就要谈到这个问题。由于在计算机中数据是以 二进制的方式储存的，同时16进制数和二进制间的转换关系十分简单，所以大部分的修改工具在显示计算机中的数据时会显示16进制的代码，而且在你修改时也 需要输入16进制的数字。你清楚了吧？

    在游戏中看到的数据可都是十进制的，在要寻找并修改参数的值时，可以使用Windows提供的计算器来进行十进制和16进制的换算，我们可以在开始菜单里的程序组中的附件中找到它。

    现在要了解的知识也差不多了！不过，有个问题在游戏修改中是需要注意的。在计算机中数据的储存方式一般是低位数储存在低位字节，高位数储存在高位字节。比如，十进制数41715转换为16进制的数为A2F3，但在计算机中这个数被存为F3A2.

    看了以上内容大家对数据的存贮和数据的对应关系都了解了吗？ 好了，接下来我们要告诉大家在游戏中，封包到底是怎么一回事了，来！大家把袖口卷起来，让我们来干活吧！

    二：什么是封包？

    怎么截获一个游戏的封包？怎么去检查游戏服务器的ip地址和端口号？ Internet用户使用的各种信息服务，其通讯的信息最终均可以归结为以IP包为单位的信息传送，IP包除了包括要传送的数据信息外，还包含有信息要发 送到的目的IP地址、信息发送的源IP地址、以及一些相关的控制信息。当一台路由器收到一个IP数据包时，它将根据数据包中的目的IP地址项查找路由表，根据查找的结果将此IP数据包送往对应端口。下一台IP路由器收到此数据包后继续转发，直至发到目的地。路由器之间可以通过路由协议来进行路由信息的交换，从而更新路由表。

    那么我们所关心的内容只是IP包中的数据信息，我们可以使用许多监听网络的工具来截获客户端与服务器之间的交换数据，下面就向你介绍其中的一种工具：WPE. WPE使用方法：执行WPE会有下列几项功能可选择：

    SELECT GAME选择目前在记忆体中您想拦截的程式，您只需双击该程式名称即可。

    TRACE追踪功能。用来追踪撷取程式送收的封包。WPE必须先完成点选欲追踪的程式名称，才可以使用此项目。 按下Play键开始撷取程式收送的封包。您可以随时按下 | | 暂停追踪，想继续时请再按下 | | .按下正方形可以停止撷取封包并且显示所有已撷取封包内容。若您没按下正方形停止键，追踪的动作将依照OPTION里的设定值自动停止。如果您没有撷取到 资料，试试将OPTION里调整为Winsock Version 2.WPE 及 Trainers 是设定在显示至少16 bits 颜色下才可执行。

    FILTER过滤功能。用来分析所撷取到的封包，并且予以修改。

    SEND PACKET送出封包功能。能够让您送出假造的封包。

    TRAINER MAKER制作修改器。

    OPTIONS设定功能。让您调整WPE的一些设定值。

    FILTER的详细教学

    - 当FILTER在启动状态时 ，ON的按钮会呈现红色。- 当您启动FILTER时，您随时可以关闭这个视窗。FILTER将会留在原来的状态，直到您再按一次 on / off 钮。- 只有FILTER启用钮在OFF的状态下，才可以勾选Filter前的方框来编辑修改。- 当您想编辑某个Filter，只要双击该Filter的名字即可。

    NORMAL MODE：

    范例：

    当您在 Street Fighter Online ﹝快打旋风线上版﹞游戏中，您使用了两次火球而且击中了对方，这时您会撷取到以下的封包：SEND-> 0000 08 14 21 06 01 04 SEND-> 0000 02 09 87 00 67 FF A4 AA 11 22 00 00 00 00 SEND-> 0000 03 84 11 09 11 09 SEND-> 0000 0A 09 C1 10 00 00 FF 52 44 SEND-> 0000 0A 09 C1 10 00 00 66 52 44您的第一个火球让对方减了16滴﹝16 = 10h﹞的生命值，而您观察到第4跟第5个封包的位置4有10h的值出现，应该就是这里了。

    您观察10h前的0A 09 C1在两个封包中都没改变，可见得这3个数值是发出火球的关键。

    因此您将0A 09 C1 10填在搜寻列﹝SEARCH﹞，然后在修改列﹝MODIFY﹞的位置4填上FF.如此一来，当您再度发出火球时，FF会取代之前的10，也就是攻击力为255的火球了！

    ADVANCED MODE：范例： 当您在一个游戏中，您不想要用真实姓名，您想用修改过的假名传送给对方。在您使用TRACE后，您会发现有些封包里面有您的名字出现。假设您的名字是 Shadow，换算成16进位则是﹝53 68 61 64 6F 77﹞；而您打算用moon﹝6D6F 6F 6E 20 20﹞来取代他。1） SEND-> 0000 08 14 21 06 01 042） SEND-> 0000 01 06 99 53 68 61 64 6F 77 00 01 05 3） SEND-> 0000 03 84 11 09 11 094） SEND-> 0000 0A 09 C1 10 00 53 68 61 64 6F 77 00 11 5） SEND-> 0000 0A 09 C1 10 00 00 66 52 44但是您仔细看，您的名字在每个封包中并不是出现在相同的位置上- 在第2个封包里，名字是出现在第4个位置上- 在第4个封包里，名字是出现在第6个位置上在这种情况下，您就需要使用ADVANCED MODE- 您在搜寻列﹝SEARCH﹞填上：53 68 61 64 6F 77 ﹝请务必从位置1开始填﹞- 您想要从原来名字Shadow的第一个字母开始置换新名字，因此您要选择从数值被发现的位置开始替代连续数值﹝from the position of the chain found﹞.- 现在，在修改列﹝MODIFY﹞000的位置填上：6D 6F 6F 6E 20 20 ﹝此为相对应位置，也就是从原来搜寻栏的+001位置开始递换﹞- 如果您想从封包的第一个位置就修改数值，请选择﹝from the beginning of the packet﹞了解一点TCP/IP协议常识的人都知道，互联网是 将信息数据打包之后再传送出去的。每个数据包分为头部信息和数据信息两部分。头部信息包括数据包的发送地址和到达地址等。数据信息包括我们在游戏中相关操 作的各项信息。那么在做截获封包的过程之前我们先要知道游戏服务器的IP地址和端口号等各种信息，实际上最简单的是看看我们游戏目录下，是否有一个 SERVER.INI的配置文件，这个文件里你可以查看到个游戏服务器的IP地址，比如金庸群侠传就是如此，那么除了这个我们还可以在DOS下使用 NETSTAT这个命令， NETSTAT命令的功能是显示网络连接、路由表和网络接口信息，可以让用户得知目前都有哪些网络连接正在运作。或者你可以使用木马客星等工具来查看网络 连接。工具是很多的，看你喜欢用哪一种了。

    NETSTAT命令的一般格式为：NETSTAT [选项]命令中各选项的含义如下：-a 显示所有socket，包括正在监听的。-c 每隔1秒就重新显示一遍，直到用户中断它。

    -i 显示所有网络接口的信息。-n 以网络IP地址代替名称，显示出网络连接情形。-r 显示核心路由表，格式同"route -e".-t 显示TCP协议的连接情况。-u 显示UDP协议的连接情况。-v 显示正在进行的工作。

    三：怎么来分析我们截获的封包？

    首先我们将WPE截获的封包保存为文本文件，然后打开它，这时会看到如下的数据（这里我们以金庸群侠传里PK店小二客户端发送的数据为例来讲解）：第一个 文件：SEND-> 0000 E6 56 0D 22 7E 6B E4 17 13 13 12 13 12 13 67 1BSEND-> 0010 17 12 DD 34 12 12 12 12 17 12 0E 12 12 12 9BSEND-> 0000 E6 56 1E F1 29 06 17 12 3B 0E 17 1ASEND-> 0000 E6 56 1B C0 68 12 12 12 5ASEND-> 0000 E6 56 02 C8 13 C9 7E 6B E4 17 10 35 27 13 12 12SEND-> 0000 E6 56 17 C9 12第二个文件：SEND-> 0000 83 33 68 47 1B 0E 81 72 76 76 77 76 77 76 02 7ESEND-> 0010 72 77 07 1C 77 77 77 77 72 77 72 77 77 77 6DSEND-> 0000 83 33 7B 94 4C 63 72 77 5E 6B 72 F3SEND-> 0000 83 33 7E A5 21 77 77 77 3FSEND-> 0000 83 33 67 AD 76 CF 1B 0E 81 72 75 50 42 76 77 77SEND-> 0000 83 33 72 AC 77我们发现两次PK店小二的数据格式一样，但是内容却不相同，我们是PK的同一个NPC，为什么会不同呢？ 原来金庸群侠传的封包是经过了加密运算才在网路上传输的，那么我们面临的问题就是如何将密文解密成明文再分析了。

    因为一般的数据包加密都是异或运算，所以这里先讲一下什么是异或。 简单的说，异或就是"相同为0，不同为1"（这是针对二进制按位来讲的），举个例子，0001和0010异或，我们按位对比，得到异或结果是0011，计 算的方法是：0001的第4位为0，0010的第4位为0，它们相同，则异或结果的第4位按照"相同为0，不同为1"的原则得到0，0001的第3位为 0，0010的第3位为0，则异或结果的第3位得到0，0001的第2位为0，0010的第2位为1，则异或结果的第2位得到1，0001的第1位为 1，0010的第1位为0，则异或结果的第1位得到1，组合起来就是0011.异或运算今后会遇到很多，大家可以先熟悉熟悉，熟练了对分析很有帮助的。

    下面我们继续看看上面的两个文件，按照常理，数据包的数据不会全部都有值的，游戏开发时会预留一些字节空间来便于日后的扩充，也就是说数据包里会存在一些"00"的字节，观察上面的文件，我们会发现文件一里很多"12"，文件二里很多"77"，那么这是不是代表我们说的"00"呢？推理到这里，我们就开始行动吧！

    我们把文件一与"12"异或，文件二与"77"异或，当然用手算很费事，我们使用"M2M 1.0 加密封包分析工具"来计算就方便多了。得到下面的结果：第一个文件：1 SEND-> 0000 F4 44 1F 30 6C 79 F6 05 01 01 00 01 00 01 75 09SEND-> 0010 05 00 CF 26 00 00 00 00 05 00 1C 00 00 00 892 SEND-> 0000 F4 44 0C E3 3B 13 05 00 29 1C 05 083 SEND-> 0000 F4 44 09 D2 7A 00 00 00 484 SEND-> 0000 F4 44 10 DA 01 DB 6C 79 F6 05 02 27 35 01 00 005 SEND-> 0000 F4 44 05 DB 00第二个文件：1 SEND-> 0000 F4 44 1F 30 6C 79 F6 05 01 01 00 01 00 01 75 09SEND-> 0010 05 00 70 6B 00 00 00 00 05 00 05 00 00 00 1A2 SEND-> 0000 F4 44 0C E3 3B 13 05 00 29 1C 05 843 SEND-> 0000 F4 44 09 D2 56 00 00 00 484 SEND-> 0000 F4 44 10 DA 01 B8 6C 79 F6 05 02 27 35 01 00 005 SEND-> 0000 F4 44 05 DB 00哈，这一下两个文件大部分都一样啦，说明我们的推理是正确的，上面就是我们需要的明文！

    接下来就是搞清楚一些关键的字节所代表的含义，这就需要截获大量的数据来分析。

    首先我们会发现每个数据包都是"F4 44"开头，第3个字节是变化的，但是变化很有规律。我们来看看各个包的长度，发现什么没有？对了，第3个字节就是包的长度！ 通过截获大量的数据包，我们判断第4个字节代表指令，也就是说客户端告诉服务器进行的是什么操作。例如向服务器请求战斗指令为"30"，战斗中移动指令 为"D4"等。 接下来，我们就需要分析一下上面第一个包"F4 44 1F 30 6C 79 F6 05 01 01 00 01 00 01 75 09 05 00 CF 26 00 00 00 00 05 00 1C 00 00 00 89"，在这个包里包含什么信息呢？应该有通知服务器你PK的哪个NPC吧，我们就先来找找这个店小二的代码在什么地方。 我们再PK一个小喽罗（就是大理客栈外的那个咯）：SEND-> 0000 F4 44 1F 30 D4 75 F6 05 01 01 00 01 00 01 75 09SEND-> 0010 05 00 8A 19 00 00 00 00 11 00 02 00 00 00 C0 我们根据常理分析，游戏里的NPC种类虽然不会超过65535（FFFF），但开发时不会把自己限制在字的范围，那样不利于游戏的扩充，所以我们在双字里 看看。通过"店小二"和"小喽罗"两个包的对比，我们把目标放在"6C 79 F6 05"和"CF 26 00 00"上。（对比一下很容易的，但你不能太迟钝咯，呵呵）我们再看看后面的包，在后面的包里应该还会出现NPC的代码，比如移动的包，游戏允许观战，服务 器必然需要知道NPC的移动坐标，再广播给观战的其他玩家。在后面第4个包"SEND-> 0000 F4 44 10 DA 01 DB 6C 79 F6 05 02 27 35 01 00 00"里我们又看到了"6C 79 F6 05"，初步断定店小二的代码就是它了！（这分析里边包含了很多工作的，大家可以用WPE截下数据来自己分析分析）

    第一个包的分析暂时就到这里（里面还有的信息我们暂时不需要完全清楚了）

    我们看看第4个包"SEND-> 0000 F4 44 10 DA 01 DB 6C 79 F6 05 02 27 35 01 00 00"，再截获PK黄狗的包，（狗会出来2只哦）看看包的格式：SEND-> 0000 F4 44 1A DA 02 0B 4B 7D F6 05 02 27 35 01 00 00SEND-> 0010 EB 03 F8 05 02 27 36 01 00 00根据上面的分析，黄狗的代码为"4B 7D F6 05"（100040011），不过两只黄狗服务器怎样分辨呢？看看"EB 03 F8 05"（100140011），是上一个代码加上100000，呵呵，这样服务器就可以认出两只黄狗了。我们再通过野外遇敌截获的数据包来证实，果然如 此。

    那么，这个包的格式应该比较清楚了：第3个字节为包的长度，"DA"为指令，第5个字节为NPC个数，从第7个字节开始的10个字节代表一个NPC的信息，多一个NPC就多10个字节来表示。

    大家如果玩过网金，必然知道随机遇敌有时会出现增援，我们就利用游戏这个增援来让每次战斗都会出现增援的NPC吧。

    通过在战斗中出现增援截获的数据包，我们会发现服务器端发送了这样一个包：F4 44 12 E9 EB 03 F8 05 02 00 00 03 00 00 00 00 00 00 第5-第8个字节为增援NPC的代码（这里我们就简单的以黄狗的代码来举例）。 那么，我们就利用单机代理技术来同时欺骗客户端和服务器吧！

    好了，呼叫NPC的工作到这里算是完成了一小半，接下来的事情，怎样修改封包和发送封包，我们下节继续讲解吧。

    四：怎么冒充"客户端"向"服务器"发我们需要的封包？

    这里我们需要使用一个工具，它位于客户端和服务器端之间，它的工作就是进行数据包的接收和转发，这个工具我们称为代理。如果代理的工作单纯就是接收和转发 的话，这就毫无意义了，但是请注意：所有的数据包都要通过它来传输，这里的意义就重大了。我们可以分析接收到的数据包，或者直接转发，或者修改后转发，或 者压住不转发，甚至伪造我们需要的封包来发送。

    下面我们继续讲怎样来同时欺骗服务器和客户端，也就是修改封包和伪造封包。 通过我们上节的分析，我们已经知道了打多个NPC的封包格式，那么我们就动手吧！

    首先我们要查找客户端发送的包，找到战斗的特征，就是请求战斗的第1个包，我们找"F4 44 1F 30"这个特征，这是不会改变的，当然是要解密后来查找哦。 找到后，表示客户端在向服务器请求战斗，我们不动这个包，转发。 继续向下查找，这时需要查找的特征码不太好办，我们先查找"DA"，这是客户端发送NPC信息的数据包的指令，那么可能其他包也有"DA"，没关系，我们 看前3个字节有没有"F4 44"就行了。找到后，我们的工作就开始了！

    我们确定要打的NPC数量。这个数量不能很大，原因在于网金的封包长度用一个字节表示，那么一个包可以有255个字节，我们上面分析过，增加一个NPC要增加10个字节，所以大家算算就知道，打20个NPC比较合适。

    然后我们要把客户端原来的NPC代码分析计算出来，因为增加的NPC代码要加上100000哦。再把我们增加的NPC代码计算出来，并且组合成新的封包，注意代表包长度的字节要修改啊，然后转发到服务器，这一步在编写程序的时候要注意算法，不要造成较大延迟。

    上面我们欺骗服务器端完成了，欺骗客户端就简单了。

    发送了上面的封包后，我们根据新增NPC代码构造封包马上发给客户端，格式就是"F4 44 12 E9 NPC代码 02 00 00 03 00 00 00 00 00 00"，把每个新增的NPC都构造这样一个包，按顺序连在一起发送给客户端，客户端也就被我们骗过了，很简单吧。

    以后战斗中其他的事我们就不管了，尽情地开打吧。

    游戏外挂基本原理及实现

    解释游戏外挂的基本原理和实现方法

    游戏外挂已经深深地影响着众多网络游戏玩家，今天在网上看到了一些关于游戏外挂编写的技术，于是转载上供大家参考

    1、游戏外挂的原理

    外挂现在分为好多种，比如模拟键盘的，鼠标的，修改数据包的，还有修改本地内存的，但好像没有修改服务器内存的哦，呵呵。其实修改服务器也是有办法的，只是技术太高一般人没有办法入手而已。（比如请GM去夜总会、送礼、收黑钱等等办法都可以修改服务器数据，哈哈）

    修改游戏无非是修改一下本地内存的数据，或者截获API函数等等。这里我把所能想到的方法都作一个介绍，希望大家能做出很好的外挂来使游戏厂商更好的完善 自己的技术。我见到一篇文章是讲魔力宝贝的理论分析，写得不错，大概是那个样子。下来我就讲解一下技术方面的东西，以作引玉之用。

   2 技术分析部分

    2.1 模拟键盘或鼠标的响应

    我们一般使用：

UINT SendInput(
　　　　UINT nInputs,　　 // count of input events
　　　PINPUT pInputs,　// array of input events
　　　　int cbSize　　　　// size of structure
　　);
    API函数。第一个参数是说明第二个参数的矩阵的维数的，第二个参数包含了响应事件，这个自己填充就可以，最后是这个结构的大小，非常简单，这是最简单的方法模拟键盘鼠标了，呵呵。注意，这个函数还有个替代函数：

VOID keybd_event(
　　　　BYTE bVk,　　　　　　　// 虚拟键码
　　　　BYTE bScan,　　　　　　// 扫描码
　　　　DWORD dwFlags,
　　　　ULONG_PTR dwExtraInfo　// 附加键状态
　　);
　　与
　　VOID mouse_event(
　　　　DWORD dwFlags,　　　　　 // motion and click options
　　　　DWORD dx,　　　　 　　　 // horizontal position or change
　　　　DWORD dy,　　　　　　　　// vertical position or change
　　　　DWORD dwData,　　　　　　// wheel movement
　　　　ULONG_PTR dwExtraInfo　　// application-defined information
　　);
    这两个函数非常简单了，我想那些按键精灵就是用的这个吧。上面的是模拟键盘，下面的是模拟鼠标的。这个仅仅是模拟部分，要和游戏联系起来我们还需要找到游 戏的窗口才行，或者包含快捷键，就象按键精灵的那个激活键一样，我们可以用GetWindow函数来枚举窗口，也可以用Findwindow函数来查找制 定的窗口（注意，还有一个FindWindowEx），FindwindowEx可以找到窗口的子窗口，比如按钮，等什么东西。当游戏切换场景的时候我们 可以用FindWindowEx来确定一些当前窗口的特征，从而判断是否还在这个场景，方法很多了，比如可以GetWindowInfo来确定一些东西， 比如当查找不到某个按钮的时候就说明游戏场景已经切换了，等等办法。有的游戏没有控件在里面，这是对图像做坐标变换的话，这种方法就要受到限制了。这就需 要我们用别的办法来辅助分析了。

    至于快捷键我们要用动态连接库实现了，里面要用到hook技术了，这个也非常简单。大家可能都会了，其实就是一个全局的hook对象然后 SetWindowHook就可以了，回调函数都是现成的，而且现在网上的例子多如牛毛。这个实现在外挂中已经很普遍了。如果还有谁不明白，那就去看看 MSDN查找SetWindowHook就可以了。

    不要低估了这个动态连接库的作用，它可以切入所有的进程空间，也就是可以加载到所有的游戏里面哦，只要用对，你会发现很有用途的。这个需要你复习一下Win32编程的基础知识了。呵呵，赶快去看书吧。

    2.2 截获消息

    有些游戏的响应机制比较简单，是基于消息的，或者用什么定时器的东西。这个时候你就可以用拦截消息来实现一些有趣的功能了。

    我们拦截消息使用的也是hook技术，里面包括了键盘消息，鼠标消息，系统消息，日志等，别的对我们没有什么大的用处，我们只用拦截消息的回调函数就可以 了，这个不会让我写例子吧。其实这个和上面的一样，都是用SetWindowHook来写的，看看就明白了很简单的。

    至于拦截了以后做什么就是你的事情了，比如在每个定时器消息里面处理一些我们的数据判断，或者在定时器里面在模拟一次定时器，那么有些数据就会处理两次， 呵呵。后果嘛，不一定是好事情哦，呵呵，不过如果数据计算放在客户端的游戏就可以真的改变数据了，呵呵，试试看吧。用途还有很多，自己想也可以想出来的， 呵呵。

    2.3 拦截Socket包

    这个技术难度要比原来的高很多。

    首先我们要替换WinSock.DLL或者WinSock32.DLL，我们写的替换函数要和原来的函数一致才行，就是说它的函数输出什么样的，我们也要 输出什么样子的函数，而且参数，参数顺序都要一样才行，然后在我们的函数里面调用真正的WinSock32.DLL里面的函数就可以了。

    首先：我们可以替换动态库到系统路径。

    其次：我们应用程序启动的时候可以加载原有的动态库，用这个函数LoadLibary然后定位函数入口用GetProcAddress函数获得每个真正Socket函数的入口地址。

    当游戏进行的时候它会调用我们的动态库，然后从我们的动态库中处理完毕后才跳转到真正动态库的函数地址，这样我们就可以在里面处理自己的数据了，应该是一 切数据。呵呵，兴奋吧，拦截了数据包我们还要分析之后才能进行正确的应答，不要以为这样工作就完成了，还早呢。等分析完毕以后我们还要仿真应答机制来和服 务器通信，一个不小心就会被封号。

    分析数据才是工作量的来源呢，游戏每次升级有可能加密方式会有所改变，因此我们写外挂的人都是亡命之徒啊，被人愚弄了还不知道。

    2.4 截获API

    上面的技术如果可以灵活运用的话我们就不用截获API函数了，其实这种技术是一种补充技术。比如我们需要截获Socket以外的函数作为我们的用途，我们就要用这个技术了，其实我们也可以用它直接拦截在Socket中的函数，这样更直接。

    现在拦截API的教程到处都是，我就不列举了，我用的比较习惯的方法是根据输入节进行拦截的，这个方法可以用到任何一种操作系统上，比如Windows 98/2000等，有些方法不是跨平台的，我不建议使用。这个技术大家可以参考《Windows核心编程》里面的545页开始的内容来学习，如果是 Win98系统可以用“Windows系统奥秘”那个最后一章来学习。

    网络游戏通讯模型初探

    [文章导读]本文就将围绕三个主题来给大家讲述一下网络游戏的网络互连实现方法

    序言

    网络游戏，作为游戏与网络有机结合的产物，把玩家带入了新的娱乐领域。网络游戏在中国开始发展至今也仅有3，4年的历史，跟已经拥有几十年开发历史的单机游戏相比，网络游戏还是非常年轻的。当然，它的形成也是根据历史变化而产生的可以说没有互联网的 兴起，也就没有网络游戏的诞生。作为新兴产物，网络游戏的开发对广大开发者来说更加神秘，对于一个未知领域，开发者可能更需要了解的是网络游戏与普通单机 游戏有何区别，网络游戏如何将玩家们连接起来，以及如何为玩家提供一个互动的娱乐环境。本文就将围绕这三个主题来给大家讲述一下网络游戏的网络互连实现方 法。

    网络游戏与单机游戏

    说到网络游戏，不得不让人联想到单机游戏，实际上网络游戏的实质脱离不了单机游戏的制作思想，网络游戏和单机游戏的差别大家可以很直接的想到：不就是可以 多人连线吗？没错，但如何实现这些功能，如何把网络连线合理的融合进单机游戏，就是我们下面要讨论的内容。在了解网络互连具体实现之前，我们先来了解一下 单机与网络它们各自的运行流程，只有了解这些，你才能深入网络游戏开发的核心。

    现在先让我们来看一下普通单机游戏的简化执行流程：

Initialize() // 初始化模块
{
　初始化游戏数据;
}
Game() // 游戏循环部分
{
　绘制游戏场景、人物以及其它元素;
　获取用户操作输入;
　switch( 用户输入数据)
　{
　　case 移动:
　　{
　　　处理人物移动;
　　}
　　break;
　　case 攻击:
　　{
　　　处理攻击逻辑:
　　}
　　break;
　　...
　　其它处理响应;
　　...
　　default:
　　　break;
　}
　游戏的NPC等逻辑AI处理;
}
Exit() // 游戏结束
{
　释放游戏数据;
　离开游戏;
}

    我们来说明一下上面单机游戏的流程。首先，不管是游戏软件还是其他应用软件，初始化部分必不可少，这里需要对游戏的数据进行初始化，包括图像、声音以及一 些必备的数据。接下来，我们的游戏对场景、人物以及其他元素进行循环绘制，把游戏世界展现给玩家，同时接收玩家的输入操作，并根据操作来做出响应，此外， 游戏还需要对NPC以及一些逻辑AI进行处理。最后，游戏数据被释放，游戏结束。

    网络游戏与单机游戏有一个很显著的差别，就是网络游戏除了一个供操作游戏的用户界面平台（如单机游戏）外，还需要一个用于连接所有用户，并为所有用户提供数据服务的服务器，从某些角度来看，游戏服务器就像一个大型的数据库，

    提供数据以及数据逻辑交互的功能。让我们来看看一个简单的网络游戏模型执行流程：

    客户机：

Login()// 登入模块
{
　初始化游戏数据;
　获取用户输入的用户和密码;
　与服务器创建网络连接;
　发送至服务器进行用户验证;
　...
　等待服务器确认消息;
　...
　获得服务器反馈的登入消息;
　if( 成立 )
　　进入游戏;
　else
　　提示用户登入错误并重新接受用户登入;
}
Game()// 游戏循环部分
{
　绘制游戏场景、人物以及其它元素;
　获取用户操作输入;
　将用户的操作发送至服务器;
　...
　等待服务器的消息;
　...
　接收服务器的反馈信息;
　switch( 服务器反馈的消息数据 )
　{
　　case 本地玩家移动的消息:
　　{
　　　if( 允许本地玩家移动 )
　　　　客户机处理人物移动;
　　　else
　　　　客户机保持原有状态;
　　}
　　　break;
　　case 其他玩家/NPC的移动消息:
　　{
　　　根据服务器的反馈信息进行其他玩家或者NPC的移动处理;
　　}
　　break;
　　case 新玩家加入游戏:
　　{
　　　在客户机中添加显示此玩家;
　　}
　　　break;
　　case 玩家离开游戏:
　　{
　　　在客户机中销毁此玩家数据;
　　}
　　　break;
　　...
　　其它消息类型处理;
　　...　
　　default:
　　　break;
　}
}
Exit()// 游戏结束
{
　发送离开消息给服务器;
　...
　等待服务器确认;
　...
　得到服务器确认消息;
　与服务器断开连接;
　释放游戏数据;
　离开游戏;
}

　　服务器：

Listen()　　// 游戏服务器等待玩家连接模块
{
　...
　等待用户的登入信息;
　...
　接收到用户登入信息;
　分析用户名和密码是否符合;
　if( 符合 )
　{
　　发送确认允许进入游戏消息给客户机;　
　　把此玩家进入游戏的消息发布给场景中所有玩家;
　　把此玩家添加到服务器场景中;
　}
　else
　{
　　断开与客户机的连接;
　}
}
Game()　// 游戏服务器循环部分
{
　...
　等待场景中玩家的操作输入;
　...
　接收到某玩家的移动输入或NPC的移动逻辑输入;
　// 此处只以移动为例
　进行此玩家/NPC在地图场景是否可移动的逻辑判断;

　if( 可移动 )
　{
　　对此玩家/NPC进行服务器移动处理;
　　发送移动消息给客户机;
　　发送此玩家的移动消息给场景上所有玩家;
　}
　else
　　发送不可移动消息给客户机;
}
Exit()　　// 游戏服务＝器结束
{
　接收到玩家离开消息;
　将此消息发送给场景中所有玩家;
　发送允许离开的信息;
　将玩家数据存入数据库;
　注销此玩家在服务器内存中的数据;
}
}

    让我们来说明一下上面简单网络游戏模型的运行机制。先来讲讲服务器端，这里服务器端分为三个部分（实际上一个完整的网络游戏远不止这些）：登入模块、游戏 模块和登出模块。登入模块用于监听网络游戏客户端发送过来的网络连接消息，并且验证其合法性，然后在服务器中创建这个玩家并且把玩家带领到游戏模块中； 游戏模块则提供给玩家用户实际的应用服务，我们在后面会详细介绍这个部分； 在得到玩家要离开游戏的消息后，登出模块则会把玩家从服务器中删除，并且把玩家的属性数据保存到服务器数据库中，如： 经验值、等级、生命值等。

    接下来让我们看看网络游戏的客户端。这时候，客户端不再像单机游戏一样，初始化数据后直接进入游戏，而是在与服务器创建连接，并且获得许可的前提下才进入 游戏。除此之外，网络游戏的客户端游戏进程需要不断与服务器进行通讯，通过与服务器交换数据来确定当前游戏的状态，例如其他玩家的位置变化、物品掉落情 况。同样，在离开游戏时，客户端会向服务器告知此玩家用户离开，以便于服务器做出相应处理。

    以上用简单的伪代码给大家阐述了单机游戏与网络游戏的执行流程，大家应该可以清楚看出两者的差别，以及两者间相互的关系。我们可以换个角度考虑，网络游戏 就是把单机游戏的逻辑运算部分搬移到游戏服务器中进行处理，然后把处理结果（包括其他玩家数据）通过游戏服务器返回给连接的玩家。

    网络互连

    在了解了网络游戏基本形态之后，让我们进入真正的实际应用部分。首先，作为网络游戏，除了常规的单机游戏所必需的东西之外，我们还需要增加一个网络通讯模块，当然，这也是网络游戏较为主要的部分，我们来讨论一下如何实现网络的通讯模块。

    一个完善的网络通讯模块涉及面相当广，本文仅对较为基本的处理方式进行讨论。网络游戏是由客户端和服务器组成，相应也需要两种不同的网络通讯处理方式，不 过也有相同之处，我们先就它们的共同点来进行介绍。我们这里以Microsoft Windows 2000 [2000 Server]作为开发平台，并且使用Winsock作为网络接口（可能一些朋友会考虑使用DirectPlay来进行网络通讯，不过对于当前在线游 戏，DirectPlay并不适合，具体原因这里就不做讨论了）。

    确定好平台与接口后，我们开始进行网络连接创建之前的一些必要的初始化工作，这部分无论是客户端或者服务器都需要进行。让我们看看下面的代码片段：

WORD wVersionRequested;
WSADATAwsaData;
wVersionRequested MAKEWORD(1, 1);
if( WSAStartup( wVersionRequested, &wsaData ) !0 )
{
　Failed( WinSock Version Error!" );
}
　　上面通过调用Windows的socket API函数来初始化网络设备，接下来进行网络Socket的创建，代码片段如下：

SOCKET sSocket socket( AF_INET, m_lProtocol, 0 );
if( sSocket == INVALID_SOCKET )
{
　Failed( "WinSocket Create Error!" );
}

    这里需要说明，客户端和服务端所需要的Socket连接数量是不同的，客户端只需要一个Socket连接足以满足游戏的需要，而服务端必须为每个玩家用户 创建一个用于通讯的Socket连接。当然，并不是说如果服务器上没有玩家那就不需要创建Socket连接，服务器端在启动之时会生成一个特殊的 Socket用来对玩家创建与服务器连接的请求进行响应，等介绍网络监听部分后会有更详细说明。

    有初始化与创建必然就有释放与删除，让我们看看下面的释放部分：

if( sSocket != INVALID_SOCKET )
{
　closesocket( sSocket );
}
if( WSACleanup() != 0 )
{
　Warning( "Can't release Winsocket" );
}

    这里两个步骤分别对前面所作的创建初始化进行了相应释放。

    接下来看看服务器端的一个网络执行处理，这里我们假设服务器端已经创建好一个Socket供使用，我们要做的就是让这个Socket变成监听网络连接请求的专用接口，看看下面代码片段：

SOCKADDR_IN addr;
memset( &addr, 0, sizeof(addr) );
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = htonl( INADDR_ANY );
addr.sin_port = htons( Port ); 　// Port为要监听的端口号
// 绑定socket
if( bind( sSocket, (SOCKADDR*)&addr, sizeof(addr) ) == SOCKET_ERROR )
{
　Failed( "WinSocket Bind Error!");
}
// 进行监听
if( listen( sSocket, SOMAXCONN ) == SOCKET_ERROR )
{
　Failed( "WinSocket Listen Error!");
}

    这里使用的是阻塞式通讯处理，此时程序将处于等待玩家用户连接的状态，倘若这时候有客户端连接进来，则通过accept（）来创建针对此玩家用户的Socket连接，代码片段如下：

sockaddraddrServer;
int nLen sizeof( addrServer );
SOCKET sPlayerSocket accept( sSocket, &addrServer, &nLen );
if( sPlayerSocket == INVALID_SOCKET )
{
　Failed( WinSocket Accept Error!");
}

    这里我们创建了sPlayerSocket连接，此后游戏服务器与这个玩家用户的通讯全部通过此Socket进行，到这里为止，我们服务器已经有了接受玩家用户连接的功能，现在让我们来看看游戏客户端是如何连接到游戏服务器上，代码片段如下：

SOCKADDR_IN addr;
memset( &addr, 0, sizeof(addr) );
addr.sin_family = AF_INET;// 要连接的游戏服务器端口号
addr.sin_addr.s_addr = inet_addr( IP );// 要连接的游戏服务器IP地址，
addr.sin_port = htons( Port );//到此，客户端和服务器已经有了通讯的桥梁，
//接下来就是进行数据的发送和接收：
connect( sSocket, (SOCKADDR*)&addr, sizeof(addr) );
if( send( sSocket, pBuffer, lLength, 0 ) == SOCKET_ERROR )
{
　Failed( "WinSocket Send Error!");
}


    这里的pBuffer为要发送的数据缓冲指针，lLength为需要发送的数据长度，通过这支Socket API函数，我们无论在客户端或者服务端都可以进行数据的发送工作，同时，我们可以通过recv（）这支Socket API函数来进行数据接收：

lLength, 0 ) == SOCKET_ERROR )
{
　Failed( "WinSocket Recv Error!");
}

    其中pBuffer用来存储获取的网络数据缓冲，lLength则为需要获取的数据长度。

    现在，我们已经了解了一些网络互连的基本知识，但作为网络游戏，如此简单的连接方式是无法满足网络游戏中百人千人同时在线的，我们需要更合理容错性更强的网络通讯处理方式，当然，我们需要先了解一下网络游戏对网络通讯的需求是怎样的。

    大家知道，游戏需要不断循环处理游戏中的逻辑并进行游戏世界的绘制，上面所介绍的Winsock处理方式均是以阻塞方式进行，这样就违背了游戏的执行本 质，可以想象，在客户端连接到服务器的过程中，你的游戏不能得到控制，这时如果玩家想取消连接或者做其他处理，甚至显示一个最基本的动态连接提示都不行。

    所以我们需要用其他方式来处理网络通讯，使其不会与游戏主线相冲突，可能大家都会想到： 创建一个网络线程来处理不就可以了？没错，我们可以创建一个专门用于网络通讯的子线程来解决这个问题。当然，我们游戏中多了一个线程，我们就需要做更多的 考虑，让我们来看看如何创建网络通讯线程。

    在Windows系统中，我们可以通过CreateThread（）函数来进行线程的创建，看看下面的代码片段：

DWORD dwThreadID;
HANDLE hThread = CreateThread( NULL, 0, NetThread/*网络线程函式*/, sSocket, 0, &dwThreadID );
if( hThread == NULL )
{
　Failed( "WinSocket Thread Create Error!");
}
　　这里我们创建了一个线程，同时将我们的Socket传入线程函数：

DWORD WINAPINetThread(LPVOID lParam)

{
　SOCKET sSocket (SOCKET)lParam;
　...
　return 0;
}

    NetThread就是我们将来用于处理网络通讯的网络线程。那么，我们又如何把Socket的处理引入线程中？

    看看下面的代码片段：

HANDLE hEvent;
hEvent = CreateEvent(NULL,0,0,0);
// 设置异步通讯
if( WSAEventSelect( sSocket, hEvent,
FD_ACCEPT|FD_CONNECT|FD_READ|FD_WRITE|FD_CLOSE ) ==SOCKET_ERROR )
{
　Failed( "WinSocket EventSelect Error!");
}

    通过上面的设置之后，WinSock API函数均会以非阻塞方式运行，也就是函数执行后会立即返回，这时网络通讯会以事件方式存储于hEvent，而不会停顿整支程式。

    完成了上面的步骤之后，我们需要对事件进行响应与处理，让我们看看如何在网络线程中获得网络通讯所产生的事件消息：

WSAEnumNetworkEvents( sSocket, hEvent, &SocketEvents );
if( SocketEvents.lNetworkEvents != 0 )
{
　switch( SocketEvents.lNetworkEvents )
　{
　　case FD_ACCEPT:
　　　WSANETWORKEVENTS SocketEvents;
　　　break;
　　case FD_CONNECT:
　　{
　　　if( SocketEvents.iErrorCode[FD_CONNECT_BIT] == 0)
　　　// 连接成功 　
　　　{
　　　// 连接成功后通知主线程（游戏线程）进行处理
　　　}
　　}
　　　break;
　　case FD_READ:
　　// 获取网络数据
　　{
　　　if( recv( sSocket, pBuffer, lLength, 0) == SOCKET_ERROR )
　　　{
　　　　Failed( "WinSocket Recv Error!");
　　　}
　　}
　　　break;
　　case FD_WRITE:
　　　break;
　　case FD_CLOSE:
　　　// 通知主线程（游戏线程）， 网络已经断开
　　　break;
　　default:
}
}

    这里仅对网络连接（FD_CONNECT） 和读取数据（FD_READ） 进行了简单模拟操作，但实际中网络线程接收到事件消息后，会对数据进行组织整理，然后再将数据回传给我们的游戏主线程使用，游戏主线程再将处理过的数据发 送出去，这样一个往返就构成了我们网络游戏中的数据通讯，是让网络游戏动起来的最基本要素。

    最后，我们来谈谈关于网络数据包（数据封包）的组织，网络游戏的数据包是游戏数据通讯的最基本单位，网络游戏一般不会用字节流的方式来进行数据传输，一个 数据封包也可以看作是一条消息指令，在游戏进行中，服务器和客户端会不停的发送和接收这些消息包，然后将消息包解析转换为真正所要表达的指令意义并执行。

    互动与管理

    说到互动，对于玩家来说是与其他玩家的交流，但对于计算机而言，实现互动也就是实现数据消息的相互传递。前面我们已经了解过网络通讯的基本概念，它构成了 互动的最基本条件，接下来我们需要在这个网络层面上进行数据的通讯。遗憾的是，计算机并不懂得如何表达玩家之间的交流，因此我们需要提供一套可让计算机了 解的指令组织和解析机制，也就是对我们上面简单提到的网络数据包（数据封包）的处理机制。

    为了能够更简单的给大家阐述网络数据包的组织形式，我们以一个聊天处理模块来进行讨论，看看下面的代码结构：

struct tagMessage{
　long lType;
　long lPlayerID;
};
// 消息指令
// 指令相关的玩家标识
char strTalk[256]; // 消息内容

    上面是抽象出来的一个极为简单的消息包结构，我们先来谈谈其各个数据域的用途：首先，lType 是消息指令的类型，这是最为基本的消息标识，这个标识用来告诉服务器或客户端这条指令的具体用途，以便于服务器或客户端做出相应处理。lPlayerID 被作为玩家的标识。大家知道，一个玩家在机器内部实际上也就是一堆数据，特别是在游戏服务器中，可能有成千上万个玩家，这时候我们需要一个标记来区分玩 家，这样就可以迅速找到特定玩家，并将通讯数据应用于其上。

    strTalk 是我们要传递的聊天数据，这部分才是真正的数据实体，前面的参数只是数据实体应用范围的限定。

    在组织完数据之后，紧接着就是把这个结构体数据通过Socket 连接发送出去和接收进来。这里我们要了解，网络在进行数据传输过程中，它并不关心数据采用的数据结构，这就需要我们把数据结构转换为二进制数据码进行发 送，在接收方，我们再将这些二进制数据码转换回程序使用的相应数据结构。让我们来看看如何实现：

tagMessageMsg;
Msg.lTypeMSG_CHAT;
Msg.lPlayerID 1000;
strcpy( &Msg.strTalk, "聊天信息" );

    首先，我们假设已经组织好一个数据包，这里MSG_CHAT 是我们自行定义的标识符，当然，这个标识符在服务器和客户端要统一。玩家的ID 则根据游戏需要来进行设置，这里1000 只作为假设，现在继续：

char* p = (char*)&Msg;
long lLength = sizeof( tagMessage );
send( sSocket, p, lLength );
// 获取数据结构的长度

    我们通过强行转换把结构体转变为char 类型的数据指针，这样就可以通过这个指针来进行流式数据处理，这里通过

    sizeof（） 获得结构体长度，然后用WinSock 的Send（） 函数将数据发送出去。

    接下来看看如何接收数据：

long lLength = sizeof( tagMessage );
char* Buffer = new char[lLength];
recv( sSocket, Buffer, lLength );
tagMessage* p = (tagMessage*)Buffer;
// 获取数据

    在通过WinSock 的recv（） 函数获取网络数据之后，我们同样通过强行转换把获取出来的缓冲数据转换为相应结构体，这样就可以方便地对数据进行访问。（注：强行转换仅仅作为数据转换的 一种手段，实际应用中有更多可选方式，这里只为简洁地说明逻辑）谈到此处，不得不提到服务器/ 客户端如何去筛选处理各种消息以及如何对通讯数据包进行管理。无论是服务器还是客户端，在收到网络消息的时候，通过上面的数据解析之后，还必须对消息类型 进行一次筛选和派分，简单来说就是类似Windows 的消息循环，不同消息进行不同处理。这可以通过一个switch 语句（熟悉Windows 消息循环的朋友相信已经明白此意），基于消

    息封包里的lType 信息，对消息进行区分处理，考虑如下代码片段：

switch( p->lType ) // 这里的p->lType为我们解析出来的消息类型标识
{
　case MSG_CHAT: // 聊天消息
　　break;
　case MSG_MOVE: // 玩家移动消息
　　break;
　case MSG_EXIT: // 玩家离开消息
　　break;
　default:
　　break;
}

    面片段中的MSG_MOVE 和MSG_EXIT 都是我们虚拟的消息标识（一个真实游戏中的标识可能会有上百个，这就需要考虑优化和优先消息处理问题）。此外，一个网络游戏服务器面对的是成百上千的连接 用户，我们还需要一些合理的数据组织管理方式来进行相关处理。普通的单体游戏服务器，可能会因为当机或者用户过多而导致整个游戏网络瘫痪，而这也就引入分 组服务器机制，我们把服务器分开进行数据的分布式处理。

    我们把每个模块提取出来，做成专用的服务器系统，然后建立一个连接所有服务器的数据中心来进行数据交互，这里每个模块均与数据中心创建了连接，保证了每个 模块的相关性，同时玩家转变为与当前提供服务的服务器进行连接通讯，这样就可以缓解单独一台服务器所承受的负担，把压力分散到多台服务器上，同时保证了数 据的统一，而且就算某台服务因为异常而当机也不会影响其他模块的游戏玩家，从而提高了整体稳定性。分组式服务器缓解了服务器的压力，但也带来了服务器调度 问题，分组式服务器需要对服务器跳转进行处理，就以一个玩家进行游戏场景跳转作为讨论基础：假设有一玩家处于游戏场景A，他想从场景A 跳转到场景B，在游戏中，我们称之场景切换，这时玩家就会触发跳转需求，比如走到了场景中的切换点，这样服务器就把玩家数据从"游戏场景A 服务器"删除，同时在"游戏场景B 服务器"中把玩家建立起来。

    这里描述了场景切换的简单模型，当中处理还有很多步骤，不过通过这样的思考相信大家可以派生出很多应用技巧。

    不过需要注意的是，在场景切换或者说模块间切换的时候，需要切实考虑好数据的传输安全以及逻辑合理性，否则切换很可能会成为将来玩家复制物品的桥梁。

    总结

    本篇讲述的都是通过一些简单的过程来进行网络游戏通讯，提供了一个制作的思路，虽然具体实现起来还有许多要做 ，但只要顺着这个思路去扩展、去完善，相信大家很快就能够编写出自己的网络通讯模块。由于时间仓促，本文在很多细节方面都有省略，文中若有错误之处也望大 家见谅

以下六点，将助你分清楚哪些我们可以努力，哪些我们不值得努力，弄明白实时游戏中同步问题关键之所在，巧妙的化解与规避游戏，最终在适合普遍用户网络环境中(200ms)，实现实时快速互动游戏：

1. 基本情况：
   (A) 网络性能指标一：带宽，限制了实时游戏的人数容量
   (B) 网络性能指标二：延时，决定了实时游戏的最低反应时间

2. 两个基本原则：
   (A) 让所有的用户屏幕上面表现出完全不同的表象是完全没有问题的。
   (B) 把这些完全不同表象完全柔和在一个统一的逻辑中也是完全没有问题的。

3. 同步的十二条应对策略：
   (A) 最大可能减少游戏中的数据传输
   (B) 将阻塞通信放到线程池中实现
   (C) 永远不要为了等待某个数据而不让游戏进行下去
   (D) 利用预测和插值改进游戏的效果
   (E) 当使用预测插值的时候传送的数据不仅包括坐标，还需要速度和加速度
   (F) 将输入数据枷锁或者队列化(例如键盘消息队列)，直到下次发送数据的时刻，传统的方法是在固定的时间(发送数据前)检测键盘，在游戏的原理上隐藏延时
   (G) 使用事件调度表，将需要在所有用户客户端同时发生的事件，提前广播到所有用户
   (H) 使用多次攻击来杀死一个精灵，尽量减少一次性的、确定性的、延时敏感的事件
   (I) 延长子弹或者火箭在空中飞行的时间(在其飞行的同时，在所有客户端进行预测插值)
   (J) 所有物体从一个地方移动到另外一个地方都需要时间，避免诸如“瞬间移动”的设计
   (K) 尽量使游戏中所有精灵，飞船或者其他物体，都按照可预测的轨迹运行，比如在移动中增加惯性
   (L) 充分发挥创造力，尽最大可能的合并游戏中前后相关的事件，合并游戏中存在的延时此问题，需要在技术上改进的同时也需要策划有所重视，规避一些影响较大的设计，巧妙的隐藏"延时"

4. 同步问题现状：
   (A) 重视程度不够：很多人尚未意识到此问题的存在，曾有公司花半年时间打算做一款“松鼠大战”的网络版。
   (B) 技术上无彻底解决方案：对于多数程序员，单机游戏技术善未成熟就匆匆步入网络时代。
   (C) 研究这个技术需要条件：需要有实力的公司才能提供，无此条件，即便有能力的程序员也无法成功。

5. 目前网游的三大技术难题：
   (A) 服务器的响应问题：如何使服务器在支持越来越多的人数的情况下提供最高的响应。
   (B) 同步问题：如何在有限的网络响应情况下，实现快速实时类游戏，提供最完美的交互。
   (C) 服务器分布式问题：如何在统一用户数据的情况下，利用分部式将各个分散的“世界”统一到一个“世界”中。
   谁能真正解决好以上三个问题，配合策划在设计上的突破，将使其他人在至少两年内无法超越。
  
6. 相关补充：
   (A) 网格技术现在还是抄作，真正用到游戏中，还有很多技术难点需要突破(比如：目前网格的单位计算时间是以秒计算).
   (B) 其实与很多人想法相反的是现在3D技术早已不是主要的矛盾。而现在国内外对于以上三个问题可以说处于同一个起跑线上，完全有机会取得先机。
   (C) 现在解决同步问题已经很紧迫，而同时所需要的环境也已经成熟，只要有所关注，半年之内可以得出较成熟的结论

那么具体怎么解决呢？再下一步怎么办？
这就得自己去实践了，我只说这么多了，哈哈，不然又教懒了那些成天再网上搜方案的人。

MMO的同步策略目前已经没有什么秘密可言了，简单叙述下各要素：


MMO人行走：MMO中如果是鼠标点击行走传目的地+中间寻路接点就行了，服务器简单验证一下。如果是键盘控制行走的话，需要做简单的预测插值。

MMO打怪：要看怎么个打法，客户端根本不必管服务端什么时候传来消息，直接演示动画就行了，最好把被砍的过程动画做长一点，可以在播放动画的过程中等待服务器传过来的延迟敏感事件，比如--该人已死。这样处理起来比较容易，最重要的是客户端看起来要流畅。

MMO插值：所谓“把不同表象柔和在一起”算法很多，简单的可以参考DR，位置不同的时候可以做一次线性插值，直接把人拉扯过去，或者二次线形插值，做一条平滑的曲线修正，看具体项目选择了。

时钟：就是时钟同步，所有时钟都是以“贞”为单位的，服务器主逻辑循环可以是5-10fps，多则无益，客户端同样维持一个和服务端频率相同的消息同步贞。

时间贞：把ping值加到时间计算里面是多余的，按贞计算的话，服务端告诉客户端在n贞发生xx事件的时候，客户端收到的时候如果客户端贞数大于n，说明是发生过了的，那么做插值，如果小于n，说明是未来发生的，那么加入时间表。

1 游戏中的行走，则是一个需要同步的重头戏，当今游戏分成两种同步方式，一种是以服务器端为准，如果发现客户端的坐标和服务器的坐标不符合的话，则拉回。这点的好处是可以弥补瞬移外挂的出现，但在网络环境差的情况下，则出现游戏不流畅。

所 以，我比较推荐使用以客户端计算为准的方法（当然是我因为我这个游戏对游戏流畅性要求很高），客户端向服务器发送计算好的数据，服务器经过一定的预测判 断，广播给其他玩家，这个虽然是能引起和wow一样的问题，瞬移外挂，但完全可以从游戏设计方面进行根本避免。（这里就不谈策划方面的问题了）

2 游戏的战斗，战斗的同步性要求也相当高，这里我也引用楼主说的，在固定时间检测键盘，以一定频率发送攻击消息，这里有一个关键，就是服务器和客户端都进行 攻击判定，即使服务器中没有攻击判定成功，但在客户端判定成功，也要播放攻击效果。不过一切计算效果以服务器为准。这是一个欺骗玩家的手段。

那么网络游戏中，是否真的无法模拟实现这种模拟呢？

首先我们来看看模拟此种操作会带来什么样的麻烦：

1，服务器必须trace火球的运行轨迹，乍一想，挺慢的。

2，网络延迟，传过来有延迟，传过去有延迟，延迟还不稳定，麻烦。

3，都有两点解决不了了，接下来不愿意再想了。

呵呵，实际上呢，对火球的模拟比对人物运动的模拟要轻松很多，原因很简单，火球的方向不会变。下面来看看具体用什么样的结构来实现：

不知道大家是否还记得我去年这个时候提到过的Dead Reckoning算法，我们要模拟火球运动的关键就在于一个叫Moving Objects Tracing Server的服务器程序，这个服务器是干什么的呢。这个服务器接收主游戏服务器发过来的注册事件的信息，比如有个玩家，开始移动了，那么主游戏服务器就 把该玩家的运动PDU，包括方向，速度，加速度，起点发给MOTS (Moving Objects Tracing Server)，然后MOTS自己开始对其运行进行模拟，当游戏服务器发来第二个PDU包的时候，则对各个物件的位置进行修正，并重新开始模拟。那么，我 们模拟的目的是什么呢？当然是发生某些事件，比如说碰撞，或者掉入地图的某个陷阱的时候，会将该事件回发给主逻辑服务器。然后逻辑服务器来处理该事件。

那么，对于火球的处理，也和处理其他玩家的同步一样，当接收到玩家的发火球的指令以后，产生一个火球，并指定其PDU信息，在MOTS上注册该个运 动物 体。当MOTS自行模拟到这个物体和其他玩家或者NPC物体产生碰撞，则通知主逻辑服务器，然后主逻辑服务器产生相应的动作。

那么关于延迟呢？有些人也许会说，比如说前面有个火球，我本地操纵的小人其实躲过去了，但是因为网络延迟，在服务器上我并没有躲过去，那么怎么算？ 呵呵， 不知道大家玩过星际没有，有没有发现在星际中玩多人连线模式的时候，有一点最特别的地方，就是控制一个小兵的时候，点了地图上的某个位置，但是小兵并不会 马上开始移动，而是有一定的延迟，但是这一小点延迟并不能掩盖星际的经典，同样的理论用到这里也成立。对于客户端的控制，当玩家操纵的主角改变PDU信息 的时候，确保信息发送到服务器之后，再开始处理本地的操作指令，这样就能保证本地的预测和服务器的预测几乎是没有什么误差的，即使有很小的误差产生，以服 务器为主，这样玩家也不会有太大的抱怨。

————————————————————————————————————————-

网络游戏同步详解之一

同步在网络游戏中是非常重要的，它保证了每个玩家在屏幕上看到的东西大体是一样的。其实呢，解决同步问题的最简单的方法就是把每个玩家的动作都向其 他玩家广播一遍，这里其实就存在两个问题：1，向哪些玩家广播，广播哪些消息。2，如果网络延迟怎么办。事实上呢，第一个问题是个非常简单的问题，不过之 所以我提出这个问题来，是提醒大家在设计自己的消息结构的时候，需要把这个因素考虑进去。而对于第二个问题，则是一个挺麻烦的问题，大家可以来看这么个例 子：
比如有一个玩家A向服务器发了条指令，说我现在在P1点，要去P2点。指令发出的时间是T0，服务器收到指令的时间是T1，然后向周围的玩家广播这条 消息，消息的内容是“玩家A从P1到P2”有一个在A附近的玩家B，收到服务器的这则广播的消息的时间是T2，然后开始在客户端上画图，A从P1到P2 点。这个时候就存在一个不同步的问题，玩家A和玩家B的屏幕上显示的画面相差了T2-T1的时间。这个时候怎么办呢？

有个解决方案，我给它取名叫预测拉扯，虽然有些怪异了点，不过基本上大家也能从字面上来理解它的意思。要解决这个问题，首先要定义一个值叫：预 测误差。然后需要在服务器端每个玩家连接的类里面加一项属性，叫TimeModified，然后在玩家登陆的时候，对客户端的时间和服务器的时间进行比 较，得出来的差值保存在TimeModified里面。还是上面的那个例子，服务器广播消息的时候，就根据要广播对象的TimeModified，计算出 一个客户端的CurrentTime，然后在消息头里面包含这个CurrentTime，然后再进行广播。并且同时在玩家A的客户端本地建立一个队列，保 存该条消息，只到获得服务器验证就从未被验证的消息队列里面将该消息删除，如果验证失败，则会被拉扯回P1点。然后当玩家B收到了服务器发过来的消息“玩 家A从P1到P2”这个时候就检查消息里面服务器发出的时间和本地时间做比较，如果大于定义的预测误差，就算出在T2这个时间，玩家A的屏幕上走到的地点 P3，然后把玩家B屏幕上的玩家A直接拉扯到P3，再继续走下去，这样就能保证同步。更进一步，为了保证客户端运行起来更加smooth，我并不推荐直接 把玩家拉扯过去，而是算出P3偏后的一点P4，然后用(P4-P1)/T(P4-P3)来算出一个很快的速度S，然后让玩家A用速度S快速移动到P4，这 样的处理方法是比较合理的，这种解决方案的原形在国际上被称为（Full plesiochronous），当然，该原形被我篡改了很多来适应网络游戏的同步，所以而变成所谓的：预测拉扯。

另外一个解决方案，我给它取名叫验证同步，听名字也知道，大体的意思就是每条指令在经过 服务器验证通过了以后再执行动作。具体的思路如下：首先 也需要在每个玩家连接类型里面定义一个 TimeModified，然后在客户端响应玩家鼠标行走的同时，客户端并不会先行走动，而是发一条走路的指令给服务器，然后等待服务器的验证。服务器接 受到这条消息以后，进行逻辑层的验证，然后计算出需要广播的范围，包括玩家A在内，根据各个客户端不同的TimeModified生成不同的消息头，开始 广播，这个时候这个玩家的走路信息就是完全同步的了。这个方法的优点是能保证各个客户端之间绝对的同步，缺点是当网络延迟比较大的时候，玩家的客户端的行 为会变得比较不流畅，给玩家带来很不爽的感觉。该种解决方案的原形在国际上被称为（Hierarchical master-slave synchronization），80年代以后被广泛应用于网络的各个领域。

最后一种解决方案是一种理想化的解决方案，在国际上被称为Mutual synchronization，是一种对未来网络的前景的良好预测出来的解决方案。这里之所以要提这个方案，并不是说我们已经完全的实现了这种方案，而 只是在网络游戏领域的某些方面应用到这种方案的某些思想。我对该种方案取名为：半服务器同步。大体的设计思路如下：

首先客户端需要在登陆世界的时候建立很多张广播列表，这些列表在客户端后台和服务器要进行不及时同步，之所以要建立多张列表，是因为要广播的类 型是不止一种的，比如说有local message,有remote message,还有global message 等等，这些列表都需要在客户端登陆的时候根据服务器发过来的消息建立好。在建立列表的同时，还需要获得每个列表中广播对象的TimeModified，并 且要维护一张完整的用户状态列表在后台，也是不及时的和服务器进行同步，根据本地的用户状态表，可以做到一部分决策由客户端自己来决定，当客户端发送这部 分决策的时候，则直接将最终决策发送到各个广播列表里面的客户端，并对其时间进行校对，保证每个客户端在收到的消息的时间是和根据本地时间进行校对过的。 那么再采用预测拉扯中提到过的计算提前量，提高速度行走过去的方法，将会使同步变得非常的smooth。该方案的优点是不通过服务器，客户端自己之间进行 同步，大大的降低了由于网络延迟而带来的误差，并且由于大部分决策都可以由客户端来做，也大大的降低了服务器的资源。由此带来的弊端就是由于消息和决策权 都放在客户端本地，所以给外挂提供了很大的可乘之机。

综合以上三种关于网络同步派系的优缺点，综合出一套关于网络游戏传输同步的较完整的解决方案，我称它为综合同步法（colligate synchronization）。大体设计思路如下：

首先将服务器需要同步的所有消息从划分一个优先等级，然后按照3/4的比例划分出重要消息和非重要消息，对于非重要消息，把决策权放在客户端，在客户端逻辑上建立相关的决策机构和各种消息缓存区，以及相关的消息缓存区管理机构，如下图所示：

上图简单说明了对于非重要消息，客户端的大体处理流程，其中有一个客户端被动行为值得大家注意，其中包括对服务器发过来的某些验证代码做返回， 来确保消息缓存中的消息和服务器端是一致的，从而有效的防止外挂来篡改本地消息缓存。其中的消息来源是包括本地的客户端响应玩家的消息以及远程服务器传递 过来的消息。

对于重要消息，比如说战斗或者是某些牵扯到玩家一些比较敏感数据的操作，则采用另外一套方案，该方案首先需要在服务器和客户端之间建立一套 Ping System，然后服务器保存和用户的及时的ping值，当ping比较小的时候，响应玩家消息的同时先不进行动作，而是先把该消息反馈给服务器，并且阻 塞，服务器收到该消息，进行逻辑验证之后向所有该详细广播的有效对象进行广播（包括消息发起者），然后客户端收到该消息的验证，才开始执行动作。而当 ping比较大的时候，客户端响应玩家消息的同时立刻进行动作，并且同时把该消息反馈给服务器，值得注意的是这个时候还需要在本地建立一个无验证消息的队 列，把该消息入队，执行动作的同时等待服务器的验证，还需要保存当前状态。服务器收到客户端的请求后，进行逻辑验证，并把消息反馈到各个客户端，带上各个 客户端校对过的本地时间。如果验证通过不过，则通知消息发起者，该消息验证失败，然后客户端自动把已经在进行中的动作取消，恢复原来状态。如果验证通过， 则广播到的各个客户端根据从服务器获得校对时间进行对其进行拉扯，保证在该行为完成之前完成同步。

至此，一个比较成熟的网络游戏的同步机制已经初步建立起来了，接下来的逻辑代码就根据各自不同的游戏风格以及侧重点来写了。

同步是网络游戏最重要的问题，如何同步也牵扯到各个方面的问题，比如说游戏的规模，游戏的类型以及各种各样的方面，对于规模比较大的游戏，在同 步方面可以下很多的工夫，把消息分得十分的细腻，对于不同的消息采用不同的同步机制，而对于规模比较小的游戏，则可以采用大体上一样的同步机制，究竟怎么 样同步，没有个定式，是需要根据自己的不同情况来做出不同的同步决策的网游同步算法之导航推测（Dead Reckoning）算法：

——————————————————————————————————————————

网络游戏同步详解之二

在了解该算法前，我们先来谈谈该算法的一些背景资料。大家都知道，在网络传输的时候，延迟现象是很普遍的，而在基于Server/Client结构 下的网络游戏的同步也就成了很头疼的问题，在保证客户端响应用户本地指令流畅的情况下，没法有效的保证的同步的及时性。同样，在军方也有类似的事情发生， 即使是同一LAN里面的机器，也会因为传输的延迟，导致一些运算的失误，介于此，美国国防部投入了大量的资金用于研究一种比较的好的方案来解决分布式系统 中的延迟问题，特别是一个叫分布式模拟运动（Distributed Interactive Simulation）的系统，这套系统呢，其中就提出了一套号称是Latency Hiding & Bandwidth Reduction的方案，命名为Dead Reckoning。呵呵，来头很大吧，恩，那么我们下面就来看看这套系统的一些观点，以及我们如何把它运用到我们的网络游戏的同步中。

首先，这套同步方案是基于我那篇《网络游戏的同步》一文中的Mutual Synchronization同步方案的，也就是说，它并不是Server/Client结构的，而是基于客户端之间的同步的。下面我们先来说一些本文中将用到的名词概念：
网状网络：客户端之间构成的网络
节点：网状网络中的每个客户端
极限误差：进行同步的时候可能产生的误差的极值

恩，在探讨其原理的之前，我们先来看看我们需要一个什么样的环境。首先，需要一个网状网络，网状网络如何构成呢？当有新节点进入的时候，通知该 网络里面的所有节点，各节点为该客户端在本地创建一个副本，登出的时候，则通知所有节点销毁本地关于该节点的副本。然后每个节点该保存一些什么数据呢？首 先有一个很重要的包需要保存，叫做协议数据包（PDU Protocol Data Unit），PDU包含节点的一些相关的运动信息，比如当前位置，速度，运动方向，或者还有加速度等一些信息。除PDU之外，还有其他信息需要保存，比如 说节点客户端人物的HP，MP之类的。然后，保证每个节点在最少8秒之内要向其它节点广播一次PDU信息。最后，设置一个极限误差值。到此，其环境就算搭 建完成了。下面，我们就来看看相关的具体算法：

假设在节点A有一个小人（路人甲），开始跑路了，这个时候，就像所有的节点广播一次他的PDU信息，包括：速度（S），方向（O），加速度 （A）。那么所有的节点就开始模拟路人甲的运动轨迹和路线，包括节点A本身（这点很重要），同时，路人甲在某某玩家的控制下，会不时的改变一下方向，让其 跑路的路线变得不是那么正规。在跑路的过程中，节点A有一个值在不停的记录着其真实坐标和在后台模拟运动的坐标的差值，当差值大于极限误差的时候，则计算 出当前的速度S，方向O和速度A（算法将在后面介绍），并广播给网络中其他所有节点。其他节点在收到这条消息之后呢，就可以用一些很平滑的移动把路人甲拉 扯过去，然后重新调整模拟跑路的数据，让其继续在后台模拟跑路。

很显然，如果极限误差定义得大了，其他节点看到的偏差就会过大，如果极限偏差定义得小了，网络带宽就会增大。如果定义这个极限误差，就该根据各 种数据的重要性来设计了。如果是回合制的网络游戏，那么在走路上把极限误差定义得大些无所谓，可以减少带宽。但是如果是及时打斗的网络游戏，那么就得把极 限误差定义得小一些，否则会出现某人看到某人老远把自己给砍死的情况。

Dead Reckoning的主要算法有9种，但是只有两种是解决主要问题的，其他的基本上只是针对不同的坐标系的一些不同的算法，这里就不一一介绍了。好，那么我们下面来看传说中的最主要的两种算法：
第一：目标点 = 原点 + 速度 * 时间差
第二：目标点 = 原点 + 速度 * 时间差 + 1/2 * 加速度 * 时间差
呵呵，传说中的算法都是很经典的，虽然我们早在初中物理的时候就学过。

该算法的好处呢，正如它开始所说的，Latency Hiding & Bandwidth Reduction，从原则上解决了网络延迟导致的不同步的问题，并且有效的减少了带宽，不好的地方就是该算法基本上只能使用于移动中的同步，当然，移动 的同步是网络游戏中同步的最大的问题。

该方法结合我在《网络游戏的同步》一文中提出的综合同步法的构架可以基本上解决掉网络游戏中走路同步的问题。相关问题欢迎大家一起讨论。

有关导航推测算法（Dead Reckoning）中的平滑处理：

根据我上篇文章所介绍的，在节点A收到节点B新的PDU包时，如果和A本地的关于B的模拟运动的坐标不一致时，怎么样在A的屏幕上把B拽到新的 PDU包所描叙的点上面去呢，上文中只提了用“很平滑的移动”把B“拉扯”过去，那么实际中应该怎么操作呢？这里介绍四种方法。

第一种方法，我取名叫直接拉扯法，大家听名字也知道，就是直接把B硬生生的拽到新的PDU包所描叙的坐标上去，该方法的好处是：简单。坏处是：看了以下三种方法之后你就不会用这种方法了。

第二种方法，叫直线行走（Linear），即让B从它的当前坐标走直线到新的PDU包所描叙的坐标，行走速度用上文中所介绍的经典算法：
目标点 = 原点 + 速度 * 时间差 + 1/2 * 加速度 * 时间差算出：
首先算出从当前坐标到PDU包中描叙的坐标所需要的时间：
T = Dest( TargetB – OriginB ) / Speed
然后根据新PDU包中所描叙的坐标信息模拟计算出在时间T之后，按照新的PDU包中的运动信息所应该达到的位置：
_TargetB = NewPDU.Speed * T
然后根据当前模拟行动中的B和_TargetB的距离配合时间T算出一个修正过的速度_S：
_S = Dest( _TargetB – OriginB ) / T
然后在画面上让B以速度_S走直线到Target_B，并且在走到之后调整其速度，方向，加速度等信息为新的PDU包中所描叙的。

这种方法呢，非常的土，会让物体在画面上移动起来变得非常的不现实，经常会出现很生硬的拐角，而且对于经常要修改的速度_S，在玩家A的画面上，玩家B的行动会变得非常的诡异。其好处是：比第一种方法要好。

第三种方法，叫二次方程行走（Quadratic），该方法的原理呢，就是在直线行走的过程中，加入二次方程来计算一条曲线路径，让Dest( _TargetB – OriginB )的过程是一条曲线，而不是一条直线，恩，具体的实现方法，就是在Linear方法的计算中，设定一个二次方程，在Dest函数计算距离的时候根据设定的 二次方程来计算，这样一来，可以使B在玩家A屏幕上的移动变得比较的有人性化一些。但是该方法的考虑也是不周全的，仅仅只考虑了TargetB到 _TargetB的方向，而没有考虑新的PDU包中的方向描叙，那么从_TargetB开始模拟行走的时候，仍然是会出现比较生硬的拐角，那么下面提出的 最终解决方案，将彻底解决这个问题。

——————————————————————————————————————————

网络游戏同步详解之三

最后一种方法叫：立方体抖动（Cubic Splines），这个东东比较复杂，它需要四个坐标信息作为它的参数来进行运算，第一个参数Pos1是OriginB，第二个参数Pos2是 OriginB在模拟运行一秒以后的位置，第三个参数Pos3是到达_TargetB前一秒的位置，第四个参数pos4是_TargetB的位置。

Struct pos {
Coordinate X;
Coordinate Y;
}
Pos1 = OriginB
Pos2 = OriginB + V
Pos3 = _TargetB – V
Pos4 = _TargetB
运动轨迹中(x, y)的坐标。
x = At^3 + Bt^2 + Ct + D
y = Et^3 + Ft^2 + Gt + H
（其中时间t的取值范围为0-1，在Pos1的时候为0，在Pos4的时候为1）
x(0-3)代表Pos1-Pos4中x的值，y(0-3)代表Pos1-Pos4中y的值
A = x3 – 3 * x2 +3 * x1 – x0
B = 3 * x2 – 6 * x1 + 3 * x0
C = 3 * x1 – 3 * x0
D = x0
E = y3 – 3 * y2 +3 * y1 – y0
F = 3 * y2 – 6 * y1 + 3 * y0
G = 3 * y1 – 3 * y0
H = y0

上面是公式，那么下面我们来看看如何获得Pos1-Pos4：首先，Pos1和 Pos2的取值会比较容易获得，根据OriginB配合当前的速度和方向可以获得，然而Pos3和Pos4呢，怎么获得呢？如果在从Pos1到Pos4的 过程中有新的PDU到达，那么我们定义它为NewPackage。

Pos3 = NewPackage.X + NewPackage.Y * t + 1/2 * NewPackage.a * t^2
Pos4 = Pos3 – (NewPackage.V + NewPackage.a * t)

如果没有NewPackage的情况下,则Pos3和Pos4按照开始所规定的方法获得。

至此，关于导航推测的算法大致介绍完毕。

原文来自：http://xinsync.xju.edu.cn/index.php/archives/4079

http://canremember.com/?p=10

过去一年中，花了很多时间在考虑服务器架构设计方面的问题。看了大量文章、也研究了不少开源项目，眼界倒是开阔了不少，不过回过头来看，对网游架构设计方面的帮助却是不多。老外还是玩儿console game的多，MMO Games方面涉及的还是不如国内广泛。看看 Massively Multiplayer Games Development 1 & 2 这两本书吧，质量说实话很一般，帮助自然也很有限。当然这也是好事，对国内的研发公司/团队来说，在网游服务器技术方面当然就存在超越老外的可能性，而且在这方面技术超越的机会更大，当然前提是要有积累、要舍得投入，研发人员更要耐得住寂寞、经得起诱惑，在平均每天收到超过3个猎头电话的时候——依然不动心。

上面有点儿扯远了，下面聊聊无缝世界架构（Seamless world server architecture）设计方面的一点儿看法。

先说架构设计的目标——我的看法，服务器组架构设计的目标就是确定各服务器拓补关系和主要的业务逻辑处理方法。主要要解决的问题就是在满足游戏内容设计需要的前提下，如何提高带负载能力的问题。

最简单的架构就是基本的C/S架构，一台Server直接构成一个Cluster，所有Client直接连接这个Server，这个Server完成所有逻辑和数据处理。这架构其实很好，最大的好处就是它架构上的 Simplicity ，Cluster内部的跨进程交互完全被排除，复杂度立刻就降下来了，而且——完全可以实现一个无缝（Seamless world）的游戏世界。但是即使我不说，大家也知道这种单Server架构会有什么问题。不过我们不妨以另外一个角度来看这个Server——一个黑盒子。从系统外部的角度来看，什么样的系统都可以看成一个整体、一个黑盒，而不管系统内部的拓补关系和实现复杂度方面的问题。在不考虑这个系统的实现的前提下，理论上Cluster的处理能力就是由硬件的数量和能力决定的，也就是说一个Server Cluster内包含越多的服务器、服务器越‘快’，那么这个Cluster的处理能力越好、带负载能力越好。那么我们要面对的带负载能力的问题，就是如何高效的利用这些Server的问题，基本上也可以理解为如何提高玩家请求的并发处理能力的问题。

CPU厂商在很久以前就在考虑这方面的问题了，CPU其实也可以看成个黑盒。看看他们用过的技术——流水线（pipeline）技术、多CPU/多核（multicore）技术，以及这些技术的衍生技术。我想了很久让 Server Cluster 内部处理并行的方法、并且有了比较清晰的思路之后，才发现其实早就可以参照CPU厂商的方法。流水线的方法就是把一个指令处理拆分成很多个步骤，这样指令的处理被分解之后就可以部分重叠（相当于变成并发的了）执行。我们的Server Cluster一样可以用这种方法来拆分，我想了个名字——

Services-based Architecture——基于服务的架构。在这种架构内部，我们根据处理数据、逻辑的相关性来划分组内各个服务器的工作任务。例如：位置服务提供物体可见性信息、物品服务处理所有物品相关的逻辑、社会关系服务提供行会家族等等方面的逻辑、战斗服务器只处理战斗相关的逻辑，等等。这样划分的话、逻辑处理的并发就有了可能性。举例来说：A砍B一刀这件事情与C从奸商手里买到一件武器这个事情是完全不相干的，而且这2个请求本来就在不同的服务器上被处理，他们是被不同的Service Server并发处理的。这就是 Services-based Architecture 的并发方法。

基本上，把游戏逻辑的处理拆分成一个个的service，就和设计cpu的时候把机器指令的具体处理拆分，然后设计出一个个流水线单元是一个道理。

Cells-based Architecture——基于cell的架构。每个cell都在不同的物理 server上面运行着完全一样的应用程序服务器，但是他们负责承载不同的游戏场景区域的游戏逻辑。和 services-based arch. 明显不同的就是，每个cell都是个‘在逻辑上完整的’服务器。它得处理物品操作、人物移动、战斗计算等等几乎所有的游戏逻辑。尽管这么做会带来一些（可能是很复杂）的问题，但是它完全是可行的。举例来说：在吴国A砍B一刀显然地和千里之外在越国的C砍D一刀不搭界，他们完全可以被不同的Cell并发地处理。

基本上，这就相当于一个主板上面插多个CPU或者一个CPU但是有多个内核，每个CPU能做的事情都是一样的，而且能一起做。

从一组服务器的角度来看，一般来说，我们的服务器组（Cluster）内都会有登陆验证服务器（Login Server）、持久性数据服务器（DB及DB Proxy）、连接代理服务器（Gate Server、FEP Server、Client Proxy等）以及Auto Patch Server、还有用于集中管理及控制组的服务器等等，由于这些服务器基本上什么样的架构设计都会用到，所以——现在不考虑以上这些服务器，只考虑具体处理游戏逻辑、游戏规则的各个服务器。以此为前提来分析一下 Services-based Architecture 和 Cells-based Architecture 的优缺点。

对Services-based Architecture 的分析
 

基于服务的架构，顾名思义这种架构的实现（程序）会是和服务的具体内容（策划）相关的，这是因为——各种【服务】内容的确定是建立于项目的【需求分析】基础上的，【需求分析】的前提是基本确定了【策划设计】，至少是项目的概要设计。

我想多数做过游戏项目的人都应该对需求变更有很深的感触，每个人都说“开始想做的那个和最后实际做出来的那个不一样”。特别是在项目的早期阶段，团队的不同成员对项目做完之后的样子有相当不同的看法（很可能大家互相都不知道对方怎么看的），这很容易理解，谁也不可能从几页纸几张图就确切地知道这个游戏做完了什么样子，即使不考虑需求变更。涉及到项目开发方法方面的东西这里就不多说了，总之我的看法就是——尽管我们不大可能设计出一个架构能够适应任何的游戏设计，但是不同开发任务间的耦合度显然还是越低越好，基于服务的架构适应需求变更的能力较差。

关于服务耦合
不管如何划分service，不同 service之间都一定存在不同程度的耦合（coupling）关系，不同的 service 之间会有相互依赖关系。而你们的策划设计可能会让这种关系复杂到程序在运行时的状态很难以琢磨的程度。

假设：
服务器组内的战斗处理和物品处理分别由两个不同的服务（器）提供
游戏规则：
人物被攻击后自己携带的物品可能掉落到地上
某些物品掉落后会爆炸
物品在地上爆炸可能伤及周围（半径10米内）人物
人物之间的‘仇恨度’影响战斗数值计算
被攻击时掉落的物品爆炸后伤及的人物，会增加对‘被攻击人’的‘仇恨度’

我想我还能想出很多很多“看上去不算过分”的规则来让这个事情变得复杂无比，很可能你们的策划也在无意中，已经拥有我这种能力 :) 而且他们在写文档时候的表达还多半不如我上面写的清楚，另外，他们还会把这些规则分到很多不同的文档里面去写。好吧，你肯定会想“把这两个服务合二为一好了 ”，实际上不管你想把哪两个（或多个）服务合并为一个服务的时候，都应该先考虑一下当时是为什么把他们独立为不同服务的？

实际上很多这样“看上去不算过分”的规则都会导致service间的频繁交互，所以每个service最好都是stateless service，这样的话情况会好很多，但是对于游戏来说这很难做到。

请求处理的时序问题
服务耦合的问题在不考虑开发复杂度比较高的情况下，还是可以被搞定的，只要脑袋够清醒，愿意花够多的时间，那么还有更难以搞定的么？我看确实还有，如果你对将要面对的问题，了解得足够多的话:)

上面两个序列图描述的是某个玩家做了连续做了两次同样的操作但是很可能得到了不同的结果，当然这些请求都是异步地被处理。问题的关键在于——尽管两次玩家执行的命令一样、顺序一样，甚至时间间隔都一样，但是结果却很不同——因为图（1）里面C2CS::Request_to_attack请求被处理的时候，C2IS::Request_equip_item 这个请求还没有被处理完，但是图（2）显示的情况就不一样了。因为C2IS::Request_equip_item这个操作很可能会改变游戏人物的属性，这个属性又很可能影响attack的结果。这两幅图实际上省略了 Combat Server 与 Item Server 之间的交互过程。但是已经足以说明问题了，每个Service处理每个Request时具体会消耗的时间，是无法在设计时确定的!

谁喜欢这类结果上的不确定性？举个例子：玩家很可能已经装备上了“只能使用1次的魔兽必杀刀”然后攻击了一下魔兽，但是它却没死！这会导致什么样的结果？请自行想象。另外，这种不确定性还会表现为“在项目开发期和运营期的行为差异”，或者“出现某些偶然的奇怪现象”。

那还有解决方案么？有的，其实只要序列化玩家请求的处理，使处理有序进行就可以了。但是又一次的，这会带来新的复杂度——在某个范围（整个服务器组？一个行会？一个队伍？）内，以每个玩家为单位，序列化他（们）的（可能是所有）操作，但是也显而易见，这在某种程度上降低了请求处理的并发性，尽管它对并发性的影响可能只局限于不大（最少是一个玩家）的范围。

对Cells-based Architecture 的分析
 

基于Cell的架构有个明显的优势就是Cell如何划分和你的策划没有关系J这是真的。而且Cell间如何交互可以被放到系统的底层，具体有多底层、多隐蔽（实际上可以隐蔽到对开发上层游戏逻辑的程序员都不可见的程度）要看你的实现如何了。如果做到了某个系统的程序设计与游戏设计完全无关的话，显然，这个系统受到游戏设计变更（需求变更）的影响就会很小很小，甚至会到完全不受影响的程度，当然这是理想情况。

关于跨边界对象交互
在基于Cell的服务器架构里面，实现无缝世界（Seamless World）的主要难点在于实现跨边界对象的交互时会出现的一些问题，因为这些对象在不同的Cell进程里面，这些Cell一般来说是在不同的物理服务器上运行。

无缝世界的特点自然就是无缝，并且因为无缝给玩家带来更好的游戏体验，所以显然我们希望“跨边界对象交互”问题不把事情搞砸，那么这种交互的表现就必须满足稳定、高效的前提。一般来说，高于300ms的延迟对玩家操作来说就属于“明显可见”的程度了，不能让玩家骑着500块RMB买来的虚拟马在一片大草原上面畅快的奔跑的时候，在某个地方突然就被“看不见的墙”给“挡”了一下，因为这“墙”根本看不见，所以会很影响“上帝”的游戏心情。

关于组成整个虚拟世界的Cell之间的关系，下面来分析两种情况：

<!--[if !supportLists]-->一， <!--[endif]-->Cell 承载的场景不重叠

如图（1），一个连续的虚拟世界场景被分成左右两块，分别在不同的Cell Server上面运行。A、B、C分别是3个不同的游戏角色。在这种情况下B与C的交互并不存在任何障碍，因为B和C只不过是同一个物理服务器上同一个进程内的两块不同的内存数据而已。但是A与B/C的交互就不那么直接了，尽管他们所在的场景看上去是“连续的、一体的”但是事情不会像表面上那么简单。A与B发生交互时候会发生什么事情？例如A攻击了B、A与B交易物品等等，因为在这种结构下做数据同步会带来很多问题，例如对象状态不确定性、开发复杂度等等、相对来说两个Cell Server之间做网络通讯而带来的延迟可能反而是最小的问题，这些问题不需要很复杂的分析就可以得出结论，在此不再多说了。

<!--[if !supportLists]-->二，Cell 承载的场景（部分地）重叠

如图（2），一个连续的虚拟世界场景被分成左右两块，分别在不用的Cell Server上面运行。A、B、C、D分别是4个不同的游戏角色。这个情况下，中间的区域为2个Cell所共同维护，中间区域的对象同属于2个Cell所‘拥有’。这有什么好处？现在，任意两个对象之间，除了A与C之间的交互，都变得更‘直接’了。变得直接肯定是一件好事儿，那么A与C之间呢？他们之间其实也没有任何问题J 因为双方都已经超出了对方的Area of Interest（AoI）区域，游戏规则可以限制他们不能直接交互。

上面提到的第二种方案算不上什么魔法，但是肯定是比第一种方案更有效。接下来怎么办？假设B是个玩家，他站在中间这块区域上面时，并不会产生“我到底是在哪里”这样的疑问J 问题的关键在于对于Cell Server来说，怎么样同步那些处于重叠区域对象的状态。游戏世界内的对象可能同时处于1个、2个、3个或者4个不同的Cell Server。如果你的Cell分隔方法不限于水平线和垂直线、或者有人故意捣乱的话，还可能会更多。需要被同步的对象也不只是玩家本身，还包括怪物、NPC、一颗会走的树、某玩家在地上吐的痰等等。

由于我们的基于无缝世界的游戏规则不大会直接去限制游戏世界某处玩家的行为，也就是说玩家如果能相互交易物品的话，他们肯定希望在任何地方都能交易，“为什么其他地方都行，但是在某个墙角做交易就会导致物品丢失？”所以比较可靠的方法是建立一套的用于同步的底层机制，来同步这些跨边界对象。

怎么实现？这个话题很大，恐怕再写几篇Blog我也讲不完，但是有一些东西可以作为参考，例如：DCOM和CORBA规范，Java的RMI，基于Python的 PYRO，TAO(The ACE ORB)等等。好在分布式处理的问题不止是网络游戏会涉及到，可以借鉴的东西还是很多的。

总结
很显然，这篇文章在两种架构的评价上面存在某些倾向性，但是倾向性本身只是副产品。另外一个副产品就是关于一些技术分析方法。

在考虑采用何种技术的时候，我们往往很容易地就会忽略对程序之外那些事情的影响。上面我提到的关于Services-based架构实现的时候，提到划分service及数据设计对程序设计能力的挑战、对策划设计的制约，对适应需求变更能力的影响，都不会只是空谈。这些问题也不是只在实现这种架构的时候才出现。

不要高估自己的智商，Keep It Simple and Stupid :) 应该可以让我们离成功更近一点儿。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/romandion/archive/2009/04/02/4044368.aspx

我们一开始的游戏逻辑层是基于网络包驱动的，也就是将 client 消息定义好结构打包发送出去，然后再 server 解析这些数据包，做相应的处理。

写了一段时间后，觉得这种方案杂乱不利于复杂的项目。跟同事商量以后，改成了非阻塞的 RPC 模式。

首先由处理逻辑的 server 调用 client 的远程方法在 client 创建出只用于显示表现的影子对象；然后 server 对逻辑对象的需要client 做出相应表现的操作，变成调用 client 端影子对象的远程方法来实现。

这使得游戏逻辑编写变的清晰了很多，基本可以无视网络层的存在，和单机游戏的编写一样简单。

• 懂至少一种编程语言。 迄今为止， C++因为性能和效率的优越性成为游戏开发者的首选。 Visual Basic, Java 或者 C# 可能也是不错的选择。
  
• 熟悉一种图形库。通常的选择是SDL, OpenGL, 或者DX/D3D。(译者注：网上也有很多免费/付费引擎下载和出售)
• 选择一种网络通讯库。 你可以从WinSock, SDL_net, 或DirectPlay中选择。(译者注：很多人喜欢开发自己独特的网络库，这并不复杂，似乎ACE也是一种选择)
  
• 对游戏开发有大体的经验。 例如，事件循环， 多线程， GUI 设计，等等。

• C/S结构通讯。
• 多平台开发。 你可能希望设计一个MMORPG, 尤其是服务器能运行在多种操作系统。为此，我推荐使用SDL, OpenGL 和SDL_net。
  
• 网站开发。如果你想让用户通过网站查看玩家统计，服务器信息和其他信息，这是必须的。(译者注：其实网站可以交给其他人开发，如果有必要的话)。
• 安全管理。 你当然不想因为有人攻击你的服务器而浪费时间！
• 团队组织能力。 你需要一个你能成功领导和管理的团队。
  

• 创建一个新角色
• 保存那个角色(服务器端)
• 用那个角色登陆
• 能够和其他人交谈
• 能在3D空间游览

• Offset 0: 1 字节 表示传输的命令。
• Offset 1: 2 字节，传输的数据长度。
• Offset 3: 变长，消息内容。

• 服务器响应会更加平滑，因为如果一个玩家需要大量时间(例如从数据库中读取数据)，这会在它自己的线程中完成，不会影响其他人。(译者注：也许作者的意思是每个玩家都有独立的线程，但这对MMORPG不太现实)
• 难以恰当的实现和调试：你可能需要大量同步，并且一个小疏忽就会导致灾难性的后果( 服务器瘫痪，物品复制，等等)。
• 可以利用多处理器。

• 实现和调试更简单。
• 响应速度慢。

• 至少3 个程序员： 1 个做服务器，两个客户端(或者一个客户端，一个负责工具，例如美术插件，世界编辑器，等等)。有6个程序员是最好的，更多就没必要了。这取决于你的领导能力。最少一个美工，2到3个更合适。如果这是个3D游戏，你需要一个3D美工，一个2D美工(制作帖图，界面，等等)，一个动画师，和一个美术部负责人。美术部应该由有经验的人组织和安排，除非你就是个艺术家。,
• 少数世界构建者:创建所有地图是个漫长的过程， 并且直接关系到游戏的成败。再次，你需要一个世界构建部的负责人。你的世界需要协调一致，所以不能只有一个意气用事的人。
• 一个 网站管理员是必须的，除非你精通网站设计，并且愿意花时间做网站。音效和音乐不是必须的，但是有音效和音乐的游戏比没有的会更吸引人。
• 一个游戏经济系统 设计师.。你也许觉得那很简单，可以自己来做，但事实上那是最复杂的工作之一。如果经济系统设计不良(比如物品没有平衡，资源在地图上随意放置，等等。)玩家会觉得无聊并且退出游戏。我们早期的进展存在很大的问题，尤其是因为经济系统主要是由我(一个程序员)设计的，它没有被恰当的计划。 于是，我们花费了两个月来重新思考和建立一整个新的经济系统。这需要一次完全的物品清除。我告诉你，玩家会很不乐意你删除他们的物品。幸运的是，大部分玩家赞同这个想法，但是这么多小时的争论，妥协，解释和时间的浪费还是让我们丧气。以后会更多。
  

• 你无法制作MMORPG, 只有大公司才可以。
  我不同意。虽然制作一款像魔兽世界(World of Warcraft)，无尽任务2(Ever Quest 2)，亚瑟王的召唤2(Asheron's Call 2)，血统2(Lineage 2)，和其他一些游戏对一个小型的自发团队是不可能的，但是做一款像样的游戏还是可以的，只要你有经验，动机，和时间。,你需要1000小时的编程来制作一个可运行的测试版，大概10~15k小时完成几乎完整的客户端和服务器。但是作为团队领导者，你不能只编程。保持团队团结，解决争执，维护公共关系(PR)，技术支持，架设服务器，惩罚捣乱分子，自由讨论，等等都是你的职责。你可能会被非编程的任务淹没。你很可能需要上班/上学，这减少了你花费在项目上的时间。我们很幸运，没有成员离开团队，但是如果这种事情发生，那的确是大问题。假设你的美工半途离开。或者更糟糕，他/她没有给你使用他/她作品的许可。当然这可以通过和他们签订合同来解决，但找另外一个美工仍然很麻烦。一个工程中有两种不同的美术风格也是问题。
• 需要大笔金钱(通常 4-6 位数) 用来架设一个 MMORPG 服务器.
  当然，这不是真的。我见过专业服务器，1000GB/月，不到100美元/月(2~300美元的初装费)。除非你的数据传输协议设计非常不合理，1000GB/月对一个1000玩家在线(平均)的服务器来说足够了。当然，你还需要另一个服务器做网站和客户端下载(客户端下载会占用大量流量，当游戏变得流行的时候)。我们的客户端有22MB，有时候会有400GB/月的传输量。而我们还没有很流行(仍然)。另一件事，我们不需要另一台专用服务器开启这个工程。ADSL/cable服务器可以胜任，直到你的同时在线人数达到20~30。然后要么找一个友好的主机公司，用广告交换免费主机，要么就只能自己掏腰包了。  
  
• 制作一个MMORPG很有趣。
  这不是真的。你可能认为每个人都会赏识你，玩家会支持你，你标新立异，并且，当然，很多玩家都玩你的游戏。玩家可能让人讨厌。即使是完全免费的游戏，他们也能找到理由抱怨。更糟糕的是人们经常会抱怨矛盾的事。战士会抱怨升级太难，商人会对战士掠夺大量钱财很失望。如果你减少怪物掉落物品，有些玩家就会威胁说要退出游戏。如果你增加，同样的一群人会不满新手能更简单赚钱的事实。 真是左右为难。改革和改进是必须的。如果你决定改变某些东西，例如给加工物品增加挑战性，有些人会说太难了。如果你不做，他们又会说太简单无味。你会发现满意的玩家通常不会说什么并且感到满意，同时破坏者会怨声载道。
  

当WOW终于来到中国时，我一边欣喜着终于可以在艾泽拉斯的大陆上自由翱翔，一边却咒骂着9C的破服务器，动不动就宕机。当然，身为游戏程序设计师的我明知道，这大部分的错误都不应归罪于代理商9C，但是，谁让blizzard是我心目中的神，谁又让WOW成为我游戏制作的教科书呢。好吧，我知道上面这段极力追捧blizzard跟WOW的话可能早已让你恶心连连，不堪入目了，对不起，忘了这一节，让我们继续。

服务器宕机后都发生了些什么？

显然的，宕机后玩家会骂，就像我在玩WOW时那样，骂游戏公司，骂老板，骂GM。非常抱歉，我们可爱的玩家们似乎并不清楚，这个时候最该骂的其实是我们这些程序员们。长久的遗忘被我们当成了包容，以至于游戏程序员在公司里都养成了趾高气扬，不可一世的坏毛病：看吧，策划们，你们做的太烂了，数值不平衡，玩法没新意，只会照抄WOW跟大菠萝，能怪玩家骂你们吗？运营不得力，买服务器的钱不知道去了哪里，游戏里卡的要死，偶尔办个活动还没半点吸引力，能不被玩家骂你是无良运营商吗？GM们能不天天被骂家指着骂吗？……呃，又扯远了。

赶紧先把服务器重启吧。老板正站在你的身后，一脸愁容，虽然暂时还没有发作，但看得出来：老板很生气，后果很严重！

玩家们很快又回来了，不得不为玩家们的毅力和执着精神而感动，更为自己的错误而愧疚，凌晨时分，服务器启了又宕，宕了又启，如此反复，可热情的玩家们依然陪着我在折腾。哦，当年安其拉开门的时候，我也曾这样折腾过。

这个时候不是你一个人在战斗。GM们在忙碌地处理着玩家不断打来的投诉电话：刚买的装备在宕机后消失了；花光了身上所有材料合成的武器回档了，但材料却没有还给我……数据库维护组的同事们也在紧张的恢复着数据，尽可能的将玩家的损失减到最少。

真是一件令人沮丧的事。

真的该试着做点什么了吧！

既然我们非常不愿意看到宕机的情况发生，但又无法100%保证写出来的服务器程序一定不会出错，那我们就在当机发生后的抢救措施上花点功夫，让玩家的损失不至于太大，也让我们的维护人员少些压力吧。

一个最简单也最有效的做法是为每一台服务器都配备物理冗余，同步更新冗余服务器上的状态，当宕机发生时，立即将处理切换到后备服务器上。只是，物理冗余的代价太大，从成本方面考虑，老板可能不大愿意点头。

既然不能做硬冗余，那就再来考虑软的吧。

如果只是简单的启动冗余进程，其实是换汤不换药的做法。原来能跑1000人的服务器，由于同时运行了两个相同的进程，使得CPU和内存开销都翻了倍，结果是只能跑500人了。还是要加服务器。

看来只能更深一层，从架构设计上来动手了。

假设我们的游戏世界是由多个独立场景构成的，那么在实现上我们可以让这些场景在进程上也独立，这样做的好处是可以使得一个场景的宕机不会影响到其他场景的正常运行。如果我们的游戏世界物理上没有分隔，是一个无缝的大世界，我们也可以人为的将其分成多个独立区域，所需要做的额外工作是处理好那些站在区域边界附近的对象。事实上，现在的无缝大世界也都是这样实现的。

有了这样一个前提，我们再来看这个已宕掉的场景该如何处理。

还是老办法，赶紧先把它拉起来吧。一个具体可行的方案是，由场景管理器，或者你也有可能叫它世界服务器，来监视各个场景进程的运行状态，当某个场景异常失去联系时，由管理器来将其重新启动。这里需要再花点心思的是，如何让玩家数据正常地发送到新启动的场景进程中，而且这个过程对于客户端来说是透明的。

这个方案听起来似乎不错，只是，如果宕掉的是场景管理器进程，那该怎么办呢？

按照前面的描述，场景管理器可以看作是整个游戏世界的中心，它以一个指挥者的身份维护着游戏世界的有序运行，所以它的宕机对整个游戏世界的影响也将会是巨大的。

有没有什么办法能够使得场景管理器进程再次启动后能够恢复先前的状态呢？

我们可以为管理器和场景进程定义一套协议，使得管理器不仅能够创建并恢复一个已有场景，而且场景管理器还能通过现有的场景进程数据恢复出自己。

一个理论上可行的方案是，场景管理器与场景进程间保持TCP长连接，并以一定频率进行心跳联系，任意一方发现联系中断或长时间未收到心跳包后都会立即做出处理。

如果是管理器发现场景进程失去联系，那就启动新的场景，如前面所描述的那样。如果是场景进程发现管理器失去联系，那就立即启动重连过程，直接再次连接上管理器，然后立即将自己当前的状态和负责的场景ID报告给管理器。管理器通过这些上报的数据就能恢复出游戏世界内的场景对应关系表，也就是恢复出了自己原来的状态。

进程是恢复出来了，可我们忘了最重要的内容：数据。当场景进程宕机后，上面保存的玩家属性数据也随之丢失了，虽然我们能够再次将这个场景创建出来，并把原来在这个场景内的客户端数据重新定向过来，但这些客户端对应的玩家对象的数据却没有了，游戏仍然无法继续。

也许我们可以再做一点修改，把场景内的玩家数据分离出来，保存到一个独立的进程上，比如，我们可以把这个进程叫做数据服务器，或者数据中心之类的。一个隐含的要求是，数据服务器的逻辑实现非常简单，简单到你可以认为它是绝对安全的，不会宕机。所以，保存在这里的玩家数据也就是绝对安全的。

让我们在这个问题上稍微再深入一点。

场景进程上每次执行玩家的游戏逻辑时都要异步地到数据服务器上来存取数据，这个开销可能太大，而且会使得一些游戏逻辑的实现变的很复杂，那么，把一些会频繁使用到的数据直接保存在场景进程中，当数据发生改变时同步更新到数据服务器上，这样可能会比较容易接受。

老板全都满意了吗？

从理论上来说，我们已经解决了场景进程宕机和管理器宕机后的状态恢复问题，并且在场景恢复后也不会因为丢失了玩家数据而无法继续进行游戏，而且，只要处理得当，这个过程对客户端来说可以是完全透明的，也就是玩家根本不知道服务器上有个进程意外结束，我们做了这么多的工作来将它恢复了。

事实上，这个过程的透明也是必须的，我们并不需要嚷嚷着告诉我们的用户，也就是玩家，我们做了多少多少事情来让你玩的更顺畅，又花了多少多少精力来解决因为服务器宕机而引起的麻烦，对于最终的用户来说，他只需要享受最好的服务。闲话少说，让我们继续。

真的已经完全解决了所有问题吗？

想象这样一个场景：我带着几个刚刚降临到艾泽拉斯大陆的伙伴冲向了艾尔文森林，去开荒霍格！正在霍格只剩下一丝血的时候，服务器稍稍卡了一下，等我缓过神来，面前的霍格骤然消失，地上也不见尸体。找了一圈，它正在出生点摇头晃脑，也在四处张望，但头顶上的血条分明是，满血！

怎么回事？

处理这张地图的场景进程意外结束了，服务器的宕机处理机制很快地恢复了这个场景进程，并且把我的客户端数据重新定向到了新场景。只是，事情并不是一切都完美。因为这个场景是完全重新创建的，这意味着所有的怪物也是重新创建并被摆放到了初始位置，所以，只剩下一丝血的霍格碰上了好运气……

类似的还有，正在护送NPC返回营地，在稍微停顿了一会儿之后，NPC又重新回到了原来的地方，等等。

虽然这比起最初的“客户端被迫断开连接，服务器端数据丢失”要进步了许多，但会给我工资的老板仍然可能不太满意，他希望，霍格应该还在我的面前，而且只有一丝血，那个跟着我的NPC也应该还在我旁边……

我要是不能说服老板，这是“根本不可能完成的任务！”，那也就只能坐下来再试一试。

也许，可以考虑将所有对象的数据都保存到数据服务器上，当然，这要求每个怪物都跟玩家一样，有一个唯一ID，这一点实现起来可能会有些麻烦。

再不然，为对象提供一个从已有的内存数据构造的方法，这样便可以使用共享内存来保存现场数据，再从共享内存中恢复出原来的对象。理论上来说，这个方法是可行的，只是，这三十多个字的文字描述要用C++来实现也可能将会是一项极大的挑战，所以，这也仅只是可供参考的一个尝试方案。

我想，我们走的够远了

让我们先暂停一会儿，回过头来看一看最初的目的。其实我们想要的只是尽可能的让服务器进程不要宕机，如果实在是没有办法，就尽可能的让宕机后的玩家损失比较小，不需要我们做大量的工作去做善后处理。

很简单的需求，似乎我们纠缠的有些过头了。

写出能够稳定运行的程序是对程序员的最基本要求，如果一个程序连稳定性都不具备，那根本都不用再去考虑功能啊、扩展啊等其他标准了。但是，正如我最开始所说的，没有一个人能够100%保证他写出来的服务器程序是绝对不会崩溃的。我们所能要求的只是尽可能的仔细，尽可能的多一些必要的测试，离安全尽可能的更近一步。

剩下的就是在宕机后如何降低损失的问题了。

对于一般的MMOG来说，玩家在进入游戏时会从数据库中将该玩家的所有相关数据读到内存，以便快速的进行游戏逻辑的处理，而在玩家下线时再将数据的改动存回数据库。

显然的，当服务器进程出现意外宕机时，内存中所有的数据都丢失了，这也就造成了玩家数据的回档，而且玩家在游戏中呆的时间越长，回档的损失就越大。所以，一个被广泛采用的做法是为玩家数据实现一种定时存盘的机制，就像现在大多数的单机游戏一样，AutoSave。比如，每5分钟自动为玩家存一次盘，这样就可以使得回档的最大损失控制在5分钟以内。

另外，对于一些重要数据的变动，比如玩家花大量游戏货币购买了一件贵重的武器装备，这时可将玩家数据立即做一次存盘操作，这也将有效的减少玩家的重大损失。

听起来这是一项不错的技术，在意外宕机的时候最多只回档5分钟，而且还没有贵重物品的损失，玩家应该是可以接受的吧。

我已经听到了数据库维护员的咆哮

“数据库已经快要崩溃了，你就不能让每秒需要执行的SQL语句少一点吗？”

“呃………”

我一直以为我们的数据库非常强大，可以处理任何的数据，唯一的缺点就是查询速度比直接内存读取要慢很多。所以我使用了异步数据存取的方法，并且开启了多个数据库操作线程来并行的执行我的请求，运行的效果看起来还不错。

也许，我应该来算一算，每秒种究竟丢了多少条操作请求给数据库。

请允许我再自私一回，我已经很久没有提到WOW了……

大概可信的数字是，WOW一组服务器的玩家数量在3000到5000之间，去掉最大的数，再去掉最小的数，最后的平均值是，4000吧，就算4000。

4000人在线，假设也是每5分钟定时存盘一次，再假设所有玩家的存盘时间是平均分布的。这样算下来，每秒种就会有67个玩家向数据库发出存盘请求操作。

才67个，数据库维护组的同事就跟我说不堪重负了？笑话，这数据库服务器是谁买的？

先别急，67是玩家数，但是每个玩家的存盘请求不会只有一条SQL语句。

虽然每个游戏的内容都各有差别，但是一款MMOG需要存入数据库的数据少不了会有技能、物品、任务、宠物、好友、公会这些东西。取决于游戏的类型差异，每个游戏都会有自己的存盘方式，比如我可能会把所有的技能ID作为一条数据来存储，但是我也有可能把每个技能作为一条单独的记录来存储，这样可以方便对技能附加数据的扩展，等等。

但是，游戏中的物品存储大概都是相同的，只能是一件(组)物品作为一条记录来存储。

而且，可以说游戏中存储量最大的就是物品数据。算一算你的角色背包有多大，50格？ 100格？还是200格？不要忘了银行、摆摊位、装备拦、宠物背包和邮箱这些地方也能放物品。并且，在游戏进行过程中，玩家背包中物品数据的变动也是相当的频繁，不断的有药品被用掉，不断地又有些小玩意儿被捡起来，不久后，它们又被卖给了NPC。

虽然你可以使用一些巧妙的比较算法来过滤掉那些实际上没有发生变动的物品更新，另外也不是所有的玩家物品数据变动都很频繁，但在实际运营中，尤其是当玩家的背包格数都很多的时候，物品数据的存盘的确会成为一个很大的问题。

除了物品，还有玩家的基本属性存盘，社会关系存盘等等，再加上全局公共数据的存盘，如公会数据，拍卖行物品数据，如果老板也要我在游戏中开上一家拍卖行的话。

这么一算下来，似乎是有些多了。

再一次的挑战

具体的数字将取决于游戏的类型和设计的数据表结构。

而数据库服务器能承担的每秒查询数则取决于数据库服务器的软硬件配置情况。

但是一般来说，数据库维护人员可能会告诉我，当每秒执行的SQL语句数达到1000条时，数据库服务器将会感受到明显的压力，我可能也会看到数据库执行队列中的请求数一直在增长，也可能会看到数据库服务器间歇性地拒绝响应，等等。

看起来我们又一次的面对到了巨大的打冷战。

这个问题的起因是什么？我们不希望服务器进程宕机时回档太久，所以我们增加了一个玩家数据定时存盘的机制，结果却导致了数据库请求的骤然增多。

那再退回到这个起点处，将定时存盘的时间间隔延长点，比如10分钟才存一次？数据库的压力会有缓解，但最初的问题却又会有所暴露。真是个两难的问题。

既想要玩家数据存盘间隔时间短一点，又不想给数据库造成的压力太大。

同样的需求似乎出现过很多回了：在中间加一层代理做缓冲。我们姑且称这一层代理为数据库代理服务器，它所要完成的工作是从场景进程收集玩家的定时存盘请求数据，再以一个低一点的频率写入到数据库。

听起来这又像是一个换汤不换药的做法，写入数据库的时间间隔还是变长了。但实际上在前面我们就曾经描述过，如果服务器进程不会出现意外的宕机，玩家数据只需要在他上线时读取，在他下线时写入即可，中间添加的这些定时存盘过程完全只是为了防范宕机回档所造成的巨大损失。

因为这个中间代理层的加入，我们把场景进程宕机的隐患与数据丢失的后果隔离开来了，现在即使场景进程宕机，数据还在数据库代理服务器上，当然这里又隐含了一个条件：数据库代理服务器需要足够稳定，不会在场景进程之前先宕掉。事实上，因为这个代理进程的工作是，我们完全有理由相信，这个进程是非常稳定的，那样的话，多久时间才把缓存的数据真正写入数据库，就看你自己的喜好了。

该结束了吧

是否有些似曾相识的感觉？

没错，前面我们曾经描述过一个数据服务器，也是这样说的。

所以，数据服务器，数据库代理服务器可以合并到一起，来共同保证数据的安全。

再加上场景进程与管理器进程的恢复协议，让服务器的重启对玩家保持透明。

看起来这个晚上可以睡个安稳觉。

一、游戏世界的划分

理想状态的游戏世界仅由一个完整的场景组成，在《魔兽争霸 III 》、《 CS 》这样的单机游戏中，所有玩家位于该场景中，在理论上，位于该场景中的任意玩家都可以看到游戏中所有玩家并与之交互，出于公平性和游戏性（而不是技术上）的考虑，游戏中并不会这样做。

然而，目前的 MMORPG 中，几乎没有任何一款可以做到整个游戏世界只包含一个场景，因为在一款 MMORPG 中，同时在线的玩家数量成百上千，甚至是数万人同时在一个游戏世界中交互。以现在的网络技术和计算机系统，还无法为这么多玩家的交互提供即时处理。因此， MMORPG 的游戏世界被划分为大小不等、数量众多的场景，游戏服务器对于这些场景的处理分为分区和无缝两种。

在分区式服务器中，一个场景中的玩家无法看到另一个场景中的玩家，当玩家从一个场景到另外一个场景跨越时，都有一个数据转移和加载的过程（尤其是从一个分区服务器跨越到另外一个服务器时），玩家都有一个等待的时间，在这段时间内，服务器的主要工作是实现跨越玩家数据的转移和加载以及后一个场景中玩家、 NPC 等数据的传输，客户端的主要工作是实现新场景资源的加载和服务器通信。主要时间的长短主要取决于后一个场景中资源数据的大小。分区式服务器的优点主要是各分区服务器保持相对独立，缺点是游戏空间不够大，而且，一旦某个分区服务器中止服务，位于该服务器上的所有玩家将失去连接。

所谓无缝服务器，玩家几乎察觉不到场景之间的这种切换，在场景间没有物理上的屏障，对于玩家而言，众多场景构成了一个巨大的游戏世界。场景之间，甚至服务器之间“没有了”明确的界线。因此，无缝服务器为玩家提供了更大的游戏空间和更友好的交互，实现了动态边界的无缝服务器甚至可以在某个服务器中止服务时，按一定策略将负载动态分散到其他服务器。因此，无缝服务器在技术上要比分区服务器更加复杂。

目前国内上市的 MMORPG ，大多采用分区式服务器，做到无缝世界的主要有《完美世界》和《天下贰》等，国外的 MMORPG 中，像《魔兽世界》、《 EVE 》等，都实现了无缝世界。

无缝服务器与分区式服务器在技术上的主要区别是，当位于场景 S1 中的玩家 P1 处于两个（甚至更多）场景 S1 、 S2 的边界区域内时，要保证 P1 能够看到场景 S2 中建筑、玩家、 NPC 等可感知对象。而且边界区域的大小要大于等于 P1 可感知的范围，否则就可能发生 S2 中的可感知对象突然闪现在 P1 视野中的异常。

无疑，无缝世界为玩家提供了更人性化和更具魅力的用户体验。

二、无缝世界游戏服务器的整体架构

MMORPG 的服务器架构从功能上主要划分为三种：

1、 登录服务器（ Login Server ）

登录服务器用于玩家验证登录，并根据系统记录玩家信息得到其所在节点服务器，并通过世界服务器为登录玩家和对应节点服务器建立连接。

2、 世界服务器（ World Server ）

世界服务器将整个游戏世界划分成不同场景，将所有场景按一定策略分配给节点服务器，并对节点服务器进行管理。世界服务器的另一功能是与登录服务器交互。因此，世界服务器是登录服务器、节点服务器的沟通桥梁，当然，一旦玩家登录成功，世界服务器将主要处理节点服务器间的通信。因此，世界服务器对于玩家是透明的。

3、 节点服务器（ Node Server ）

节点服务器负责管理位于该节点的所有玩家、 NPC 的所有交互，在无缝世界游戏中，由于边界区域的存在，一个节点服务器甚至要处理相邻节点上位于边界区域的玩家和 NPC 的信息。

在具体实现上，不同的 MMORPG 为了便于管理，可能还会具有 AI 服务器、日志服务器、数据库缓存服务器、代理服务器等。

三、 无缝世界游戏服务器的主要技术需求

1、 编程语言（ C/C++ 、 SQL 、 Lua 、 Python ）

2、 图形库（ Direct 3D 、 OpenGL ）

3、 网络通信（ WinSock 、 BSD Socket ，或者 ACE ）

4、 消息、事件、多线程、 GUI

5、 OS

三、无缝世界游戏服务器需要解决的主要问题

1、 资源管理

无论是服务器还是客户端，都涉及到大量资源：玩家数据、 NPC 数据、战斗公式、模型资源、通信资源等。当这些资源达到一定规模，其管理的难度不可忽视。而且，资源管理的好坏，直接关系到游戏的安全和生命。

2、 网络安全

安全永远是第一位的，我们无法指望所有的玩家及其所持的客户端永远是友好的。事实上，威胁到游戏的公平性和安全性的大多数问题，归根结底，都是由于网络通信中存在的欺骗和攻击造成的，这些问题包含但不限于交易欺骗、物品复制。

3、 逻辑安全

逻辑安全按理说应该是游戏中最基本的考虑，覆盖的范围也最广最杂。随机数系统是一个非常值得重视的问题，随机数不仅仅用于玩家可见的一些任务系统、战斗公式、人工智能、物品得失等，还可用于网络报文加密等。因此，随机数系统本身的安全不容忽视。另外一个常见的逻辑安全是玩家的移动，最主要的就是防止加速齿轮这样的变态操作。

4、 负载均衡

MMORPG 中的负载均衡包括客户端及服务器资源管理和逻辑处理的负载均衡，其中最难预知的是网络通信的负载均衡，正常情况下的网络通信数量是可以在游戏设计时做出评估的，但因恶意攻击造成的网络负载是无法预测的。因此，负载均衡所要处理的主要是实时动态负载均衡和灾难恢复。负载均衡需要解决的问题包括负载监控、负载分析、负载分发和灾难恢复。

5、 录像系统

录像系统的构建，主要用于重现关键数据的输入输出，如玩家交易、玩家充值，或者当 bug 出现后，为逻辑服务器（泛指上文提到的所有类型服务器，主要是节点服务器）相应部分启动录像系统。待收集到足够数据后，通过录像系统重现 bug 。为了使逻辑服务器不受自身时间（如中断调试等）的影响，还可以专门设计心跳服务器来控制数据传输。

四、总结

在 MMORPG 中，真正的 bug 永远存在于将来。从这一点出发，关于 MMORPG 中游戏世界的构建，怎样苛刻的思考都不为过。

参考资料：

1、 [美] Kim Pallister编, 孟宪武 等译. 游戏编程精粹5, P467-474, P516. 人民邮电出版社, 2007年9月. 北京.
2、 [美] Thor Alexander编, 史晓明 译. 大型多人在线游戏开发, P174-185. 人民邮电出版社, 2006年12月. 北京.
3、 [美] Dante Treglia编, 张磊 译. 游戏编程精粹3, P117-122. 人民邮电出版社, 2003年7月. 北京.
4、 [美] Mark DeLoura编, 王淑礼 等译. 游戏编程精粹1, P90-93. 人民邮电出版社, 2004年10月. 北京.
5、 [美] Douglas 等著, 於春景 译. C++网络编程 卷1. 中国电力出版社, 2004年11月. 北京.
6、 [美] Stephen D. Huston 等著, 马维达 译. ACE程序员指南. 中国电力出版社, 2004年11月. 北京.
7、 [美] Erich Gamma等著, 李英军 等译. 设计模式. 机械工业出版社, 2000年6月. 北京.
8、 游戏引擎全剖析. http://bbs.gameres.com/showthread.asp?threadid=101293.
9、 服务器结构探讨：登录服的负载均衡. http://gamedev.csdn.net/page/351491d0-05ad-48a4-85e1-77870bc1eef3.
10、服务器结构探讨：最终的结构. http://gamedev.csdn.net/page/28695655-974c-4291-8ac4-2589c4e770d3.

方案一：
　·服务器上每个场景用一个list来保存上面的player和NPC
　·玩家行走、进入和离开等事件发给list中的所有player
　·客户端的list保有该场景上的所有player和npc
　优点：处理起来简单直接
　缺点：发送的消息会随玩家数量的增加而暴增、客户端负担很重

方案二：
　·服务器上每个场景用一个list来保存上面的player和NPC
　·玩家行走、进入和离开等事件只发给该玩家一定范围内的Player
　·客户端的list只保有本玩家附近的player和npc
　·在服务器可以考虑使用hash表来优化查询速度
　优点：减少了服务器发送消息的数量、减轻了客户端的负担
　缺点：实现相对复杂，服务器负担大大加重（因为要不断判断玩家间的位置关系）

方案三：
　·在服务器上把场景划分为小区域（大于屏幕大小）。每个区域对应一个list，场景中的所有对象按他们的位置加入到对应区域的list中，那么每次行走只需要把消息发送给最多４个相临区域的Player
　·客户端的list只保有本玩家附近的player和npc
　优点：大大减轻了服务器遍历list的负担、减少了发送消息的数量、减轻了客户端的负担
　缺点：实现非常复杂、而且在服务器需要不断判断玩家是否跨越区域

方案四：
　·服务器上场景的每个TILE保存一个Object指针用来绑定该格子上的player或NPC
　·玩家行走、进入和离开等事件发给玩家周围一定范围内的player
　·客户端保有该player周围一定范围内的player和npc
　优点：处理起来极为直接、避免了耗时链表遍历（典型的以空间换时间）
　缺点：地图每个TILE都要加入一个指针变量（管理不善容易出错）、每次发送场景广播要遍历所有TILE

方案五：
　·服务器上每个场景用一个list来保存上面的player和NPC
　·不使用事件通知，而使用状态位置通知的方式通过定时发送状态来更新客户端的player和npc状态
　·客户端保有该player周围一定范围内的player和npc
　优点：处理比较简单
　缺点：实时性太低，对于要求同步比较精确的ＡＲＰＧ不太适合

　　有个解决方案，我给它取名叫 预测拉扯，虽然有些怪异了点，不过基本上大家也能从字面上来理解它的意思。要解决这个问题，首先要定义一个值叫：预测误差。然后需要在服务器端每个玩家连接的类里面加一项属性，叫TimeModified，然后在玩家登陆的时候，对客户端的时间和服务器的时间进行比较，得出来的差值保存在TimeModified里面。还是上面的那个例子，服务器广播消息的时候，就根据要广播对象的TimeModified，计算出一个客户端的CurrentTime，然后在消息头里面包含这个CurrentTime，然后再进行广播。并且同时在玩家A的客户端本地建立一个队列，保存该条消息，只到获得服务器验证就从未被验证的消息队列里面将该消息删除，如果验证失败，则会被拉扯回P1点。然后当玩家B收到了服务器发过来的消息“玩家A从P1到P2”这个时候就检查消息里面服务器发出的时间和本地时间做比较，如果大于定义的预测误差，就算出在T2这个时间，玩家A的屏幕上走到的地点P3，然后把玩家B屏幕上的玩家A直接拉扯到P3，再继续走下去，这样就能保证同步。更进一步，为了保证客户端运行起来更加smooth，我并不推荐直接把玩家拉扯过去，而是算出P3偏后的一点P4，然后用(P4-P1)/T(P4-P3)来算出一个很快的速度S，然后让玩家A用速度S快速移动到P4，这样的处理方法是比较合理的，这种解决方案的原形在国际上被称为（Full plesiochronous），当然，该原形被我篡改了很多来适应网络游戏的同步，所以而变成所谓的：预测拉扯。

另外一个解决方案，我给它取名叫 验证同步，听名字也知道，大体的意思就是每条指令在经过服务器验证通过了以后再执行动作。具体的思路如下：首先也需要在每个玩家连接类型里面定义一个TimeModified，然后在客户端响应玩家鼠标行走的同时，客户端并不会先行走动，而是发一条走路的指令给服务器，然后等待服务器的验证。服务器接受到这条消息以后，进行逻辑层的验证，然后计算出需要广播的范围，包括玩家A在内，根据各个客户端不同的TimeModified生成不同的消息头，开始广播，这个时候这个玩家的走路信息就是完全同步的了。这个方法的优点是能保证各个客户端之间绝对的同步，缺点是当网络延迟比较大的时候，玩家的客户端的行为会变得比较不流畅，给玩家带来很不爽的感觉。该种解决方案的原形在国际上被称为（Hierarchical master-slave synchronization），80年代以后被广泛应用于网络的各个领域。

　最后一种解决方案是一种理想化的解决方案，在国际上被称为Mutual synchronization，是一种对未来网络的前景的良好预测出来的解决方案。这里之所以要提这个方案，并不是说我们已经完全的实现了这种方案，而只是在网络游戏领域的某些方面应用到这种方案的某些思想。我对该种方案取名为：半服务器同步。大体的设计思路如下：

首先客户端需要在登陆世界的时候建立很多张广播列表，这些列表在客户端后台和服务器要进行不及时同步，之所以要建立多张列表，是因为要广播的类型是不止一种的，比如说有local message,有remote message,还有global message 等等，这些列表都需要在客户端登陆的时候根据服务器发过来的消息建立好。在建立列表的同时，还需要获得每个列表中广播对象的TimeModified，并且要维护一张完整的用户状态列表在后台，也是不及时的和服务器进行同步，根据本地的用户状态表，可以做到一部分决策由客户端自己来决定，当客户端发送这部分决策的时候，则直接将最终决策发送到各个广播列表里面的客户端，并对其时间进行校对，保证每个客户端在收到的消息的时间是和根据本地时间进行校对过的。那么再采用预测拉扯中提到过的计算提前量，提高速度行走过去的方法，将会使同步变得非常的smooth。该方案的优点是不通过服务器，客户端自己之间进行同步，大大的降低了由于网络延迟而带来的误差，并且由于大部分决策都可以由客户端来做，也大大的降低了服务器的资源。由此带来的弊端就是由于消息和决策权都放在客户端本地，所以给外挂提供了很大的可乘之机。

　综合以上三种关于网络同步派系的优缺点，综合出一套关于网络游戏传输同步的较完整的解决方案，我称它为综合同步法（colligate synchronization）。大体设计思路如下：

　　首先将服务器需要同步的所有消息从划分一个优先等级，然后按照3/4的比例划分出重要消息和非重要消息，对于非重要消息，把决策权放在客户端，在客户端逻辑上建立相关的决策机构和各种消息缓存区，以及相关的消息缓存区管理机构，如下图所示：

　　上图简单说明了对于非重要消息，客户端的大体处理流程，其中有一个客户端被动行为值得大家注意，其中包括对服务器发过来的某些验证代码做返回，来确保消息缓存中的消息和服务器端是一致的，从而有效的防止外挂来篡改本地消息缓存。其中的消息来源是包括本地的客户端响应玩家的消息以及远程服务器传递过来的消息。

　　对于重要消息，比如说战斗或者是某些牵扯到玩家一些比较敏感数据的操作，则采用另外一套方案，该方案首先需要在服务器和客户端之间建立一套Ping System，然后服务器保存和用户的及时的ping值，当ping比较小的时候，响应玩家消息的同时先不进行动作，而是先把该消息反馈给服务器，并且阻塞，服务器收到该消息，进行逻辑验证之后向所有该详细广播的有效对象进行广播（包括消息发起者），然后客户端收到该消息的验证，才开始执行动作。而当ping比较大的时候，客户端响应玩家消息的同时立刻进行动作，并且同时把该消息反馈给服务器，值得注意的是这个时候还需要在本地建立一个无验证消息的队列，把该消息入队，执行动作的同时等待服务器的验证，还需要保存当前状态。服务器收到客户端的请求后，进行逻辑验证，并把消息反馈到各个客户端，带上各个客户端校对过的本地时间。如果验证通过不过，则通知消息发起者，该消息验证失败，然后客户端自动把已经在进行中的动作取消，恢复原来状态。如果验证通过，则广播到的各个客户端根据从服务器获得校对时间进行对其进行拉扯，保证在该行为完成之前完成同步。

　　至此，一个比较成熟的网络游戏的同步机制已经初步建立起来了，接下来的逻辑代码就根据各自不同的游戏风格以及侧重点来写了。

　　同步是网络游戏最重要的问题，如何同步也牵扯到各个方面的问题，比如说游戏的规模，游戏的类型以及各种各样的方面，对于规模比较大的游戏，在同步方面可以下很多的工夫，把消息分得十分的细腻，对于不同的消息采用不同的同步机制，而对于规模比较小的游戏，则可以采用大体上一样的同步机制，究竟怎么样同步，没有个定式，是需要根据自己的不同情况来做出不同的同步决策的

网游同步算法之导航推测（Dead Reckoning）算法：

 

　　在了解该算法前，我们先来谈谈该算法的一些背景资料。大家都知道，在网络传输的时候，延迟现象是很普遍的，而在基于Server/Client结构下的网络游戏的同步也就成了很头疼的问题，在保证客户端响应用户本地指令流畅的情况下，没法有效的保证的同步的及时性。同样，在军方也有类似的事情发生，即使是同一LAN里面的机器，也会因为传输的延迟，导致一些运算的失误，介于此，美国国防部投入了大量的资金用于研究一种比较的好的方案来解决分布式系统中的延迟问题，特别是一个叫分布式模拟运动（Distributed Interactive Simulation）的系统，这套系统呢，其中就提出了一套号称是Latency Hiding & Bandwidth Reduction的方案，命名为Dead Reckoning。呵呵，来头很大吧，恩，那么我们下面就来看看这套系统的一些观点，以及我们如何把它运用到我们的网络游戏的同步中。

　　首先，这套同步方案是基于我那篇《网络游戏的同步》一文中的Mutual Synchronization同步方案的，也就是说，它并不是Server/Client结构的，而是基于客户端之间的同步的。下面我们先来说一些本文中将用到的名词概念：
　　网状网络：客户端之间构成的网络
　　节点：网状网络中的每个客户端
　　极限误差：进行同步的时候可能产生的误差的极值

　　恩，在探讨其原理的之前，我们先来看看我们需要一个什么样的环境。首先，需要一个网状网络，网状网络如何构成呢？当有新节点进入的时候，通知该网络里面的所有节点，各节点为该客户端在本地创建一个副本，登出的时候，则通知所有节点销毁本地关于该节点的副本。然后每个节点该保存一些什么数据呢？首先有一个很重要的包需要保存，叫做协议数据包（PDU Protocol Data Unit），PDU包含节点的一些相关的运动信息，比如当前位置，速度，运动方向，或者还有加速度等一些信息。除PDU之外，还有其他信息需要保存，比如说节点客户端人物的HP，MP之类的。然后，保证每个节点在最少8秒之内要向其它节点广播一次PDU信息。最后，设置一个极限误差值。到此，其环境就算搭建完成了。下面，我们就来看看相关的具体算法：

　　假设在节点A有一个小人（路人甲），开始跑路了，这个时候，就像所有的节点广播一次他的PDU信息，包括：速度（S），方向（O），加速度（A）。那么所有的节点就开始模拟路人甲的运动轨迹和路线，包括节点A本身（这点很重要），同时，路人甲在某某玩家的控制下，会不时的改变一下方向，让其跑路的路线变得不是那么正规。在跑路的过程中，节点A有一个值在不停的记录着其真实坐标和在后台模拟运动的坐标的差值，当差值大于极限误差的时候，则计算出当前的速度S，方向O和速度A（算法将在后面介绍），并广播给网络中其他所有节点。其他节点在收到这条消息之后呢，就可以用一些很平滑的移动把路人甲拉扯过去，然后重新调整模拟跑路的数据，让其继续在后台模拟跑路。

　　很显然，如果极限误差定义得大了，其他节点看到的偏差就会过大，如果极限偏差定义得小了，网络带宽就会增大。如果定义这个极限误差，就该根据各种数据的重要性来设计了。如果是回合制的网络游戏，那么在走路上把极限误差定义得大些无所谓，可以减少带宽。但是如果是及时打斗的网络游戏，那么就得把极限误差定义得小一些，否则会出现某人看到某人老远把自己给砍死的情况。

　　Dead Reckoning的主要算法有9种，但是只有两种是解决主要问题的，其他的基本上只是针对不同的坐标系的一些不同的算法，这里就不一一介绍了。好，那么我们下面来看传说中的最主要的两种算法：
　　　　第一：目标点 = 原点 + 速度 * 时间差
　　　　第二：目标点 = 原点 + 速度 * 时间差 + 1/2 * 加速度 * 时间差
呵呵，传说中的算法都是很经典的，虽然我们早在初中物理的时候就学过。

　　该算法的好处呢，正如它开始所说的，Latency Hiding & Bandwidth Reduction，从原则上解决了网络延迟导致的不同步的问题，并且有效的减少了带宽，不好的地方就是该算法基本上只能使用于移动中的同步，当然，移动的同步是网络游戏中同步的最大的问题。

　　该方法结合我在《网络游戏的同步》一文中提出的综合同步法的构架可以基本上解决掉网络游戏中走路同步的问题。相关问题欢迎大家一起讨论。

有关导航推测算法（Dead Reckoning）中的平滑处理：

　　根据我上篇文章所介绍的，在节点A收到节点B新的PDU包时，如果和A本地的关于B的模拟运动的坐标不一致时，怎么样在A的屏幕上把B拽到新的PDU包所描叙的点上面去呢，上文中只提了用“很平滑的移动”把B“拉扯”过去，那么实际中应该怎么操作呢？这里介绍四种方法。

　　第一种方法，我取名叫直接拉扯法，大家听名字也知道，就是直接把B硬生生的拽到新的PDU包所描叙的坐标上去，该方法的好处是：简单。坏处是：看了以下三种方法之后你就不会用这种方法了。

　　第二种方法，叫直线行走（Linear），即让B从它的当前坐标走直线到新的PDU包所描叙的坐标，行走速度用上文中所介绍的经典算法：
　　　　目标点 = 原点 + 速度 * 时间差 + 1/2 * 加速度 * 时间差算出：
　　首先算出从当前坐标到PDU包中描叙的坐标所需要的时间：
　　　　T = Dest( TargetB – OriginB ) / Speed
　　然后根据新PDU包中所描叙的坐标信息模拟计算出在时间T之后，按照新的PDU包中的运动信息所应该达到的位置：
　　　　_TargetB = NewPDU.Speed * T
　　然后根据当前模拟行动中的B和_TargetB的距离配合时间T算出一个修正过的速度_S：
　　　　_S = Dest( _TargetB – OriginB ) / T
　　然后在画面上让B以速度_S走直线到Target_B，并且在走到之后调整其速度，方向，加速度等信息为新的PDU包中所描叙的。

　　这种方法呢，非常的土，会让物体在画面上移动起来变得非常的不现实，经常会出现很生硬的拐角，而且对于经常要修改的速度_S，在玩家A的画面上，玩家B的行动会变得非常的诡异。其好处是：比第一种方法要好。

　　第三种方法，叫二次方程行走（Quadratic），该方法的原理呢，就是在直线行走的过程中，加入二次方程来计算一条曲线路径，让Dest( _TargetB – OriginB )的过程是一条曲线，而不是一条直线，恩，具体的实现方法，就是在Linear方法的计算中，设定一个二次方程，在Dest函数计算距离的时候根据设定的二次方程来计算，这样一来，可以使B在玩家A屏幕上的移动变得比较的有人性化一些。但是该方法的考虑也是不周全的，仅仅只考虑了TargetB到_TargetB的方向，而没有考虑新的PDU包中的方向描叙，那么从_TargetB开始模拟行走的时候，仍然是会出现比较生硬的拐角，那么下面提出的最终解决方案，将彻底解决这个问题。

　　最后一种方法叫：立方体抖动（Cubic Splines），这个东东比较复杂，它需要四个坐标信息作为它的参数来进行运算，第一个参数Pos1是OriginB，第二个参数Pos2是OriginB在模拟运行一秒以后的位置，第三个参数Pos3是到达_TargetB前一秒的位置，第四个参数pos4是_TargetB的位置。

Struct pos {
    Coordinate X;
    Coordinate Y;
}

　　　Pos1 = OriginB
　　　Pos2 = OriginB + V
　　　Pos3 = _TargetB – V
　　　Pos4 = _TargetB
运动轨迹中(x, y)的坐标。
　　　x = At^3 + Bt^2 + Ct + D
　　　y = Et^3 + Ft^2 + Gt + H
（其中时间t的取值范围为0-1，在Pos1的时候为0，在Pos4的时候为1）

x(0-3)代表Pos1-Pos4中x的值，y(0-3)代表Pos1-Pos4中y的值
　　　A = x3 – 3 * x2 +3 * x1 – x0
　　　B = 3 * x2 – 6 * x1 + 3 * x0
　　　C = 3 * x1 – 3 * x0
　　　D = x0

　　　E = y3 – 3 * y2 +3 * y1 – y0
　　　F = 3 * y2 – 6 * y1 + 3 * y0
　　　G = 3 * y1 – 3 * y0
　　　H = y0

　　上面是公式，那么下面我们来看看如何获得Pos1-Pos4：首先，Pos1和 Pos2的取值会比较容易获得，根据OriginB配合当前的速度和方向可以获得，然而Pos3和Pos4呢，怎么获得呢？如果在从Pos1到Pos4的过程中有新的PDU到达，那么我们定义它为NewPackage。

　　　Pos3 = NewPackage.X + NewPackage.Y * t + 1/2 * NewPackage.a * t^2
　　　Pos4 = Pos3 – (NewPackage.V + NewPackage.a * t)

如果没有NewPackage的情况下,则Pos3和Pos4按照开始所规定的方法获得。

至此，关于导航推测的算法大致介绍完毕。

欢迎讨论，联系作者：QQ 181194   MSN: xiataiyi@hotmail.com
参考文献《Defeating Lag with Cubic Splines》

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/wind520/archive/2009/02/17/3898948.aspx

暗夜教父 2009-09-07 16:22 发表评论

]]>