Kevin Lynx

引言

在一个高效的系统中，我们经常会将一些费时的操作转换为异步操作。例如往数据库中写日志。如果数据库
配置在网络上，那么往数据库中插入一些日志信息将非常慢(相对于程序其他部分)。

如何转换为异步？

将类似于以上过程转换为异步操作，一个典型的做法是：建立一个单独的数据库日志线程，一个线程安全的
队列。要写日志时，只需要往队列里放入数据，数据库日志线程则从这个队列里取数据然后完成写操作。

大致的过程类似于：

typedef safe_list<std::string> SafeList;
SafeList gLogList; 

// database thread.read log string.
unsigned int __stdcall DBThread( void *p )
{
    while( true )
    {
        // read gLogList and write log string into the database
    } 

    _endthreadex( 0 );
    return 0;
} 

// other threads. write log string.
void wrtie_log( const std::string &log )
{
    gLogList.push_back( log );
} 

将他们包装起来

我们很有可能会在同一个系统中多次遇到类似需要转换为异步操作的地方，如果每一次都手动去创建一个队列和一
个线程，那将会多么乏味啊！懒惰的程序员喜欢重用各种代码。所以，我自己觉得很有必要将这一切封装起来。我
们只需要封装这个队列和创建线程的繁琐细节，让应用层全部专注于具体的逻辑处理：

template <typename _NodeType>
class async_operator
{
public:
    /**//// the list node type.
    typedef _NodeType node_type;
    /**//// the list.
    typedef multi_list<node_type, Mutex, Semaphore> list_type;
    /**//// operator signature
    typedef functor<void, TYPE_LIST1( list_type& )> operator_type;
    /**//// init function signature, called when the thread starts.
    typedef functor<void> init_type;
    /**//// called before the thread exits.
    typedef functor<void> release_type; 

public:
    /**////
    /// start the thread and execute the operation.
    /// @param op the callback function operate the list node.
    /// 
    void execute( operator_type &op, init_type &init = init_type(), release_type &release = release_type() ); 

    /**////
    /// exit the thread.It will block until the thread exited.
    ///
    void exit(); 

    /**////
    /// get the list so that you can pust list nodes.
    ///
    list_type &list(); 

private:
    list_type _list;
    operator_type _operator;
    init_type _init;
    release_type _release;
    thread _thread;
}; 

我利用了已有的组件：线程安全的容器multi_list、包装任意执行体的functor、线程维护类thread。那么，现在，
应用层只需要定义队列节点类型，写应用相关的回调函数(任意可被functor包装的广义函数)。(见附件例子)

之所以为这个组件加上init和release，是因为有些东西(例如COM)需要在线程启动时初始化，而在线程快结束时释放，例如对于
使用COM的应用来说，就需要在线程初始化时CoInitialize，结束时CoUninitialize。

闲说下其他东西

在本文的附件代码里，你可以获取到functor、thread、multi_list这些东西，所以我有必要提一下。

关于functor，你可以参看<实现functor - 增强型的函数指针>，基本上可以看成增强版的C回调函数；至于multi_list，基本上
是一个container adapter (套用下STL的概念)，使用条件变量参与线程同步，据说效率要比简单的互斥高点；至于thread，我需要
特别说下：

thread最为重要的就是为其附加了一个windows的消息队列(只要调用PeekMessage之类的函数该队列就存在)，本意是可以让其他线
程传送数据到该线程，但是目前只用于线程退出，即其他线程可以在任何时候要求该线程安全地退出(该线程没有阻塞的情况下，
阻塞时获取不到消息)。我不知道这个安全退出策略是否真的有必要存在，但是我讨厌看到各种撇脚的退出方法(例如设置全局标志
变量，增加额外的--没封装前---event对象之类)。

结束

不知道其他人是如何做这种异步转换操作的，在这里我只是起个抛砖引玉的作用，欢迎大家提出意见。

什么是完成包？

