有个篮球联盟，有无数个球员和大概20个等级的联赛。

所有球员都是10级联赛的成员，他们自由组合互相比赛，赢的人，升级到11级联赛，输的人降到9级联赛。

然后每个等级联赛再次开赛，又有的人升级有的人降级，最终这20级的联赛都有球员参加。

我们的大量的数据证明，一个球员的水平，会让其稳定在大约3个联赛之间，也就是科比是参加20级联赛的，且当他和4个17级联赛的人组队，基本不会输给17级联赛的人。且，把科比降到10级联赛，他会轻松的在20局之内回到20级。

理想情况下，球员都是在跟自己同样经历的球员玩，一个中等水平玩家完全不会匹配到科比，科比也不会匹配到刚玩游戏的玩家。

事实上匹配系统的分级会比这个更复杂更智能，采用的是国际象棋所采用的elo系统。

再增加个FAQ：

Q：系统为了保持胜率50%，是否会在我连胜后故意塞给我一些菜队友让我输？

A：系统的目的不是为了保持你的胜率，而是让水平差不多的玩家一起玩。当你和水平差不多的玩家一起玩时胜率会趋近50%，所以，系统是不会故意坑你的。

Q：我才100胜，为什么系统老匹配600胜的玩家给我？

A：胜场并不能反应一个人的水平。如果把匹配系统比作跑步，练习了3年才能跑进11秒的和第一次就跑进11秒的人我们是同等看待的。匹配系统基于水平而不是基于经验。

Q：我胜率60%，为什么匹配40%胜率的队友、60%胜率的对手给我？

A：胜率也不能反映水平。匹配系统不但要看你是否赢了，也要看你赢了谁。就像war3的sky在职业圈胜率其实并不高，但是虐一般的玩家胜率是100%。同样水平的玩家，会因为随机匹配到对手的关系，胜率会40%~60%不等。

Q：你说水平差不多，为什么我觉得他们这么菜？

A：匹配系统提供的是公平的机会，而未必是你理想的结果。我们能追求系统公正，但是无法预测玩家单局内的表现。

系统100%匹配曼联对阵皇马，但是不能保证某一次曼联不会4：0碾压皇马，且在这局中，C罗表现yts，完全就在拖后腿。或者曼联也可能连胜皇马3次之类的。但是，系统只会把曼联去匹配皇马而不会出现曼联对阵中超深圳队。具体到某一局是皇马赢还是曼联赢取决于那一场的排兵布阵，临场发挥，以及战术意图。

如果这个坑爹玩家真的不在你的水平等级，他就会一直坑队友，一直输，等级一直降低，这样会让他离开你的匹配范围，让他不再可以和你匹配到。根据我们的数据，玩家的elo基本是稳定在较小范围内的。这也就是深圳队和皇马的差距，也是中国国家队能赢法国队，确永远打不进世界杯的理由。

系统没办法给你完美队友，玩家会因为很多原因发挥不好：使用不会的英雄、打了不想打的位置、玩法风格和队友不够搭配，前期不利想挂机等等。但是你和对方玩家遇到这种情况的概率是相同的，系统并不会偏袒任何一方。所以想要完美队友，请和朋友组队，不过那样你也会碰见更厉害的对手。

如果大家在如何鉴定玩家水平上有好的想法欢迎提，但是如果想要通过抱怨玩家游戏内表现来证明匹配系统不公平，就是在和风车决斗了。每个人的看法都不一样的，系统判断他和你在遇到同样的队友和对手时候，胜率差不多，这也是我们目前能做到最好的了。

以下是文章的正文。

概述：

匹配系统的目的如下，优先级从高到低：

1、 保护新手不被有经验的玩家虐；让高手局中没有新手。

2、 创造竞技和公平的游戏对局，使玩家的游戏乐趣最大化。

3、 无需等待太久就能找到对手进入游戏。

匹配系统尽其所能的匹配水平接近的玩家，玩家的水平是来自他们在此之前赢了谁以及他们对手的水平。当你战胜对手，系统会认为你更强，当你输给对手，系统会认为你更弱。虽然这对于某一局游戏并不是那么的公平，但是长期来看，对于多局游戏是相当的公平：因为好的玩家总会对游戏结果造成正面的、积极的影响。我们使用了这样一个方法测试：给水平高的玩家一个新帐号，然后看他们游戏数局后的结果。我们通过大量的测试来证明了我们的想法。

并且，匹配系统知道预先组队的玩家有一些优势，如果你是预先组队，会给你一些更强的玩家。我们用一些非常巧妙的数学方法来解决预先组队的玩家VS solo玩家的匹配公平问题。我甚至让两个数学博士来验证，他们都说给力！

匹配是怎么完成的？

首先，系统将你放进适当的匹配池里——根据游戏模式（匹配模式、排位solo/双人、排位5人、其他模式等等）

然后，系统会尝试将匹配池里的人分到更细的匹配池里——5人组队 VS 5人组队，低等级新手 vs 其他一些低等级新手，如此这般。

当你在匹配池中，系统会开始尝试找到合适的配对，目标是撮合一个双方获胜机会都为50%的游戏。

第1步：确定你的实力：

*如果你是solo，就直接使用你的个人匹配分（也就是elo值，匹配模式和排位赛有不同的匹配分）

*如果你是预先组队的，你的匹配分是你队伍的平均分，并且会根据你组队的规模稍微提高一些，这样才能保证你匹配到更强的对手来抵消你组队的优势。我和一个计算机生物学的博士（Computational Biology Ph.D）通过研究成百上千的游戏结果，计算出了预先组队到底有多大的优势。我们还在幕后做了一些其他调整，比如新手和高玩组队，比如某地图上蓝队和紫队的玩家哪个更有优势，诸如此类。

第2步：确定你合适的对手：

*首先，系统会基于你的elo值，给你匹配跟你非常相近的玩家。最终，系统会放宽匹配的条件，给你一些不是那么完美的匹配，因为你肯定也不想永远匹配不到人。

*新手会得到一些特殊的保护，通常新手只会匹配到其他新手（在成熟的服务器里，这个比例达到了99%+。除非这个新手和一个高级玩家朋友预先组队）

第3步：确定匹配：

*最终，系统会匹配10个大体上同水平、同等级的玩家，促成一个游戏。

*系统会尝试平衡这个队伍，尽量使双方的获胜机会都为50%。在绝大多数时间，误差会在3%之内——类似50/50，49/51，48/52。实际上的获胜机会会有一点点差别（会在Q&A里面回答这个问题），但是我们的研究标明，在绝大多数情况下，这实际上是一个非常精确的预测。

长期来讲，我的匹配分（Elo值）是如何被测量的？

我们使用了一个修改过的ELO系统。ELO系统的基本要点通过使用数学比较两个人的积分，来预测两人的比赛结果——类似“A和B比赛数局，A会赢掉75%的局”。

然后，比赛结果出来了。如果你赢了，你会加分，如果你输了，你会被扣分。如果你是“出人意料”的赢了（系统认为你输的可能性更大），你会赢得更多的分数。额外的，如果你是一个新玩家，你会加分减分更快，以便于你可以快速的进入到你的水平等级。长期来看，这意味着好的玩家会得到高的匹配分，因为他们总是超过系统的预期，他们会不断加分直到系统可以正确的预测他们的胜率。

我们修改这个系统给团队比赛使用，基本概念是：基于该团队的所有玩家，得到一个团队ELO值。如果你的队伍胜利，系统会假设该队伍的所有玩家都要比系统猜测的“更强”，并且加分。虽然有一些问题，但是总体上来讲是有效的，特别是玩家预先组队的时候。

举例，本人在北美的服务器上有2000的普通匹配模式elo。如果我建一个小号，就算没有天赋和符文，我打到8级的时候就已经有1800elo了。这个系统并不完美，但是确实能够让玩家快速的接近自己水平所在的位置。

当你才开始玩的时候，我们也对ELO做一些微调，让你更快的进入你水平所在的位置。

*我们有大量的，有优先级的方法来鉴定一个玩家，相比一个标准的新玩家是否更有技巧，更猛。如果发现是的，我们会在幕后提高他的elo一个档次。

*我们同样也会分辨真的菜鸟新手。

*提升等级也会极大的提高你的elo值。这个也将帮助系统将30级满级的召唤师和低等级的召唤师区分开来

如果你想知道ELO系统的理论，以及更多细节，你可以看看这：

http://en.wikipedia.org/wiki/Elo_rating_system

http://zh.wikipedia.org/wiki/ELO

呃，等等，你是怎么处理组队玩家 vs solo(单排)玩家的？

我们大多数情况下，会通过将5人组队的队伍匹配给另外一个5人组队的队伍来避免这种情况的发生（几乎是所有情况下）。

发现这些优势，我们就知道对于预先组队的队伍，需要提高多少elo值，来达成一个公平的匹配，确定一个适当的，在数学上合理的调整。结果在有些情况下非常令人惊讶（同时会校正统计数据）。

虽然我们不会给出精确的数值，因为这是商业机密，但是我们可以告诉您：

*5人组队只是比5个路人稍强。

*部分组队只是比5个路人略强。

*菜鸟5人组队并不会带来太大的优势，但是高玩组队会有很大的优势。

*团队实力方差高的队伍，会比方差低的队伍更强。（方差简单来说，是在平均值相同的情况下反应各个元素的大小差异，方差大表示差异大，高方差的队伍类似高玩带低玩，低方差的队伍各个队员实力接近。）

*这说明了大体上，高水平玩家的Carry作用（可以理解为带领或者大腿），比低水平玩家的送人头作用（feeder）要强力。

好吧…那为什么要把预先组队的玩家和非组队玩家匹配到一起？

这是一些原因：

*这会帮助系统更快的找到适合你的匹配分，让系统更快的给你公平的匹配。这个的工作原理是，如果你组队，会减低运气所带来的成分，如果你单排，你的队友的好坏将对你输赢的影响更大。如果你预先组队，你会和你水平差不多的玩家组成队伍，你随机遇到猛男/坑爹队友几率会更小。因为游戏的结果更多来自你和水平相近的朋友的表现，而不是随机因素，所以你的匹配分会更快的到达精确的值。

*我们希望玩家可以和自己的朋友一起玩，因为这样会让他们玩的更有乐趣。你也不可能为5v5的游戏设置单独的2人匹配池或者3人匹配池，你需要组合他们来让系统工作。我们选择包含5人组队，因为这非常有乐趣。如果我们以后有足够大的匹配池，我们可能会将5人组队和部分组队区分开来，但是数据告诉我们，这基本不会提升匹配的公平程度，两者的效果基本相同。

