上一篇谈了一些关键技术的实现方案。本篇描述一些遇到的问题。

一

在策划制作完了几个职业后（主要是技能制作），大概去年年底公司内部进行了一次混战测试。30个角色在一个场景进行混战，测试结果从技术上来说非常不理想。首先是客户端和服务器都巨卡无比。服务器CPU一直是满负载状态。而客户端又频繁宕机。

我们关注的主要问题，是服务器CPU满负载问题。最开始，我通过日志初步定位为网络模块问题，因为逻辑线程表现不是那么差。然后考虑到技能过程中的特效、动作都是通过服务器消息驱动，并且本身特效和动作就比一般网游复杂，通过逐一屏蔽这一部分功能，最终确认确为网络模块导致。然后团队决定从两方面努力：重写网络模块，改善性能；改善技能实现机制，将表现类逻辑移到客户端。

至于网络模块，在后来才发现，虽然网络流量过高，但导致网络线程CPU满的原因竟然是网络模块自身的流量限制导致。而技能实现机制的改善，考虑到改动的成本，最终使用了一种RPC机制，让服务器脚本可以调用客户端脚本，并且支持传入复杂参数。然后策划通过一些关键数据在客户端计算出特效、动作之类。

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

二

在策划制作了一个PVP竞技副本后，服务器在10V10测试过程中又表现出CPU负载较高的情况。这个问题到目前为止依然存在，只不过情况略微不同。

首先是触发器生命周期的问题。触发器自身包含最大触发次数、存留时间等需求，即当触发一定次数，或超过存留时间后，需要由程序自动删除；另一方面，触发器可以是定时器类型，而定时器也决定了触发器的生命周期。这一块代码写的非常糟糕，大概就是管理职责划分不清，导致出现对象自己删除自己，而删除后还在依赖自己做逻辑。

但这样的逻辑，最多就是导致野指针的出现。不过，这种混乱的代码，也更容易导致BUG。例如，在某种情况下触发器得不到自动删除了。但这个BUG并不是直接暴露的，直接暴露的，是CPU满了。我们的怪物AI在脚本中是通过定时器类触发器驱动的，每次AI帧完了后就注册一个触发器，以驱动下一次AI帧。由于这个BUG导致触发器没有被删除，从而导致服务器上触发器的数量急剧增加。但，这也就导致内存增长吧？

另一个巧合的原因在于，在当时的版本中，触发器是保存一个表里的，即定时器类触发器、属性类触发器、移动类触发器等都在一个表里。每次任意触发器事件发生时，例如属性改变，都会遍历这个表，检查其是否触发。

基于以上原因，悲剧就发生了。在这个怪物的AI脚本里，有行代码设置了怪物的属性。这会导致程序遍历该怪物的所有触发器。而这个怪物的触发器数量一直在增长。然后就出现了在很多游戏帧里出现过长的遍历操作，CPU就上去了。

找到这个问题了几乎花了我一天的时间。因为脚本代码不是我写的，触发器的最初版本也不是我写的。通过逐一排除可能的代码，最终竟然发现是一行毫不起眼的属性改变导致。这个问题的查找流程，反映了将大量逻辑放在脚本中的不便之处：查起问题来实在吃力不讨好。

修复了这个BUG后，我又对触发器管理做了简单的优化。将触发器列表改成二级表，将触发器按照类型保存成几个列表。每次触发事件时，找出对应类型的表遍历。

改进

除了修改触发器的维护数据结构外，程序还实现了一套性能统计机制，大概就是统计某个函数在一段时间内的执行时间情况。最初这套机制仅用于程序，但考虑到脚本代码在整个项目中的比例，又决定将其应用到脚本中。

这个统计需要在函数进入退出时做一些事情，C++中可以通过类对象的构建和析构完成，但lua中没有类似机制。最初，我使用了lua的调试库来捕获函数进入/退出事件，但后来又害怕这种方式本身存在效率消耗，就取消了。我们使用lua的方式，不仅仅是全局函数，还包括函数对象。而函数对象是没有名字标示的，这对于日志记录不是什么好事。为了解决这个问题，我只好对部分功能做了封装，并让策划显示填入函数对于的字符串标示。

除此之外，因为触发器是一种重要的敏感资源，我又加入了一个专门的触发器统计模块，分别统计触发器的类型数量、游戏对象拥有的触发器数量等。

END

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

我们的逻辑服务器(Game Server，以下简称GS)主要逻辑大概是从去年夏天开始写的。因为很多基础模块，包括整体结构沿用了上个项目的代码，所以算不上从头开始做。转眼又快一年，我觉得回头总结下对于经验的积累太有必要。

整体架构

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

需求

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

实现

基于以上需求，程序员所做的就是开发框架，制定功能实现方案。脚本为了与整个游戏框架交互，我们制定了“触发器“这个概念，大概就是一种事件系统。