完成包，即IO Completion Packet，是指异步IO操作完毕后OS提交给应用层的通知包。IOCP维护了一个IO操作结果队列，里面
保存着各种完成包。应用层调用GQCS(也就是GetQueueCompletionStatus)函数获取这些完成包。

最大并发线程数

在一个典型的IOCP程序里，会有一些线程调用GQCS去获取IO操作结果。最大并发线程数指定在同一时刻处理完成包的线程数目。
该参数在调用CreateIoCompletionPort时由NumberOfConcurrentThreads指定。

工作者线程

工作者线程一般指的就是调用GQCS函数的线程。要注意的是，工作者线程数和最大并发线程数并不是同一回事(见下文)。工作者
线程由应用层显示创建(_beginthreadex 之类)。工作者线程通常是一个循环，会不断地GQCS到完成包，然后处理完成包。

调度过程

工作者线程以是否阻塞分为两种状态：运行状态和等待状态。当线程做一些阻塞操作时(线程同步，甚至GQCS空的完成队列)，线程
处于等待状态；否则，线程处于运行状态。

另一方面，OS会始终保持某一时刻处于运行状态的线程数小于最大并发线程数。每一个调用GQCS函数的线程OS实际上都会进行记录，
当完成队列里有完成包时，OS会首先检查当前处于运行状态的工作线程数是否小于最大并发线程数，如果小于，OS会按照LIFO的顺
序让某个工作者线程从GQCS返回(此工作者线程转换为运行状态)。如何决定这个LIFO？这是简单地通过调用GQCS函数的顺序决定的。

从这里可以看出，这里涉及到线程唤醒和睡眠的操作。如果两个线程被放置于同一个CPU上，就会有线程切换的开销。因此，为了消
除这个开销，最大并发线程数被建议为设置成CPU数量。

从以上调度过程还可以看出，如果某个处于运行状态的工作者线程在处理完成包时阻塞了(例如线程同步、其他IO操作)，那么就有
CPU资源处于空闲状态。因此，我们也看到很多文档里建议，工作者线程数为(CPU数*2+2)。

在一个等待线程转换到运行状态时，有可能会出现短暂的时间运行线程数超过最大并发线程数，这个时候OS会迅速地让这个新转换
的线程阻塞，从而减少这个数量。(关于这个观点，MSDN上只说：by not allowing any new active threads，却没说明not allowing
what)

调度原理

这个知道了其实没什么意义，都是内核做的事，大致上都是操作线程control block，直接摘录<Inside IO Completion Ports>:

The list of threads hangs off the queue object. A thread's control block data structure has a pointer in it that
references the queue object of a queue that it is associated with; if the pointer is NULL then the thread is not
associated with a queue.

So how does NT keep track of threads that become inactive because they block on something other than the completion
port" The answer lies in the queue pointer in a thread's control block. The scheduler routines that are executed
in response to a thread blocking (KeWaitForSingleObject, KeDelayExecutionThread, etc.) check the thread's queue
pointer and if its not NULL they will call KiActivateWaiterQueue, a queue-related function. KiActivateWaiterQueue
decrements the count of active threads associated with the queue, and if the result is less than the maximum and
there is at least one completion packet in the queue then the thread at the front of the queue's thread list is
woken and given the oldest packet. Conversely, whenever a thread that is associated with a queue wakes up after
blocking the scheduler executes the function KiUnwaitThread, which increments the queue's active count.

参考资料

<Inside I/O Completion Ports>:
http://technet.microsoft.com/en-us/sysinternals/bb963891.aspx
<I/O Completion Ports>:
http://msdn.microsoft.com/en-us/library/aa365198(VS.85).aspx
<INFO: Design Issues When Using IOCP in a Winsock Server>:
http://support.microsoft.com/kb/192800/en-us/

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里。测试代码稍微测试了下，发现在不同的机器上有明显的差距。

Kevin Lynx