其他一些常见的问题：

Q：为什么不加入一些其他的细节，类似击杀数等等来确定我的匹配分？

A：因为这是有偏差的，并且因为非常难以给击杀数这个数值来评分，你使用一个gank英雄的时候（类似老鼠和易大师），要杀多少人才能算是好的呢？而且这会让好的辅助玩家非常吃亏，因为他们的目的就不是拿人头，甚至会为了自己的Carry挡死。最后，玩家会为了刷数据，故意拖长游戏时间，然后拿大量farm对方的人头，而不是为了赢得比赛。我们尽量把测量玩家水平和激励玩家的机制放到努力取胜上面，我们避免了一些不必要的周边行为，而这些行为既没乐趣，还会扰乱匹配系统。

Q：我非常愤怒，因为匹配系统老给我坑爹队友（feeders，送人头的）。为什么不阻止这种情况发生？

A：我们的确有试图阻止这种情况发生，但是如果你被匹配到一个明显很弱的玩家，这也说明匹配系统同时匹配给你了一个或者多个强力的玩家。根据我们的研究，我们发现Carry（大腿）对队伍的带领作用要比feeder（送人头，坑爹）的坑爹作用更强。原因是在LOL里，多次击杀同一个玩家的收益是会递减的，并不像其他的同类游戏。我们的分析标明，在平均elo相同的情况下，提高或者降低这个队伍的某个玩家的elo值100（其他玩家相应降低/提高以保持平均分相同），整个队伍的实力会提高约7点elo值。这也表明，LOL中Carry的作用要比feeder的作用更给力一些。确实，有时候你会因为匹配到feeder而输掉这一局比赛，但是那是因为你们队的Carry不够给力。

Q：这样的话，如果我连胜了数盘，我是不是会被匹配到一些完全不可战胜的对手？

A：不全是。连胜导致你的匹配分会提高，你会不断遇到更强的对手——但是我们并不是故意的让你的胜率保持在50%的，我们的目的只是为了系统能够正确的预测游戏结果。最终，你会达到你的极限，你将会大致保持50%的胜率。比平均水平高的玩家，往往胜率会比50%略高，因为比他们弱的玩家更多，比他们强的玩家更少。所以匹配时，往往会略微“向下匹配”。对于排位顶尖的高端玩家，他们经常会有90%的胜率。

Q：你们会如何设计固定的队伍？类似WOW的竞技场队伍？

A：这是一个非常好的想法，并且让我们有机会设计出更好的匹配系统。我们迟早会做这个，并且使用我们开发的新方法。我们需要检验并且搞清楚你大体上有多强力（例如你的个人积分），同时允许你创建/解散队伍。这是个非常大的工程，但是我们对此非常有激情~

Q：如果匹配系统真的那么公平，那为何我老遇见那种一边倒的比赛？

A：有两个原因。第一，LOL有时候“雪球效应”会非常明显。前期太差的表现会导致游戏让人感觉非常一边倒。特别是某些队伍，如果他们开始很顺风，就会一直很顺风。我们遇到过同样的队伍，第一局25-5取胜，第2局确以类似的比分输掉。第二个原因是，玩家发挥的并不好，队伍选取阵容也不好。要进行一局势均力敌的比赛，你需要平衡玩家水平和平衡阵容的选取。有时候玩家选了一个比较渣的阵容，比如5个近战dps，或者3坦克2法师之类的，或者没选打野英雄而对面有。这样的话，尽管你的队伍实力也很不错，但是情况往往惨不忍睹。

Q：为什么我作为一个高等级玩家，有时候会匹配到一些低等级玩家？他们看上去都是来送人头的。

A：当一个高等级玩家和一个低等级玩家组队，这是一个非常令人头疼的问题。我们希望玩家可以和自己的朋友一起玩，并且希望这是一种愉快的体验。但是我们并不希望将一部分人的快乐建立在另一部分人的痛苦之上，所以我们往往将这种组合评分更高，保护新玩家不会被高等级玩家虐待。非常不幸的是，不管我们怎么做，我们把这样的组合匹配到任何的游戏中，都有可能造成不愉快的体验。因此，我们计划将实施一个“不平衡组队”的队列，类似我们尽量将5人组队匹配给5人组队。

Q：我20级了，然后我被匹配到了一些10级的和一些29级的，怎么回事？

A：当不同等级的玩家组队，我们会使用他们的平均等级来作为匹配的参考。等级并不是匹配系统的主导参数——匹配系统通常是使用实力来匹配——但是我们也会尽量将等级相近的玩家匹配到一起。在预先组队的情况下，我们没法替玩家选择，所以我们尽我们所能，使用平均等级。我们会在这个计算系统里把30级的玩家看作36级，所以我们通常能让中等级玩家的游戏没有30级玩家，然而有时候呢，29级玩家能插进来。

　　Item类型又派兵出了一类Bag对象，这是一种特殊的物品对象，其本身具有物品的所有属性及方法，但又可作为新的容器类型，并具有自己特有的属性和方法，所以实现上采用了派生。mangos在实现时对Bag的类型定义做了点小技巧，Item的类型为2，Bag的类型为6，这样在通过位的方式来表示类型时，Bag类型也就同时属于Item类型了。虽然只是很小的一个技巧，但在很多地方却带来了极大的便利。

　　从WorldObject派生出的类型就有好几种了，Unit、GameObject、DynamicObject和Corpse。Unit为所有生物类型的基类，同WorldObject一样，也不可被实例化。它定义了生物类型的公有属性，如种族、职业、性别、生命、魔法等，另外还提供了相关的一些操作接口。游戏中实际的生物对象类型为Creature，从Unit派生，另外还有一类派生对象Player为玩家对象。Player与Creature在实现上最大的区别是玩家的操作由客户端发来的消息驱动，而Creature的控制是由自己定义的AI对象来驱动，另外Player内部还包括了很多的逻辑系统实现。

　　另外还有两类特殊的Creature，Pet和Totem，其对象类型仍然还是生物类，只是实现上与会有些特殊的东西需要处理，所以在mangos中将其作为独立的派生类，只是实现上的一点处理。另外在GameObject中也实现有派生对象，最终的继承关系图比较简单，就不麻烦地去画图了。

　　从我所了解的早期游戏实现来看，大部分的游戏对象结构都是采用的类似这种方式。可能与早期对面向对象的理解有关，当面向对象的概念刚出来时，大家认为继承就是面向对象的全部，所以处处皆对象，处处皆继承。

　　类实现的是一种封装，虽然从云风那里出来的弃C++而转投C的声音可能会影响一部分人，但是，使用什么语言本身就是个人喜好及团队整体情况决定的。我们所要的也是最终的实现结果，至于中间的步骤，完全看个人。还是用云风的话说，这只是一种信仰问题，我依然采用我所熟悉的C++，下面的描述也是如此。

　　随着面向对象技术的深入，以及泛型等概念的相继提出，软件程序结构方面的趋势也有了很大改变。C++大师们常说的话中有一句是这样说的，尽是采用组合而不是继承。游戏对象的实现也有类似的转变，趋向于以组合的方式来实现游戏对象类型，也就是实现一个通用的entity类型，然后以脚本定义的方式组合出不同的实际游戏对象类型。

　　描述的有些抽象，具体实现下一篇来仔细探讨下。


在游戏编程精粹四有三篇文章讲到了实体以及实体管理的实现方案，其中一篇文章说到了实体管理系统的四大要素：定义实体怎样沟通的实体消息，实现一实体类代码和数据的实体代码，维护已经注册在案的实体类列表，和用来创建、管理、发送消息的实体管理器。

　　关于实体消息的内容之前讨论事件机制的时候做过一点说明，其实这也就是按接口调用和按消息驱动的区别，现在mangos的做法是完全的接口调用，所以引擎内部就没有任何的实体消息。实体代码实现和实体管理器是我们重点要讨论的内容。

　　另有一篇文章也提到了使用类继续的方式实现游戏对象的两大问题，一是它要求系统中的所有对象都必须从一个起点衍生而成，也就是说所有对象类在编译的时候已经确定，这可能是一个不受欢迎的限制，如果开发者决定添加新的对象类，则必须要对基类有所了解，方能支持新类。另一个问题在于所有的对象类都必须实现同样的一些底层函数。

　　对于第二个问题，可以通过接口继承的方式来避免基类的方法太多。在mangos的实现中就采用了类似的方法，从Object虚基类派生的Unit和WorldObject仍然还是不可实例化的类，这两种对象定义了不同的属性和方法，分来实现不同类型的对象。在游戏内部可以根据对象的实际类型来Object指针向下转型为Unit或WorldObject，以调用需要的接口。方法虽然不够OO，也还能解决问题。但是第一个问题是始终无法避免的。

　　所以我们便有了通用实体这么一个概念，其主要方法是将原来基类的接口进行分类，分到一个个不同的子类中，然后以对象组合的方式来生成我们所需要的实际游戏对象类型。这个组合的过程可以通过脚本定义的方式，这样便可以在运行时生成为同的对象类型，也就解决了上面提到的第一个问题。

　　通用实体的实现方法在目前的游戏引擎及开源代码中也可以看到影子。一个是BigWorld，从提供的资料来看，其引擎只提供了一个entity游戏对象，然后由游戏内容实现者通过xml和python脚本来自由定义不同类型的entity类型，每种类型可有不同的property和不同的方法。这样原来由基类定义的接口完全转移到脚本定义，具有非常强的灵活性。

　　另外还有一个是CEL中的entity实现。按照CEL的描述，entity可以是游戏中的任意对象，包括玩家可交互的对象，如钥匙、武器等，也可以包括不能直接交互的对象，如游戏世界，甚至任务链中的一部分等。entity本身并没有任何特性，具体的功能实现需要靠附加property来完成。简单来说，property才定义了entity可以做什么，至于该怎么做，那又是依靠behavior来定义。所以，最终在CEL中一个游戏对象其实是由entity组合了多个property及多个behavior而生成的。

　　但是CEL中的property与BigWorld中的property意义不大一样，在CEL中可定义的property其实是引擎内部要先提供的，比如其示例中所举的pcobject.mesh、pcmove.linear、pctools.inventory等，而BigWorld中的property是完全的自由定制。从这个角度来讲，其实可以把CEL中的property看作是游戏的逻辑系统，也就是我们上面所描述的，接口分类后所定义的子类。