这个触发器系统，简单来说，就是提供一种“关心“、”通知“的交互方式，也就是一般意义上的事件机制。例如，脚本中告诉程序它关心某个对象的移动，那么当程序中该对象产生移动时，就通知脚本。脚本中可以关心很多东西，包括对象属性，其关心的方式包括属性值改变、变大、变小，各种变化形式；对象开始移动，移动停止；对象碰撞，这个会单独谈谈；定时器等。

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

第三，怪物AI模块。AI模块的设计在开发周期上靠后。同样，程序不会去编写某类AI的实现。程序提供了另一种简单的事件系统，这个系统其实就是一个调用脚本的方案。当关于某个怪物发生了某个事件时，程序调用脚本，传入事件类型和事件参数。这个事件分为两类：程序类和脚本类。脚本类程序不需关心，仅提供事件触发API。程序类事件非常有限：怪物创建、出生、删除。

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

接下来谈一些关键模块的实现。

定时器

整个GS的很多逻辑模块都基于这个定时器来实现。这个定时器接收逻辑模块的注册，在主循环中传入系统时间，定时器模块检查哪些定时器实例超时，然后触发调用之。这个主循环以每帧5ms的速率运行，也即帧率1000/5。

这个定时器是基于操作系统的时间。随着帧率的不同，它在触发逻辑功能时，就必然不精确。游戏客户端（包括单机游戏）在帧率这块的实现上，一般逻辑功能的计算都会考虑到一个dt（也就是一帧的时间差），例如移动更新，一般都是x = last_x + speed * dt。但，我们这里并没有这样做。我们的几乎所有逻辑功能，都没有考虑这个时间差。

例如，我们的移动模块注册了一个固定时间值的定时器，假设是200ms。理想情况下，定时器模块每200ms回调移动模块更新坐标。但现实情况肯定是大于200ms的更新频率，悲剧的是，移动模块每次更新坐标都更新一个固定偏移。这显然是不够精确的。

更悲剧的是，定时器的实现中，还可能出现跳过一些更新帧。例如，理论情况下，定时器会在系统时间点t1/t2/t3/t4分别回调某个逻辑模块。某一帧里，定时器大概在t1回调了某逻辑模块，而当该帧耗时严重时，下一帧定时器模块在计算时，其时间值为t，而t大于t4，此时定时器模块跳过t2/t3。相当于该逻辑模块少了2次更新。这对于移动模块而言，相当于某个对象本来在1秒的时间里该走5格，但实际情况却走了1格。

当然，当游戏帧率无法保证时，逻辑模块运行不理想也是情有可原的。但，不理想并不包含BUG。而我觉得，这里面是可能出现BUG的。如何改善这块，目前为止我也没什么方案。

移动

有很多更上层的模块依赖移动。我们的移动采用了一种分别模拟的实现。客户端将复杂的移动路径拆分为一条一条的线段，然后每个线段请求服务器移动。然后服务器上使用定时器来模拟在该线段上的移动。因为服务器上的阻挡是二维格子，这样服务器的模拟也很简单。当然，这个模块在具体实现上复杂很多，这里不细谈。

碰撞检测

我们的技能要求有碰撞检测，这主要包括对象与对象之间的碰撞。在最早的实现中，当脚本关心某个对象的碰撞情况时，程序就为该对象注册定时器，然后周期触发检测与周围对象的距离关系，这个周期低于100ms。这个实现很简单，维护起来也就很简单。但它是有问题的。因为它基于了一个不精确的定时器，和一个不精确的移动模块。

首先，这个检测是基于对象的当前坐标。前面分析过在帧率掉到移动更新帧都掉帧的情况下，服务器的对象坐标和理论情况差距会很大，而客户端基本上是接近正确情况的，这个时候做的距离检测，就不可能正确。另一方面，就算移动精确了，这个碰撞检测还是会带来BUG。例如现在检测到了碰撞，触发了脚本，脚本中注册了关心离开的事件。但不幸的是，在这个定时器开始检测前，这两个对象已经经历了碰撞、离开、再碰撞的过程，而定时器开始检测的时候，因为它基于了当前的对象坐标，它依然看到的是两个对象处于碰撞状态。

最开始，我们直觉这样的实现是费时的，是不精确的。然后有了第二种实现。这个实现基于了移动的实现。因为对象的移动是基于直线的（服务器上）。我们就在对象开始移动时，根据移动方向、速度预测两个对象会在未来的某个时间点发生碰撞。当然，对于频繁的小距离移动而言，这个预测从直觉上来说也是费时的。然后实现代码写了出来，一看，挺复杂，维护难度不小。如果效果好这个维护成本也就算了，但是，它依然是不精确的。因为，它也依赖了这个定时器。