Proactor和Reactor都是并发编程中的设计模式。在我看来，他们都是用于派发/分离IO操作事件的。这里所谓的
IO事件也就是诸如read/write的IO操作。"派发/分离"就是将单独的IO事件通知到上层模块。两个模式不同的地方
在于，Proactor用于异步IO，而Reactor用于同步IO。

摘抄一些关键的东西：

"
Two patterns that involve event demultiplexors are called Reactor and Proactor [1]. The Reactor patterns
involve synchronous I/O, whereas the Proactor pattern involves asynchronous I/O.
"

关于两个模式的大致模型，从以下文字基本可以明白：

"
An example will help you understand the difference between Reactor and Proactor. We will focus on the read
operation here, as the write implementation is similar. Here's a read in Reactor:

* An event handler declares interest in I/O events that indicate readiness for read on a particular socket ;
* The event demultiplexor waits for events ;
* An event comes in and wakes-up the demultiplexor, and the demultiplexor calls the appropriate handler;
* The event handler performs the actual read operation, handles the data read, declares renewed interest in
  I/O events, and returns control to the dispatcher .

By comparison, here is a read operation in Proactor (true async):

* A handler initiates an asynchronous read operation (note: the OS must support asynchronous I/O). In this
  case, the handler does not care about I/O readiness events, but is instead registers interest in receiving
  completion events;
* The event demultiplexor waits until the operation is completed ;
* While the event demultiplexor waits, the OS executes the read operation in a parallel kernel thread, puts
  data into a user-defined buffer, and notifies the event demultiplexor that the read is complete ;
* The event demultiplexor calls the appropriate handler;
* The event handler handles the data from user defined buffer, starts a new asynchronous operation, and returns
  control to the event demultiplexor.

"

可以看出，两个模式的相同点，都是对某个IO事件的事件通知(即告诉某个模块，这个IO操作可以进行或已经完成)。在结构
上，两者也有相同点：demultiplexor负责提交IO操作(异步)、查询设备是否可操作(同步)，然后当条件满足时，就回调handler。
不同点在于，异步情况下(Proactor)，当回调handler时，表示IO操作已经完成；同步情况下(Reactor)，回调handler时，表示
IO设备可以进行某个操作(can read or can write)，handler这个时候开始提交操作。

用select模型写个简单的reactor，大致为：

/**////
class handler
{
public:
    virtual void onRead() = 0;
    virtual void onWrite() = 0;
    virtual void onAccept() = 0;
}; 

class dispatch
{
public:
    void poll()
    {
        // add fd in the set.
        //
        // poll every fd
        int c = select( 0, &read_fd, &write_fd, 0, 0 );
        if( c > 0 )
        {
            for each fd in the read_fd_set
            {    if fd can read
                    _handler->onRead();
                if fd can accept
                    _handler->onAccept();
            } 

            for each fd in the write_fd_set
            {
                if fd can write
                    _handler->onWrite();
            }
        }
    } 

    void setHandler( handler *_h )
    {
        _handler = _h;
    } 

private:
    handler *_handler;
}; 

/**//// application
class MyHandler : public handler
{
public:
    void onRead()
    {
    } 

    void onWrite()
    {
    } 

    void onAccept()
    {
    }
}; 

在网上找了份Proactor模式比较正式的文档，其给出了一个总体的UML类图，比较全面：

根据这份图我随便写了个例子代码：

class AsyIOProcessor
{
public:
    void do_read()
    {
        //send read operation to OS
        // read io finished.and dispatch notification
        _proactor->dispatch_read();
    } 

private:
    Proactor *_proactor;
}; 

class Proactor
{
public:
    void dispatch_read()
    {
        _handlerMgr->onRead();
    } 

private:
    HandlerManager *_handlerMgr;
}; 

class HandlerManager
{
public:
    typedef std::list<Handler*> HandlerList; 

public:
    void onRead()
    {
        // notify all the handlers.
        std::for_each( _handlers.begin(), _handlers.end(), onRead );
    } 

private:
    HandlerList *_handlers;
}; 

class Handler
{
public:
    virtual void onRead() = 0;
}; 