　　由引擎内部提供可选择的property与BigWorld所采用的完全自由定制property其实本质上是相同的。在用BigWorld实现的游戏中，也不可能为每种游戏对象类型都完全从头定义property，基于代码利用的原则，也会先定义一些小类，然后在entity类型定义时以自定义property的方式来包含这些小类。当然，我没有使用过BigWorld，上面的描述也只是基于游戏实现的大原则所做出来的。

　　描述的依然有些抽象，我们可以用wow及mangos代码来说明一下。mangos中为object定义了一个属性集合，根据对象类型的不同，这个属性集的大小及保存数据也会有差异，另外游戏对象内部含有处理不同游戏逻辑的系统，如RestSystem、FloodFilterSystem、VariousSystem等等，在player.h中以接口组的方式进行定义。

　　如果要将这种结构改为我们描述的通用entity系统，可以让object只提供property注册和删除的接口，这里的property定义与CEL中的相同，放在mangos中也就是上面说的RestSystem、FloodFilterSystem、VariousSystem这些。然后也通过xml文件的方式定义我们所需要的游戏对象类型，如player,creature,item等，不同的对象类型可以选择加载不同的property，加载的原则是需要哪些功能就加载哪些property。

　　对象的定义按上面的方法完成后，对象的实现也需要做一些修改。以前客户端的消息是直接交由player来处理，AI也是直接调用creature的接口来完成一些功能，现在通用的entity内部已经没有任何可用的方法，所有的实现都转到了property中，所以需要由各个property实现自己来注册感兴趣的事件及消息，entity实现一个消息的转发，转给对此感兴趣的property来处理。其余的实现就没有什么不同了。

　　当然，我们再做一点扩展，让property不光由引擎来提供，用脚本本身也能定义property，并且可以通过xml来注册这些property，这样便实现了与BigWorld一样的完全自由特性。这其实也就是将很多用C++实现的功能转移到了python中，这种做法可作为参考，但不一定对所有人合适，至少在我看来，这样的实现也基本只能由程序员来做，所以让程序员选择自己最擅长的语言可能会更易于开发和调试。

有关游戏对象实现的描述，前面两篇文章中说的不甚清楚，主要是一直都要引用网上能够找到的资料来进行描述，以避免与公司引起不必要的麻烦。所以语言有些拼凑的感觉，举的例子也很不恰当，今天正好看到了游戏编程精粹五和六上的两篇文章，内容都差不多，<<基于组件的对象管理>>和<<基于组件的游戏对象系统>>，说的也是我上两篇文章想要描述的内容，所以再补一篇，引用其中的部分文字进行明确的说明。

　　传统的游戏对象管理系统采用继承的方式来实现，例如，所有的子类都从CObject派生。大多数情况下，直接派生的也是抽象类，其中带一些功能而另一些子类则不带这些功能，比如可控制/不可控制，可动画/不可动画等。mangos的实现中基本就是这种情况，从Object直接派生的Unit和WorldObject都是不可直接实例化的类。

　　传统方法的问题在于无法应对需求的变化，如要求武器也有动画效果时就无法处理了。如果硬要是这样做，那随着需求的啬，很多的方法会被放到基类中，最终的结果是继承树变得越来越头重脚轻，这样的类会丧失它的内聚性，因为它们试图为所有对象完成所有的事。

　　就是说到最后，基类会有一个很长的接口列表，而很多的游戏对象类型根本不需要实现其中的一些甚至大部分接口，但是按照这种结构却又必须去实现。以至于于实现一个非常庞大的对象，而且想要修改一点功能会导致系统的大调整。

　　我们希望的系统是可以将现有的功能组合到新的对象中，并且在将新的功能添加到现有的对象中时不需要重构大量的代码和调整继承树的结构。

　　实现的方法就是从组件来创建一个对象。组件是一个包含所有相关数据成员和方法的类，它完成某个特定的任务。把几个组件组合在一起就可以创建一个新的对象。如把Entity组件、Render组件和Collectable组件组合在一起生成了一个Spoon对象。Entity组件让我们可以把对象放到游戏世界中，Render组件让我们可以为对象指定一个模型进行渲染，而Collectable组件让我们可以拾取这个对象。

　　关于组件的实现，所有的组件都从一个基础组件接口派生，可称其为IComponent。每个组件也有自己的接口定义，并且这个接口也需要从IComponent派生，类似于这样：IComponent -- ICmpRender -- CCmpRender

　　这里的每个组件也就是我在上一篇中所说的由引擎提供的属性，或者说在BigWorld中自己实现然后定义的属性，或者使用mangos中的定义，就是一个个的System，虽然mangos并没有将其完全做成组件，但是通过其代码注释可以看到，接口也是按功能组进行了分类，如果要拆分成组件也是比较方便的。

　　组件之间的通信有两种方法，一是用组件ID查询到组件接口指针，然后调用接口方法；二是使用消息的方式，向对象中所有组件发消息。在初始化的时候，每一个组件类型都会告诉对象管理器应该接收什么样的消息。

　　查询接口的方法也就是直接的方法调用，只不过接口不是全部在基类中，所以必须先查询到指定的组件然后才能调用其接口。消息的使用前面已经说过多次，其实现方案也有过说明。

　　最后是关于游戏对象功能的扩展和游戏对象的定义。需要扩展功能也就是需要实现一个新的组件，或者修改现在组件。在大多数情况下，扩展都不会引起结构的很大调整，受影响的最多只是使用到该组件的部分代码。

　　游戏对象定义可采用完全数据驱动的方式，使用xml或者脚本语言来定义对象类型，以及每个类型需要加载的组件。对象类型注册到对象管理器后，由管理器提供创建指定类型的对象的方法。数据驱动的方式能够让策划自由定义游戏对象类型，并且随时可自由创建新的对象类型。

{

if( !m_creature->getVictim() && m_creature->GetCharmInfo() &&

m_creature->GetCharmInfo()->HasReactState(REACT_AGGRESSIVE) &&

u->isTargetableForAttack() && m_creature->IsHostileTo( u ) &&

u->isInAccessablePlaceFor(m_creature))

{ //好多判断：不是我已有的攻击目标，并且我是攻击性的，并且我可以攻击此单位，并且单位是我的敌对方，并且我能够得着它

float attackRadius = m_creature->GetAttackDistance(u);

if(m_creature->IsWithinDistInMap(u, attackRadius) && m_creature->GetDistanceZ(u) <= CREATURE_Z_ATTACK_RANGE) //在我的攻击范围内

{

if(m_creature->IsWithinLOSInMap(u)) //在我的视野中

{

AttackStart(u); //攻击开始消息

u->RemoveSpellsCausingAura(SPELL_AURA_MOD_STEALTH); //去掉我的有隐身状态（有的话）

}

}

}

}

下面看看AttackStart干了什么：

void PetAI::AttackStart(Unit *u)

{

if(!u || (m_creature->isPet() && ((Pet*)m_creature)->getPetType() == MINI_PET)) //一些保护

return;

if(m_creature->Attack(u,true)) //攻击成功

{

m_creature->clearUnitState(UNIT_STAT_FOLLOW); //清除我的跟随状态

m_creature->GetMotionMaster()->MoveChase(u); //通过MotionMaster修改移动类型为Chase，并开始追。MotionMaster的分析见下面

inCombat = true;

}

}

四、MotionMaster

在Unit类中还有个MotionMaster成员，Creature在初始化AI的时候，对MotionMaster进行初始化。MotionMaster维护一个移动的列表并负责不同移动类型的生成。具体的移动类型控制Creature的移动。

下面是MotionMaster生成不同移动类型的接口函数：

void MoveIdle();

void MoveTargetedHome();

void MoveFollow(Unit* target, float dist, float angle);

void MoveChase(Unit* target, float dist = 0.0f, float angle = 0.0f);

void MoveConfused();

void MoveFleeing(Unit* enemy, uint32 time = 0);

void MovePoint(uint32 id, float x,float y,float z);

void MoveSeekAssistance(float x,float y,float z);

void MoveSeekAssistanceDistract(uint32 timer);

void MoveTaxiFlight(uint32 path, uint32 pathnode);

void MoveDistract(uint32 time);

Mangos对移动进行了单独的处理，这个是它的一个亮点和优点。

五、结论

1．Object类主要功能

1) InWorld判断和操作

2) GUID

Mangos的每个对象都有唯一的GUID，每类GUID的最大值是保存在数据库中，初始化时候从数据库加载。Mangos这样做还是很奢侈的，国内服务器可能都存在合服需求，所以国内服务器操持角色ID不同即可。可能要合服的服务器在开服的时候要把的角色ID范围要规划好(天龙八部的角色ID的最大值是保存在数据库中的)。国内服务器中对于重要物品、宠物可能需要唯一的ID，可以考虑角色ID + 物品、宠物id来实现。uint32应该够用了，但是也要限制重要物品的种类和数量。

3) Object类型TypeId

enum TypeID

{

TYPEID_OBJECT = 0,

TYPEID_ITEM = 1,

TYPEID_CONTAINER = 2,

TYPEID_UNIT = 3,

TYPEID_PLAYER = 4,

TYPEID_GAMEOBJECT = 5,

TYPEID_DYNAMICOBJECT = 6,

TYPEID_CORPSE = 7

};

4) 网络包发送SendUpdateToPlayer

5) 基本状态组包Values、OutOfRange、Movement UpdateBlock等

6) Int, UInt, float等标记数据设置、加载、访问Get/SetXXXValue、SetFlag

union

{

int32 *m_int32Values;

uint32 *m_uint32Values;

float *m_floatValues;

};

Object有很多数据、状态以数组形式存储，访问时候通过类型和标记定位。

7) 任务判断接口hasQuest

2．Item类主要功能

1) 创建和复制Create/CloneItem

2) 所有者Owner(Player)

3) 数据库存取SaveTo/LoadFromDB

Mangos的每个Item在数据中是作为一条记录保存的，一般国内网游是打包保存在玩家记录里面，国内网游的做法在数据库效率上要高很多。

4) 绑定Binding、损坏Broken、是否可交易CanBeTrade、叠放数量、是否装备等一般道具属性

5) 在包中的位置Bag、Slot

6) 增强状态和时效Enhancement

7) Timer更新

8) 状态更新和广播State

9) 技能和魔法相关Skill/Spell