例如，在某个对象开始移动时，我们预测到在200ms会与对象B发生碰撞。然后注册了一个200ms的定时器。但定时器不会精确地在未来200ms触发，随着帧率的下降，400ms触发都有可能。即便不考虑帧率下降的情况，它还是有问题。前面说过，我们游戏帧保证每帧至少5ms，本来这是一个限帧手段，目的当然是避免busy-loop。这导致定时器最多出现5ms的延迟。如果策划使用这个碰撞检测去做飞行道具的实现，例如一个快速飞出去的火球，当这个飞行速度很快的时候，这5ms相对于这个预测碰撞时间就不再是个小数目。真悲剧。

技能

虽然具体的技能不是程序写的，但正如把几乎所有具体逻辑交给策划写带来的悲剧一样：这事不是你干的，但你得负责它的性能。所以有必要谈谈技能的实现。

技能的实现里，只有一个技能使用入口，程序只需要在客户端发出使用技能的消息时，调用这个入口脚本函数。然后脚本中会通过注册一些触发器来驱动整个技能运作。程序员一直希望策划能把技能用一个统一的、具体的框架统一起来，所谓的变动都是基于这个框架来变的。但策划也一直坚持，他们心目中的技能是无法统一的。

我们的技能确实很复杂。一个技能的整个过程中，服务器可能会和客户端发生多次消息交互。在最初的实现中，服务器甚至会控制客户端的技能特效、释放动作等各种细节；甚至于服务器会在这个过程中依赖客户端的若干次输入。

下一篇我将谈谈一些遇到的问题。

MMO游戏对象属性设计

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

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

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

class Entity {
private:
    GUID id;
    std::map<std::string, IComponent*> components;
    std::map<std::string, Property*> properties;
};
class Property {
private:
    std::string name;
    Value val;
    std::vector<IComponent*> 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;
};

SGI实现的STL里，所有的容器都使用SGI自己定义的allocator。这个allocator实现了一个small object的内存池。
Loki里为了处理小对象的内存分配，也实现了类似的内存管理机制。

该内存池大致上，就是一大块一大块地从系统获取内存，然后将其分成很多小块以链表的形式链接起来。其内部
有很多不同类型的链表，不同的链表维护不同大小的内存块。每一次客户端要求分配内存时，allcator就根据请求
的大小找到相应的链表(最接近的尺寸)，然后从链表里取出内存。当客户端归还内存时，allocator就将这块内存
放回到对应的链表里。

我简单地画了幅图表示整个结构：

allocator内部维护一个链表数组，数组元素全部是链表头指针。链表A每一个节点维护一个8bytes的内存块，链表
B每一个节点维护一个16bytes的内存块。

当客户端请求分配10bytes的内存时，allocator将10调整为最接近的16bytes(只能大于10bytes)，然后发现16bytes
这个链表(链表B)里有可用内存块，于是从B里取出一块内存返回。当客户端归还时，allocator找到对应的链表，将
内存重新放回链表B即可。

大致过程就这么简单，也许有人要说用链表维护一块内存，链表本身就会浪费一些内存(在我很早前接触内存池时，
总会看到类似的论点= =|)，其实通过一些简单的技巧是完全可以避免的。例如，这里allocator维护了很多内存块，
反正这些内存本身就是闲置的，因此我们就可以直接在这些内存里记录链表的信息(下一个元素)。

还是写点代码详细说下这个小技巧：

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 );

这样，通过header指针和next域，就可以逐块(这里是10byts)地访问mem所指向的内存，而这些链表的节点，都
是直接保存在这块内存里的，所以完全没有额外消耗。

我用C模仿着SGI的这个allocator写了个可配置的内存池，在其上按照STL的标准包装了一个allocator，可以直接
用于VC自带的STL里。测试代码稍微测试了下，发现在不同的机器上有明显的差距。

前言：

在很多比较各种网络模型的文章中，但凡提到select模型时，都会说select受限于轮询的套接字数量，这个
数量也就是系统头文件中定义的FD_SETSIZE值(例如64)。但事实上这个算不上真的限制。

C语言的偏方：

在C语言的世界里存在一个关于结构体的偏门技巧，例如：

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

str_type用于保存字符串(我只是举例，事实上这个结构体没什么用处)，乍看上去str_type只能保存长度为
1的字符串('\0')。但是，通过写下如下的代码，你将突破这个限制：

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

这个技巧原理很简单，因为_s恰好在结构体尾部，所以可以为其分配一段连续的空间，只要注意指针的使用，
这个就算不上代码上的罪恶。但是这个技巧有个限制，str_type定义的变量必须是被分配在堆上，否则会破
坏堆栈。另外，需要动态增长的成员需要位于结构体的末尾。最后，一个忠告就是，这个是C语言里的技巧，
如果你的结构体包含了C++的东西，这个技巧将不再安全(<Inside the C++ object model>)。

