欧美电影在线观看完整版,国内成人精品2018免费看,国产精品美女久久久久av超清

Kevin Lynx — Wed, 29 Aug 2012 03:37:00 GMT

MMO中的聊天服务主要功能��是做客��L��之间的聊天内容�{发。但是聊天的形式有很多，例如�U�聊、同场景聊、队伍内聊、工会内聊、全服务器聊、甚至�� 时组建房间聊。这些逻辑功能其实都是可以做在逻辑服务器上的，最多改改世界服务器�Q�但是这样完成功能的话，不免��聊天本�w�的逻辑与游戏逻辑兌��h��。我�?希望做得更上一层，��聊天服务本�w�脱��d��来。但是独立聊天服务还不够�Q�因为就��独立出来了�Q�也有可能在实现上与具体的游戏逻辑相关联。所以，我们做了�q�一步的抽象�Q�想实现一个更为通用的聊天服务器�?/p>

设计实现

实体设计

聊天�q�个�q�程�Q�我们将其抽象�ؓ实体(entity)与实体间的对话。这个实体概念其实很宽泛。�Q何可接收聊天消息的都��做实体�Q�例如单个玩家、一�?场景、一个队伍、一个房间、一个工会、甚��x��个服务器。这个思想其实��是支持整个聊天服务器设计的最�Ҏ��思想。最开始，我将聊天服务器分��Z��体和�l�两个概念，其实�q�个抽象�E�度都太低，�q�且会导致实��C��的复杂。相反，��整个系�l�完全��用实体这个概忉|��l�装�Q�就��单很多。当�Ӟ��实体是有很多�U�类的，在处理接�?聊天消息�q�个动作�Ӟ��其处理方式就不同。例如单个玩家实体仅做消息的发送，场景实体则是��消息发�l�场景内的所有玩�Ӟ��队伍实体��是��消息发�l�队伍内的所�?玩家。从�q�一�Ҏ��看，我们的实体种�c�d��实�ƈ不多�Q�因为场景、队伍这些，都是�l�实�?group entity)。用C++来描�q�ͼ�

class Entity {
public:
    // send text to this entity
    virtual bool Send(Entity *sender, const std::string &text) = 0;

protected:
    GUID m_id;
    int m_type;
};

class SockEntity : pubilc Entity {
public:
    virtual bool Send(Entity *sender, const std::string &text) {
        // find the map socket and send text to the socket
        long socket = FindSocket(this);
        Message msg(MSG_CS2E_SENDTEXT);
        msg.Add(sender->ID());
        msg.Add(text);
        msg.SendToSocket(socket);
        return true;
    }
};

class GroupEntity : public Entity {
public:
    virtual bool Send(Entity *sender, const std::string &text) {
        for (std::list<Entity*>::const_iterator it = m_mems.begin(); it != m_mems.end(); ++it) {
            (*it)->Send(sender, text);
        }
        return true;
    }
private:
    std::list<Entity*> m_mems;
};

SockEntity用于表示物理上聊天服务器的客��L��Q�例如游戏客��L��?/p>

�|�络拓扑