10) 任务相关hasQuest

3．Bag类主要功能

1) 增加、删除、得到某位置的道具Store/RemoveItem

2) 空间IsEmpty、GetFreeSlots

3) 数据库存取SaveTo/LoadFromDB

4) 组包更新BuildCreateUpdateBlockForPlayer

4．WorldObject类主要功能

1) 位置和朝向Relocate、SetOrientation

2) 附近空间位置GetClosePoint

3) 所在地图、区域和地区GetMapId、GetZoneId、GetAreaId

4) 名字GetName

5) 和其它WorldObject位置、角度等关系IsWithinDist、IsInRange

6) 发送网络消息SendMessageToSet

7) 发送聊天、喊叫等消息MonsterSay、MonsterYellToZone

8) 对玩家来说是否可见isVisibleFor

9) 召唤Creature，SummonCreature

5．Unit类主要功能

Unit类是很复杂的一个类，改类具有很多属性和方法，实现了游戏中Player，Creature等主要功能。

1) 渐变状态GetDiminishing

2) 战斗相关（计时器、攻击对象、停止等）setAttackTimer、Attack、getVictim、SendMeleeAttackStop

3) 单元状态addUnitState

4) 等级、种族、职业、装甲、血量、伤害能力等属性getLevel、getGender、getRace、GetArmor、GetHealth、GetPower

5) 友好、敌对等阵营关系IsHostileTo、IsFriendlyTo

6) 站立、行走、骑乘、战斗、飞行、水下、恐惧、死亡等状态getStandState、IsMounted、DeathState

7) 技能和伤害处理DealDamage、MeleeSpellHitResult、GetWeaponSkillValue

8) 类型（商店、银行、飞行点、行会、拍卖行等）isVendor、isBanker

9) 施展法术CastSpell

10) 光环状态和特效以及数值影响HasAura、RemoveAura

11) 广播伤害、攻击状态等消息SendAttackStateUpdate、SendSpellMiss

12) 主人、召唤者、宠物等信息GetOwnerGUID、SetCharmerGUID、GetPet

13) 状态更新广播stat system

14) 可见性处理Visibility system

15) 威胁值处理Threat related methods

16) DynamicObject对象和GameObject对象的附加GetDynObject

17) event处理m_Events

18) MotionMaster

Unit类设计得过大，还包含了战斗、技能、伤害处理、光环状态影响等这些比较复杂的功能模块。

6．Creature类主要功能

1) 加入到世界

2) 加载装备

3) 数据库存取

4) 类型，是否是车辆、宠物、图腾、精英等

5) 能力，能否行走、游泳、飞行

6) 对技能免疫

7) AI和脚本

8) 售卖的道具

9) 状态更新

10) 对话内容

11) 聊天、喊叫

12) 战斗行为，寻求帮助

13) 重生处理

14) 任务相关

7．Player类主要功能

1) 加入到世界

2) 传送

3) 更新

4) 社会关系

5) 飞机

6) 位置

7) 宠物

8) 聊天

9) 装备、背包和仓库

10) 增强状态

11) 完整的任务处理

12) 数据库存取

13) 邮件

14) 技能

15) 天赋

16) 声望

17) 战场

18) 战斗状态和模式更新

19) 竞技场

20) 移动处理

21) 副本

22) 组队

Player类是继Unit类后另外一个很大的类，实现和很多功能。我现在很佩服Mangos服务器的程序员的水平了，这么多功能，居然一个类搞定。这样的代码对后继维护和修改者绝对是噩梦。

其它类比较小，略过。

一、acceptor socket的监听启动及注册

mangosd的main ()函数调用单例对象sMaster的Run ()函数，启动监听socket的代码如下：

   1: int Master::Run()

   2: {

   3:     ........

   4:  

   5:     ///- Launch the world listener socket

   6:     uint16 wsport = sWorld.getConfig (CONFIG_UINT32_PORT_WORLD);

   7:     std::string bind_ip = sConfig.GetStringDefault ("BindIP", "0.0.0.0");

   8:  

   9:     if (sWorldSocketMgr->StartNetwork (wsport, bind_ip) == -1)

  10:     {

  11:         sLog.outError ("Failed to start network");

  12:         Log::WaitBeforeContinueIfNeed();

  13:         World::StopNow(ERROR_EXIT_CODE);

  14:         // go down and shutdown the server

  15:     }

  16:  

  17:     sWorldSocketMgr->Wait ();

  18:  

  19:     ........

  20: }

mangosd用WorldSocketMgr类来管理socket。StartNetwork ()会调用StartReactiveIO ()来启动监听socket，处理代码如下：

   1: int WorldSocketMgr::StartReactiveIO (ACE_UINT16 port, const char* address)

   2: {

   3:     ........

   4:  

   5:     //（1）

   6:     m_NetThreadsCount = static_cast<size_t> (num_threads + 1);

   7:     m_NetThreads = new ReactorRunnable[m_NetThreadsCount];

   8:  

   9:     // -1 means use default

  10:     m_SockOutKBuff = sConfig.GetIntDefault ("Network.OutKBuff", -1);

  11:     m_SockOutUBuff = sConfig.GetIntDefault ("Network.OutUBuff", 65536);

  12:     if ( m_SockOutUBuff <= 0 )

  13:     {

  14:         sLog.outError ("Network.OutUBuff is wrong in your config file");

  15:         return -1;

  16:     }

  17:  

  18:     //（2）

  19:     WorldSocket::Acceptor *acc = new WorldSocket::Acceptor;

  20:     m_Acceptor = acc;

  21:  

  22:     ACE_INET_Addr listen_addr (port, address);

  23:     if (acc->open (listen_addr, m_NetThreads[0].GetReactor (), ACE_NONBLOCK) == -1)

  24:     {

  25:         sLog.outError ("Failed to open acceptor ,check if the port is free");

  26:         return -1;

  27:     }

  28:  

  29:     //（3）

  30:     for (size_t i = 0; i < m_NetThreadsCount; ++i)

  31:         m_NetThreads[i].Start ();

  32:  

  33:     return 0;

  34: }

（1）ReactorRunnable类继承了ACE_Task_Base，ACE_Task_Base 是ACE 中的任务或主动对象“处理结构”的基类。在ACE 中使用了此类来实现主动对象模式。所有希望成为“主动对象”的对象都必须从此类派生。可以把ACE_TASK 看作是更高级的、更为面向对象的线程类[1]。ACE_Task_Base调用时继承类必须重写svc方法，并且在使用时保证调用了activate ()方法。

（2）指定监听地址，端口并把Acceptor绑定到第一个线程的Reactor上。启动Acceptor开始监听网络IO。

（3）启动所有线程，每个线程上有一个单独的ACE_Reactor* m_Reactor;，这里的Reactor使用的是多线程的ACE_TP_Reactor。可以各自单独完成事件的多路复用。

二、线程体函数

线程体函数ReactorRunnable::svc () 如下：

   1: virtual int svc ()

   2: {

   3:     //（1）

   4:     WorldDatabase.ThreadStart ();

   5:     

   6:     SocketSet::iterator i, t;

   7:     while (!m_Reactor->reactor_event_loop_done ())

   8:     {

   9:         // dont be too smart to move this outside the loop

  10:         // the run_reactor_event_loop will modify interval

  11:         ACE_Time_Value interval (0, 10000);

  12:  

  13:         //（2）

  14:         if (m_Reactor->run_reactor_event_loop (interval) == -1)

  15:             break;

  16:  

  17:         //（3）

  18:         AddNewSockets ();

  19:  

  20:         for (i = m_Sockets.begin (); i != m_Sockets.end ();)

  21:         {

  22:             //（4）

  23:             if ((*i)->Update () == -1)

  24:             {

  25:                 t = i;

  26:                 ++i;

  27:                 (*t)->CloseSocket ();

  28:                 (*t)->RemoveReference ();

  29:                 --m_Connections;

  30:                 m_Sockets.erase (t);

  31:             }

  32:             else

  33:                 ++i;

  34:         }

  35:     }

  36:  

  37:     WorldDatabase.ThreadEnd ();

  38:     DEBUG_LOG ("Network Thread Exitting");

  39:  

  40:     return 0;

  41: }

（1）会调用mysql_thread_init ()函数，初始化与该线程相关的变量。

（2）run_reactor_event_loop ()函数为多路复用的等待函数，当注册的事件发生、运行超时或者出现错误时返回。

（3）AddNewSockets ()函数会将缓存在m_NewSockets里的新到达的socket添加到SocketSet m_Sockets;里，同时检查并处理m_Sockets;里已经closed的socket。

（4）循环每一个WorldSocket，调用其Update ()方法，这里只处理每个socket的handle_output，即每个在此线程上的写事件，向客户端发送数据。下一节详细介绍：

三、WorldSocket::Update () 方法

Update方法用于处理每个socket的输出：

   1: int WorldSocket::Update (void)

   2: {

   3:     if (closing_)

   4:         return -1;

   5:  

   6:     //（1）

   7:     if (m_OutActive || m_OutBuffer->length () == 0)

   8:         return 0;

   9:  

  10:     return handle_output (get_handle ());

  11: }

（1）m_OutBuffer有数据时才会调用handle_output，handle_output ()用于处理输出，如果输出不能一次性做完，会调用schedule_wakeup_output ()再次激活write事件。当输出处理完毕后则调用cancel_wakeup_output ()取消激活write事件，使reactor恢复到正常的loop ()循环中。详细过程如下：

   1: int WorldSocket::handle_output (ACE_HANDLE)

   2: {

   3:     //（1）

   4:     ACE_GUARD_RETURN (LockType, Guard, m_OutBufferLock, -1);

   5:  

   6:     if (closing_)

   7:         return -1;

   8:  

   9:     const size_t send_len = m_OutBuffer->length ();

  10:     if (send_len == 0)

  11:         return cancel_wakeup_output (Guard);

  12:  

  13: #ifdef MSG_NOSIGNAL

  14:     ssize_t n = peer ().send (m_OutBuffer->rd_ptr (), send_len, MSG_NOSIGNAL);

  15: #else

  16:     ssize_t n = peer ().send (m_OutBuffer->rd_ptr (), send_len);

  17: #endif // MSG_NOSIGNAL

  18:  

  19:     if (n == 0)

  20:         return -1;

  21:     else if (n == -1)

  22:     {

  23:         if (errno == EWOULDBLOCK || errno == EAGAIN) //----------（2）

  24:             return schedule_wakeup_output (Guard);

  25:  

  26:         return -1;

  27:     }

  28:     else if (n < (ssize_t)send_len) //now n > 0      //----------（3）

  29:     {

  30:         m_OutBuffer->rd_ptr (static_cast<size_t> (n));

  31:  

  32:         // move the data to the base of the buffer

  33:         m_OutBuffer->crunch ();

  34:  

  35:         return schedule_wakeup_output (Guard);

  36:     }

  37:     else //now n == send_len                         //----------（4）

  38:     {

  39:         m_OutBuffer->reset ();

  40:  

  41:         if (!iFlushPacketQueue ())

  42:             return cancel_wakeup_output (Guard);

  43:         else

  44:             return schedule_wakeup_output (Guard);

  45:     }

  46:  

  47:     ACE_NOTREACHED (return 0);

  48: }