其实select也可以这样做：

事实上，因为select涉及到的fd_set是一个完全满足上述要求的结构体：

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;

但是，如果使用了以上技巧来增加fd_array的数量(也就是保存的套接字数量)，那么关于fd_set的那些宏可
能就无法使用了，例如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)

有点让人眼花缭乱，我鼓励你仔细看，其实很简单。这里有个小技巧，就是他把这些代码放到一个do...while(0)
里，为什么要这样做，我觉得应该是防止名字污染，也就是防止那个__i变量与你的代码相冲突。可以看出，
FD_SET会将fd_count与FD_SETSIZE相比较，这里主要是防止往fd_array的非法位置写数据。

因为这个宏原理不过如此，所以我们完全可以自己写一个新的版本。例如：

#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换成这个长度参数。
于是，现在你可以写下这样的代码：

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模型：

这里我不会具体讲select模型，我只稍微提一下。一个典型的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(一个超小型的基本用于练习网络编程的网络库,google yourself)中，作者
的轮询方式则有所不同：

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

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

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

相关下载(5.21.2008)

主要部分，四次握手：

断开连接其实从我的角度看不区分客户端和服务器端，任何一方都可以调用close(or closesocket)之类
的函数开始主动终止一个连接。这里先暂时说正常情况。当调用close函数断开一个连接时，主动断开的
一方发送FIN(finish报文给对方。有了之前的经验，我想你应该明白我说的FIN报文时什么东西。也就是
一个设置了FIN标志位的报文段。FIN报文也可能附加用户数据，如果这一方还有数据要发送时，将数据附
加到这个FIN报文时完全正常的。之后你会看到，这种附加报文还会有很多，例如ACK报文。我们所要把握
的原则是，TCP肯定会力所能及地达到最大效率，所以你能够想到的优化方法，我想TCP都会想到。

当被动关闭的一方收到FIN报文时，它会发送ACK确认报文(对于ACK这个东西你应该很熟悉了)。这里有个
东西要注意，因为TCP是双工的，也就是说，你可以想象一对TCP连接上有两条数据通路。当发送FIN报文
时，意思是说，发送FIN的一端就不能发送数据，也就是关闭了其中一条数据通路。被动关闭的一端发送
了ACK后，应用层通常就会检测到这个连接即将断开，然后被动断开的应用层调用close关闭连接。

我可以告诉你，一旦当你调用close(or closesocket)，这一端就会发送FIN报文。也就是说，现在被动
关闭的一端也发送FIN给主动关闭端。有时候，被动关闭端会将ACK和FIN两个报文合在一起发送。主动
关闭端收到FIN后也发送ACK，然后整个连接关闭(事实上还没完全关闭，只是关闭需要交换的报文发送
完毕)，四次握手完成。如你所见，因为被动关闭端可能会将ACK和FIN合到一起发送，所以这也算不上
严格的四次握手---四个报文段。

在前面的文章中，我一直没提TCP的状态转换。在这里我还是在犹豫是不是该将那张四处通用的图拿出来，
不过，这里我只给出断开连接时的状态转换图，摘自<The TCP/IP Guide>：

给出一个正常关闭时的windump信息：

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 

补充细节：

关于以上的四次握手，我补充下细节：
1. 默认情况下(不改变socket选项)，当你调用close( or closesocket，以下说close不再重复)时，如果
发送缓冲中还有数据，TCP会继续把数据发送完。
2. 发送了FIN只是表示这端不能继续发送数据(应用层不能再调用send发送)，但是还可以接收数据。
3. 应用层如何知道对端关闭？通常，在最简单的阻塞模型中，当你调用recv时，如果返回0，则表示对端
关闭。在这个时候通常的做法就是也调用close，那么TCP层就发送FIN，继续完成四次握手。如果你不调用
close，那么对端就会处于FIN_WAIT_2状态，而本端则会处于CLOSE_WAIT状态。这个可以写代码试试。
4. 在很多时候，TCP连接的断开都会由TCP层自动进行，例如你CTRL+C终止你的程序，TCP连接依然会正常关
闭，你可以写代码试试。

特别的TIME_WAIT状态：

从以上TCP连接关闭的状态转换图可以看出，主动关闭的一方在发送完对对方FIN报文的确认(ACK)报文后，
会进入TIME_WAIT状态。TIME_WAIT状态也称为2MSL状态。

什么是2MSL？MSL即Maximum Segment Lifetime，也就是报文最大生存时间，引用<TCP/IP详解>中的话：“
它(MSL)是任何报文段被丢弃前在网络内的最长时间。”那么，2MSL也就是这个时间的2倍。其实我觉得没
必要把这个MSL的确切含义搞明白，你所需要明白的是，当TCP连接完成四个报文段的交换时，主动关闭的
一方将继续等待一定时间(2-4分钟)，即使两端的应用程序结束。你可以写代码试试，然后用netstat查看下。

为什么需要2MSL？根据<TCP/IP详解>和<The TCP/IP Guide>中的说法，有两个原因：
其一，保证发送的ACK会成功发送到对方，如何保证？我觉得可能是通过超时计时器发送。这个就很难用
代码演示了。
其二，报文可能会被混淆，意思是说，其他时候的连接可能会被当作本次的连接。直接引用<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状态时，该连接将不能再被使用。事实上，对于我们比较有现实意义的
是，这个端口将不能再被使用。某个端口处于TIME_WAIT状态(其实应该是这个连接)时，这意味着这个TCP
连接并没有断开(完全断开)，那么，如果你bind这个端口，就会失败。

对于服务器而言，如果服务器突然crash掉了，那么它将无法再2MSL内重新启动，因为bind会失败。解决这
个问题的一个方法就是设置socket的SO_REUSEADDR选项。这个选项意味着你可以重用一个地址。

对于TIME_WAIT的插曲：

当建立一个TCP连接时，服务器端会继续用原有端口监听，同时用这个端口与客户端通信。而客户端默认情况
下会使用一个随机端口与服务器端的监听端口通信。有时候，为了服务器端的安全性，我们需要对客户端进行
验证，即限定某个IP某个特定端口的客户端。客户端可以使用bind来使用特定的端口。

对于服务器端，当设置了SO_REUSEADDR选项时，它可以在2MSL内启动并listen成功。但是对于客户端，当使
用bind并设置SO_REUSEADDR时，如果在2MSL内启动，虽然bind会成功，但是在windows平台上connect会失败。
而在linux上则不存在这个问题。(我的实验平台：winxp, ubuntu7.10)

要解决windows平台的这个问题，可以设置SO_LINGER选项。SO_LINGER选项决定调用close时，TCP的行为。
SO_LINGER涉及到linger结构体，如果设置结构体中l_onoff为非0，l_linger为0，那么调用close时TCP连接
会立刻断开，TCP不会将发送缓冲中未发送的数据发送，而是立即发送一个RST报文给对方，这个时候TCP连
接就不会进入TIME_WAIT状态。

如你所见，这样做虽然解决了问题，但是并不安全。通过以上方式设置SO_LINGER状态，等同于设置SO_DONTLINGER
状态。

断开连接时的意外：
这个算不上断开连接时的意外，当TCP连接发生一些物理上的意外情况时，例如网线断开，linux上的TCP实现
会依然认为该连接有效，而windows则会在一定时间后返回错误信息。

这似乎可以通过设置SO_KEEPALIVE选项来解决，不过不知道这个选项是否对于所有平台都有效。

总结：

个人感觉，越写越烂。接下来会讲到TCP的数据发送，这会涉及到滑动窗口各种定时器之类的东西。我真诚
希望各位能够多提意见。对于TCP连接的断开，我们只要清楚：
1. 在默认情况下，调用close时TCP会继续将数据发送完毕；
2. TIME_WAIT状态会导致的问题；
3. 连接意外断开时可能会出现的问题。
4. maybe more...

区。我对于当年那种疯狂编程的干劲很是自豪，现在差了很多，以前帮别人做小学生系列游戏外包的时候，可以12小时出

个弱智的小游戏，那些日子一度被我称为’12小时编程挑战赛‘，只是自己跟自己比赛。

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

每次都给我删掉了。我自己汇总一下：

1. 最让我自豪的一个游戏引擎，耗尽了我当时所有的设计能力。我努力把它做得很具扩展性，可是忽略了功能性。现在基本不维护了，可能是用户群太少了。我想我还是没做好吧：

edge2d google code page

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

2. PacShooter3d:

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

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

源代码下载。

3. Space Demon demo

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

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

4. Crazy Eggs Clone

<Crazy Eggs>是小林子他们工作室做的东西，属于casual games，拿到国外去卖的。我当时也觉得casual games市场不错，还找了个美工，大谈特谈，吹嘘了很多，最终在写策划案的时候失败了。我当时心也懒了，最终失败。

同样是在GameRes上：http://www.gameres.com/showmessage.asp?TopicID=72351

源代码下载。

后来我为了宣传edge2d，特地把这个游戏移植到我的引擎上。我从来很自豪自己代码的模块性，所以移植起来很容易。除了edge2d版本，我还做了HGE版本，不过HGE版本是做给别人的外包：

edge2d版本下载

5. Brick Shooter Jr

这个游戏也是我翻版别人的，用的别人的美术+音乐资源，自己重写代码。后来网上有个人又用我的资源翻作了个，做的比我好。

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

源代码下载

6. Feeding Frenzy

Popcap的经典游戏，我做的垃圾东西，不提其他的了：

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

源代码下载

7.是男人就下一百层

超级古老的东西，这个东西当初还和上海一家广告公司合作过。我签署了长这么大的第一份合同，结果后来一分钱没捞到。他们公司现在也不做这个了。和我合作的产品经理现在貌似在搞棋牌。

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

源代码下载

8. 所谓的雷电，一个我最早做的东西，现在你开baidu搜索 kevin lynx，出来最多的链接就是<雷电kevinlynx版>，别信那

些，全是流氓软件。

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

源代码下载

其他还给别人做了一些外包，在此特别感谢哆啦G梦老大，给我找了很多工作。他这个人四处跳巢，还给我说了几次工作。

只是我还想暂时留在成都，所以都拒绝了。那些外包做的都比较垃圾，做到后来基本有个小游戏框架了。版权问题可能不

能发布出来吧。

准备：

在这里本文将遵循上一篇文章的风格，只提TCP协议中的要点，这样我觉得可以更容易地掌握TCP。或者
根本谈不上掌握，对于这种纯理论的东西，即使你现在掌握了再多的细节，一段时间后也会淡忘。

在以后各种细节中，因为我们会涉及到分析一些TCP中的数据报，因此一个协议包截获工具必不可少。在
<TCP/IP详解>中一直使用tcpdump。这里因为我的系统是windows，所以只好使用windows平台的tcpdump，
也就是WinDump。在使用WinDump之前，你需要安装该程序使用的库WinpCap。

关于WinDump的具体用法你可以从网上其他地方获取，这里我只稍微提一下。要让WinDump开始监听数据，
首先需要确定让其监听哪一个网络设备(或者说是网络接口)。你可以:

windump -D

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

windump -i 2 

开始对网络接口2的数据监听。windump如同tcpdump(其实就是tcpdump)一样支持过滤表达式，windump
将会根据你提供的过滤表达式过滤不需要的网络数据包，例如：

windump -i 2 port 4000 

那么windump只会显示端口号为4000的网络数据。

序号和确认号：

要讲解TCP的建立过程，也就是那个所谓的三次握手，就会涉及到序号和确认号这两个东西。翻书到TCP
的报文头，有两个很重要的域(都是32位)就是序号域和确认号域。可能有些同学会对TCP那个报文头有所
疑惑(能看懂我在讲什么的会产生这样的疑惑么？)，这里我可以告诉你，你可以假想TCP的报文头就是个
C语言结构体(假想而已，去翻翻bsd对TCP的实现，肯定没这么简单)，那么大致上，所谓的TCP报文头就是：

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

那么，这个序号和确认号是什么？TCP报文为每一个字节都设置一个序号，觉得很奇怪？这里并不是为每一
字节附加一个序号(那会是多么可笑的编程手法?)，而是为一个TCP报文附加一个序号，这个序号表示报文
中数据的第一个字节的序号，而其他数据则是根据离第一个数据的偏移来决定序号的，例如，现在有数据：
abcd。如果这段数据的序号为1200，那么a的序号就是1200，b的序号就是1201。而TCP发送的下一个数据包
的序号就会是上一个数据包最后一个字节的序号加一。例如efghi是abcd的下一个数据包，那么它的序号就
是1204。通过这种看似简单的方法，TCP就实现了为每一个字节设置序号的功能(终于明白为什么书上要告诉
我们‘为每一个字节设置一个序号’了吧?)。注意，设置序号是一种可以让TCP成为’可靠协议‘的手段。
TCP中各种乱七八糟的东西都是有目的的，大部分目的还是为了’可靠‘两个字。别把TCP看高深了，如果
让你来设计一个网络协议，目的需要告诉你是’可靠的‘，你就会明白为什么会产生那些乱七八糟的东西了。

接着看，确认号是什么？因为TCP会对接收到的数据包进行确认，发送确认数据包时，就会设置这个确认号，
确认号通常表示接收方希望接收到的下一段报文的序号。例如某一次接收方收到序号为1200的4字节数举报，
那么它发送确认报文给发送方时，就会设置确认号为1204。

大部分书上在讲确认号和序号时，都会说确认号是序号加一。这其实有点误解人，所以我才在这里废话了
半天(高手宽容下:D)。

开始三次握手：

如果你还不会简单的tcp socket编程，我建议你先去学学，这就好比你不会C++基本语法，就别去研究vtable
之类。

三次握手开始于客户端试图连接服务器端。当你调用诸如connect的函数时，正常情况下就会开始三次握手。
随便在网上找张三次握手的图：

如前文所述，三次握手也就是产生了三个数据包。客户端主动连接，发送SYN被设置了的报文(注意序号和
确认号，因为这里不包含用户数据，所以序号和确认号就是加一减一的关系)。服务器端收到该报文时，正
常情况下就发送SYN和ACK被设置了的报文作为确认，以及告诉客户端：我想打开我这边的连接(双工)。客户
端于是再对服务器端的SYN进行确认，于是再发送ACK报文。然后连接建立完毕。对于阻塞式socket而言，你
的connect可能就返回成功给你。

在进行了铺天盖地的罗利巴索的基础概念的讲解后，看看这个连接建立的过程，是不是简单得几近无聊？

我们来实际点，写个最简单的客户端代码：

   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。运行程序前我们运行windump：

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的结果，建议参看<tcp/ip详解>中对于tcpdump的描述。

建立连接的附加信息：

虽然SYN、ACK之类的报文没有用户数据，但是TCP还是附加了其他信息。最为重要的就是附加的MSS值。这个
可以被协商的MSS值基本上就只在建立连接时协商。如以上数据表示，MSS为1460字节。

连接的意外：

连接的意外我大致分为两种情况(也许还有更多情况)：目的主机不可达、目的主机并没有在指定端口监听。
当目的主机不可达时，也就是说，SYN报文段根本无法到达对方(如果你的机器根本没插网线，你就不可达)，
那么TCP收不到任何回复报文。这个时候，你会看到TCP中的定时器机制出现了。TCP对发出的SYN报文进行
计时，当在指定时间内没有得到回复报文时，TCP就会重传刚才的SYN报文。通常，各种不同的TCP实现对于
这个超时值都不同，但是据我观察，重传次数基本上都是3次。例如，我连接一个不可达的主机：

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>

发出了三个序号一样的SYN报文，但是没有得到一个回复报文(废话)。每一个SYN报文之间的间隔时间都是
有规律的，在windows上是3秒6秒9秒12秒。上面的数据你看不到12秒这个数据，因为这是第三个报文发出的
时间和connect返回错误信息时的时间之差。另一方面，如果连接同一个网络，这个间隔时间又不同。例如
直接连局域网，间隔时间就差不多为500ms。

(我强烈建议你能运行windump去试验这里提到的每一个现象，如果你在ubuntu下使用tcpdump，记住sudo :D)

出现意外的第二种情况是如果主机数据包可达，但是试图连接的端口根本没有监听，那么发送SYN报文的这
方会收到RST被设置的报文(connect也会返回相应的信息给你)，例如：

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 

可以看出，7AURORA-CCTEST.7100返回了RST报文给我，但是我这边根本不在乎这个报文，继续发送SYN报文。
三次过后connect就返回了。(数据反映的事实是这样)

关于listen:

TCP服务器端会维护一个新连接的队列。当新连接上的客户端三次握手完成时，就会将其放入这个队列。这个队

列的大小是通过listen设置的。当这个队列满时，如果有新的客户端试图连接（发送SYN），服务器端丢弃报文，

同时不做任何回复。

总结：
TCP连接的建立的相关要点就是这些(or more?)。正常情况下就是三次握手，非正常情况下就是SYN三次超时，
以及收到RST报文却被忽略。

预计新项目会选择lua或python之一作为游戏的脚本语言。以前草草地接触过这两门语言，对于语法，以及嵌入进C/C++程序都有点感性上的认识。可能是受《UNIX编程艺术》中KISS原则的影响，现在总喜欢简洁的东西。所以我个人比较偏向于使用lua。

这两天翻了下网络上的资料，在lua的wiki上看到一篇比较lua和python的文章，草草地翻译出要点：

Python:
1. 扩展库很多，资料很多
2. 数值计算比较强大，支持多维数组，而lua没有数组类型
3. 本身带的c类型(?)支持处理动态链接库，不需要进行C封装(C扩展)
4. 远程调试器，似乎lua扩展工具支持
5. 自然语言似的语法
6. 对于string和list的支持，lua可以通过扩展库实现
7. 对unicode的支持
8. 空格敏感(代码不忽略空格)，这其实可以使python的代码风格看起来更好一点
9. 内建位操作，lua可以通过扩展库支持
10.语言本身对错误的处理要好些，可以有效减少程序错误
11.初级文档比lua多
12.对面向对象支持更好

Lua:
1. 比python小巧很多(包括编译出来的运行时库)
2. 占用更小的内存
3. 解释器速度更快
4. 比python更容易集成到C语言中
5. 对于对象不使用引用计数(引用计数会导致更多的问题？)
6. lua早期定位于一种配置语言(作为配置文件)，因此比起python来更容易配置数据
7. 语言更漂亮(nice)、简单(simple)、强大(powerful)。
8. lua支持多线程，每个线程可以配置独立的解释器，因此lua更适合于集成进多线程程序
9. 对空格不敏感，不用担心编辑器会将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的支持更适用于嵌入进游戏，虽然python也有，但是并没有包含进核心模块

3.Python was a language better suited to Game AI

本来想去找点对于python的正面资料(嵌入进游戏这方面），但是居然没找到。客观地说如果单独用python做应用，python还是很有优势。现在心意已决，应该向leader推荐lua。

ps，希望能补充以上两种语言的特点。

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.

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

Author: Kevin Lynx

Ascent是WoW的服务器模拟器，你可以从它的SVN上获取它的全部代码，并从它的WIKI页面获取架构起整个服务器的相关步骤。

基本架构：

Ascent网络模块核心的几个类关系如下图所示：

ThreadBase属于Ascent线程池模块中的类，它实现了一个job类，当其被加入到线程池中开始执行时，线程池管理器会为其分配一个线程（如果有线程资源）并多态调用到ThreadBase派生类的run函数。

SocketWorkerThread用以代表IOCP网络模型中的一个工作者线程，它会从IOCP结果队列里取出异步IO的操作结果。这里的IOCP使用的完成键是Socket对象指针。SocketWorkerThread获取到IO操作结果后，根据获得的完成键将结果通知给具体的Socket对象。（Socket的说明见后面）

ListenSocket代表一个监听套接字。该网络模块其实只是简单地将socket中的概念加以封装。也就说，它依然把一个套接字分为两种类型：监听套接字和数据套接字（代表一个网络连接）。所谓的监听套接字，是指只可以在该套接字上进行监听操作；而数据套接字则只可以在此套接字上进行发送、接收数据的操作。

Socket代表我上面说的数据套接字。ListenSocket是一个类模板，为这个模板指定的模板参数通常是派生于Socket的类。其实这里使用了这个小技巧隐藏了工厂模式的细节。因为ListenSocket被放在一个单独的线程里运作，当其接受到一个新的网络连接时，就创建一个Socket派生类对象。（ListenSocket类如何知道这个派生类的类名？这就是通过类模板的那个模板参数）

上层模块通常会派生Socket类，实现一些IO操作的回调。也就说，当某个IO操作完成后，会通过Socket基类让上层模块获取通知。

SocketMgr是一个全局单件类。它主要负责一些网络库的全局操作（例如winsock库的初始化），它还维护了一个容器，保存所有的Socket对象。这其实是它的主要作用。

运作之一，接收新的连接：

接收新的网络连接是通过ListenSocket实现的。在创建一个ListenSocket对象时，你需要指定它的模板参数。这个参数通常是一个派生于Socket的类。如下：

ascent-logonserver/Main.cpp

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

AuthSocket派生于Socket。创建ListenSocket时构造函数指定监听IP和监听端口。

因为ListenSocket派生于ThreadBase，属于线程池job，因此要让ListenSocket工作起来，只需要将其加入到线程池管理器：

ascent-logonserver/Main.cpp

ThreadPool.ExecuteTask(cl);

ListenSocket开始运作起来后，会阻塞式地WSAAccept。如果WSAAccept返回一个有效的套接字，ListenSocket就创建一个Socket派生类对象（类型由模板参数指定），在上面举的例子中，也就是AuthSocket：

ascent-logonserver/ ListenSocketWin32.h

  socket = new T(aSocket); //创建AuthSocket并保存网络套接字aSocket

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

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

Accept函数最终会将新创建的Socket对象保存到SocketMgr对象内部维护的容器里。在这里，还会回调到上层模块的OnConnect函数，从而实现信息捕获。

运作之二，接收数据

在windows平台下，该网络模块使用的是IOCP模型，属于异步IO。当接收新的连接时，即发出WSARecv的IO操作。在工作者线程中，也就是SocketWorkerThread中，会根据IOCP完成键得到Socket对象指针，然后根据不同的IO操作结果多态回调到Socket派生类对应的函数。例如如果是WSARecv完成，则调用到AuthSocket::OnRead函数（上述例子）。OnRead函数直接可以获取到保存数据的缓冲区指针。事实上，每一个Socket对象在被创建时，就会自动创建接收缓冲区以及发送缓冲区。

运作之三，发送数据

分析到这里，我们可以看出，该网络模块实现得很一般。在接受数据部分，网络工作者线程回调到对应的Socket对象，Socket直接对数据进行上层逻辑处理。更好的做法是当工作者线程回调到上层Socket（Socket的派生类）时，这里应该简单地将数据组织成上层数据包并放入上层数据包队列，让上层逻辑稍后处理，而不是让网络模块自己去处理。这样做主要是考虑到多线程模型。

同样，该网络模块的发送模块也是一样，没有缓冲机制。当要发送数据时，直接调用到Socket的Send函数。该函数拷贝用户数据到自己维护的发送缓冲区，然后将自己的缓冲区指针直接提交给IOCP，WSASend发送。

结束

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