// application level handler.
class MyHandler : public Handler
{
public:
    void onRead() 
    {
        // 
    }
}; 

Reactor通过某种变形，可以将其改装为Proactor，在某些不支持异步IO的系统上，也可以隐藏底层的实现，利于编写跨平台
代码。我们只需要在dispatch(也就是demultiplexor)中封装同步IO操作的代码，在上层，用户提交自己的缓冲区到这一层，
这一层检查到设备可操作时，不像原来立即回调handler，而是开始IO操作，然后将操作结果放到用户缓冲区(读)，然后再
回调handler。这样，对于上层handler而言，就像是proactor一样。详细技法参见这篇文章。

其实就设计模式而言，我个人觉得某个模式其实是没有完全固定的结构的。不能说某个模式里就肯定会有某个类，类之间的
关系就肯定是这样。在实际写程序过程中也很少去特别地实现某个模式，只能说模式会给你更多更好的架构方案。

最近在看spserver的代码，看到别人提各种并发系统中的模式，有点眼红，于是才来扫扫盲。知道什么是leader follower模式，
reactor, proactor，multiplexing，对于心中的那个网络库也越来越清晰。

最近还干了些离谱的事，写了传说中的字节流编码，用模板的方式实现，不但保持了扩展性，还少写很多代码；处于效率考虑，
写了个static array容器(其实就是template <typename _Tp, std::size_t size> class static_array { _Tp _con[size])，
加了iterator，遵循STL标准，可以结合进STL的各个generic algorithm用，自我感觉不错。基础模块搭建完毕，解析了公司
服务器网络模块的消息，我是不是真的打算用自己的网络模块重写我的验证服务器？在另一个给公司写的工具里，因为实在厌恶
越来越多的重复代码，索性写了几个宏，还真的做到了代码的自动生成:D。

对优雅代码的追求真的成了种癖好.  = =|

1.半同步/半异步（half-sync/half-async）：

在网上一份资料中引用了一本貌似很经典的书里的比喻：
”
许多餐厅使用 半同步/半异步 模式的变体。例如，餐厅常常雇佣一个领班负责迎接顾客，并在餐厅繁忙时留意给顾客安排桌位，
为等待就餐的顾客按序排队是必要的。领班由所有顾客“共享”，不能被任何特定顾客占用太多时间。当顾客在一张桌子入坐后，
有一个侍应生专门为这张桌子服务。
“

按照另一份似乎比较权威的文档的描述，要实现半同步/半异步模式，需要实现三层：异步层、同步层、队列层。因为很多操作
采用异步方式会比较有效率(例如高效率的网络模型似乎都采用异步IO)，但是异步操作的复杂度比较高，不利于编程。而同步
操作相对之下编程要简单点。为了结合两者的优点，就提出了这个模式。而为了让异步层和同步层互相通信(模块间的通信)，系
统需要加入一个通信队列。异步层将操作结果放入队列，同步层从队列里获取操作结果。

回过头来看看我之前写的那个select网络模型代码，个人认为基本上算是一个半同步半异步模式的简单例子：Buffer相当于通信
队列，网络底层将数据写入Buffer，上层再同步地从该队列里获取出数据。这样看来似乎也没什么难度。 = =

关于例子代码，直接引用iunknown给的：

//这就是一个典型的循环队列的定义，iget 是队列头，iput 是队列尾</STRONG>  
int clifd[MAXNCLI], iget, iput;   
int main( int argc, char * argv[] )  
{  
  ......  
  int listenfd = Tcp_listen( NULL, argv[ 1 ], &addrlen );  
  ......  
  iget = iput = 0;  
  for( int i = 0; i < nthreads; i++ ) {  
    pthread_create( &tptr[i].thread_tid, NULL, &thread_main, (void*)i );  
  for( ; ; ) {  
    connfd = accept( listenfd, cliaddr,, &clilen );  
    clifd[ iput ] = connfd;     // 接受到的连接句柄放入队列</STRONG>  
    if( ++iput == MAXNCLI ) iput = 0;    
  }  
}  
void * thread_main( void * arg )  
{  
  for( ; ; ) {  
    while( iget == iput ) pthread_cond_wait( ...... );  
    connfd = clifd[ iget ];     // 从队列中获得连接句柄</STRONG>  
    if( ++iget == MAXNCLI ) iget = 0;  
    ......  
    web_child( connfd );  
    close( connfd );  
  }  
} 

2.领导者/追随者（Leader/Followers）：

同样，给出别人引用的比喻：
”
在日常生活中，领导者/追随者模式用于管理许多飞机场出租车候车台。在该用例中，出租车扮演“线程”角色，排在第一辆的出
租车成为领导者，剩下的出租车成为追随者。同样，到达出租车候车台的乘客构成了必须被多路分解给出租车的事件，一般以先进
先出排序。一般来说，如果任何出租车可以为任何顾客服务，该场景就主要相当于非绑定句柄/线程关联。然而，如果仅仅是某些
出租车可以为某些乘客服务，该场景就相当于绑定句柄/线程关联。
“

其实这个更简单，我记得<unix网络编程>中似乎提到过这个。总之有一种网络模型(connection-per-thread?)里，一个线程用于
accept连接。当接收到一个新的连接时，这个线程就转为connection thread，而这个线程后面的线程则上升为accept线程。这里，
accept线程就相当于领导者线程，而其他线程则属于追随者线程。

iunknown 的例子代码：

int listenfd;  
int main( int argc, char * argv[] )  
{  
  ......  
  listenfd = Tcp_listen( NULL, argv[ 1 ], &addrlen );  
  ......  
  for( int i = 0; i < nthreads; i++ ){  
    pthread_create( &tptr[i].thread_tid, NULL, &thread_main, (void*)i );  
  }  
  ......  
}  
void * thread_main( void * arg )  
{  
  for( ; ; ){  
    ......  
    // 多个线程同时阻塞在这个 accept 调用上，依靠操作系统的队列</STRONG>  
    connfd = accept( listenfd, cliaddr, &clilen );  
    ......  
    web_child( connfd );  
    close( connfd );  
    ......  
  }  
} 

这个例子聊天服务器可以使用telnet登录，服务器直接将telnet发来的字符串转发给所有客户端。我稍微写了一个小的网络
模块，可以用于以后写网络程序的例子代码，也算是练习下网络库的设计。

系统总体类图如下：

Address用于包装sockaddr_in结构体，目的就是让系统用起来更方便。

Buffer用于封装原始内存，主要目的是拿来做发送、接收数据缓冲。

Fdset差不多和FD_SET一样，只是这里自己写一个FD_SET，可以让连接数不受FD_SETSIZE的限制。

Socket封装了基本的SOCKET操作，包括创建、销毁套接字。

Session比较有意思，按我的意思，就是代表一个网络连接。对于服务器端，可能会有很多连接，每一个连接可以用一个
Session对象表示。而对于客户端，只有一个连接，那么就是一个Session对象。对于Session对象来说，可以进行数据的
发送和接收，因此这里Session有recv、send之类的接口。为了缓冲数据，所以Session对于读写分别有一个Buffer对象。

Server代表一个服务器，直接提供创建服务器的接口。同时使用一个unsigned long作为每一个连接的ID号。

Client代表一个客户端，可以直接用于连接服务器。

下载文件提供网络模块代码，以及三个例子程序。点击下载

1. 什么是delayed ack algorithm
   delayed ack algorithm也就是<TCP/IP详解>中所谓的"经受时延的确认"(翻译得真饶舌 = =||)。在RFC1122中提到delayed ack
   的概念：
  

  "
      A host that is receiving a stream of TCP data segments can
      increase efficiency in both the Internet and the hosts by
      sending fewer than one ACK (acknowledgment) segment per data
      segment received; this is known as a "delayed ACK" [TCP:5].
    "

   我在之前提到过，TCP在收到每一个数据包时，都会发送一个ACK报文给对方，用以告诉对方"我接收到你刚才发送的数据了"。并
   且会在报文的确认号字段中标志希望接收到的数据包。

   但是，如你所想，如果为每一个接收到的报文都发送一个ACK报文，那将会增加网络的负担。于是，为了解决这个问题，delayed
   ack被提出。也就是说，实现了delayed ack的TCP，并不见得会对每一个接收到的数据包发送ACK确认报文。

   实际情况是，TCP延迟发送这个ACK。延迟多久？<TCP/IP详解>中说的是200ms，在RFC1122中说的则是500ms。delayed ack有时候
   还会附加到数据报文段一起发送，如果在延迟时间内有报文段要发送的话，如果没有，那么当延迟时间到时，就单独发送ACK。

   在另一份文档中，作者讲到delayed ack的好处：
   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;
   c) to allow the stack to send one ACK for several frames, if those frames arrive within the delay period.

   a) 所谓的糊涂窗口综合症(别人都这样翻译的，似乎有点搞笑:D)
   b) 将ACK与将要发送的数据报文一起发送
   c) 一个ack确认多个报文段，如果这几个报文段在延迟时间内到达