（1）对m_OutBuffer加锁。

（2）考虑信号打断的情况等，暂时不能写。

（3）只发送了部分数据则继续wakeup该线程对应的Reactor。

（4）检查m_OutBuffer数据发送完毕同时等待buffer（PacketQueueT m_PacketQueue;）里已经没有数据时，cancel wakeup让Reactor恢复正常。

四、socket到对应线程的指派

上一节内容可以看到线程内如何处理socket，及新到达的socket。但从第一节中可知只有第一个线程注册为acceptor线程，那么新连接到达时，是如何被指派到对应的“接待”线程的呢？

可以先看一下ACE_Acceptor的处理时序图：

图3.1 连接到达处理时序 [2]

上图可以看出，当连接到达时，acceptor会调用对应的SVC_HANDLER的open ()函数，在mangosd里就是acceptor对应的int WorldSocket::open (void *a)，如下：

   1: int WorldSocket::open (void *a)

   2: {

   3:     ........

   4:  

   5:     // Hook for the manager.

   6:     if (sWorldSocketMgr->OnSocketOpen (this) == -1)

   7:         return -1;

   8:  

   9:     ........

  10: }

OnSocketOpen方法：

   1: int WorldSocketMgr::OnSocketOpen (WorldSocket* sock)

   2: {

   3:     ........

   4:  

   5:     // we skip the Acceptor Thread

   6:     size_t min = 1;

   7:  

   8:     MANGOS_ASSERT (m_NetThreadsCount >= 1);

   9:  

  10:     //（1）

  11:     for (size_t i = 1; i < m_NetThreadsCount; ++i)

  12:         if (m_NetThreads[i].Connections () < m_NetThreads[min].Connections ())

  13:             min = i;

  14:  

  15:     return m_NetThreads[min].AddSocket (sock);

  16: }

（1）将WorldSocket均衡的分配给每个线程。AddSocket ()将socket添加到m_NewSockets中做缓存，待该线程自行调用AddNewSockets ()添加到处理队列里。

总结：

mangosd对socket的处理因为使用了ACE，逻辑处理代码相对比较简单，写事件的异常处理主要涉及

（1）一次不能写完则不断的wakeup Reactor。

（2）信号中断等错误的判断。似乎这里并没有考虑全面（见附录）

（3）使用另一个buffer缓存，因写缓存m_OutBuffer满而带来的多出的数据。

References：

[1] http://blog.csdn.net/yecao_kinux/article/details/1546914

[2] http://postfiles12.naver.net/data41/2009/4/11/187/33_kbkim007.jpg?type=w3

本文将介绍客户端连接到mangosd后，mangosd认证客户端合法性并最终建立RC4流加密的过程。具体过程如下：

（1） 客户端与mangosd建立TCP连接后，mangosd会向客户端发送消息SMSG_AUTH_CHALLENGE

   1: int WorldSocket::open (void *a)

   2: {

   3:     ........

   4:  

   5:     // Send startup packet.

   6:     WorldPacket packet (SMSG_AUTH_CHALLENGE, 4);

   7:     packet << m_Seed;

   8:     if (SendPacket (packet) == -1)

   9:         return -1;

  10:  

  11:     ........

  12: }

m_Seed是一个随机数，每次客户端连接上来的时生成一个新的随机数（随着WorldSocket的创建而初始化）。

（2）客户端收到SMSG_AUTH_CHALLENGE消息后，知道服务器要求其提供身份认证信息，于是开始构造CMSG_AUTH_SESSION消息。（以下代码并非客户端真实代码）

   1: //client do auth

   2: {

   3:     BigNumber clientSeed;

   4:     clientSeed.SetRand(4 * 8);

   5:     sha.Initialize();

   6:     sha.UpdateData("abu");

   7:     uint32 t = 0;

   8:     sha.UpdateData((uint8 *)&t, 4);

   9:     sha.UpdateBigNumbers(&clientSend, NULL);

  10:     sha.UpdateData((uint8 *)&serverSeed, 4);

  11:     sha.UpdateBigNumbers(&K, NULL);

  12:     sha.Finalize();

  13:  

  14:     uint32 unk2;

  15:     ByteBuffer pktbuf;

  16:     string account = "abu";

  17:     uint16 pktbuf_size = 4+4+4+account.length()+4+20;

  18:     EndianConvertReverse(pktbuf_size);

  19:     pktbuf << uint16(pktbuf_size);

  20:     pktbuf << uint32(CMSG_AUTH_SESSION);

  21:     pktbuf << uint32(5875); //build version

  22:     pktbuf << unk2;

  23:     pktbuf << account;

  24:     pktbuf.append(clientSeed.AsByteArray(4), 4);

  25:     pktbuf.append(sha.GetDigest(), 20);

  26:  

  27:     send((char const*)pktbuf.contents(), pktbuf.size());

  28: }

其中最为关键的是构造20位的sha验证密文M：

M = sha(t, account, clientSeed, serverSeed, K);

t为0；account是明文的用户名；clientSeed是由客户端生成的随机数，用于本次连接游戏session；serverSeed是SMSG_AUTH_CHALLENGE消息发过来的服务器随机数；K是之前和realmd交互做keyexchange时生成的，由服务器和客户端分别进行计算，SRP6算法要求(保证)两边的计算结果一致，服务器端保存在realmd.account.sessionkey字段。

（3）服务器收到客户端发来的CMSG_AUTH_SESSION，首先对收到的数据包进行分析，客户端发来的数据包的包头如下：

   1: struct ClientPktHeader

   2: {

   3:     uint16 size; //packet_size except itself

   4:     uint32 cmd;  //opCode

   5: };

收到客户端发来的data，处理流程可以简化为如下代码：

int WorldSocket::handle_input (ACE_HANDLE)

{

……………

handle_input_missing_data()

{

handle_input_header();

handle_input_payload()

{

const int ret = ProcessIncoming (m_RecvWPct);

}

}

}

在ProcessIncoming()函数中使用switch case把客户端发过来的不同的opcode定位到不同的处理函数中，而登录认证过程需要定位到int WorldSocket::HandleAuthSession (WorldPacket& recvPacket)函数。

在HandleAuthSession()函数中，服务器以客户端相同的方式计算sha密文，并和客户端传来的做比较，如果相同则认证通过，然后创建WorldSession实例，初始化m_Crypt成员，以便以后服务器和客户端之间交互的RC4对称加密使用。最后把新创建的WorldSession对象的m_Session添加到游戏世界中，添加完毕后，在游戏世界的主线程(Update线程)可以对该客户端做相应的处理。

（4）HandleAuthSession()处理的最后会使用下面的代码，进行判断：如果session可以作为normal_session的而不是queue_session则发送SMSG_AUTH_RESPONSE消息，至此所有发送的消息都将进行RC4的流加密。

   1: void World::AddSession_ (WorldSession* s)

   2: {

   3:     ........

   4:  

   5:     if (pLimit > 0 && Sessions >= pLimit && s->GetSecurity () == SEC_PLAYER )

   6:     {

   7:         AddQueuedSession(s);

   8:         UpdateMaxSessionCounters();

   9:         DETAIL_LOG("PlayerQueue: Account id %u is in Queue Position (%u).", s->GetAccountId (), ++QueueSize);

  10:         return;

  11:     }

  12:  

  13:     // Checked for 1.12.2

  14:     WorldPacket packet(SMSG_AUTH_RESPONSE, 1 + 4 + 1 + 4);

  15:     packet << uint8 (AUTH_OK);

  16:     packet << uint32 (0);                                   // BillingTimeRemaining

  17:     packet << uint8 (0);                                    // BillingPlanFlags

  18:     packet << uint32 (0);                                   // BillingTimeRested

  19:     s->SendPacket (&packet);

  20:  

  21:     ........

  22: }

总结：

（1）realmd和mangosd在登录认证过程中，相互之间基本不通信，通过MySQL来传递client认证所需的sessionkey。

（2）每次客户端和mangosd之间认证时，各自生成一个随机数Seed，保证在传输过程中隐藏sessionkey。

图中的（1）~（7）详细过程如下：

（1）Client启动后立即尝试连接realmlist.wtf文件中指定的认证服务器，就发送LogonChallenge给认证服务器realmd。协议结构如下：

   1: typedef struct AUTH_LOGON_CHALLENGE_C

   2: {

   3:     uint8   cmd;                //Cmd is the command/operation code of the packet. Always 0 for this message

   4:     uint8   error;

   5:     uint16  size;            //Size of the remaining part of the message

   6:     uint8   gamename[4];    //4 byte C-String, containing the String "WoW\0"

   7:     uint8   version1;            //Major version number of the client ( 1 for 1.12.1 )

   8:     uint8   version2;            //Minor version number of the client ( 12 for 1.12.1 )

   9:     uint8   version3;            //Patchlevel version number of the client ( 1 for 1.12.1 )

  10:     uint16  build;            //Build number of the client. ( 5875 for 1.12.1 )

  11:     uint8   platform[4];        //Platform the client is running on, reversed C-String ( "68x\0" for x86 )

  12:     uint8   os[4];            //OS the client is running on, reversed C-String ( "niW\0" for Windows )

  13:     uint8   country[4];        //Locale of the client, reversed C-String ( "SUne" for enUS )

  14:     uint32  timezone_bias;

  15:     uint32  ip;                //IP address of the client in binary format

  16:     uint8   I_len;            //Length of the Identity ( user name ) in characters

  17:     uint8   I[1];                //The Identity string ( user name )

  18: } sAuthLogonChallenge_C;