实际上，除了转发聊天内容�?Entity::Send)�Q�实体还有很多其他行为，例如最��L��的，创徏�l�实体，往�l�实体里��d��成员�{�。在设计上，�l?实体的创建由逻辑服务器或者其他服务器来完成，目前游戏客户端是没有创徏�l�实体的权限的（实现上我们还为实体添加了权限验证机制�Q�。在�|�络拓扑上，聊天�?务器始终是作为服务器角色�Q�而它的客��L��则包括游戏客��L��、逻辑服务器、甚臛_��他服务器�Q�这栯��天服务器在提供了固定的协议后�Q�它��是完全独立的，不依�?��M��其他�l��g�Q?/p>

             CS
          /  |  \
         /   |   \
        /    |    \
       GC   GC   GS

(CS: Chat Server, GC: Game Client, GS: Game Server)

��Z��此，我们扩充了Entity的类体系�Q?/p>

class ClientEntity : public SockEntity {

private:
GUID m_gsEntity; // 标示该客��L��实体位于哪个逻辑服务器实体上
};

class GSEntity : public SockEntity {
};

消息协议

聊天服务器的核心实现�Q�其实就是针对以上实体做操作。因此，聊天服务器的消息协议斚w��Q�也主要是针对这些实体的操作�Q�包括：

创徏

实体的创建很��单，不同的实体其创徏所需的参数都不一栗��例如客��L��实体创徏旉��要传入一个逻辑服务器实体的ID�Q�组实体的创建可以携带组成员实体列表�?��Z��处理权限和安全问题，在具体实��C��Q�逻辑服务器实体的创徏是由聊天服务器本地的配置军_��Q�即聊天服务器启动则�Ҏ��配置创徏好逻辑服务器实体；客户端实体是当角色进入逻辑服务器后�Q�由服务器创建，客户端无法创建实体�?/p>
删除

实体的删除�ؓ了处理方便，�U�定删除��h��必须由实体的创徏者发赗��因��Z��逻辑上将�Q�某个模块如果可以创��Z��个实体，那么其必然知道什么时候该删除�q�个实体�?/p>
修改

修改指的是修改实体内部实现的一些属性，例如�l�实体修改其�l�成员。这个操作是非常重要的。对�?code>SockEntity�?�a��Q�修�Ҏ��味着修改其连接状态，例如当逻辑服务器在聊天服务器上创徏了客��L��实体后，实际上此时客��L��q�没有在�|�络斚w��q�接聊天服务器，此时�q�个Entity�?际上是不可用的，因�ؓ它无法用于发送消息。这个时候我们标志该实体的状态�ؓ非连接状态。当客户端主动连接上聊天服务器后�Q�客��L��׃��动发起修改自己对应的客户端实体请求，该请求将自己的状态修改�ؓ�q�接状态。当客户端关闭时�Q�聊天服务器�|�络层接收到�q�接断开通知�Q�该通知肯定是早于逻辑服务器发来的删除实体�?知的�Q�此时将该客��L��实体状态修改�ؓ断开状态，�q�在接收到逻辑服务器删除实体通知时将其真正删除。这里展�C�的�q�种状态修改策略，实际上在整个�pȝ��中是非常重要的。它用于指导�|�络�q�接和上层逻辑之间的关�p�，因�ؓ整个聊天�pȝ��中，各个�q�程的状态是不可预料的（随时可能宕掉�Q�，当某个进�E�尤其是逻辑服务器宕�?后，聊天服务器是得不��C�Q何正帔R��辑通知的，它只能得到网�l�连接的通知�?/p>

�ȝ��

整个�pȝ��实现下来�Q�实际上是非常简单的�Q�代码量也很��。当然还有很多细节问题，例如聊天信息中携带物品信息，�q�涉及到异步预处理聊天内容，�q�里��׃�� 方便�l�说了�?/p>

原文地址�Q?http://codemacro.com/2012/08/29/mmo-chat-server/
written by Kevin Lynx posted at http://codemacro.com

Kevin Lynx 2012-08-29 11:37 发表评论

谈谈我们的游戏逻辑服务器实玎ͼ�二）

Kevin Lynx — Wed, 25 Apr 2012 08:55:00 GMT

原文链接�Q?a >http://codemacro.com/2012/04/25/game-server-info-2/

上一��谈了一些关键技术的实现�Ҏ��。本��描�q�C��些遇到的问题�?/p>

一

在策划制作完了几个职业后�Q�主要是技能制作）�Q�大概去�q�年底公司内部进行了一�ơ�؜战测试�?0个角色在一个场景进行�؜战，��试�l�果从技术上来说非常不理惟뀂首先是客户端和服务器都巨卡无比。服务器CPU一直是满负载状态。而客��L��又频�J�宕机�?/p>

我们��x��的主要问题，是服务器CPU满负载问题。最开始，我通过日志初步定位为网�l�模块问题，因�ؓ逻辑�U�程表现不是那么差。然后考虑到技能过�E�中的特效、动作都是通过服务器消息驱动，�q�且本��n�Ҏ��和动作就比一般网游复杂，通过逐一屏蔽�q�一部分功能�Q�最�l�确认确为网�l�模块导致。然后团队决定从两方面努力：重写�|�络模块�Q�改善性能�Q�改善技能实现机�Ӟ��表现类逻辑�U�d��客户端�?/p>

至于�|�络模块�Q�在后来才发玎ͼ�虽然�|�络��量�q�高�Q�但��D��|�络�U�程CPU满的原因竟然是网�l�模块自�w�的��量限制��D��。而技能实现机制的改善�Q�考虑到改动的成本�Q�最�l��用了一�U�RPC机制�Q�让服务器脚本可以调用客��L��脚本�Q��ƈ且支持传入复杂参数。然后策划通过一些关键数据在客户端计��出�Ҏ��、动作之�c�R�?/p>

此外�Q�程序将更多的技能属性广播给客户端，一个客��L��上保存了周围角色的技能数据，从而可以进行更多的客户端逻辑。这一块具体的修改当然�q�是�{�划在做�Q�我们的脚本�{�划基本��是半个�E�序员）。后�l�测试，效果改善显著�?/p>

�?/h2>
在策划制作了一个PVP竞技副本后，服务器在10V10��试�q�程中又表现出CPU负蝲较高的情��c��这个问题到目前为止依然存在�Q�只不过情况略微不同�?/p>
首先是触发器生命周期的问题。触发器自��n包含最大触发次数、存留时间等需求，卛_��触发一定次敎ͼ�或超�q�存留时间后�Q�需要由�E�序自动删除�Q�另一斚w��Q�触发器可以是定时器�c�d��Q�而定时器也决定了触发器的生命周期。这一块代码写的非常糟�p�，大概��是��理职责划分不清�Q�导致出现对象自己删除自己，而删除后�q�在依赖自己做逻辑�?/p>
但这��L��逻辑�Q�最多就是导致野指针的出现。不�q�，�q�种混�ؕ的代码，也更�Ҏ��D��BUG。例如，在某�U�情况下触发器得不到自动删除了。但�q�个BUG�q�不是直接暴露的�Q�直接暴露的�Q�是CPU满了。我们的怪物AI在脚本中是通过定时器类触发器驱动的�Q�每�ơAI帧完了后��注册一个触发器�Q�以驱动下一�ơAI帧。由于这个BUG��D��触发器没有被删除�Q�从而导致服务器上触发器的数量急剧增加。但�Q�这也就��D��内存增长吧？

另一个��y合的原因在于�Q�在当时的版本中�Q�触发器是保存一个表里的�Q�即定时器类触发器、属性类触发器、移动类触发器等都在一个表里。每�ơ�Q意触发器事�g发生�Ӟ��例如属性改变，都会遍历�q�个表，��查其是否触发�?/p>
��Z��以上原因�Q�悲剧就发生了。在�q�个怪物的AI脚本里，有行代码讄��了怪物的属性。这会导致程序遍历该怪物的所有触发器。而这个怪物的触发器数量一直在增长。然后就出现了在很多游戏帧里出现�q�长的遍历操作，CPU��׃��M��?/p>
扑ֈ��q�个问题了几乎花了我一天的旉��。因��本代码不是我写的�Q�触发器的最初版本也不是我写的。通过逐一排除可能的代码，最�l�竟然发现是一行毫不�v眼的属性改变导致。这个问题的查找��程�Q�反映了��大量逻辑攑֜�脚本中的不便之处�Q�查起问题来实在吃力不讨好�?/p>
修复了这个BUG后，我又对触发器��理做了��单的优化。将触发器列表改成二�U�表�Q�将触发器按照类型保存成几个列表。每�ơ触发事件时�Q�找出对应类型的表遍历�?/p>

改进

除了修改触发器的�l�护数据�l�构外，�E�序�q�实��C��一套性能�l�计机制�Q�大概就是统计某个函数在一�D�|��间内的执行时间情��c��最初这套机制仅用于�E�序�Q�但考虑到脚本代码在整个��目中的比例�Q�又军_��其应用到脚本中�?/p>

�q�个�l�计需要在函数�q�入退出时做一些事情，C++中可以通过�c�d��象的构徏和析构完成，但lua中没有类似机制。最初，我��用了lua的调试库来捕获函数进�?退��Z��Ӟ��但后来又��x��这�U�方式本�w�存在效率消耗，��取消了。我们��用lua的方式，不仅仅是全局函数�Q�还包括函数对象。而函数对象是没有名字标示的，�q�对于日志记录不是什么好事。�ؓ了解册��个问题，我只好对部分功能做了��装�Q��ƈ让策划显�C�填入函数对于的字符串标�C��?/p>

除此之外�Q�因��发器是一�U�重要的敏感资源�Q�我又加入了一个专门的触发器统计模块，分别�l�计触发器的�c�d��数量、游戏对象拥有的触发器数量等�?/p>

END

到目前�ؓ止，��D��服务器CPU负蝲�q�高�Q�一般都是由BUG��D��。这些BUG通常会造成一个过长的列表�Q�然后有针对�q�个列表的遍历操作，从而导致CPU负蝲�q�高。更重要的，我们使用了这么多的脚本去开发这个游戏，如何扑ֈ�一个更有效合理的监��方法，如何让程序框架更�E�_��Q�则是接下来更困难而又必须去面对的事情�?/p>

Kevin Lynx 2012-04-25 16:55 发表评论

Kevin Lynx — Wed, 25 Apr 2012 08:54:00 GMT

原文链接�Q?a >http://codemacro.com/2012/04/23/game-server-info-1/

我们的逻辑服务�?Game Server�Q�以下简�U�GS)主要逻辑大概是从��d��夏天开始写的。因为很多基��模块�Q�包括整体结构沿用了上个��目的代码，所以算不上从头开始做。�{眼又快一�q�_��我觉得回头�ȝ��下对于经验的�U�篏太有必要�?/p>

整体架构

GS的架构很大程度取决于游戏的功能需求，当然更受限于上个��目的基��架构。基��架构包括场景、对象的关系��理�Q�消息广播等�?/p>

需�?/h3>
�q�一回，�E�序员其实已�l�不需要太�q�关心需求。因为我们决定大量��用脚本。到目前为止整个��目主要�q�是集中在技能开发上。而这个��用脚本的度，��是技能全部由�{�划使用脚本制作�Q�程序员不会�ȝ��写某个具体技能，也不会提供某�U�配�|�方式去让策划通过配置来开发技能。这真是一个好消息�Q�不��对于程序员而言�Q�还是对于策划而言。但后来�Q�我觉得对于�q�一点还是带来了很多问题�?/p>

实现

��Z��以上需求，�E�序员所做的��是开发框�Ӟ��制定功能实现�Ҏ��。脚本�ؓ了与整个游戏框架交互�Q�我们制定了“触发�?#8220;�q�个概念�Q�大概就是一�U�事件系�l��?/p>

�q�个触发器系�l�，��单来��_��是提供一�U?#8220;兛_��“�?#8221;通知“的交互方式，也就是一般意义上的事件机制。例如，脚本中告诉程序它兛_��某个对象的移动，那么当程序中该对象��生移动时�Q�就通知脚本。脚本中可以兛_��很多东西�Q�包括对象属性，其关心的方式包括属性值改变、变大、变��，各种变化形式�Q�对象开始移动，�U�d��停止�Q�对象碰撞，�q�个会单独谈谈；定时器等�?/p>

除了触发器系�l�外�Q�还有个较大的系�l�是游戏对象的属性系�l�。对象的属性必然是游戏逻辑中策划最兛_��最�Ҏ��改动的模块。既然我们程序的大方向是��可能地不关心策划需求，所以对象属性在设计上就不可能去�~�写某个具体属性，更不会编写这个属性相关的逻辑功能。简单来��_��E�序为每个对象维护一个key-value表，也就是属性名、属性��D��。该表的内容��p��本填入，脚本享有存取权限。然后脚本中��可以围�l�某个属性来�~�写功能�Q�而程序仅起存储作用�?/p>

�W�三�Q�怪物AI模块。AI模块的设计在开发周期上靠后。同��P��E�序不会�ȝ��写某�c�AI的实现。程序提供了另一�U�简单的事�g�pȝ��Q�这个系�l�其实就是一个调用脚本的�Ҏ��。当关于某个怪物发生了某个事件时�Q�程序调用脚本，传入事�g�c�d��和事件参数。这个事件分��Z��c�：�E�序�c�d��脚本�c�R��脚本类�E�序不需兛_��Q�仅提供事�g触发API。程序类事�g非常有限�Q�怪物创徏、出生、删除�?/p>

除了以上三块之外�Q�还有很多零散的脚本交互。例如游戏对象属性初始化�Q�角色进入游戏，角色�q�入场景�{�。这些都无关痛痒�?/p>

接下来谈一些关键模块的实现�?/p>

定时�?/strong>

整个GS的很多逻辑模块都基于这个定时器来实现。这个定时器接收逻辑模块的注册，在主循环中传入系�l�时��_��定时器模块检查哪些定时器实例��时�Q�然后触发调用之。这个主循环以每�?ms的速率�q�行�Q�也卛_��?000/5�?/p>
�q�个定时器是��Z��操作�pȝ��的时间。随着帧率的不同，它在触发逻辑功能�Ӟ��必然不�_��。游戏客��L��Q�包括单机游戏）在��率这块的实现上，一般逻辑功能的计��都会考虑��C��个dt�Q�也��是一帧的旉��差）�Q�例如移动更斎ͼ�一般都是x = last_x + speed * dt。但�Q�我们这里�ƈ没有�q�样做。我们的几乎所有逻辑功能�Q�都没有考虑�q�个旉��差�?/p>
例如�Q�我们的�U�d��模块注册了一个固定时间值的定时器，假设�?00ms。理��x��况下�Q�定时器模块�?00ms回调�U�d��模块更新坐标。但现实情况肯定是大�?00ms的更新频率，悲剧的是�Q�移动模块每�ơ更新坐标都更新一个固定偏�U�R��这昄��是不够精��的�?/p>
更悲剧的是，定时器的实现中，�q�可能出现蟩�q�一些更新��。例如，理论情况下，定时器会在系�l�时间点t1/t2/t3/t4分别回调某个逻辑模块。某一帧里�Q�定时器大概在t1回调了某逻辑模块�Q�而当该��耗时严重�Ӟ��下一帧定时器模块在计��时�Q�其旉��gؓt�Q�而t大于t4�Q�此时定时器模块跌��t2/t3。相当于该逻辑模块��了2�ơ更新。这对于�U�d��模块而言�Q�相当于某个对象本来�?�U�的旉��里该�?��|��但实际情况却��C��1根{�?/p>
当然�Q�当游戏帧率无法保证�Ӟ��逻辑模块�q�行不理想也是情有可原的。但�Q�不理想�q�不包含BUG。而我觉得�Q�这里面是可能出现BUG的。如何改善这块，目前为止我也没什么方案�?/p>
�U�d��

有很多更上层的模块依赖移动。我们的�U�d��采用了一�U�分别模拟的实现。客��L��复杂的�U�d��路径拆分��Z��条一条的�U�段�Q�然后每个线�D�请求服务器�U�d��。然后服务器上��用定时器来模拟在该线�D�上的移动。因为服务器上的��L��是二�l�格子，�q�样服务器的模拟也很��单。当�Ӟ��q�个模块在具体实��C��复杂很多�Q�这里不�l�谈�?/p>
��撞��?/strong>

我们的技能要求有��撞��，�q�主要包括对象与对象之间的碰撞。在最早的实现中，当脚本关心某个对象的��撞情况�Ӟ��E�序��׃ؓ该对象注册定时器�Q�然后周期触发检��与周围对象的距��d��p�，�q�个周期低于100ms。这个实现很��单，�l�护��h��也就很简单。但它是有问题的。因为它��Z��了一个不�_��的定时器�Q�和一个不�_��的移动模块�?/p>
首先�Q�这个检��是��Z��对象的当前坐标。前面分析过在��率掉到移动更新��都掉帧的情况下，服务器的对象坐标和理论情况差距会很大�Q�而客��L��基本上是接近正确情况的，�q�个时候做的距��L��，��׃��可能正确。另一斚w��Q�就��移动精��了�Q�这个碰撞检��还是会带来BUG。例如现在检��到了碰撞，触发了脚本，脚本中注册了兛_��d��的事件。但不幸的是�Q�在�q�个定时器开始检��前�Q�这两个对象已经�l�历了碰撞、离开、再��撞的过�E�，而定时器开始检��的时候，因�ؓ它基于了当前的对象坐标，它依然看到的是两个对象处于碰撞状态�?/p>
最开始，我们直觉�q�样的实现是�Ҏ��的，是不�_��的。然后有了第二种实现。这个实现基于了�U�d��的实现。因为对象的�U�d��是基于直�U�的�Q�服务器上）。我们就在对象开始移动时�Q�根据移动方向、速度预测两个对象会在未来的某个时间点发生��撞。当�Ӟ��对于频繁的小距离�U�d��而言�Q�这个预��从直觉上来说也是费时的。然后实��C��码写了出来，一看，挺复杂，�l�护隑ֺ�不小。如果效果好�q�个�l�护成本也就��了�Q�但是，它依然是不精��的。因为，它也依赖了这个定时器�?/p>
例如�Q�在某个对象开始移动时�Q�我们预��到�?00ms会与对象B发生��撞。然后注册了一�?00ms的定时器。但定时器不会精��地在未�?00ms触发�Q�随着帧率的下降，400ms触发都有可能。即便不考虑帧率下降的情况，它还是有问题。前面说�q�，我们游戏帧保证每帧至��?ms�Q�本来这是一个限帧手�D�，目的当然是避免busy-loop。这��D��定时器最多出�?ms的�g�q�。如果策划��用这个碰撞检��去做飞行道��L��实现�Q�例如一个快速飞出去的火球，当这个飞行速度很快的时候，�q?ms相对于这个预��碰撞时间就不再是个��数目。真悲剧�?/p>
技�?/strong>

虽然具体的技能不是程序写的，但正如把几乎所有具体逻辑交给�{�划写带来的悲剧一��P��q�事不是你干的，但你得负责它的性能。所以有必要谈谈技能的实现�?/p>
技能的实现里，只有一个技能��用入口，�E�序只需要在客户端发��Z��用技能的消息�Ӟ��调用�q�个入口脚本函数。然后脚本中会通过注册一些触发器来驱动整个技能运作。程序员一直希望策划能把技能用一个统一的、具体的框架�l�一��h��Q�所谓的变动都是��Z��q�个框架来变的。但�{�划也一直坚持，他们心目中的技能是无法�l�一的�?/p>
我们的技能确实很复杂。一个技能的整个�q�程中，服务器可能会和客��L��发生多次消息交互。在最初的实现中，服务器甚至会控制客户端的技能特效、释攑֊�作等各种�l�节�Q�甚至于服务器会在这个过�E�中依赖客户端的若干�ơ输入�?/p>

下一��我��谈谈一些遇到的问题�?/p>

Kevin Lynx 2012-04-25 16:54 发表评论

Kevin Lynx — Mon, 02 May 2011 11:19:00 GMT

MMO游戏对象属性设�?/h1>

Author: Kevin Lynx

Date: 5.2.2011

一般的MMORPG中，游戏对象主要包括怪物和玩家。这两类对象在经�q�游戏性方面的不断“�q�化”后，其属性数量及与之相关的逻辑往往会变得很巨大。如何将�q�一块做得既不损失效率，又能保证�l�构的灵�z�R��清晰、可�l�护�Q�本文将提供一�U�简单的�l�构�?/p>

原始�l�构

最原始的结构，极有可能��?

Player: +---------------+ | property-1 | +---------------+ | property-2 | +---------------+ | ... | +---------------+ | operator-1 | +---------------+ | operator-2 | +---------------+ | ... | +---------------+

也就是，一个对象�ؓ一个C++�c�，然后里面直接塞满了各�U�属性名�Q�然后是针对�q�个属性的逻辑操作�Q�函敎ͼ�。其�l�果��是Player成�ؓ巨类。针对这个情况，一直以来我觉得可以使用一�U�简单的�Ҏ��来拆分这个类。冠以官腔，�U�C��为Entity-Component-based Desgin。��生这�U�想法和我的个�h技术积累有一定关�p�，见下文�?/p>

Policy-based Design

Policy-based Design�Q�基于决�{�的设计。这个概忉|��源于。虽然这本书讲述的是针对C++模板的��用及设计技巧。但�q�种思想依然被我潜意识般地用在其他地斏V��Policy大致来说��是一个小的组�?Component)。它努力不依赖于其他东西�Q�它可能��是个简单的�c�，它拥有极��的数据�l�构�Q�及针对�q�些数据的极��操作接口。�D例而言�Q�玩家MP的自动回复功能，��可��装��Z��个Policy。将许多Policy�l�合��h��Q�就可完成一个复杂的功能�?/p>
�q�种思想�q�可指导很多�E�序�l�构斚w��的设计。例如在做功能的接口拆分�Ӟ��将每个函数设计得��够小�Q�小到单�U�地完成一个功能。一个功能的入口函数�Q�就��之前实现的��函数全部组合�v来，然后共同完成功能炏V�?/p>
当然�Q?lt;Modern C++ Design>里的Policy在表现�Ş式上有所不同。但其核心思想相同�Q�主要体现在 �l�合 特点上�?/p>

Entity-Component-based Design

Entity-Component-based Design按照google到的文章�Q�严格来说算是与OOP完全不同的��Y件设计方法。不�q�在�q�里它将按照我的意思重新被解释�?/p>
如果说Policy-based Design极大可能地媄响着我们�q�x��的细节编码，那么Entity-Component则是直接�Ҏ��戏对象的�l�构设计做直接的说明�?一个游戏对象就是一个Entity�?/strong> Entity拥有很少的属性，也许仅包含一个全局标示的ID�?一个Component则是Entity的某个行为、或者说某个�l�成部分�?/strong> 其实说白了，以玩家�ؓ例，一个玩家对象就是一个Entity�Q�而一个MP的自动回复功能就可被包装��Z��个Component。这个Component可能包含若干与该功能相关的数据，例如回复旉��间隔�Q�每�ơ的回复量等。我们往玩家对象�q�个Entity��d��各种Component�Q�也��是�l�玩家添加各�U�逻辑功能�?/p>
但是�Q�Component之间可能会涉及到交互�Q�玩家对象之外的模块可能也会与玩家内的某个Component交互。子功能点的拆分�Q�不得不涉及到更多的胶水代码�Q�这也算一�U�代仗��?/p>

游戏对象属性设�?/h1>
�q�䆾属性结构设计，基本��是参考了上面提到的设计思想。整个系�l�有如下�l��g:

Entity: +-------------------+ | property-table | +-------------------+ | component-table | +-------------------+ Property: +-------------------+ | observer-list | +-------------------+ Component: +--------------------+ | logic-related data | +--------------------+ | logic-related func | +--------------------+

意即�Q�所有Entity都包含一个属性表和组件表。这里的属性表�q��编码的属性数据成员集合，而是一个key-value形式的表。Property包含一个观察者列表，其实��是一�p�d��回调函数�Q�但是这些观察者本质上也是�l��g�Q�后面会提到。Component正如上文描述�Q�仅包含Component本��n实现的功能所需要的数据和函数。整个结构大致的代码如下:

class Entity { private: GUID id; std::map components; std::map properties; }; class Property { private: std::string name; Value val; std::vector observers; }; class IComponent { public: virtual bool Operate (const Args &args) { return false; } virtual void OnNotify (const Property &property, const Args &args) {} protected: std::string name; Entity *entity; };

属性本�w�是抽象的，�q�完全是因�ؓ我们��属性统一地放在了一个表里。从而又��D��属性的��g��需�?a >�l�箋阅读

Kevin Lynx 2011-05-02 19:19 发表评论

�|�游中的玩家�U�d��

Kevin Lynx — Tue, 22 Jun 2010 13:27:00 GMT
     摘要: MMORPG中，玩家的移动主要逻辑都放在客��L��q�行�Q�包括自动寻路和响应玩家的操作，服务
器在�q�里担当一个被动角艌Ӏ�但是服务器端的玩家数据却是真正的被其他逻辑模块参考的�?
据�?nbsp; 阅读全文

Kevin Lynx 2010-06-22 21:27 发表评论

Kevin Lynx — Sat, 19 Jun 2010 06:59:00 GMT
     摘要: 一般的资源包文件格式基本上是由包文件头和包内容�l�成。文件头描述资源包内打包的文�?
信息�Q�例如文件名、在资源包里的偏�U�R��大��、压�~�加密相关信息等�Q�包内容则是实际文�g
打包在一起后的内容，可能直接是未打包前文件连�l�存攑֜�一��L��内容�Q�也可能是相同类�?
文�g除掉文�g头的内容�Q�例如某个资源包里打包的全部是相同格式的囄��文�g�Q�那么这些图
片文件被打包后包内只需要保存一个图片文件头�Q�包内容全部是直接的囄��数据�Q��?  阅读全文

Kevin Lynx 2010-06-19 14:59 发表评论

SGI STL的内存池

Kevin Lynx — Thu, 12 Jun 2008 13:26:00 GMT

stl中各�U�容器都有一个可选的模板参数�Q�allocator�Q�也��是一个负责内存分配的�l��g。STL标准规定的allcator
被定义在memory文�g中。STL标准规定的allocator只是单纯地封装operator new�Q�效率上有点�q�意不去�?
SGI实现的STL里，所有的容器都��用SGI自己定义的allocator。这个allocator实现了一个small object的内存池�?br>Loki里�ؓ了处理小对象的内存分配，也实��C��c�M��的内存管理机制�?
该内存池大致上，��是一大块一大块��C��pȝ��获取内存�Q�然后将其分成很多小块以链表的�Ş式链接�v来。其内部
有很多不同类型的链表�Q�不同的链表�l�护不同大小的内存块。每一�ơ客��L��要求分配内存�Ӟ��allcator��根据请�?br>的大��找到相应的链表(最接近的尺�?�Q�然后从链表里取出内存。当客户端归�q�内存时�Q�allocator��将�q�块内存
攑֛�到对应的链表里�?
我简单地��M��q�图表示整个�l�构�Q?/font>

allocator内部�l�护一个链表数�l�，数组元素全部是链表头指针。链表A每一个节点维护一�?bytes的内存块�Q�链�?br>B每一个节点维护一�?6bytes的内存块�?
当客��L��h��分配10bytes的内存时�Q�allocator��?0调整为最接近�?6bytes(只能大于10bytes)�Q�然后发�?6bytes
�q�个链表(链表B)里有可用内存块，于是从B里取��Z��块内存返回。当客户端归�q�时�Q�allocator扑ֈ�对应的链表，��?br>内存重新攑֛�链表B卛_��?
大致�q�程��p��么简单，也许有�h要说用链表维护一块内存，链表本��n��׃��费一些内�?在我很早前接触内存池�Ӟ��
��M��看到�c�M��的论�? =|)�Q�其实通过一些简单的技巧是完全可以避免的。例如，�q�里allocator�l�护了很多内存块�Q?br>反正�q�些内存本��n��是闲置的，因此我们��可以直接在�q�些内存里记录链表的信息(下一个元�?�?
�q�是写点代码详细说下�q�个��技巧：


struct Obj
    {
        Obj *next;
    };

    void *mem = malloc( 100 );
    Obj *header = (Obj*) mem;
    Obj *cur_obj = header;
    Obj *next_obj = cur_obj;
    for( int i = 0; ; ++ i )
    {
        cur_obj = next_obj;
        next_obj = (Obj*)((char*)next_obj + 10 );
        if( i == 9 )
        {
            cur_obj->next = 0;
            break;
        }
        else
        {
            cur_obj->next = next_obj;
        }
    }
    free( mem );

�q�样�Q�通过header指针和next域，��可以逐块(�q�里�?0byts)地访问mem所指向的内存，而这些链表的节点�Q�都
是直接保存在�q�块内存里的�Q�所以完全没有额外消耗�?
我用C模仿着SGI的这个allocator写了个可配置的内存池�Q�在其上按照STL的标准包装了一个allocator�Q�可以直�?br>用于VC自带的STL里�?/font>��试代码�E�微��试了下�Q�发现在不同的机器上有明昄��差距�?

Kevin Lynx 2008-06-12 21:26 发表评论

�H�破select的FD_SETSIZE限制

Kevin Lynx — Tue, 20 May 2008 03:20:00 GMT

Author : Kevin Lynx
前言�Q?/strong>
在很多比较各�U�网�l�模型的文章中，但凡提到select模型�Ӟ��都会说select受限于轮询的套接字数量，�q�个
数量也就是系�l�头文�g中定义的FD_SETSIZE�?例如64)。但事实上这个算不上真的限制�?
C语言的偏方：
在C语言的世界里存在一个关于结构体的偏门技巧，例如�Q?

typedef struct _str_type
{
    int _len;
    char _s[1];
}str_type;

str_type用于保存字符�?我只是�D例，事实上这个结构体没什么用�?�Q�乍看上去str_type只能保存长度�?br>1的字�W�串('\0')。但是，通过写下如下的代码，你将�H�破�q�个限制�Q?

int str_len = 5;
str_type *s = (str_type*) malloc( sizeof( str_type ) + str_len - 1 );
//
free( s );

�q�个技巧原理很��单，因�ؓ_s恰好在结构体��N��Q�所以可以�ؓ其分配一�D�连�l�的�I�间�Q�只要注意指针的使用�Q?br>�q�个��q��不上代码上的�|�恶。但是这个技巧有个限�Ӟ��str_type定义的变量必��L��被分配在堆上�Q�否则会�?br>坏堆栈。另外，需要动态增长的成员需要位于结构体的末��。最后，一个忠告就是，�q�个是C语言里的技巧，
如果你的�l�构体包含了C++的东西，�q�个技巧将不再安全()�?
其实select也可以这样做�Q?/strong>
事实上，因�ؓselect涉及到的fd_set是一个完全满��上�q�要求的�l�构体：

winsock2.h :

typedef struct fd_set {
        u_int fd_count;               /**//* how many are SET? */
        SOCKET fd_array[FD_SETSIZE];   /**//* an array of SOCKETs */
} fd_set;

但是�Q�如果��用了以上技巧来增加fd_array的数�?也就是保存的套接字数�?�Q�那么关于fd_set的那些宏�?br>能就无法使用了，例如FD_SET�?

winsock2.h :

#define FD_SET(fd, set) do { \
    u_int __i; \
    for (__i = 0; __i < ((fd_set FAR *)(set))->fd_count; __i++) { \
        if (((fd_set FAR *)(set))->fd_array[__i] == (fd)) { \
            break; \
        } \
    } \
    if (__i == ((fd_set FAR *)(set))->fd_count) { \
        if (((fd_set FAR *)(set))->fd_count < FD_SETSIZE) { \
            ((fd_set FAR *)(set))->fd_array[__i] = (fd); \
            ((fd_set FAR *)(set))->fd_count++; \
        } \
    } \
} while(0)

有点让�h��D��~��ؕ�Q�我鼓励你仔�l�看�Q�其实很��单。这里有个小技巧，��是他把�q�些代码攑ֈ�一个do...while(0)
里，��Z��么要�q�样做，我觉得应该是防止名字污染�Q�也��是防止那个__i变量与你的代码相冲突。可以看出，
FD_SET会将fd_count与FD_SETSIZE相比较，�q�里主要是防止往fd_array的非法位�|�写数据�?
因�ؓ�q�个宏原理不�q�如此，所以我们完全可以自己写一个新的版本。例如：

#define MY_FD_SET( fd, set, size ) do { \
    unsigned int i = 0; \
    for( i = 0; i < ((fd_set*) set)->fd_count; ++ i ) { \
        if( ((fd_set*)set)->fd_array[i] == (fd) ) { \
            break; \
        } \
    } \
    if( i == ((fd_set*)set)->fd_count ) { \
        if( ((fd_set*)set)->fd_count < (size) ) { \
            ((fd_set*)set)->fd_array[i] = (fd); \
            ((fd_set*)set)->fd_count ++; \
        } \
    } \
} while( 0 )

没什么变化，只是为FD_SET加入一个fd_array的长度参敎ͼ�宏体也只是将FD_SETSIZE换成�q�个长度参数�?br>于是�Q�现在你可以写下�q�样的代码：

unsigned int count = 100;
fd_set *read_set = (fd_set*) malloc( sizeof( fd_set ) + sizeof(SOCKET) * (count - FD_SETSIZE ) );
SOCKET s = socket( AF_INET, SOCK_STREAM, 0 );
//
MY_FD_SET( s, read_set, count );
//
free( read_set );
closesocket( s );

��提下select模型�Q?/strong>
�q�里我不会具体讲select模型�Q�我只稍微提一下。一个典型的select轮询模型为：

int r = select( 0, &read_set, 0, 0, &timeout );
if( r < 0 )
{
    // select error
}

if( r > 0 )
{
    for( each sockets )
    {
        if( FD_ISSET( now_socket, &read_set ) )
        {
            // this socket can read data
        }
    }
}

轮询write时也差不多。在Etwork(一个超��型的基本用于练习网�l�编�E�的�|�络�?google yourself)中，作�?br>的轮询方式则有所不同�Q?

// read_set, write_set为采用了上文所�q�技巧的fd_set�c�d��的指�?/span>
int r = select( 0, read_set, write_set, 0, &timeout );
// error handling
for( int i = 0; i < read_set->fd_count; ++ i )
{
    // 轮询所有socket�Q�这里直接采用read_set->fd_array[i] == now_socket判断�Q�而不是FD_ISSET
}

for( int i = 0; i < write_set->fd_count; ++ i )
{
    // 轮询所有socket�Q�检查其whether can write�Q�判断方式同�?/span>
}

两种方式的效率从代码上看��M��乎都差不多，关键在于�Q�FD_ISSET�q�了什么？�q�个宏实际上使用了__WSAFDIsSet
函数�Q�而__WSAFDIsSet做了什么则不知道。也许它会依赖于FD_SETSIZE宏，那么�q�在我们�q�里��是不安全的�Q?br>所以相比之下，如果我们使用了这个突破FD_SETSIZE的偏�Ҏ��D�，那么也许�W�二�U�方式要好些�?

相关下蝲(5.21.2008)
随便写了一个改�q�的select模型的echo服务器，放上源码�?/span>

Kevin Lynx 2008-05-20 11:20 发表评论

tcp要点学习-断开�q�接

Kevin Lynx — Wed, 14 May 2008 07:46:00 GMT

Author : Kevin Lynx
主要部分�Q�四�ơ握手：
断开�q�接其实从我的角度看不区分客��L��和服务器端，��M��一斚w��可以调用close(or closesocket)之类
的函数开始主动终止一个连接。这里先暂时说正常情��c��当调用close函数断开一个连接时�Q�主动断开�?br>一方发送FIN(finish报文�l�对斏V��有了之前的�l�验�Q�我想你应该明白我说的FIN报文时什么东�ѝ��也��是
一个设�|�了FIN标志位的报文�D�c��FIN报文也可能附加用��h��据，如果�q�一方还有数据要发送时�Q�将数据�?br>加到�q�个FIN报文时完全正常的。之后你会看刎ͼ��q�种附加报文�q�会有很多，例如ACK报文。我们所要把�?br>的原则是�Q�TCP肯定会力所能及地达到最大效率，所以你能够惛_��的优化方法，我想TCP都会惛_��?
当被动关闭的一�Ҏ��到FIN报文�Ӟ��它会发送ACK��认报文(对于ACK�q�个东西你应该很熟悉�?。这里有�?br>东西要注意，因�ؓTCP是双工的�Q�也��是��_��你可以想象一对TCP�q�接上有两条数据通�\。当发送FIN报文
�Ӟ��意思是��_��发送FIN的一端就不能发送数据，也就是关闭了其中一条数据通�\。被动关闭的一端发�?br>了ACK后，应用层通常��׃��到�q�个�q�接卛_��断开�Q�然后被动断开的应用层调用close关闭�q�接�?
我可以告诉你�Q�一旦当你调用close(or closesocket)�Q�这一端就会发送FIN报文。也��是��_��现在被动
关闭的一端也发送FIN�l�主动关闭端。有时候，被动关闭端会��ACK和FIN两个报文合在一起发送。主�?br>关闭端收到FIN后也发送ACK�Q�然后整个连接关�?事实上还没完全关闭，只是关闭需要交换的报文发�?br>完毕)�Q�四�ơ握手完成。如你所见，因�ؓ被动关闭端可能会��ACK和FIN合到一起发送，所以这也算不上
严格的四�ơ握�?--四个报文�D�c�?
在前面的文章中，我一直没提TCP的状态�{换。在�q�里我还是在犹��U是不是该��那张四处通用的图拿出来，
不过�Q�这里我只给出断开�q�接时的状态�{换图�Q�摘�?lt;The TCP/IP Guide>�Q?

�l�出一个正常关闭时的windump信息�Q?br>

14:00:38.819856 IP cd-zhangmin.1748 > 220.181.37.55.80: F 1:1(0) ack 1 win 65535
14:00:38.863989 IP 220.181.37.55.80 > cd-zhangmin.1748: F 1:1(0) ack 2 win 2920
14:00:38.864412 IP cd-zhangmin.1748 > 220.181.37.55.80: . ack 2 win 65535

补充�l�节�Q?/strong>
关于以上的四�ơ握手，我补充下�l�节�Q?br>1. 默认情况�?不改变socket选项)�Q�当你调用close( or closesocket�Q�以下说close不再重复)�Ӟ��如果
发送缓冲中�q�有数据�Q�TCP会��l�把数据发送完�?br>2. 发送了FIN只是表示�q�端不能�l�箋发送数�?应用层不能再调用send发�?�Q�但是还可以接收数据�?br>3. 应用层如何知道对端关闭？通常�Q�在最��单的��d��模型中，当你调用recv�Ӟ��如果�q�回0�Q�则表示对端
关闭。在�q�个时候通常的做法就是也调用close�Q�那么TCP层就发送FIN�Q��l�完成四�ơ握手。如果你不调�?br>close�Q�那么对端就会处于FIN_WAIT_2状态，而本端则会处于CLOSE_WAIT状态。这个可以写代码试试�?br>4. 在很多时候，TCP�q�接的断开都会由TCP层自动进行，例如你CTRL+C�l�止你的�E�序�Q�TCP�q�接依然会正常关
闭，你可以写代码试试�?
特别的TIME_WAIT状态：
从以上TCP�q�接关闭的状态�{换图可以看出�Q�主动关闭的一方在发送完对对方FIN报文的确�?ACK)报文后，
会进入TIME_WAIT状态。TIME_WAIT状态也�U�Cؓ2MSL状态�?
什么是2MSL�Q�MSL即Maximum Segment Lifetime�Q�也��是报文最大生存时��_��引用中的话：�?br>�?MSL)是�Q何报文段被丢弃前在网�l�内的最长时间。”那么，2MSL也就是这个时间的2倍。其实我觉得�?br>必要把这个MSL的确切含义搞明白�Q�你所需要明白的是，当TCP�q�接完成四个报文�D늚�交换�Ӟ��d��关闭�?br>一方将�l�箋�{�待一定时�?2-4分钟)�Q�即使两端的应用�E�序�l�束。你可以写代码试试，然后用netstat查看下�?
��Z��么需�?MSL�Q�根�?lt;TCP/IP详解>�?lt;The TCP/IP Guide>中的说法�Q�有两个原因�Q?br>其一�Q�保证发送的ACK会成功发送到�Ҏ��Q�如何保证？我觉得可能是通过��时计时器发送。这个就很难�?br>代码演示了�?br>其二�Q�报文可能会被�؜淆，意思是��_��其他时候的�q�接可能会被当作本次的连接。直接引�?lt;The TCP/IP Guide>
的说法：The second is to provide a “buffering period�?between the end of this connection
and any subsequent ones. If not for this period, it is possible that packets from different
connections could be mixed, creating confusion.
TIME_WAIT状态所带来的媄响：
当某个连接的一端处于TIME_WAIT状态时�Q�该�q�接��不能再被��用。事实上�Q�对于我们比较有现实意义�?br>是，�q�个端口��不能再被��用。某个端口处于TIME_WAIT状�?其实应该是这个连�?�Ӟ��q�意味着�q�个TCP
�q�接�q�没有断开(完全断开)�Q�那么，如果你bind�q�个端口�Q�就会失败�?
对于服务器而言�Q�如果服务器�H�然crash掉了�Q�那么它��无法再2MSL内重新启动，因�ؓbind会失败。解册��
个问题的一个方法就是设�|�socket的SO_REUSEADDR选项。这个选项意味着你可以重用一个地址�?
对于TIME_WAIT的插�Ԍ��
当徏立一个TCP�q�接�Ӟ��服务器端会��l�用原有端口监听�Q�同时用�q�个端口与客��L��通信。而客��L��默认情况
下会使用一个随机端口与服务器端的监听端口通信。有时候，��Z��服务器端的安全性，我们需要对客户端进�?br>验证�Q�即限定某个IP某个特定端口的客��L��。客��L��可以使用bind来��用特定的端口�?
对于服务器端�Q�当讄��了SO_REUSEADDR选项�Ӟ��它可以在2MSL内启动�ƈlisten成功。但是对于客��L��Q�当�?br>用bind�q�设�|�SO_REUSEADDR�Ӟ��如果�?MSL内启动，虽然bind会成功，但是在windows�q�_��上connect会失败�?br>而在linux上则不存在这个问题�?我的实验�q�_��Q�winxp, ubuntu7.10)
要解决windows�q�_��的这个问题，可以讄��SO_LINGER选项。SO_LINGER选项军_��调用close�Ӟ��TCP的行为�?br>SO_LINGER涉及到linger�l�构体，如果讄��l�构体中l_onoff为非0�Q�l_linger�?�Q�那么调用close时TCP�q�接
会立��L��开�Q�TCP不会��发送缓冲中未发送的数据发送，而是立即发送一个RST报文�l�对方，�q�个时候TCP�q?br>接就不会�q�入TIME_WAIT状态�?
如你所见，�q�样做虽然解决了问题�Q�但是�ƈ不安全。通过以上方式讄��SO_LINGER状态，�{�同于设�|�SO_DONTLINGER
状态�?
断开�q�接时的意外�Q?/strong>
�q�个��不上断开�q�接时的意外�Q�当TCP�q�接发生一些物理上的意外情冉|��Q�例如网�U�断开�Q�linux上的TCP实现
会依然认��q�接有效�Q�而windows则会在一定时间后�q�回错误信息�?
�q�似乎可以通过讄��SO_KEEPALIVE选项来解冻I��不过不知道这个选项是否对于所有��^台都有效�?
�ȝ��Q?/strong>
个�h感觉�Q�越写越烂。接下来会讲到TCP的数据发送，�q�会涉及到滑动窗口各�U�定时器之类的东�ѝ��我真诚
希望各位能够多提意见。对于TCP�q�接的断开�Q�我们只要清楚：
1. 在默认情况下�Q�调用close时TCP会��l�将数据发送完毕；
2. TIME_WAIT状态会��D��的问题；
3. �q�接意外断开时可能会出现的问题�?br>4. maybe more...

Kevin Lynx 2008-05-14 15:46 发表评论

学生时代做的东西-留个�U�念

Kevin Lynx — Wed, 14 May 2008 01:23:00 GMT

可能我这个�h比较怀旧，对什么东襉K��惛_��个记录，方便日后回忆。可能很多认识我的朋友都是通过GameRes那个作品�?/p>
区。我对于当年那种疯狂�~�程的干劲很是自豪，现在差了很多�Q�以前帮别�h做小学生�p�d��游戏外包的时候，可以12��时�?/p>
个弱智的��游戏，那些日子一度被我称为�?2��时�~�程挑战赛‘，只是自己跟自己比赛�?/p>

每一�ơ发布在GameRes(排除早期的那些垃圄��意）�Q�在写简介时我都要把自己开发用的时间写上，可是脾气好的sea_bug

每次都给我删掉了。我自己汇��M��下：

1. 最让我自豪的一个游戏引擎，耗尽了我当时所有的设计能力。我努力把它做得很具扩展性，可是忽略了功能性。现在基本不�l�护了，可能是用��L��太少了。我��x��q�是没做好吧�Q?/p>
edge2d google code page

托sea_bug的忙搞了个论坛，��h��得让我心�?http://bbs.gameres.com/showforum.asp?forumid=91

2. PacShooter3d:

http://data.gameres.com/showmessage.asp?TopicID=90655

不知道怎么的被人放��C��个网站上了：http://noyes.cn/Software.Asp?id=9667

源代码下载�?/a>

3. Space Demon demo

当初看到dophi写的俄罗斯方块营造的那种感觉觉得很不错，于是军_��认真地做个游戏出来。结果后来做的东西让我很失望。这是一个在代码上过度设计的东西。我虽然对这个游戏不满意�Q�但是我对代码还基本满意。后来这个游戏的代码被我游戏学院的一个朋友拿�l�金��q��一个主�E�（在他们学校教书？�Q�看�Q�还得到了表扬�?D

�q�个游戏我是直接开源了的：http://www.gameres.com/showmessage.asp?TopicID=73123

4. Crazy Eggs Clone

是小林子他们工作室做的东西，属于casual games�Q�拿到国外去卖的。我当时也觉得casual games市场不错�Q�还找了个美工，大谈特谈�Q�吹嘘了很多�Q�最�l�在写策划案的时候失败了。我当时心也懒了�Q�最�l�失败�?/p>
同样是在GameRes上：http://www.gameres.com/showmessage.asp?TopicID=72351

源代码下载�?/a>

后来我�ؓ了宣传edge2d�Q�特地把�q�个游戏�U�L��到我的引擎上。我从来很自豪自�׃��码的模块性，所以移植�v来很�Ҏ��。除了edge2d版本�Q�我�q�做了HGE版本�Q�不�q�HGE版本是做�l�别人的外包�Q?/p>
edge2d版本下蝲

5. Brick Shooter Jr

�q�个游戏也是我翻版别人的�Q�用的别人的��术+音乐资源�Q�自己重写代码。后来网上有个�h又用我的资源��M��了个�Q�做的比我好�?/p>
http://data.gameres.com/showmessage.asp?TopicID=65654

源代码下�?/a>

6. Feeding Frenzy

Popcap的经典游戏，我做的垃圾东西，不提其他的了�Q?/p>
http://data.gameres.com/showmessage.asp?TopicID=62796

源代码下�?/a>

7.是男人就下一癑ֱ�

��古老的东西�Q�这个东西当初还和上��一家广告公司合作过。我�{��v了长�q�么大的�W�一份合同，�l�果后来一分钱没捞到。他们公司现在也不做�q�个了。和我合作的产品�l�理现在貌似在搞��牌�?/p>
http://data.gameres.com/showmessage.asp?TopicID=54475

源代码下�?/a>

8. 所谓的��L��Q�一个我最早做的东西，现在你开baidu搜烦 kevin lynx�Q�出来最多的链接��是<��L��kevinlynx�?gt;�Q�别信那

些，全是��氓软�g�?/p>
http://data.gameres.com/showmessage.asp?TopicID=54474

源代码下�?/a>

其他�q�给别�h做了一些外包，在此特别感谢哆啦G梦老大�Q�给我找了很多工作。他�q�个人四处蟩巢，�q�给我说了几�ơ工作�?/p>
只是我还��x��时留在成都，所以都拒绝了。那些外包做的都比较垃圾�Q�做到后来基本有个小游戏框架了。版权问题可能不

能发布出来吧�?/p>

Kevin Lynx 2008-05-14 09:23 发表评论

tcp要点学习-建立�q�接

Kevin Lynx — Sat, 10 May 2008 17:03:00 GMT

Author : Kevin Lynx
准备�Q?/strong>
在这里本文将遵��@上一��文章的风格�Q�只提TCP协议中的要点�Q�这��h��觉得可以更容易地掌握TCP。或�?br>�Ҏ��谈不上掌握，对于�q�种�U�理论的东西�Q�即使你现在掌握了再多的�l�节�Q�一�D�|��间后也会淡忘�?
在以后各�U�细节中�Q�因为我们会涉及到分析一些TCP中的数据报，因此一个协议包截获工具必不可少。在
中一直��用tcpdump。这里因为我的系�l�是windows�Q�所以只好��用windows�q�_��的tcpdump�Q?br>也就�?a target="_blank">WinDump。在使用WinDump之前�Q�你需要安装该�E�序使用的库WinpCap�?
关于WinDump的具体用法你可以从网上其他地方获取，�q�里我只�E�微提一下。要让WinDump开始监听数据，
首先需要确定让其监听哪一个网�l�设�?或者说是网�l�接�?。你可以:

windump -D

获取当前机器上的�|�络接口。然后��用：

windump -i 2

开始对�|�络接口2的数据监听。windump如同tcpdump(其实��是tcpdump)一��h��持过滤表辑ּ��Q�windump
��会�Ҏ��你提供的�q��o表达式过滤不需要的�|�络数据包，例如�Q?

windump -i 2 port 4000

那么windump只会昄��端口号�ؓ4000的网�l�数据�?
序号和确认号�Q?/strong>
要讲解TCP的徏立过�E�，也就是那个所谓的三次握手�Q�就会涉及到序号和确认号�q�两个东�ѝ��翻书到TCP
的报文头�Q�有两个很重要的�?都是32�?��是序号域和��认号域。可能有些同学会对TCP那个报文头有所
疑惑(能看懂我在讲什么的会��生这��L��疑惑么？)�Q�这里我可以告诉你，你可以假想TCP的报文头��是�?br>C语言�l�构�?假想而已�Q�去��ȝ��bsd对TCP的实玎ͼ�肯定没这么简�?�Q�那么大致上�Q�所谓的TCP报文头就是：

typedef struct _tcp_header
{
    /**//// 16位源端口�?/span>
    unsigned short src_port;
    /**//// 16位目的端口号
    unsigned short dst_port;
    /**//// 32位序�?/span>
    unsigned long seq_num;
    /**//// 32位确认号
    unsigned long ack_num;
    /**//// 16位标志位[4位首部长度，保留6位，ACK、SYN之类的标志位]
    unsigned short flag;
    /**//// 16位窗口大��?/span>
    unsigned short win_size;
    /**//// 16位校验和
    short crc_sum;
    /**//// 16位紧急指�?/span>
    short ptr;
    /**//// 可选选项
    /// how to implement this ?
} tcp_header;

那么�Q�这个序号和��认��h��什么？TCP报文为每一个字节都讄��一个序��P��觉得很奇怪？�q�里�q�不是�ؓ每一
字节附加一个序�?那会是多么可�W�的�~�程手法?)�Q�而是��Z��个TCP报文附加一个序��P��q�个序号表示报文
中数据的�W�一个字节的序号�Q�而其他数据则是根据离�W�一个数据的偏移来决定序��L��Q�例如，现在有数据：
abcd。如果这�D�|��据的序号�?200�Q�那么a的序号就�?200�Q�b的序号就�?201。而TCP发送的下一个数据包
的序号就会是上一个数据包最后一个字节的序号加一。例如efghi是abcd的下一个数据包�Q�那么它的序号就
�?204。通过�q�种看似��单的�Ҏ��Q�TCP��实��C��为每一个字节设�|�序��L��功能(�l�于明白��Z��么书上要告诉
我们‘�ؓ每一个字节设�|�一个序号’了�?)。注意，讄��序号是一�U�可以让TCP成�ؓ’可靠协议‘的手段�?br>TCP中各�U��ؕ七八�p�的东西都是有目的的�Q�大部分目的�q�是��Z��’可靠‘两个字。别把TCP看高�׃��Q�如�?br>让你来设计一个网�l�协议，目的需要告诉你是’可靠的‘，你就会明白�ؓ什么会产生那些�׃��八糟的东西了�?
接着看，��认��h��什么？因�ؓTCP会对接收到的数据包进行确认，发送确认数据包�Ӟ��׃��讄��q�个��认��P��
��认号通常表示接收方希望接收到的下一�D�|��文的序号。例如某一�ơ接收方收到序号�?200�?字节��C�D报，
那么它发送确认报文给发送方�Ӟ��׃��讄��认号�ؓ1204�?
大部分书上在讲确认号和序��h��Q�都会说��认��h��序号加一。这其实有点误解人，所以我才在�q�里废话�?br>半天(高手宽容�?D)�?
开始三�ơ握手：
如果你还不会��单的tcp socket�~�程�Q�我��你先��d��学，�q�就好比你不会C++基本语法�Q�就别去研究vtable
之类�?
三次握手开始于客户端试图连接服务器端。当你调用诸如connect的函数时�Q�正常情况下��׃��开始三�ơ握手�?br>随便在网上找张三�ơ握手的图：

如前文所�q�ͼ�三次握手也就是��生了三个数据包。客��L��d��q�接�Q�发送SYN被设�|�了的报�?注意序号�?br>��认��P��因�ؓ�q�里不包含用��h��据，所以序号和��认号就是加一减一的关�p?。服务器端收到该报文�Ӟ��?br>常情况下��发送SYN和ACK被设�|�了的报文作为确认，以及告诉客户端：我想打开我这边的�q�接(双工)。客�?br>端于是再�Ҏ��务器端的SYN�q�行��认�Q�于是再发送ACK报文。然后连接徏立完毕。对于阻塞式socket而言�Q�你
的connect可能��p��回成功给你�?
在进行了铺天盖地的罗利巴索的基础概念的讲解后�Q�看看这个连接徏立的�q�程�Q�是不是��单得几近无聊�Q?
我们来实际点�Q�写个最��单的客户端代码：

   sockaddr_in addr;
    memset( &addr, 0, sizeof( addr ) );
    addr.sin_family = AF_INET;
    addr.sin_port = htons( 80 );
    /**//// 220.181.37.55
    addr.sin_addr.s_addr = inet_addr( "220.181.37.55" );
    printf( "%s : connecting to server.\n", _str_time() );
    int err = connect( s, (sockaddr*) &addr, sizeof( addr ) );

主要��是connect。运行程序前我们�q�行windump�Q?

windump -i 2 host 220.181.37.55

00:38:22.979229 IP noname.domain.4397 > 220.181.37.55.80: S 2523219966:2523219966(0) win 65535 <mss 1460,nop,nop,sackOK>
00:38:23.024254 IP 220.181.37.55.80 > noname.domain.4397: S 1277008647:1277008647(0) ack 2523219967 win 2920 <mss 1440,nop,nop,sackOK>
00:38:23.024338 IP noname.domain.4397 > 220.181.37.55.80: . ack 1 win 65535

如何分析windump的结果，��参看中对于tcpdump的描�q��?
建立�q�接的附加信息：
虽然SYN、ACK之类的报文没有用��h��据，但是TCP�q�是附加了其他信息。最为重要的��是附加的MSS倹{��这�?br>可以被协商的MSS值基本上��只在徏立连接时协商。如以上数据表示�Q�MSS�?460字节�?
�q�接的意外：
�q�接的意外我大致分�ؓ两种情况(也许�q�有更多情况)�Q�目的主��Z��可达、目的主机�ƈ没有在指定端口监听�?br>当目的主��Z��可达�Ӟ��也就是说�Q�SYN报文�D�|��本无法到辑֯��?如果你的机器�Ҏ��没插�|�线�Q�你��׃��可达)�Q?br>那么TCP收不��C�Q何回复报文。这个时候，你会看到TCP中的定时器机制出��C��。TCP对发出的SYN报文�q�行
计时�Q�当在指定时间内没有得到回复报文�Ӟ��TCP��׃��重传刚才的SYN报文。通常�Q�各�U�不同的TCP实现对于
�q�个��时值都不同�Q�但是据我观察，重传�ơ数基本上都�?�ơ。例如，我连接一个不可达的主机：

12:39:50.560690 IP cd-zhangmin.1573 > 220.181.37.55.1024: S 3117975575:3117975575(0) win 65535 <mss 1460,nop,nop,sackOK>
12:39:53.538734 IP cd-zhangmin.1573 > 220.181.37.55.1024: S 3117975575:3117975575(0) win 65535 <mss 1460,nop,nop,sackOK>
12:39:59.663726 IP cd-zhangmin.1573 > 220.181.37.55.1024: S 3117975575:3117975575(0) win 65535 <mss 1460,nop,nop,sackOK>

发出了三个序号一��L��SYN报文�Q�但是没有得��C��个回复报�?废话)。每一个SYN报文之间的间隔时间都�?br>有规律的�Q�在windows上是3�U?�U?�U?2�U�。上面的数据你看不到12�U�这个数据，因�ؓ�q�是�W�三个报文发出的
旉��和connect�q�回错误信息时的旉��之差。另一斚w��Q�如果连接同一个网�l�，�q�个间隔旉��又不同。例�?br>直接�q�局域网�Q�间隔时间就差不多�ؓ500ms�?
(我强烈徏议你能运行windump去试验这里提到的每一个现象，如果你在ubuntu下��用tcpdump�Q�记住sudo :D)
出现意外的第二种情况是如果主机数据包可达�Q�但是试图连接的端口�Ҏ��没有监听�Q�那么发送SYN报文的这
方会收到RST被设�|�的报文(connect也会�q�回相应的信息给�?�Q�例如：

13:37:22.202532 IP cd-zhangmin.1658 > 7AURORA-CCTEST.7100: S 2417354281:2417354281(0) win 65535 <mss 1460,nop,nop,sackOK>
13:37:22.202627 IP 7AURORA-CCTEST.7100 > cd-zhangmin.1658: R 0:0(0) ack 2417354282 win 0
13:37:22.711415 IP cd-zhangmin.1658 > 7AURORA-CCTEST.7100: S 2417354281:2417354281(0) win 65535 <mss 1460,nop,nop,sackOK>
13:37:22.711498 IP 7AURORA-CCTEST.7100 > cd-zhangmin.1658: R 0:0(0) ack 1 win 0
13:37:23.367733 IP cd-zhangmin.1658 > 7AURORA-CCTEST.7100: S 2417354281:2417354281(0) win 65535 <mss 1460,nop,nop,sackOK>
13:37:23.367826 IP 7AURORA-CCTEST.7100 > cd-zhangmin.1658: R 0:0(0) ack 1 win 0

可以看出�Q?AURORA-CCTEST.7100�q�回了RST报文�l�我�Q�但是我�q�边�Ҏ��不在乎这个报文，�l�箋发送SYN报文�?br>三次�q�后connect��p��回了�?数据反映的事实是�q�样)
关于listen:
TCP服务器端会维护一个新�q�接的队列。当新连接上的客��L��三次握手完成�Ӟ��׃��其攑օ��q�个队列。这个队
列的大小是通过listen讄��的。当�q�个队列满时�Q�如果有新的客户端试图连接（发送SYN�Q�，服务器端丢弃报文�Q?
同时不做��M��回复�?
�ȝ��Q?/strong>
TCP�q�接的徏立的相关要点��是�q�些(or more?)。正常情况下��是三次握手�Q�非正常情况下就是SYN三次��时�Q?br>以及收到RST报文却被忽略�?

Kevin Lynx 2008-05-11 01:03 发表评论

Kevin Lynx — Tue, 06 May 2008 09:37:00 GMT

预计新项目会选择lua或python之一作�ؓ游戏的脚本语�a�。以前草草地接触�q�这两门语言�Q�对于语法，以及嵌入�q�C/C++�E�序都有�Ҏ��性上的认识。可能是受《UNIX�~�程艺术》中KISS原则的媄响，现在��d��Ƣ简�z�的东西。所以我个�h比较偏向于��用lua�?/p>

�q�两天翻了下�|�络上的资料�Q�在lua的wiki上看��C��比较lua和python�?a >文章�Q�草草地��译��点：

Python:
1. 扩展库很多，资料很多
2. 数��D��比较强大，支持多维数组�Q�而lua没有数组�c�d��
3. 本��n带的c�c�d��(?)支持处理动态链接库�Q�不需要进行C��装(C扩展)
4. �q�程调试器，��g��lua扩展工具支持
5. 自然语言似的语法
6. 对于string和list的支持，lua可以通过扩展库实�?br>7. 对unicode的支�?br>8. �I�格敏感(代码不忽略空�?�Q�这其实可以使python的代码风格看��h��更好一�?br>9. 内徏位操作，lua可以通过扩展库支�?br>10.语言本��n寚w��误的处理要好些，可以有效减少�E�序错误
11.初��文档比lua�?br>12.寚w��向对象支持更�?
Lua:
1. 比python��y很多(包括�~�译出来的运行时�?
2. 占用更小的内�?br>3. 解释器速度更快
4. 比python更容易集成到C语言�?br>5. 对于对象不��用引用计�?引用计数会导致更多的问题�Q?
6. lua早期定位于一�U�配�|�语�a�(作�ؓ配置文�g)�Q�因此比起python来更�Ҏ��配置数据
7. 语言更漂�?nice)、简�?simple)、强�?powerful)�?br>8. lua支持多线�E�，每个�U�程可以配置独立的解释器�Q�因此lua更适合于集成进多线�E�程�?br>9. 对空��g��敏感�Q�不用担心编辑器会将tab替换成空�?
Useful Comments:
1. Everything is an object allocated on the heap in Python, including numbers. (So 123+456 creates a new heap object).
2. lua对于coroutine的支持更适用于嵌入进游戏�Q�虽然python也有�Q�但是�ƈ没有包含�q�核心模�?
3.Python was a language better suited to Game AI

本来惛_��扄��对于python的正面资�?嵌入�q�游戏这斚w��Q�，但是居然没找到。客观地说如果单独用python做应用，python�q�是很有优势。现在心意已冻I��应该向leader推荐lua�?/p>

ps�Q�希望能补充以上两种语言的特炏V�?/p>

Kevin Lynx 2008-05-06 17:37 发表评论

TCP/IP Concepts 1

Kevin Lynx — Fri, 18 Apr 2008 02:02:00 GMT

最�q�在草草地看TCP那一部分�Q�之所以草草地看是因�ؓ觉得早晚一天会回过头去�l�看。手头上
有工作要做，所以先草草地把之前随便摘抄的TCP/IP相关概念贴出来：

�l�箋草草地脓:

--------------------------------------------------------------------------------------------------------------------------------------------------------
TCP segment:
Thus, we have simply “passed the buck” to TCP, which must take the stream from the application
and divide it into discrete messages for IP. These messages are called TCP segments.

On regular intervals, it forms segments to be transmitted using IP. The size of the segment is
controlled by two primary factors. The first issue is that there is an overall limit to the size
of a segment, chosen to prevent unnecessary fragmentation at the IP layer. This is governed by a
parameter called the maximum segment size (MSS), which is determined during connection establishment.
The second is that TCP is designed so that once a connection is set up, each of the devices tells the
other how much data it is ready to accept at any given time. If this is lower than the MSS value, a
smaller segment must be sent. This is part of the sliding window system described in the next topic.

Since TCP works with individual bytes of data rather than discrete messages, it must use an
identification scheme that works at the byte level to implement its data transmission and tracking
system. This is accomplished by assigning each byte TCP processes a sequence number.

Since applications send data to TCP as a stream of bytes and not prepackaged messages, each
application must use its own scheme to determine where one application data element ends and the
next begins.

--------------------------------------------------------------------------------------------------------------------------------------------------------

TCP MSS:
http://www.tcpipguide.com/free/t_TCPMaximumSegmentSizeMSSandRelationshiptoIPDatagra.htm

In addition to the dictates of the current window size, each TCP device also has associated
with it a ceiling on TCP size—a segment size that will never be exceeded regardless of how
large the current window is. This is called the maximum segment size (MSS). When deciding
how much data to put into a segment, each device in the TCP connection will choose the amount
based on the current window size, in conjunction with the various algorithms described in
the reliability section, but it will never be so large that the amount of data exceeds the
MSS of the device to which it is sending.

Note: I need to point out that the name “maximum segment size” is in fact misleading. The
value actually refers to the maximum amount of data that a segment can hold—it does not
include the TCP headers. So if the MSS is 100, the actual maximum segment size could be 120
(for a regular TCP header) or larger (if the segment includes TCP options).

This was computed by starting with the minimum MTU for IP networks of 576.

Devices can indicate that they wish to use a different MSS value from the default by including
a Maximum Segment Size option in the SYN message they use to establish a connection. Each
device in the connection may use a different MSS value.

--------------------------------------------------------------------------------------------------------------------------------------------------------

delayed ACK algorithm

http://tangentsoft.net/wskfaq/intermediate.html#delayed-ack

In a simpleminded implementation of TCP, every data packet that comes in is immediately acknowledged
with an ACK packet. (ACKs help to provide the reliability TCP promises.)

In modern stacks, ACKs are delayed for a short time (up to 200ms, typically) for three reasons: a)
to avoid the silly window syndrome; b) to allow ACKs to piggyback on a reply frame if one is ready
to go when the stack decides to do the ACK; and c) to allow the stack to send one ACK for several
frames, if those frames arrive within the delay period.

The stack is only allowed to delay ACKs for up to 2 frames of data.

--------------------------------------------------------------------------------------------------------------------------------------------------------
Nagle algorithm:

Nagle's algorithm, named after John Nagle, is a means of improving the efficiency of TCP/IP networks by reducing the number of packets that need to be sent over the network.

Nagle's document, Congestion Control in IP/TCP Internetworks (RFC896) describes what he called the 'small packet problem', where an application repeatedly emits data in small chunks, frequently only 1 byte in size. Since TCP packets have a 40 byte header (20 bytes for TCP, 20 bytes for IPv4), this results in a 41 byte packet for 1 byte of useful information, a huge overhead. This situation often occurs in Telnet sessions, where most keypresses generate a single byte of data which is transmitted immediately. Worse, over slow links, many such packets can be in transit at the same time, potentially leading to congestion collapse.

Nagle's algorithm works by coalescing a number of small outgoing messages, and sending them all at once. Specifically, as long as there is a sent packet for which the sender has received no acknowledgment, the sender should keep buffering its output until it has a full packet's worth of output, so that output can be sent all at once.

[edit] Algorithm
if there is new data to send
if the window size >= MSS and available data is >= MSS
    send complete MSS segment now
else
    if there is unconfirmed data still in the pipe
      enqueue data in the buffer until an acknowledge is received
    else
      send data immediately
    end if
end if
end if
where MSS = Maximum segment size

This algorithm interacts badly with TCP delayed acknowledgments, a feature introduced into TCP at roughly the same time in the early 1980s, but by a different group. With both algorithms enabled, applications which do two successive writes to a TCP connection, followed by a read, experience a constant delay of up to 500 milliseconds, the "ACK delay". For this reason, TCP implementations usually provide applications with an interface to disable the Nagle algorithm. This is typically called the TCP_NODELAY option. The first major application to run into this problem was the X Window System.

The tinygram problem and silly window syndrome are sometimes confused. The tinygram problem occurs when the window is almost empty. Silly window syndrome occurs when the window is almost full

===================================================================================================================================
3.17 - What is the Nagle algorithm?
The Nagle algorithm is an optimization to TCP that makes the stack wait until all data is acknowledged on the connection before it sends more data. The exception is that Nagle will not cause the stack to wait for an ACK if it has enough enqueued data that it can fill a network frame. (Without this exception, the Nagle algorithm would effectively disable TCP's sliding window algorithm.) For a full description of the Nagle algorithm, see RFC 896.

So, you ask, what's the purpose of the Nagle algorithm?

The ideal case in networking is that each program always sends a full frame of data with each call to send(). That maximizes the percentage of useful program data in a packet.

The basic TCP and IPv4 headers are 20 bytes each. The worst case protocol overhead percentage, therefore, is 40/41, or 98%. Since the maximum amount of data in an Ethernet frame is 1500 bytes, the best case protocol overhead percentage is 40/1500, less than 3%.

While the Nagle algorithm is causing the stack to wait for data to be ACKed by the remote peer, the local program can make more calls to send(). Because TCP is a stream protocol, it can coalesce the data in those send() calls into a single TCP packet, increasing the percentage of useful data.

Imagine a simple Telnet program: the bulk of a Telnet conversation consists of sending one character, and receiving an echo of that character back from the remote host. Without the Nagle algorithm, this results in TCP's worst case: one byte of user data wrapped in dozens of bytes of protocol overhead. With the Nagle algorithm enabled, the TCP stack won't send that one Telnet character out until the previous characters have all been acknowledged. By then, the user may well have typed another character or two, reducing the relative protocol overhead.

This simple optimization interacts with other features of the TCP protocol suite, too:

Most stacks implement the delayed ACK algorithm: this causes the remote stack to delay ACKs under certain circumstances, which allows the local stack a bit of time to "Nagle" some more bytes into a single packet.

The Nagle algorithm tends to improve the percentage of useful data in packets more on slow networks than on fast networks, because ACKs take longer to come back.

TCP allows an ACK packet to also contain data. If the local stack decides it needs to send out an ACK packet and the Nagle algorithm has caused data to build up in the output buffer, the enqueued data will go out along with the ACK packet.
The Nagle algorithm is on by default in Winsock, but it can be turned off on a per-socket basis with the TCP_NODELAY option of setsockopt(). This option should not be turned off except in a very few situations.

Beware of depending on the Nagle algorithm too heavily. send() is a kernel function, so every call to send() takes much more time than for a regular function call. Your application should coalesce its own data as much as is practical to minimize the number of calls to send().

--------------------------------------------------------------------------------------------------------------------------------------------------------

Sliding Window Acknowledgment System :
http://www.tcpipguide.com/free/t_TCPSlidingWindowAcknowledgmentSystemForDataTranspo.htm
--------------------------------------------------------------------------------------------
A basic technique for ensuring reliability in communications uses a rule that requires a
device to send back an acknowledgment each time it successfully receives a transmission.
If a transmission is not acknowledged after a period of time, it is retransmitted by its
sender. This system is called positive acknowledgment with retransmission (PAR). One
drawback with this basic scheme is that the transmitter cannot send a second message
until the first has been acknowledged.
--------------------------------------------------------------------------------------------

http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html

The sliding window serves several purposes:
(1) it guarantees the reliable delivery of data
(2) it ensures that the data is delivered in order,
(3) it enforces flow control between the sender and the receiver.

------------------to be continued

Kevin Lynx 2008-04-18 10:02 发表评论

WoW服务器模拟器Ascent�|�络模块分析

Kevin Lynx — Wed, 02 Apr 2008 13:22:00 GMT

Ascent�|�络模块

Author: Kevin Lynx

Ascent是WoW的服务器模拟器，你可以从它的SVN上获取它的全部代码，�q�从它的WIKI��面获取架构��h��个服务器的相��x��骤�?/p>
基本架构�Q?o:p>

Ascent�|�络模块核心的几个类关系如下图所�C�：

ThreadBase属于Ascent�U�程池模块中的类�Q�它实现了一个job�c�，当其被加入到�U�程池中开始执行时�Q�线�E�池��理器会为其分配一个线�E�（如果有线�E�资源）�q�多态调用到ThreadBase�z��cȝ��run函数�?/p>
SocketWorkerThread用以代表IOCP�|�络模型中的一个工作者线�E�，它会从IOCP�l�果队列里取出异步IO的操作结果。这里的IOCP使用的完成键是Socket对象指针。SocketWorkerThread获取到IO操作�l�果后，�Ҏ��获得的完成键��结果通知�l�具体的Socket对象。（Socket的说明见后面�Q?/p>
ListenSocket代表一个监听套接字。该�|�络模块其实只是��单地��socket中的概念加以��装。也��p��Q�它依然把一个套接字分�ؓ两种�c�d��Q�监听套接字和数据套接字�Q�代表一个网�l�连接）。所谓的监听套接字，是指只可以在该套接字上进行监听操作；而数据套接字则只可以在此套接字上�q�行发送、接收数据的操作�?/p>
Socket代表我上面说的数据套接字。ListenSocket是一个类模板�Q��ؓ�q�个模板指定的模板参数通常是派生于Socket的类。其实这里��用了�q�个��技巧隐藏了工厂模式的细节。因为ListenSocket被放在一个单独的�U�程里运作，当其接受��C��个新的网�l�连接时�Q�就创徏一个Socket�z��c�d��象。（ListenSocket�c�d��何知道这个派生类的类名？�q�就是通过�c�L��板的那个模板参数�Q?/p>
上层模块通常会派生Socket�c�，实现一些IO操作的回调。也��p��Q�当某个IO操作完成后，会通过Socket基类让上层模块获取通知�?/p>
SocketMgr是一个全局单�g�c�R��它主要负责一些网�l�库的全局操作�Q�例如winsock库的初始化）�Q�它�q�维护了一个容器，保存所有的Socket对象。这其实是它的主要作用�?/p>
�q�作之一�Q�接收新的连�?/strong>�Q?o:p>

接收新的�|�络�q�接是通过ListenSocket实现的。在创徏一个ListenSocket对象�Ӟ��你需要指定它的模板参数。这个参数通常是一个派生于Socket的类。如下：

ascent-logonserver/Main.cpp



ListenSocket<AuthSocket> * cl = new ListenSocket<AuthSocket>(host.c_str(), cport);

AuthSocket�z��于Socket。创建ListenSocket时构造函数指定监听IP和监听端口�?/p>

因�ؓListenSocket�z��于ThreadBase�Q�属于线�E�池job�Q�因此要让ListenSocket工作��h��Q�只需要将其加入到�U�程池管理器�Q?/p>
ascent-logonserver/Main.cpp

ThreadPool.ExecuteTask(cl);

ListenSocket开始运作�v来后�Q�会��d��式地WSAAccept。如果WSAAccept�q�回一个有效的套接字，ListenSocket��创��Z��个Socket�z��c�d��象（�c�d��由模板参数指定）�Q�在上面丄��例子中，也就是AuthSocket�Q?/p>
ascent-logonserver/ ListenSocketWin32.h



  socket = new T(aSocket); //创徏AuthSocket�q�保存网�l�套接字aSocket

         socket->SetCompletionPort(m_cp);//保存完成端口对象

         socket->Accept(&m_tempAddress); //兌��到完成端口等

Accept函数最�l�会��新创徏的Socket对象保存到SocketMgr对象内部�l�护的容器里。在�q�里�Q�还会回调到上层模块的OnConnect函数�Q�从而实��C��息捕莗��?/p>
�q�作之二�Q�接收数�?o:p>

在windows�q�_��下，该网�l�模块��用的是IOCP模型�Q�属于异步IO。当接收新的�q�接�Ӟ��卛_��出WSARecv的IO操作。在工作者线�E�中�Q�也��是SocketWorkerThread中，会根据IOCP完成键得到Socket对象指针�Q�然后根据不同的IO操作�l�果多态回调到Socket�z��c�d��应的函数。例如如果是WSARecv完成�Q�则调用到AuthSocket::OnRead函数�Q�上�q�C��子）。OnRead函数直接可以获取��C��存数据的�~�冲区指针。事实上�Q�每一个Socket对象在被创徏�Ӟ��׃��自动创徏接收�~�冲��Z��及发送缓冲区�?/p>
�q�作之三�Q�发送数�?o:p>

分析到这里，我们可以看出�Q�该�|�络模块实现得很一般。在接受数据部分�Q�网�l�工作者线�E�回调到对应的Socket对象�Q�Socket直接�Ҏ��据进行上层逻辑处理。更好的做法是当工作者线�E�回调到上层Socket�Q�Socket的派生类�Q�时�Q�这里应该简单地��数据组�l�成上层数据包�ƈ攑օ�上层数据包队列，让上层逻辑�E�后处理�Q�而不是让�|�络模块自己��d��理。这样做主要是考虑到多�U�程模型�?/p>
同样�Q�该�|�络模块的发送模块也是一��P��没有�~�冲机制。当要发送数据时�Q�直接调用到Socket的Send函数。该函数拯��用户数据到自��q��护的发送缓冲区�Q�然后将自己的缓冲区指针直接提交�l�IOCP�Q�WSASend发送�?/p>

�l�束

该网�l�模块实现的��g��有点��陋，在该模块之上也没有数据校验、数据加密的模块�Q�这些动作散乱地分布在最上层逻辑�Q�。在架构上也没能很好地将概念区分开来，Socket套用了原始socket中的数据套接字，而不是我所希望的NetSession。可以圈点的地方在于该模块很多地方��用了回调函数表，从而方便地实现事�g传送�?/p>

Kevin Lynx 2008-04-02 21:22 发表评论

探究CRC32��法实现原理-why table-driven implemention

Kevin Lynx — Tue, 01 Apr 2008 13:22:00 GMT
     摘要: 探究CRC32��法实现原理-why table-driven implemention Author : Kevin Lynxemail : zmhn320@163.com Preface ��Z��不重造轮子的原则�Q�本文尽量不涉及�|�络上遍地都是的资料�?What's CRC ? ��而言之，CRC是一个数倹{��该数��D��用于校验数据的正��性。CRC数值简单地说就是通过让你需要做处理的数...  阅读全文

Kevin Lynx 2008-04-01 21:22 发表评论

欧美电影在线观看完整版,国内成人精品2018免费看,国产精品美女久久久久av超清

设计实现

实体设计

�|�络拓扑

消息协议

�ȝ��

谈谈我们的游戏逻辑服务器实玎ͼ�二）

一

改进

END

整体架构

实现

原始�l�构

Policy-based Design

Entity-Component-based Design

�|�游中的玩家�U�d��

SGI STL的内存池

�H�破select的FD_SETSIZE限制

tcp要点学习-断开�q�接

学生时代做的东西-留个�U�念

tcp要点学习-建立�q�接

TCP/IP Concepts 1

WoW服务器模拟器Ascent�|�络模块分析

探究CRC32���法实现原理-why table-driven implemention

探究CRC32��法实现原理-why table-driven implemention