2. 什么是Nagle algoritm ?
   简而言之，nagle算法主要目的是减少网络流量，当你发送的数据包太小时，TCP并不立即发送该数据包，而是缓存起来直到数据包
   到达一定大小后才发送。(improving the efficiency of TCP/IP networks by reducing the number of packets that need to
   be sent over the network.)

   关于这个算法，我觉得wikipedia上讲的比较好。具体点说，当上层提交数据给TCP时，TCP觉得你的数据太小了(套用一般的例子，
   如果你要发送1一个字节的数据，当附加上TCP和IP头后，数据包通常就会增加到41字节，那么这显然是低效的)，就缓存你的数据，
   当数据缓存到一定长度后，如果之前发送的数据得到了ACK确认且接收方有足够空间容纳数据，就发送这些数据，否则继续等待。

   wikipedia上给了一段nagle的伪代码：

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 

   
   TCP socket提供了关闭nagle算法的接口，你可以通过TCP_NODELAY选项决定是否开启该算法。不过MSDN上建议不要关闭此算法。如果
   你发送的数据不至于很小的话(<40byte)，我也不建议你关闭。

从开始接触网络编程这个东西开始，我就不间断地阅读一些网络库(模块)的源代码，主要目的是为了获取别
人在这方面的经验，编程这东西，还是要多实践啊。