uint8 I[1]是一个unsigned char的变长数组的头指针，保存user name，服务器端保存的时候要把\0后面的东西去掉，防止SQL injection。（1.1）执行“SELECT sha_pass_hash,id,locked,last_ip,gmlevel,v,s FROM account WHERE username = '%s'”语句从数据库中读取数据。

realmd收到sAuthLogonChallenge_C协议后处理步骤如下：

1) 检查该ip是否被封禁，如果是发送相应的错误

2) 查询数据库中是否有该账户，如果没有返回相应的错误

3) 查看最后一次登录ip与账户是否绑定，如果绑定对比当前ip与last_ip是否一致

4) 检查该账号是否被封禁，如果是发送相应的错误信息

5) 获取用户名密码，开始SRP6计算，参见本文最下方的附录《MaNGOS所使用的SRP6算法》

6) _accountSecurityLevel，保存用户的权限等级，普通用户、GM、admin等等

7) 本地化：根据_localizationName的名字找对应的.mpq文件所在的位置比如enUS，zhTW，zhCN

（2） realmd向client发送challenge，协议如下：

   1: typedef struct

   2: {

   3:     uint8   cmd;            //Cmd is the command/operation code of the packet. Always 0 for this message.

   4:     uint8   error;

   5:     uint8   unk2;        //random value

   6:     uint8   B[32];        //B is an SRP6 value. It is the server's public value.

   7:     uint8   g_len;        //Length of the SRP6 g value we send the client in bytes. Always 1

   8:     uint8   g[1];            //The SRP6 g value we send the client. Always 7

   9:     uint8   N_len;        //Lenght of the SRP6 N value we send the client. Always 32

  10:     uint8   N[32];        //The SRP6 N value we send the client. 

  11:     uint8   s[32];        //The SRP6 s value

  12:     uint8   unk3[16];        //a randomly generated 16 byte value.

  13:     uint8   unk4;        //a single byte 0.

  14: } sAuthLogonChallenge_S;

（3）客户端的Handshaking阶段，client为了回应realmd的challenge消息，证明client的密码和server上保存的密码一致，需要计算M1值，并发送给realmd，发送的协议如下：

   1: typedef struct AUTH_LOGON_PROOF_C

   2: {

   3:     uint8   cmd;                    //Cmd is the command/operation code of the packet. Always 1 for this message

   4:     uint8   A[32];                //The client SRP6 A value ( public client value ).

   5:     uint8   M1[20];                //The client's SRP6 M value.待比较的最终值

   6:     uint8   crc_hash[20];            //doesn't seem to be used

   7:     uint8   number_of_keys;        //It also seems to be always 0

   8:     uint8   securityFlags;                 // 0x00-0x04

   9: } sAuthLogonProof_C;

计算公式如下，各个变量的含义请查看本文最下方的附录《MaNGOS所使用的SRP6算法》

A = g^a mod N //a为19个字节的随机数

B = (kv + g^b) mod N

u = H(A, B)

x = H(s, p)

S = (B - kg^x) ^ (a + ux)

K = H(S)

M = H(H(N) xor H(g), H(I), s, A, B, K)

上诉的哈希函数H都使用的是SHA1

（4）realmd收到client发来的Proof协议，(a)开始检查版本是否允许，(b) 使用SRP6计算M值，与client传过来的M1做对比，if (!memcmp(M.AsByteArray(), lp.M1, 20)) { } (c) 如果M值相等计算K —— 即sessionkey，并最终保存到数据库。

（5）验证成功，realmd向client发送server的logon proof

   1: typedef struct AUTH_LOGON_PROOF_S

   2: {

   3:     uint8   cmd;

   4:     uint8   error;

   5:     uint8   M2[20];            //The SRP6 M values，M = H(H(N) xor H(g), H(I), s, A, B, K)

   6:     uint32  unk1;            // AccountFlags (trial 0x08, ProPass 0x800000, gm 0x01)

   7:     uint32  unk2;            // SurveyId

   8:     uint16  unk3;            // some flags (AccountMsgAvailable = 0x01)

   9: } sAuthLogonProof_S;

（6）_HandleRealmList，查询realmcharacters表获得角色和realmid的对应关系，然后可以在RealmList类里通过realmid找到对应的表项，RealmList在初始化的时候再realmlist表里读取数据放在内存里使用：“SELECT id, name, address, port, icon, realmflags, timezone, allowedSecurityLevel, population, realmbuilds FROM realmlist WHERE (realmflags & 1) = 0 ORDER BY name ” 查询逻辑服务器。

（7）发送realmlist给客户端，客户端选择对应的服务器后点击enter world的时，会主动断开和realmd的连接。

总结：整个登录认证过程主要干了如下几件事

(a)使用公钥算法验证client的合法性。

(b)client合法的情况下，计算sessionkey并保存在MySQL里，以备后面的逻辑服务器使用。

(c)验证通过后，把逻辑服务器列表发给client。

其中最为重要的就是在验证合法性、交换密钥的过程中，如何在传递的协议里隐藏client的密钥，使其在被截获的情况下也无法被黑客解析，这就只能依仗密码学了。WOW所使用的加密算法是SRP6，详细的介绍如下：

附录：MaNGOS所使用的SRP6算法

SRP全称Secure Remote Password(安全远程密码).使用SRP的客户机和服务器不会在网络上传送明文密码，这样可以消除直接密码嗅探行为，另外使用高强度的算法保证了不可能使用字典法攻击嗅探到的数据[1]。SRP协议的描述见 http://srp.stanford.edu/design.html

SRP6名词解释：

N - A large safe prime (N = 2q+1, where q is prime) All arithmetic is done modulo N.

g - A generator modulo N

k - Multiplier parameter (k = H(N, g) in SRP-6a, k = 3 for legacy SRP-6)

s - User's salt

I - Username

p - Cleartext Password

H() - One-way hash function

^ - (Modular) Exponentiation

u - Random scrambling parameter

a,b - Secret ephemeral values

A,B - Public ephemeral values

x - Private key (derived from p and s)

v - Password verifier

对应MaNGOS的计算方法和变量含义：

sha_pass_hash：使用这个函数进行Sha1Hash哈希std::string AccountMgr::CalculateShaPassHash(std::string& name, std::string& password)后得到的值。

N： A large safe prime (N = 2q+1, where q is prime)， All arithmetic is done modulo N. 在MaNGOS里N被设成N.SetHexStr("894B645E89E1535BBDAD5B8B290650530801B18EBFBF5E8FAB3C82872A3E9BB7");

s： 32个字节的随机数，算过一次后保存在数据库里。

x： 计算v值使用到的x，即私钥是s与数据库里的sha_pass_hash的倒置的Sha1Hash

v： g^x mod N，验证密码时使用Password verifier，算过一次后保存在数据库里。

g： g = 7

b： 为19个字节的随机数，每次client连接认证的时候重新生成。

a： 19个字节的随机数，由客户端产生。

B： 公钥， gmod = g^b, N , B = ((v * 3) + gmod) % N

K： 认证通过后最终保存到数据库里的sessionkey，(1)计算A 客户端公钥A = g^a mod N a为19为随机数，（2）计算x，x = sha(s, I)，I = sha(“username : password”)； （3）计算u，u = sha(A, B) //（服务公钥，客户公钥）；（4）计算S，S = (B - g^x*3)^(a+u*x)； （5）计算K，S为32位，K为40位是 sha(s奇部分）20位, sha(s偶部分）20位的奇偶交错组合。

M： 20个字节的数，用于与client传过来的最终结果M1进行对比，如果M和M1每个字节都相等则验证通过。计算方法：t3 = sha(N)[i] ^ sha(g)[i]，t4 = sha(username)，M = sha(t3,t4,s,A,B,K)

k： k = 3

总结：服务端,客户端各自计算S的公式个不同，公钥部分服务端用A,b, 客户端用B,a 但其计算结果相同………私钥x被很好的隐藏了，因为想从M获得x是基本不可能的！基于数学难题基础上的加密算法确实很给力。

References：

[1]http://blog.csdn.net/lfhfut/article/details/1124768

[2]http://www.arcemu.org/wiki/

[3]http://hi.baidu.com/zyy503950958/blog/item/3addce90a91eda81a877a463.html

What is MaNGOS?

The mangos project is a full featured World of Warcraft server suite, including servers for authentication, client updates, world content serving, and battlegrounds. Additional features include tools to build and develop game content. It is compatible with client version 3.3.5a.

mangos is an educational project. This means, our primary interest is to learn and teach us and our users more about C++ project development in a large scale. Our software is not intended for running public servers, and we do not support that.

本篇所编译的mangos版本是MaNGOS-Zero，对应的客户端版本是1.12.1 (build 5875) ~ 1.12.2 (build 6005)。这是现在所能找到的最原始的版本，之所以选择这个版式，因为想看看mangos“化妆前”的摸样，从较早的版本开始看也是我的习惯。

主要的编译过程和方法参照：http://hi.baidu.com/sunsee/blog/item/8b34f043238dd51972f05d15.html

client 1.12.1(build 5875)的下载地址是：http://thepiratebay.org/torrent/5158084/World_of_Warcraft_1.12.1_Full_Client___Patches

这里主要进行以下补充和一些注意事项的说明：

1. 获取代码：使用git从下面给出的mangos、scripts和database三个连接里去获取对应的代码，没有注册登录就直接用http下载可能不是最新的版本，导致程序版本和db版本对不上。“Looking for client 1.12.1 support? No need to hold your breath, there is a solution for you. mangos zero, an offspring project of mangos has your back covered. The server, the scripts, and the database are available. mangos zero has its' own forums, too”
2. 检查版本一致：下载完毕后对照/mangos-zero/src/shared/revision_sql.h文件里的三个宏：REVISION_DB_CHARACTERS、REVISION_DB_MANGOS、REVISION_DB_REALMD的值和所下载的database对应的表是否一致，分别对应：character/character_db_version、mangos/db_version、realmd/realmd_db_version
3. DB版本：其实直接使用mangos-zero/sql目录下的sql文件也是可以的，不需要单独取database文件。
4. 所需配置文件：realmd.exe、mangos.exe运行所需要的配置文件分别是mangosd.conf、realmd.conf、mods.conf、scriptdevzero.conf在mangos目录下能找到以*.dist.in结尾的配置文件模板，拷贝并修改名字后即可使用。
5. ScriptDev2：要放在src/binding目录下，VS2010可以顺利的编译通过。VS2005要编译Debug版没有问题，编译成Debug_NoPCH不能通过，不知道为什么？
6. contrib：mangos/contrib目录下是各种小工具及源码，包括解压maps的ad.exe，解压vmaps的vmap_extractor。
7. 解压vmaps文件：将使用/contrib/vmap_extract_assembler_bin目录下的所有文件拷贝到客户端的根目录，运行makevmaps_SIMPLE.bat即可。如果系统中存在两个以上的WOW客户端，则需要按照以下步骤进行：(a)使用-d参数指定目录的位置，比如 vmapextractor3.exe -d Data 等待程序提取和分析map data；(b)然后再相同目录下直接运行vmap_assembler.exe生成vmaps