基本上，Etwork是一个很小巧的网络库。Etwork基于select模型，采用我之前说的技巧，理论上可以处理很
多连接(先不说效率)。

先看看下这个库的结构：

如同很多网络库一样，总会有一个类似于ISocketManager的类，用于管理所有网络连接(当用户服务器时)。
而ISocket则用于代表一个网络连接。在其他库中，ISocketManager对应的可能就是Server，而ISocket对应
的则是Session。

在接口设计上，尽管Etwork写了很多接口类(看看那些IClass)，但是事实上它抽象得并不彻底。只是暴露给
客户端的代码很简洁，而库本身依然臃肿。不知道为什么，现在我比较喜欢纯C这种简洁的东西，对于OO以及
template，渐渐地有点心累。

在功能实现上，我以TCP服务器为例，CreateEtwork根据传来的参数建立服务器，在SocketManager::open中
是很常规的socket, bind, listen。当建立了服务器之后，需要在程序主循环里不断地轮询状态，这里主要
调用poll函数完成。

poll函数主体就是调用select。当select成功返回活动的套接字数量后，Etwork依次轮询读、写、错误fdset，
将保存的所有网络连接(就是那些ISocket对象)对应的套接字与fdset中当前的套接字做比较。大致逻辑为：

fd_count = select( 0, readset, writeset, exceptset, &timeout ); 

for( each fd in readset )
    if( fd is listening fd ) 
        accept new connection
    else
        for( each socket in all connections )
            if( fd == socket )
                can read data&n