配置文件说明：

（1）mangos.conf

• 看代码时经常会设置断点，为了不让连接断开可以将配置文件里的MaxOverspeedPings设置为0

二、事件分发和处理
WorldRunnable::run---World:update----World:UpdateSessions---WorldSession::Update(一个socket内所有事件)---各种各样的handler

基本框架：ACE的Reactor机制（ACE_TP_Reactor）

三、WorldRunnable 主要功能
WorldRunnable ----World 定时器任务+网络事件（session中的）+异步IO回调+任务系统调度+cli

 SQLite和H2内存数据库都比较快。

u       查询性能：查询一条记录 SQLite的性能要优于H2。查询（5000或10000）条 H2的性能要好于SQLite。

u       插入性能：性能差不多快，SQLite略快。

u       更新性能：更新一条记录 SQLite的性能好于H2。更新多条记录（有索引），SQLite【0.04s】的性能要好于H2【0.18s】

u       删除性能：删除一条记录.SQLite【非常小】的性能略好于H2【非常小】。删除多条记录，SQLite【0.078s】好于H2的【0.12s】

u       启动时间：都比较快

u       并发性能：H2的查询支持一定的并发性，要强于SQLite。更新和插入，基本上都没有并发可言。

总的看来，SQLite的性能要好于H2，但并发性不如。

另外SQLite一般使用C的API接口访问，而H2支持JDBC。

并且都可以大多数主流平台上

对于C\C++\C#应用而言，使用SQLite是更好的选择。对于Java应用，H2是不错的选择。

奇怪的两点：

1.         在无索引查询单条数据，SQLite的性能【0.375s】要比H2【6.9s】要快非常多。(原因发现是H2使用Big Long效率差了好多，比起Int)

2.         在无索引查询多条数据，SQLite的性能甚至比有索引时还好快一些？？？？。而有索引情况下H2查询多条数据也好于SQLite

下面分别对SQLite和H2进行了性能测试

6.1               SQLite测试方案

6.1.1   测试环境

       主机：    操作系统：    Windows XP;

CPU：    Intel Dual 2.2GHZ;

内存：    1.99GB内存

       测试目标版本：SQLite 3.6.12

6.1.2   测试数据

测试数据库表ip_table结构如下

6.1.2   测试过程

使用C++编写了测试工程，启动测试程序后，先分别插入50000条和1000000条数据，然后执行一系列的测试

6.1.3   测试结果

结论：

1.       SQLlite内存数据库的处理速度很快；

2.       SQLlite内存数据库在查找数据时有索引的情况下，查询、更新、删除速度快；

3.       SQLlite内存数据库并发性比较差，可以认为并发能力为0；

4.       SQLlite内存数据库占用内存空间，100w条数据在40M左右（创建单个索引，6个字段）

5.       针对数据流探针来说，5w条数据SQLlite归并的速度在0.688s，可以尝试将部分功能用数据库归并实现。

6.       SQLLite支持自定义函数，效率没有测试，应该和他提供的API效率差不多

7.       SQLLite支持复合sql语句

上述内存数据库，首先由于License限制，排除了所有的商业数据库产品包括：

Alitibase

Oralce Berkelay DB

Oracle TimesTen

eXtrmeDB

还包括 Berkelay DB这样的开源，但限制商业使用的数据库。

所以比较的重点就是SQLite和H2

1.1           概念

一、什么是内存数据库 

传统的数据库管理系统把所有数据都放在磁盘上进行管理，所以称做磁盘数据库（DRDB:Disk-Resident Database）。磁盘数据库需要频繁地访问磁盘来进行数据的操作，由于对磁盘读写数据的操作一方面要进行磁头的机械移动，另一方面受到系统调用（通常通过CPU中断完成，受到CPU时钟周期的制约）时间的影响，当数据量很大，操作频繁且复杂时，就会暴露出很多问题。 

    近年来，内存容量不断提高，价格不断下跌，操作系统已经可以支持更大的地址空间（计算机进入了64位时代），同时对数据库系统实时响应能力要求日益提高，充分利用内存技术提升数据库性能成为一个热点。 

    在数据库技术中，目前主要有两种方法来使用大量的内存。一种是在传统的数据库中，增大缓冲池，将一个事务所涉及的数据都放在缓冲池中，组织成相应的数据结构来进行查询和更新处理，也就是常说的共享内存技术，这种方法优化的主要目标是最小化磁盘访问。另一种就是内存数据库(MMDB:Main Memory Database，也叫主存数据库)技术，就是干脆重新设计一种数据库管理系统，对查询处理、并发控制与恢复的算法和数据结构进行重新设计，以更有效地使用CPU周期和内存，这种技术近乎把整个数据库放进内存中，因而会产生一些根本性的变化。两种技术的区别如下表：

　　内存数据库系统带来的优越性能不仅仅在于对内存读写比对磁盘读写快上，更重要的是，从根本上抛弃了磁盘数据管理的许多传统方式，基于全部数据都在内存中管理进行了新的体系结构的设计，并且在数据缓存、快速算法、并行操作方面也进行了相应的改进，从而使数据处理速度一般比传统数据库的数据处理速度快很多，一般都在10倍以上，理想情况甚至可以达到1000倍。 

　　而使用共享内存技术的实时系统和使用内存数据库相比有很多不足，由于优化的目标仍然集中在最小化磁盘访问上，很难满足完整的数据库管理的要求，设计的非标准化和软件的专用性造成可伸缩性、可用性和系统的效率都非常低，对于快速部署和简化维护都是不利的。

2.  内存数据库历史和发展

一、雏形期
从上个世纪60年代末到80年代初。在这个时期中，出现了主存数据库的雏形。1969年IBM公司研制了世界上最早的数据库管理系统------基于层次模型的数据库管理系统IMS，并作为商品化软件投入市场。在设计IMS时，IBM考虑到基于内存的数据管理方法，相应推出了IMS/VS Fast Path。Fast Path是一个支持内存驻留数据的商业化数据库，但它同时也可以很好地支持磁盘驻留数据。在这个产品中体现了主存数据库的主要设计思想，也就是将需要频繁访问，要求高响应速度的数据直接存放在物理内存中访问和管理。在这个阶段中，包括网状数据库、关系数据库等其他各种数据库技术也都逐渐成型。 
二、技术理论成熟期
1984年，D J DeWitt等人发表了《主存数据库系统的实现技术》一文。第一次提出了Main Memory Database（主存数据库）的概念。预言当时异常昂贵的计算机主存价格一定会下降，用户有可能将大容量的数据库全部保存在主存中，提出了AVL树、哈希算法、主存数据库恢复机制等主存数据库技术的关键理论，为主存数据库的发展指出了明确的方向 。
1984年，D J DeWitt等人提出使用非易逝内存或预提交和成组提交技术作为主存数据库的提交处理方案，使用指针实现主存数据库的存取访问。
1985年，IBM推出了IBM 370上运行的OBE主存数据库 
1986年，RB Hagman提出了使用检查点技术实现主存数据库的恢复机制。威斯康星大学提出了按区双向锁定模式解决主存数据库中的并发控制问题。并设计出MM-DBMS主存数据库。贝尔实验室推出了DALI主存数据库模型。 
1987年，ACM SIGMOD会议中提出了以堆文件（HEAP FILE）作为主存数据库的数据存储结构。Southern Methodist大学设计出MARS主存数据库模型。
1988年普林斯顿大学设计出TPK主存数据库。 
1990年普林斯顿大学又设计出System M主存数据库。
三、产品发展期和市场成长期
随着互联网的发展，越来越多的网络应用系统需要能够支持大用户量并发访问、高响应速度的的数据库系统，主存数据库市场成熟 
半导体技术快速发展，半导体内存大规模生产，动态随机存取存储器（DRAM）的容量越来越大，而价格越来越低，这无疑为计算机内存的不断扩大提供了硬件基础，使得主存数据库的技术可行性逐步成熟 
1994年美国OSE公司推出了第一个商业化的，开始实际应用的主存数据库产品Polyhedra 
1998年德国SoftwareAG推出了Tamino Database。 
1999年日本UBIT会社开发出XDB主存数据库产品。韩国Altibase推出Altibase 
2000年奥地利的QuiLogic公司推出了SQL-IMDB 
2001年美国McObject推出eXtremeDB。加拿大Empress公司推出EmpressDB
四、几种主存技术应用的比较
第一代：用户定制的主存数据库。通过应用程序来管理内存和数据；不支持SQL语句, 不提供本地存储, 没有数据库恢复技术；性能好但很难维护和在别的应用中不能使用；应用在实时领域比如工厂自动化生产。
第二代：简单功能的内存数据库。能够快速处理简单的查询；支持部分的 SQL语句和简单的恢复技术；主要目的是能够快速处理大量事务；针对简单事务处理领域,尤其是交换机, 移动通信等。
第三代：通用的主存数据库。针对传统的商业关系型数据库领域，能够提供更高的性能、通用性以及稳定性；提供不同的接口来处理复杂的SQL语句和满足不同的应用领域；可以应用在计费、电子商务、在线安全领域，几乎包括磁盘数据库的所有应用领域。
五、目前几种常见的通用内存数据库
eXtremeDB：eXtremeDB实时数据库是McObject公司的一款特别为实时与嵌入式系统数据管理而设计的数据库，只有50K到130K的开销，速度达到微秒级。eXtremeDB完全驻留在主内存中，不使用文件系统（包括内存盘）。eXtremeDB采用了新的磁盘融合技术，将内存拓展到磁盘，将磁盘当做虚拟内存来用，实时性能保持微秒级的同时，数据管理量在32BIT下能达到20G。
Oracle TimesTen：Oracle TimesTen是Oracle从TimesTen公司收购的一个内存优化的关系数据库，它为应用程序提供了实时企业和行业（例如电信、资本市场和国防）所需的即时响应性和非常高的吞吐量。Oracle TimesTen可作为高速缓存或嵌入式数据库被部署在应用程序层中，它利用标准的 SQL 接口对完全位于物理内存中的数据存储区进行操作。
SolidDB：Solid Information Technology 成立于 1992 年，全球总部位于加州Cupertino，
Solid数据管理平台将基于内存和磁盘的全事务处理数据库引擎、载体级高可用性及强大的数据复制功能紧密地融为一体。
Altibase：ALTIBASE公司从1999年就一直致力于内存数据库软件和其应用的开发，提供高性能和高可用性的软件解决方案。特别适合通信、网上银行、证券交易、实时应用和嵌入式系统领域。目前占据80%以上内存数据库市场，可以说是当今数据库软件技术的领导者。目前Altibase在国内成功案例也比较多，尤其是在电信行业，已经得到了广泛认可。

使用了4个外部工具库，分别是：

1. 跨平台的网络通讯框架The ADAPTIVE Communication Environment (ACE)
2. 压缩库zlib
3. Socket通信库 C++ Sockets Library (使用在realmd工程中，和使用在Mangosd工程中的RASocket，负责处理Remote Administration。其他地方没有使用到这个C++ Sockets Library ）。发现在C++ Sockets Library的TcpSocket::Open中存在一个问题，在n = connect(s, ad, ad);语句执行后，如果n=-1，C++ Sockets Library会检测是否ERR为WSAEWOULDBLOCK，否则表示成功，但在动态库中使用TcpSocket的时候，我发现n = connect(s, ad, ad);语句执行后，n=-1，ERR会为0，这个时候连接也是成功了，但TcpSocket::Open会当做不成功处理。我发现这个问题，但没有时间去探究原因，也许并不是一个问题。
4. C++的并行编程模板库Threading Building Blocks （tbb 和 tbbmalloc）

Mangos的实现分为：登录服务器（realmd）和世界服务器（mangosd+game）。realmd和mangos共用了Mangos公共库（shared）。

工程shared

提供了通用功能，包括了数据库的封装类，实现了对MySql的访问，同样，我们可以编写派生类来支持其他的数据库。

工程script

提供了脚本接口，并实现了简单的几个脚本，封装为DLL，提供给game使用，具体可参考：MaNGOS脚本接口。

通过使用不同的脚本DLL来替换Mangos中的AI实现,可以让game具有更强的AI。ScriptDev2 就是一个这样的库。ScriptDev2 is a replacement for the Script Library that comes with MaNGOS( http://www.getmangos.com ) written in C++ and is compatible with Windows and Linux. It provides scripts for NPCs, Boss events, and Items currently. Once ScriptDev2 is compiled it is automatically run by MaNGOS on server startup.

工程mangosd

mangos是世界服务器的管理器，负责初始化工作和启动世界服务器各层的线程，这些工作主要是由类Master来实现。具体是：

1. 使用三个数据库对象WorldDatabase和CharacterDatabase和loginDatabase，初始化三大数据库：World Database和Character Database和login Database，并为每个数据库的访问都启动一个DB delay threads。具体的数据库操作功能都是由Mangos公共库shared来提供。
2. 调用sWorld.SetInitialWorldSettings，对World进行初始化，包括加载所有的游戏数据和初始化各种更新定时器和邮件定时器，还有些其他的初始化工作。类World的成员函数SetInitialWorldSettings调用成员函数LoadConfigSettings解析mangosd.conf，解析后内容放入uint32 m_configs[CONFIG_VALUE_COUNT]中。
   1. 加载的游戏数据有：
      1. DBC数据
      2. Objects数据
      3. Spells数据
      4. Pooling数据
      5. Game Event数据
      6. loot数据
      7. 技能数据
      8. 所有其他的游戏数据，包括Waypoints和Trainers等等等。
      9. 脚本数据
   2. 初始化的更新定时器有：
      1. WUPDATE_OBJECTS
      2. WUPDATE_SESSIONS
      3. WUPDATE_AUCTIONS
      4. WUPDATE_WEATHERS
      5. WUPDATE_UPTIME
      6. WUPDATE_CORPSES
      7. WUPDATE_EVENTS
   3. 其他的初始化工作有:
      1. 初始化MapManager，启动Map System
      2. 初始化Battlegrounds，启动BattleGround System
      3. 初始化DailyQuestResetTime
      4. 初始化sGameEventMgr，Starting Game Event system
3. 类Master还实现了mangos server的退出管理
4. 类Master启动WorldRunnable，开始游戏逻辑。Heartbeat for the World，由Master创建，并设置线程为最高优先级。
5. 类Master启动CliRunnable：Command Line Interface handling thread，由Master创建。CliRunnable运行时候会生成一个WorldDatabase线程，在接收到输入后会调用sWorld.QueueCliCommand把Cmd放入到World::cliCmdQueue中。
6. 类Master启动RARunnable：Remote Administration，由Master创建
7. 如果配置要求，类Master还会启动一个freeze catcher thread
8. 类Master启动2个网络线程ReactorRunnable（可配置数目）

mangosd的线程总共有（1+3+1+1+1+2 +1 =10）10个线程。

1. 主线程Master
2. 2个网络线程ReactorRunnable（可配置数目）（网络层）
3. 一个World线程（逻辑层）
4. 三个DB线程（数据层）
5. 一个CLI线程（输入层），运行时候会生成一个WorldDatabase线程
6. 一个RA线程（管理层）
7. 一个freeze catcher 线程（可选）

工程g3dlite：游戏逻辑层的底层库

工程framework：系统框架

工程realm

负责登陆和选择游戏服务器，进行负载均衡。用到了C++ Sockets Library进行登录处理，采用select I/O模型。实现了Wow, Mangos登录时的SRP6认证。客户端作为它的client连接到realm server认证和选择了mangos server就断开。 而mangos server和realm server则不进行连接，只是通过数据库交互数据：mangos server把自己的状态和拥有的角色数放入库中。realm server会读取数据库中的这些信息来获知mangos server的状态。

1. 数据库realm的realmlist表保存了realm的列表
2. realm通过如下事件处理函数来负责登陆和选择游戏服务器。

   const AuthHandler table[] =
   {
       { AUTH_LOGON_CHALLENGE,     STATUS_CONNECTED, &AuthSocket::_HandleLogonChallenge    },
       { AUTH_LOGON_PROOF,         STATUS_CONNECTED, &AuthSocket::_HandleLogonProof        },
       { AUTH_RECONNECT_CHALLENGE, STATUS_CONNECTED, &AuthSocket::_HandleReconnectChallenge},
       { AUTH_RECONNECT_PROOF,     STATUS_CONNECTED, &AuthSocket::_HandleReconnectProof    },
       { REALM_LIST,               STATUS_AUTHED,    &AuthSocket::_HandleRealmList         },
       { XFER_ACCEPT,              STATUS_CONNECTED, &AuthSocket::_HandleXferAccept        },
       { XFER_RESUME,              STATUS_CONNECTED, &AuthSocket::_HandleXferResume        },
       { XFER_CANCEL,              STATUS_CONNECTED, &AuthSocket::_HandleXferCancel        }
   };

登录处理：

user登录到realm server进行身份认证，并选择登录上哪个mangos server。user登录到mangos server后，将不再和realm server交互。

参考： Wow 服务器解析

 
在BIND9中实现此功能就向添加一条A记录那么简单。举例说，如果我们向somode.com区域文件中加入下面行便可实现：
www       60     IN     A       220.181.11.124
          60     IN     A       220.181.11.125
 
当然你还可以根据需要加入更多服务器。这样如果有人请求解析[url]www.somode.com[/url]时将有一半的机率解析到220.181.11.124上，而另一半会解析到220.181.11.125上。
 
然而，使用RR-DNS方法实现负载平衡也会带来一些问题：
第一，域名服务器是一个分布式系统，是按照一定的层次结构组织的。当用户将域名解析请求提交给本地的域名服务器，它会因不能直接解析而向上一级域名服务器提交，上一级域名服务器再依次向上提交，直到RR-DNS 域名服务器把这个域名解析到其中一台服务器的IP 地址。可见，从用户到RR-DNS 间存在多台域名服务器，而它们都会缓冲已解析的名字到IP 地址的映射,这会导致该域名服务器组下所有用户都会访问同一Web 服务器，出现不同Web 服务器间的负载不平衡。为了保证在域名服务器中域名到IP 地址的映射不被长久缓冲，RR-DNS 在域名到IP 地址的映射上设置一个TTL(Time To Live)值，过了这一段时间，域名服务器将这个映射从缓冲中淘汰。当用户请求，它会再向上一级域名服务器提交请求并进行重新映射。这就涉及到如何设置这个TTL值，若这个值太大，在这个TTL 期间，很多请求会被映射到同一台Web 服务器上，同样会导致负载不平衡。若这个值太小，例如是０，会导致本地域名服务器频繁地向RR-DNS提交请求，增加了域名解析的网络流量，同样会使RR-DNS 成为系统中一个新的瓶颈。
 
第二，用户机器会缓冲从名字到IP 地址的映射，而不受TTL 值的影响，用户的访问请求会被送到同一台Web 服务器上。由于用户访问请求的突发性和访问方式不同，例如有的人访问一下就离开了，而有的人访问可长达几个小时，所以各台服务器间的负载仍存在倾斜（Skew）而不能控制。假设用户在每个会话中平均请求数为20，负载最大的服务器获得的请求数额高于各服务器平均请求数的平均比率超过百分之三十。也就是说，当TTL 值为0 时，因为用户访问的突发性也会存在着较严重的负载不平衡。
 
第三，系统的可靠性和可维护性不好。若一台服务器失效，会导致将域名解析到该服务器的用户看到服务中断，即使用户按“Reload”按钮，也无济于事。系统管理员也不能随时地将一台服务器切出服务进行维护，如进行操作系统和应用软件升级，这需要修改RR-DNS 服务器中的IP 地址列表，把该服务器的IP 地址从中划掉，然后等上一段时间，等所有域名服务器将该域名到这台服务器的映射淘汰，和所有映射到这台服务器的客户机不再使用该站点为止。
 
RR-DNS方法只是一个简单的负载平衡方案，如果你有更高要求，可以研究LVS集群（IPVS和KTCPVS、TCPHA），实现基于IP的负载均衡和基于内容的负载均衡。