select epoll 完成端口

最新推荐文章于 2022-07-07 22:05:41 发布

liu5320102

最新推荐文章于 2022-07-07 22:05:41 发布

阅读量1k

点赞数

分类专栏： select 文章标签： select

select 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

select、poll、epoll之间的区别总结[整理]

　　select，poll，epoll都是IO多路复用的机制。I/O多路复用就通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。关于这三种IO多路复用的用法，前面三篇总结写的很清楚，并用服务器回射echo程序进行了测试。连接如下所示：

select：http://www.cnblogs.com/Anker/archive/2013/08/14/3258674.html

poll：http://www.cnblogs.com/Anker/archive/2013/08/15/3261006.html

epoll：http://www.cnblogs.com/Anker/archive/2013/08/17/3263780.html

　　今天对这三种IO多路复用进行对比，参考网上和书上面的资料，整理如下：

1、select实现

select的调用过程如下所示：

（1）使用copy_from_user从用户空间拷贝fd_set到内核空间

（2）注册回调函数__pollwait

（3）遍历所有fd，调用其对应的poll方法（对于socket，这个poll方法是sock_poll，sock_poll根据情况会调用到tcp_poll,udp_poll或者datagram_poll）

（4）以tcp_poll为例，其核心实现就是__pollwait，也就是上面注册的回调函数。

（5）__pollwait的主要工作就是把current（当前进程）挂到设备的等待队列中，不同的设备有不同的等待队列，对于tcp_poll来说，其等待队列是sk->sk_sleep（注意把进程挂到等待队列中并不代表进程已经睡眠了）。在设备收到一条消息（网络设备）或填写完文件数据（磁盘设备）后，会唤醒设备等待队列上睡眠的进程，这时current便被唤醒了。

（6）poll方法返回时会返回一个描述读写操作是否就绪的mask掩码，根据这个mask掩码给fd_set赋值。

（7）如果遍历完所有的fd，还没有返回一个可读写的mask掩码，则会调用schedule_timeout是调用select的进程（也就是current）进入睡眠。当设备驱动发生自身资源可读写后，会唤醒其等待队列上睡眠的进程。如果超过一定的超时时间（schedule_timeout指定），还是没人唤醒，则调用select的进程会重新被唤醒获得CPU，进而重新遍历fd，判断有没有就绪的fd。

（8）把fd_set从内核空间拷贝到用户空间。

总结：

select的几大缺点：

（1）每次调用select，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大

（2）同时每次调用select都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很大

（3）select支持的文件描述符数量太小了，默认是1024

2 poll实现

　　poll的实现和select非常相似，只是描述fd集合的方式不同，poll使用pollfd结构而不是select的fd_set结构，其他的都差不多。

关于select和poll的实现分析，可以参考下面几篇博文：

http://blog.csdn.net/lizhiguo0532/article/details/6568964#comments

http://blog.csdn.net/lizhiguo0532/article/details/6568968

http://blog.csdn.net/lizhiguo0532/article/details/6568969

http://www.ibm.com/developerworks/cn/linux/l-cn-edntwk/index.html?ca=drs-

http://linux.chinaunix.net/techdoc/net/2009/05/03/1109887.shtml

3、epoll

　　epoll既然是对select和poll的改进，就应该能避免上述的三个缺点。那epoll都是怎么解决的呢？在此之前，我们先看一下epoll和select和poll的调用接口上的不同，select和poll都只提供了一个函数——select或者poll函数。而epoll提供了三个函数，epoll_create,epoll_ctl和epoll_wait，epoll_create是创建一个epoll句柄；epoll_ctl是注册要监听的事件类型；epoll_wait则是等待事件的产生。

　　对于第一个缺点，epoll的解决方案在epoll_ctl函数中。每次注册新的事件到epoll句柄中时（在epoll_ctl中指定EPOLL_CTL_ADD），会把所有的fd拷贝进内核，而不是在epoll_wait的时候重复拷贝。epoll保证了每个fd在整个过程中只会拷贝一次。

　　对于第二个缺点，epoll的解决方案不像select或poll一样每次都把current轮流加入fd对应的设备等待队列中，而只在epoll_ctl时把current挂一遍（这一遍必不可少）并为每个fd指定一个回调函数，当设备就绪，唤醒等待队列上的等待者时，就会调用这个回调函数，而这个回调函数会把就绪的fd加入一个就绪链表）。epoll_wait的工作实际上就是在这个就绪链表中查看有没有就绪的fd（利用schedule_timeout()实现睡一会，判断一会的效果，和select实现中的第7步是类似的）。

　　对于第三个缺点，epoll没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。

总结：

（1）select，poll实现需要自己不断轮询所有fd集合，直到设备就绪，期间可能要睡眠和唤醒多次交替。而epoll其实也需要调用epoll_wait不断轮询就绪链表，期间也可能多次睡眠和唤醒交替，但是它是设备就绪时，调用回调函数，把就绪fd放入就绪链表中，并唤醒在epoll_wait中进入睡眠的进程。虽然都要睡眠和交替，但是select和poll在“醒着”的时候要遍历整个fd集合，而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，这节省了大量的CPU时间。这就是回调机制带来的性能提升。

（2）select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，并且要把current往设备等待队列中挂一次，而epoll只要一次拷贝，而且把current往等待队列上挂也只挂一次（在epoll_wait的开始，注意这里的等待队列并不是设备等待队列，只是一个epoll内部定义的等待队列）。这也能节省不少的开销。

参考资料：

http://www.cnblogs.com/apprentice89/archive/2013/05/09/3070051.html

http://www.linuxidc.com/Linux/2012-05/59873p3.htm

http://xingyunbaijunwei.blog.163.com/blog/static/76538067201241685556302/

http://blog.csdn.net/kkxgx/article/details/7717125

https://banu.com/blog/2/how-to-use-epoll-a-complete-example-in-c/epoll-example.c

冷静思考，勇敢面对，把握未来！

一、介绍
Epoll 是一种高效的管理socket的模型，相对于select和poll来说具有更高的效率和易用性。传统的select以及poll的效率会因为 socket数量的线形递增而导致呈二次乃至三次方的下降，而epoll的性能不会随socket数量增加而下降。标准的linux-2.4.20内核不支持epoll，需要打patch。本文主要从linux-2.4.32和linux-2.6.10两个内核版本介绍epoll。
二、 Epoll的使用
epoll用到的所有函数都是在头文件sys/epoll.h中声明的，下面简要说明所用到的数据结构和函数：
所用到的数据结构

[cpp] view plain copy

typedef union epoll_data {
void ptr;
int fd;
__uint32_t u32;
__uint64_t u64;
} epoll_data_t;
struct epoll_event {
__uint32_t events; / Epoll events /
epoll_data_t data; / User data variable /
};

结构体epoll_event 被用于注册所感兴趣的事件和回传所发生待处理的事件，其中epoll_data 联合体用来保存触发事件的某个文件描述符相关的数据，例如一个client连接到服务器，服务器通过调用accept函数可以得到于这个client对应的socket文件描述符，可以把这文件描述符赋给epoll_data的fd字段以便后面的读写操作在这个文件描述符上进行。epoll_event 结构体的events字段是表示感兴趣的事件和被触发的事件可能的取值为：EPOLLIN ：表示对应的文件描述符可以读；
EPOLLOUT：表示对应的文件描述符可以写；
EPOLLPRI：表示对应的文件描述符有紧急的数据可读
EPOLLERR：表示对应的文件描述符发生错误；
EPOLLHUP：表示对应的文件描述符被挂断；
EPOLLET：表示对应的文件描述符设定为edge模式；
所用到的函数：
1、epoll_create函数
    函数声明：int epoll_create(int size)
    该函数生成一个epoll专用的文件描述符，其中的参数是指定生成描述符的最大范围。在linux-2.4.32内核中根据size大小初始化哈希表的大小，在linux2.6.10内核中该参数无用，使用红黑树管理所有的文件描述符，而不是hash。
2、epoll_ctl函数
    函数声明：int epoll_ctl(int epfd, int op, int fd, struct epoll_event event)
    该函数用于控制某个文件描述符上的事件，可以注册事件，修改事件，删除事件。
    参数：epfd：由 epoll_create 生成的epoll专用的文件描述符；
                op：要进行的操作例如注册事件，可能的取值
EPOLL_CTL_ADD 注册、
EPOLL_CTL_MOD 修改、
EPOLL_CTL_DEL 删除
fd：关联的文件描述符；
event：指向epoll_event的指针；
如果调用成功返回0,不成功返回-1
3、epoll_wait函数
函数声明:int epoll_wait(int epfd,struct epoll_event   events,int maxevents,int timeout)
该函数用于轮询I/O事件的发生；
参数：
epfd:由epoll_create 生成的epoll专用的文件描述符；
epoll_event:用于回传代处理事件的数组；
maxevents:每次能处理的事件数；
timeout:等待I/O事件发生的超时值（ms）；-1永不超时，直到有事件产生才触发，0立即返回。
返回发生事件数。-1有错误。

举一个简单的例子：

[cpp] view plain copy

main()
{
//声明epoll_event结构体的变量,ev用于注册事件,数组用于回传要处理的事件
struct epoll_event ev,events[20];
epfd=epoll_create(10000); //创建epoll句柄
listenfd = socket(AF_INET, SOCK_STREAM, 0);
//把socket设置为非阻塞方式
setnonblocking(listenfd);
bzero(&serveraddr, sizeof(serveraddr));
serveraddr.sin_family = AF_INET;
serveraddr.sin_addr.s_addr = INADDR_ANY;
serveraddr.sin_port=htons(SERV_PORT);
bind(listenfd,(struct sockaddr )&serveraddr, sizeof(serveraddr));
listen(listenfd, 255);
//设置与要处理的事件相关的文件描述符
ev.data.fd=listenfd;
//设置要处理的事件类型
ev.events=EPOLLIN;
//注册epoll事件
epoll_ctl(epfd,EPOLL_CTL_ADD,listenfd,&ev);
for ( ; ; ){
//等待epoll事件的发生
nfds=epoll_wait(epfd,events,20,1000);
//处理所发生的所有事件
for(i=0;i<nfds;++i){
if(events .data.fd==listenfd){
connfd = accept(listenfd,(struct sockaddr )&clientaddr, &clilen);
if(connfd<0){
perror("connfd<0");
}
setnonblocking(connfd);
//设置用于读操作的文件描述符
ev.data.fd=connfd;
//设置用于注测的读操作事件
ev.events=EPOLLIN|EPOLLET;
//注册event
epoll_ctl(epfd,EPOLL_CTL_ADD,connfd,&ev);
}else if(events .events&EPOLLIN){
read_socket(events .data.fd);
ev.data.fd=events .data.fd;
ev.events=EPOLLIN|EPOLLOUT|EPOLLET;
epoll_ctl(epfd,EPOLL_CTL_MOD,sockfd,&ev);
}else if(events .events&EPOLLOUT){
write_socket(events .data.fd);
ev.data.fd=events .data.fd;
ev.events=EPOLLIN|EPOLLET; //ET模式
epoll_ctl(epfd,EPOLL_CTL_MOD,sockfd,&ev);
}else{
perror("other event");
}
}
}
}

Epoll的ET模式与LT模式
ET（Edge Triggered）与LT（Level Triggered）的主要区别可以从下面的例子看出
eg：
1．标示管道读者的文件句柄注册到epoll中；
2．管道写者向管道中写入2KB的数据；
3．调用epoll_wait可以获得管道读者为已就绪的文件句柄；
4．管道读者读取1KB的数据
5．一次epoll_wait调用完成
如果是ET模式，管道中剩余的1KB被挂起，再次调用epoll_wait，得不到管道读者的文件句柄，除非有新的数据写入管道。如果是LT模式，只要管道中有数据可读，每次调用epoll_wait都会触发。

另一点区别就是设为ET模式的文件句柄必须是非阻塞的。
三、 Epoll的实现
Epoll 的源文件在/usr/src/linux/fs/eventpoll.c，在module_init时注册一个文件系统 eventpoll_fs_type，对该文件系统提供两种操作poll和release，所以epoll_create返回的文件句柄可以被poll、 select或者被其它epoll epoll_wait。对epoll的操作主要通过三个系统调用实现：
1． sys_epoll_create
2． sys_epoll_ctl
3． sys_epoll_wait
下面结合源码讲述这三个系统调用。
1.1 long sys_epoll_create (int size)
该系统调用主要分配文件句柄、inode以及file结构。在linux-2.4.32内核中，使用hash保存所有注册到该epoll的文件句柄，在该系统调用中根据size大小分配hash的大小。具体为不小于size，但小于2size的2的某次方。最小为2的9次方（512），最大为2的17次方（128 x 1024）。在linux-2.6.10内核中，使用红黑树保存所有注册到该epoll的文件句柄，size参数未使用。
1.2 long sys_epoll_ctl(int epfd, int op, int fd, struct epoll_event event)
1．注册句柄 op = EPOLL_CTL_ADD
注册过程主要包括：
A．将fd插入到hash（或rbtree）中，如果原来已经存在返回-EEXIST，
B．给fd注册一个回调函数，该函数会在fd有事件时调用，在该函数中将fd加入到epoll的就绪队列中。
C．检查fd当前是否已经有期望的事件产生。如果有，将其加入到epoll的就绪队列中，唤醒epoll_wait。

2．修改事件 op = EPOLL_CTL_MOD
修改事件只是将新的事件替换旧的事件，然后检查fd是否有期望的事件。如果有，将其加入到epoll的就绪队列中，唤醒epoll_wait。

3．删除句柄 op = EPOLL_CTL_DEL
将fd从hash（rbtree）中清除。
1.3 long sys_epoll_wait(int epfd, struct epoll_event events, int maxevents,int timeout)
如果epoll的就绪队列为空，并且timeout非0，挂起当前进程，引起CPU调度。
如果epoll的就绪队列不空，遍历就绪队列。对队列中的每一个节点，获取该文件已触发的事件，判断其中是否有我们期待的事件，如果有，将其对应的epoll_event结构copy到用户events。

revents = epi->file->f_op->poll(epi->file, NULL);
epi->revents = revents & epi->event.events;
if (epi->revents) {
……
copy_to_user;
……
}
需要注意的是，在LT模式下，把符合条件的事件copy到用户空间后，还会把对应的文件重新挂接到就绪队列。所以在LT模式下，如果一次epoll_wait某个socket没有read/write完所有数据，下次epoll_wait还会返回该socket句柄。
四、使用epoll的注意事项
1. ET模式比LT模式高效，但比较难控制。
2. 如果某个句柄期待的事件不变，不需要EPOLL_CTL_MOD，但每次读写后将该句柄modify一次有助于提高稳定性，特别在ET模式。
3. socket关闭后最好将该句柄从epoll中delete（EPOLL_CTL_DEL），虽然epoll自身有处理，但会使epoll的hash的节点数增多，影响搜索hash的速度。

Q：网络服务器的瓶颈在哪？
A：IO效率。

在大家苦苦的为在线人数的增长而导致的系统资源吃紧上的问题正在发愁的时候，Linux 2.6内核中提供的System Epoll为我们提供了一套完美的解决方案。传统的select以及poll的效率会因为在线人数的线形递增而导致呈二次乃至三次方的下降，这些直接导致了网络服务器可以支持的人数有了个比较明显的限制。

自从Linux提供了/dev/epoll的设备以及后来2.6内核中对/dev /epoll设备的访问的封装（System Epoll）之后，这种现象得到了大大的缓解，如果说几个月前，大家还对epoll不熟悉，那么现在来说的话，epoll的应用已经得到了大范围的普及。

那么究竟如何来使用epoll呢？其实非常简单。
通过在包含一个头文件#include 以及几个简单的API将可以大大的提高你的网络服务器的支持人数。

首先通过create_epoll(int maxfds)来创建一个epoll的句柄，其中maxfds为你epoll所支持的最大句柄数。这个函数会返回一个新的epoll句柄，之后的所有操作将通过这个句柄来进行操作。在用完之后，记得用close()来关闭这个创建出来的epoll句柄。

之后在你的网络主循环里面，每一帧的调用epoll_wait(int epfd, epoll_event events, int max events, int timeout)来查询所有的网络接口，看哪一个可以读，哪一个可以写了。基本的语法为：
nfds = epoll_wait(kdpfd, events, maxevents, -1);
其中kdpfd为用epoll_create创建之后的句柄，events是一个epoll_event的指针，当epoll_wait这个函数操作成功之后，epoll_events里面将储存所有的读写事件。max_events是当前需要监听的所有socket句柄数。最后一个timeout是 epoll_wait的超时，为0的时候表示马上返回，为-1的时候表示一直等下去，直到有事件范围，为任意正整数的时候表示等这么长的时间，如果一直没有事件，则范围。一般如果网络主循环是单独的线程的话，可以用-1来等，这样可以保证一些效率，如果是和主逻辑在同一个线程的话，则可以用0来保证主循环的效率。

epoll_wait范围之后应该是一个循环，遍利所有的事件：

[cpp] view plain copy

for(n = 0; n < nfds; ++n) {
if(events[n].data.fd == listener) { //如果是主socket的事件的话，则表示有新连接进入了，进行新连接的处理。
client = accept(listener, (struct sockaddr ) &local,&addrlen);
if(client < 0){
perror("accept");
continue;
}
setnonblocking(client); // 将新连接置于非阻塞模式
ev.events = EPOLLIN | EPOLLET; // 并且将新连接也加入EPOLL的监听队列。
/*
注意，这里的参数EPOLLIN | EPOLLET并没有设置对写socket的监听，\
如果有写操作的话，这个时候epoll是不会返回事件的，如果要对写操作也监听的话，应该是EPOLLIN | EPOLLOUT | EPOLLET
*/
ev.data.fd = client;
if (epoll_ctl(kdpfd, EPOLL_CTL_ADD, client, &ev) < 0) {
/*
设置好event之后，将这个新的event通过epoll_ctl加入到epoll的监听队列里面，\
这里用EPOLL_CTL_ADD来加一个新的 epoll事件，通过EPOLL_CTL_DEL来减少一个epoll事件，\
通过EPOLL_CTL_MOD来改变一个事件的监听方式。
*/
fprintf(stderr, "epoll set insertion error: fd=d0,client);
return -1;
}
}else{
/*
如果不是主socket的事件的话，则代表是一个用户socket的事件，则来处理这个用户socket的事情，\
比如说read(fd,xxx)之类的，或者一些其他的处理。
*/
do_use_fd(events[n].data.fd);
}
}

对，epoll的操作就这么简单，总共不过4个API：epoll_create, epoll_ctl, epoll_wait和close。

Linux 2.6内核中提高网络I/O性能的新方法

1、为什么select是落后的？
首先，在Linux内核中，select所用到的FD_SET是有限的，即内核中有个参数__FD_SETSIZE定义了每个FD_SET的句柄个数，在我用的2.6.15-25-386内核中，该值是1024，搜索内核源代码得到：
include/linux/posix_types.h:#define __FD_SETSIZE 1024
也就是说，如果想要同时检测1025个句柄的可读状态是不可能用select实现的。或者同时检测1025个句柄的可写状态也是不可能的。
其次，内核中实现select是用轮询方法，即每次检测都会遍历所有FD_SET中的句柄，显然，select函数执行时间与FD_SET中的句柄个数有一个比例关系，即select要检测的句柄数越多就会越费时。
当然，在前文中我并没有提及poll方法，事实上用select的朋友一定也试过poll，我个人觉得select和poll大同小异，个人偏好于用select而已。
2、2.6内核中提高I/O性能的新方法epoll
epoll是什么？按照man手册的说法：是为处理大批量句柄而作了改进的poll。要使用epoll只需要这三个系统调用：epoll_create(2)， epoll_ctl(2)， epoll_wait(2)。
当然，这不是2.6内核才有的，它是在2.5.44内核中被引进的(epoll(4) is a new API introduced in Linux kernel 2.5.44)

epoll的优点
<1>支持一个进程打开大数目的socket描述符(FD)
select 最不能忍受的是一个进程所打开的FD是有一定限制的，由FD_SETSIZE设置，默认值是2048。对于那些需要支持的上万连接数目的IM服务器来说显然太少了。这时候你一是可以选择修改这个宏然后重新编译内核，不过资料也同时指出这样会带来网络效率的下降，二是可以选择多进程的解决方案(传统的 Apache方案)，不过虽然linux上面创建进程的代价比较小，但仍旧是不可忽视的，加上进程间数据同步远比不上线程间同步的高效，所以也不是一种完美的方案。不过 epoll则没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。

<2>IO效率不随FD数目增加而线性下降
传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合，不过由于网络延时，任一时间只有部分的socket是"活跃"的，但是select/poll每次调用都会线性扫描全部的集合，导致效率呈现线性下降。但是epoll不存在这个问题，它只会对"活跃"的socket进行操作---这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有"活跃"的socket才会主动的去调用 callback函数，其他idle状态socket则不会，在这点上，epoll实现了一个"伪"AIO，因为这时候推动力在os内核。在一些 benchmark中，如果所有的socket基本上都是活跃的---比如一个高速LAN环境，epoll并不比select/poll有什么效率，相反，如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。
<3>使用mmap加速内核与用户空间的消息传递。
这点实际上涉及到epoll的具体实现了。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝就很重要，在这点上，epoll是通过内核于用户空间mmap同一块内存实现的。而如果你想我一样从2.5内核就关注epoll的话，一定不会忘记手工 mmap这一步的。
<4>内核微调
这一点其实不算epoll的优点了，而是整个linux平台的优点。也许你可以怀疑linux平台，但是你无法回避linux平台赋予你微调内核的能力。比如，内核TCP/IP协议栈使用内存池管理sk_buff结构，那么可以在运行时期动态调整这个内存pool(skb_head_pool)的大小 --- 通过echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函数的第2个参数(TCP完成3次握手的数据包队列长度)，也可以根据你平台内存大小动态调整。更甚至在一个数据包面数目巨大但同时每个数据包本身大小却很小的特殊系统上尝试最新的NAPI网卡驱动架构。
epoll的使用
令人高兴的是，2.6内核的epoll比其2.5开发版本的/dev/epoll简洁了许多，所以，大部分情况下，强大的东西往往是简单的。唯一有点麻烦是epoll有2种工作方式:LT和ET。
LT(level triggered)是缺省的工作方式，并且同时支持block和no-block socket.在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表．
ET (edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once),不过在TCP协议中，ET模式的加速效用仍需要更多的benchmark确认。
epoll只有epoll_create,epoll_ctl,epoll_wait 3个系统调用，具体用法请参考http://www.xmailserver.org/linux-patches/nio-improve.html ，
在http://www.kegel.com/rn/也有一个完整的例子，大家一看就知道如何使用了
Leader/follower模式线程pool实现，以及和epoll的配合

在Linux上开发网络服务器的一些相关细节:poll与epoll
　　随着2.6内核对epoll的完全支持，网络上很多的文章和示例代码都提供了这样一个信息：使用epoll代替传统的 poll能给网络服务应用带来性能上的提升。但大多文章里关于性能提升的原因解释的较少，这里我将试分析一下内核（2.6.21.1）代码中poll与 epoll的工作原理，然后再通过一些测试数据来对比具体效果。 POLL：

先说poll，poll或select为大部分Unix/Linux程序员所熟悉，这俩个东西原理类似，性能上也不存在明显差异，但select对所监控的文件描述符数量有限制，所以这里选用poll做说明。
poll是一个系统调用，其内核入口函数为sys_poll，sys_poll几乎不做任何处理直接调用do_sys_poll，do_sys_poll的执行过程可以分为三个部分：
1，将用户传入的pollfd数组拷贝到内核空间，因为拷贝操作和数组长度相关，时间上这是一个O（n）操作，这一步的代码在do_sys_poll中包括从函数开始到调用do_poll前的部分。
2，查询每个文件描述符对应设备的状态，如果该设备尚未就绪，则在该设备的等待队列中加入一项并继续查询下一设备的状态。查询完所有设备后如果没有一个设备就绪，这时则需要挂起当前进程等待，直到设备就绪或者超时，挂起操作是通过调用schedule_timeout执行的。设备就绪后进程被通知继续运行，这时再次遍历所有设备，以查找就绪设备。这一步因为两次遍历所有设备，时间复杂度也是O（n），这里面不包括等待时间。相关代码在do_poll函数中。
3，将获得的数据传送到用户空间并执行释放内存和剥离等待队列等善后工作，向用户空间拷贝数据与剥离等待队列等操作的的时间复杂度同样是O（n），具体代码包括do_sys_poll函数中调用do_poll后到结束的部分。
EPOLL：
接下来分析epoll，与poll/select不同，epoll不再是一个单独的系统调用，而是由epoll_create/epoll_ctl/epoll_wait三个系统调用组成，后面将会看到这样做的好处。
先来看sys_epoll_create(epoll_create对应的内核函数），这个函数主要是做一些准备工作，比如创建数据结构，初始化数据并最终返回一个文件描述符（表示新创建的虚拟epoll文件），这个操作可以认为是一个固定时间的操作。
epoll是做为一个虚拟文件系统来实现的，这样做至少有以下两个好处：
1，可以在内核里维护一些信息，这些信息在多次epoll_wait间是保持的，比如所有受监控的文件描述符。
2， epoll本身也可以被poll/epoll;
具体epoll的虚拟文件系统的实现和性能分析无关，不再赘述。
在sys_epoll_create中还能看到一个细节，就是epoll_create的参数size在现阶段是没有意义的，只要大于零就行。

接着是sys_epoll_ctl(epoll_ctl对应的内核函数），需要明确的是每次调用sys_epoll_ctl只处理一个文件描述符，这里主要描述当op为EPOLL_CTL_ADD时的执行过程，sys_epoll_ctl做一些安全性检查后进入ep_insert，ep_insert里将 ep_poll_callback做为回掉函数加入设备的等待队列（假定这时设备尚未就绪），由于每次poll_ctl只操作一个文件描述符，因此也可以认为这是一个O(1)操作

ep_poll_callback函数很关键，它在所等待的设备就绪后被系统回掉，执行两个操作：

1，将就绪设备加入就绪队列，这一步避免了像poll那样在设备就绪后再次轮询所有设备找就绪者，降低了时间复杂度，由O（n）到O（1）;
2，唤醒虚拟的epoll文件;
最后是sys_epoll_wait，这里实际执行操作的是ep_poll函数。该函数等待将进程自身插入虚拟epoll文件的等待队列，直到被唤醒（见上面ep_poll_callback函数描述），最后执行ep_events_transfer将结果拷贝到用户空间。由于只拷贝就绪设备信息，所以这里的拷贝是一个O(1）操作。
还有一个让人关心的问题就是epoll对EPOLLET的处理，即边沿触发的处理，粗略看代码就是把一部分水平触发模式下内核做的工作交给用户来处理，直觉上不会对性能有太大影响，感兴趣的朋友欢迎讨论。
POLL/EPOLL对比：
表面上poll的过程可以看作是由一次epoll_create/若干次epoll_ctl/一次epoll_wait/一次close等系统调用构成，实际上epoll将poll分成若干部分实现的原因正是因为服务器软件中使用poll的特点（比如Web服务器）：
1，需要同时poll大量文件描述符;
2，每次poll完成后就绪的文件描述符只占所有被poll的描述符的很少一部分。
3，前后多次poll调用对文件描述符数组（ufds）的修改只是很小;
传统的poll函数相当于每次调用都重起炉灶，从用户空间完整读入ufds，完成后再次完全拷贝到用户空间，另外每次poll都需要对所有设备做至少做一次加入和删除等待队列操作，这些都是低效的原因。

epoll将以上情况都细化考虑，不需要每次都完整读入输出ufds，只需使用epoll_ctl调整其中一小部分，不需要每次epoll_wait都执行一次加入删除等待队列操作，另外改进后的机制使的不必在某个设备就绪后搜索整个设备数组进行查找，这些都能提高效率。另外最明显的一点，从用户的使用来说，使用epoll不必每次都轮询所有返回结果已找出其中的就绪部分，O（n）变O（1），对性能也提高不少。

此外这里还发现一点，是不是将epoll_ctl改成一次可以处理多个fd（像semctl那样）会提高些许性能呢？特别是在假设系统调用比较耗时的基础上。不过关于系统调用的耗时问题还会在以后分析。

POLL/EPOLL测试数据对比：
测试的环境：我写了三段代码来分别模拟服务器，活动的客户端，僵死的客户端，服务器运行于一个自编译的标准2.6.11内核系统上，硬件为 PIII933，两个客户端各自运行在另外的PC上，这两台PC比服务器的硬件性能要好，主要是保证能轻易让服务器满载，三台机器间使用一个100M交换机连接。
服务器接受并poll所有连接，如果有request到达则回复一个response，然后继续poll。
活动的客户端（Active Client）模拟若干并发的活动连接，这些连接不间断的发送请求接受回复。
僵死的客户端（zombie）模拟一些只连接但不发送请求的客户端，其目的只是占用服务器的poll描述符资源。
测试过程：保持10个并发活动连接，不断的调整僵并发连接数，记录在不同比例下使用poll与epoll的性能差别。僵死并发连接数根据比例分别是：0，10，20，40，80，160，320，640，1280，2560，5120，10240。
下图中横轴表示僵死并发连接与活动并发连接之比，纵轴表示完成40000次请求回复所花费的时间，以秒为单位。红色线条表示poll数据，绿色表示 epoll数据。可以看出，poll在所监控的文件描述符数量增加时，其耗时呈线性增长，而epoll则维持了一个平稳的状态，几乎不受描述符个数影响。
在监控的所有客户端都是活动时，poll的效率会略高于epoll（主要在原点附近，即僵死并发连接为0时，图上不易看出来），究竟epoll实现比poll复杂，监控少量描述符并非它的长处。

在linux的网络编程中，很长的时间都在使用select来做事件触发。在linux新的内核中，有了一种替换它的机制，就是epoll。相比于select，epoll最大的好处在于它不会随着监听fd数目的增长而降低效率。因为在内核中的select实现中，它是采用轮询来处理的，轮询的fd数目越多，自然耗时越多。并且，linux/posix_types.h头文件有这样的声明：
#define __FD_SETSIZE    1024
          表示select最多同时监听1024个fd，当然，可以通过修改头文件再重编译内核来扩大这个数目，但这似乎并不治本。

epoll的接口非常简单，一共就三个函数：
1. int epoll_create(int size);
         创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大。这个参数不同于select()中的第一个参数，给出最大监听的fd+1的值。需要注意的是，当创建好epoll句柄后，它就是会占用一个fd值，在linux下如果查看/proc/进程id/fd/，是能够看到这个fd的，所以在使用完epoll后，必须调用close()关闭，否则可能导致fd被耗尽。

2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
           epoll的事件注册函数，它不同与select()是在监听事件时告诉内核要监听什么类型的事件，而是在这里先注册要监听的事件类型。

第一个参数是epoll_create()的返回值，

            第二个参数表示动作，用三个宏来表示：
           EPOLL_CTL_ADD：       注册新的fd到epfd中；
           EPOLL_CTL_MOD：       修改已经注册的fd的监听事件；
           EPOLL_CTL_DEL：        从epfd中删除一个fd；
          第三个参数 是需要监听的fd，

          第四个参数是告诉内核需要监听什么事件，struct epoll_event结构如下：
          struct epoll_event {
                 __uint32_t events; /* Epoll events */
                epoll_data_t data; /* User data variable */
          };
events可以是以下几个宏的集合：
EPOLLIN ：             表示对应的文件描述符可以读（包括对端SOCKET正常关闭）；
EPOLLOUT：         表示对应的文件描述符可以写；
EPOLLPRI：           表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；
EPOLLERR：         表示对应的文件描述符发生错误；
EPOLLHUP：         表示对应的文件描述符被挂断；
EPOLLET：            将EPOLL设为边缘触发(Edge Triggered)模式，这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT：   只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里

3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
        等待事件的产生，类似于select()调用。 参数events用来从内核得到事件的集合， maxevents告之内核这个events有多大，这个maxevents的值不能大于创建epoll_create()时的size，参数timeout是超时时间（毫秒，0会立即返回，-1将不确定，也有说法说是永久阻塞）。该函数返回需要处理的事件数目，如返回0表示已超时。

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

从man手册中，得到ET和LT的具体描述如下

EPOLL事件有两种模型：
Edge Triggered (ET)              // 高速工作方式，错误率比较大，只支持no_block socket
Level Triggered (LT)               // 缺省工作方式，即默认的工作方式,支持block socket和no_block socket，错误率比较小。

假如有这样一个例子：( LT方式，即默认方式下，内核会继续通知，可以读数据，ET方式，内部不会再通知，可以读数据)
1. 我们已经把一个用来从管道中读取数据的文件句柄(RFD)添加到epoll描述符
2. 这个时候从管道的另一端被写入了2KB的数据
3. 调用epoll_wait(2)，并且它会返回RFD，说明它已经准备好读取操作
4. 然后我们读取了1KB的数据
5. 调用epoll_wait(2)......

Edge Triggered 工作模式：
        如果我们在第1步将RFD添加到epoll描述符的时候使用了EPOLLET标志，那么在第5步调用epoll_wait(2)之后将有可能会挂起，因为剩余的数据还存在于文件的输入缓冲区内，而且数据发出端还在等待一个针对已经发出数据的反馈信息。只有在监视的文件句柄上发生了某个事件的时候 ET 工作模式才会汇报事件。因此在第5步的时候，调用者可能会放弃等待仍在存在于文件输入缓冲区内的剩余数据。在上面的例子中，会有一个事件产生在RFD句柄上，因为在第2步执行了一个写操作，然后，事件将会在第3步被销毁。因为第4步的读取操作没有读空文件输入缓冲区内的数据，因此我们在第5步调用 epoll_wait(2)完成后，是否挂起是不确定的。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。最好以下面的方式调用ET模式的epoll接口，在后面会介绍避免可能的缺陷。(LT方式可以解决这种缺陷)
   i    基于非阻塞文件句柄
   ii   只有当read(2)或者write(2)返回EAGAIN时才需要挂起，等待。但这并不是说每次read()时都需要循环读，直到读到产生一个EAGAIN才认为此次事件处理完成，当read()返回的读到的数据长度小于请求的数据长度时，就可以确定此时缓冲中已没有数据了，也就可以认为此事读事件已处理完成。

Level Triggered 工作模式        (默认的工作方式)
      相反的，以LT方式调用epoll接口的时候，它就相当于一个速度比较快的poll(2)，并且无论后面的数据是否被使用，因此他们具有同样的职能。因为即使使用ET模式的epoll，在收到多个chunk的数据的时候仍然会产生多个事件。调用者可以设定EPOLLONESHOT标志，在 epoll_wait(2)收到事件后epoll会与事件关联的文件句柄从epoll描述符中禁止掉。因此当EPOLLONESHOT设定后，使用带有 EPOLL_CTL_MOD标志的epoll_ctl(2)处理文件句柄就成为调用者必须作的事情。

然后详细解释ET, LT:
         //没有对就绪的fd进行IO操作，内核会不断的通知。
         LT(level triggered)是缺省的工作方式，并且同时支持block和no-block socket。在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表。
          //没有对就绪的fd进行IO操作，内核不会再进行通知。
          ET(edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了( 比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once) , 不过在TCP协议中，ET模式的加速效用仍需要更多的benchmark确认（这句话不理解）。

另外，当使用epoll的ET模型来工作时，当产生了一个EPOLLIN事件后，
        读数据的时候需要考虑的是当recv()返回的大小如果等于请求的大小，那么很有可能是缓冲区还有数据未读完，也意味着该次事件还没有处理完，所以还需要再次读取：
while(rs)           //ET模型
{
           buflen = recv(activeevents[i].data.fd, buf, sizeof(buf), 0);
           if(buflen < 0)
           {
                         /*

由于是非阻塞的模式，

当errno为EAGAIN 表示被中断 (可以继续读，或者等epoll或select的后续通知)

errno为EWOULDBLOCK||EAGAIN时,表示当前缓冲区暂时没有数据可读 (可以继续读，或者等epoll或select的后续通知)

*/
if(errno == EAGAIN || errno == EINT || errno == EWOULDBLOCK)

{

即当buflen>0且errno==EAGAIN || errno == EWOULDBLOCK || errno == EINT时，

表示暂时没有数据了。(读/写都是这样)

方法一、

usleep(1000);
continue; //这样会使读进程阻塞在这里，不断的读，直到有数据。

方法二、

既然暂时读不到，就暂时不读了，等待后续通知。(当有数据到达时，epoll和select还会被触发，再处理)

break; //不允许阻塞在这里，等待后续通知，继续读。

                        }
                        else
                               return;           //真的失败了，应该关闭链接
            }
           else if(buflen == 0)
          {
                   /*

这里表示对端的socket已正常关闭，这里也应该关闭close(activeevents[i].data.fd)，

并从select中删除，

如果是epoll，系统会自己删除对fd的监听。

                   */
           }
           if(buflen == sizeof(buf)
                   rs = 1;                       // 需要再次读取，但是但前的buf中数据已经存满，需要处理的。
           else
                   rs = 0;                       //不需要再次读取
}
非常重要::
        还有，假如发送端流量大于接收端的流量(意思是epoll所在的程序读比转发的socket要快),由于是非阻塞的socket,那么send()函数虽然返回,但实际缓冲区的数据并未真正发给接收端,这样不断的读和发，当缓冲区满后会产生EAGAIN错误(参考man send),同时,不理会这次请求发送的数据.所以,

需要封装socket_send()的函数用来处理这种情况,该函数会尽量将数据写完再返回，返回-1表示出错。在socket_send()内部,当写缓冲已满(send()返回-1,且errno为EAGAIN),那么会等待后再重试.这种方式并不很完美,在理论上可能会长时间的阻塞在socket_send()内部,但暂没有更好的办法.

这种方法类似于readn和writen的封装(自己写过，在《UNIX环境高级编程》中也有介绍)

ssize_t socket_send(int sockfd, const char* buffer, size_t buflen)
{
ssize_t tmp;
size_t total = buflen;
const char *p = buffer;

while(1)
{
    tmp = send(sockfd, p, total, 0);
    if(tmp < 0)
    {
      /*

EINTR 表示当send时，收到中断信号，可以继续写，或者等待后续epoll和select的通知，再写。

EAGAIN 表示当send时，写缓冲队列已满，我们可以继续等待，继续写，或者等待epoll和select的后续通知，再写。

     */
      if(errno == EINTR || errno == EAGAIN || errno == EWOULDBLOCK)
      {

                方法一、
                usleep(1000);
                continue;                               //继续写(这里会造成当前进程阻塞在send这里)

方法二、

                break;                                    //等待select和epoll的后续通知，再写。
      }
      return -1;
    }

    if((size_t)tmp == total)
      return buflen;

    total -= tmp;
    p += tmp;
}

return tmp;

本系列里完成端口的代码在两年前就已经写好了，但是由于许久没有写东西了，不知该如何提笔，所以这篇文档总是在酝酿之中……酝酿了两年之后，终于决定开始动笔了，但愿还不算晚…..

这篇文档我非常详细并且图文并茂的介绍了关于网络编程模型中完成端口的方方面面的信息，从API的用法到使用的步骤，从完成端口的实现机理到实际使用的注意事项，都有所涉及，并且为了让朋友们更直观的体会完成端口的用法，本文附带了有详尽注释的使用MFC编写的图形界面的示例代码。

我的初衷是希望写一份互联网上能找到的最详尽的关于完成端口的教学文档，而且让对Socket编程略有了解的人都能够看得懂，都能学会如何来使用完成端口这么优异的网络编程模型，但是由于本人水平所限，不知道我的初衷是否实现了，但还是希望各位需要的朋友能够喜欢。

由于篇幅原因，本文假设你已经熟悉了利用Socket进行TCP/IP编程的基本原理，并且也熟练的掌握了多线程编程技术，太基本的概念我这里就略过不提了，网上的资料应该遍地都是。

本文档凝聚着笔者心血，如要转载，请指明原作者及出处，谢谢！不过代码没有版权，可以随便散播使用，欢迎改进，特别是非常欢迎能够帮助我发现Bug的朋友，以更好的造福大家。^_^

本文配套的示例源码下载地址（在我的下载空间里，已经补充上了客户端的代码）

http://piggyxp.download.csdn.net/

(里面的代码包括VC++2008/VC++2010编写的完成端口服务器端和客户端的代码，还包括一个对服务器端进行压力测试的客户端，都是经过我精心调试过，并且带有非常详尽的代码注释的。当然，作为教学代码，为了能够使得代码结构清晰明了，我还是对代码有所简化，如果想要用于产品开发，最好还是需要自己再完善一下，另外我的工程是用2010编写的，附带的2008工程不知道有没有问题，但是其中代码都是一样的，暂未测试)

忘了嘱咐一下了，文章篇幅很长很长，基本涉及到了与完成端口有关的方方面面，一次看不完可以分好几次，中间注意休息，好身体才是咱们程序员最大的本钱！

对了，还忘了嘱咐一下，因为本人的水平有限，虽然我反复修正了数遍，但文章和示例代码里肯定还有我没发现的错误和纰漏，希望各位一定要指出来，拍砖、喷我，我都能Hold住，但是一定要指出来，我会及时修正，因为我不想让文中的错误传遍互联网，祸害大家。

OK, Let’s Go ! Have fun !

目录：

1．完成端口的优点

2．完成端口程序的运行演示

3．完成端口的相关概念

4．完成端口的基本流程

5．完成端口的使用详解

6．实际应用中应该要注意的地方

一．完成端口的优点

1. 我想只要是写过或者想要写C/S模式网络服务器端的朋友，都应该或多或少的听过完成端口的大名吧，完成端口会充分利用Windows内核来进行I/O的调度，是用于C/S通信模式中性能最好的网络通信模型，没有之一；甚至连和它性能接近的通信模型都没有。

2. 完成端口和其他网络通信方式最大的区别在哪里呢？

(1) 首先，如果使用“同步”的方式来通信的话，这里说的同步的方式就是说所有的操作都在一个线程内顺序执行完成，这么做缺点是很明显的：因为同步的通信操作会阻塞住来自同一个线程的任何其他操作，只有这个操作完成了之后，后续的操作才可以完成；一个最明显的例子就是咱们在MFC的界面代码中，直接使用阻塞Socket调用的代码，整个界面都会因此而阻塞住没有响应！所以我们不得不为每一个通信的Socket都要建立一个线程，多麻烦？这不坑爹呢么？所以要写高性能的服务器程序，要求通信一定要是异步的。

(2) 各位读者肯定知道，可以使用使用“同步通信(阻塞通信)+多线程”的方式来改善(1)的情况，那么好，想一下，我们好不容易实现了让服务器端在每一个客户端连入之后，都要启动一个新的Thread和客户端进行通信，有多少个客户端，就需要启动多少个线程，对吧；但是由于这些线程都是处于运行状态，所以系统不得不在所有可运行的线程之间进行上下文的切换，我们自己是没啥感觉，但是CPU却痛苦不堪了，因为线程切换是相当浪费CPU时间的，如果客户端的连入线程过多，这就会弄得CPU都忙着去切换线程了，根本没有多少时间去执行线程体了，所以效率是非常低下的，承认坑爹了不？

(3) 而微软提出完成端口模型的初衷，就是为了解决这种"one-thread-per-client"的缺点的，它充分利用内核对象的调度，只使用少量的几个线程来处理和客户端的所有通信，消除了无谓的线程上下文切换，最大限度的提高了网络通信的性能，这种神奇的效果具体是如何实现的请看下文。

3. 完成端口被广泛的应用于各个高性能服务器程序上，例如著名的Apache….如果你想要编写的服务器端需要同时处理的并发客户端连接数量有数百上千个的话，那不用纠结了，就是它了。

二．完成端口程序的运行演示

首先，我们先来看一下完成端口在笔者的PC机上的运行表现，笔者的PC配置如下：

大体就是i7 2600 + 16GB内存，我以这台PC作为服务器，简单的进行了如下的测试，通过Client生成3万个并发线程同时连接至Server，然后每个线程每隔3秒钟发送一次数据，一共发送3次，然后观察服务器端的CPU和内存的占用情况。

如图2所示，是客户端3万个并发线程发送共发送9万条数据的log截图

图3是服务器端接收完毕3万个并发线程和每个线程的3份数据后的log截图

最关键是图4，图4是服务器端在接收到28000个并发线程的时候，CPU占用率的截图，使用的软件是大名鼎鼎的Process Explorer，因为相对来讲这个比自带的任务管理器要准确和精确一些。

我们可以发现一个令人惊讶的结果，采用了完成端口的Server程序(蓝色横线所示)所占用的CPU才为 3.82%，整个运行过程中的峰值也没有超过4%，是相当气定神闲的……哦，对了，这还是在Debug环境下运行的情况，如果采用Release方式执行，性能肯定还会更高一些，除此以外，在UI上显示信息也很大成都上影响了性能。

相反采用了多个并发线程的Client程序(紫色横线所示)居然占用的CPU高达11.53%，甚至超过了Server程序的数倍……

其实无论是哪种网络操模型，对于内存占用都是差不多的，真正的差别就在于CPU的占用，其他的网络模型都需要更多的CPU动力来支撑同样的连接数据。

虽然这远远算不上服务器极限压力测试，但是从中也可以看出来完成端口的实力，而且这种方式比纯粹靠多线程的方式实现并发资源占用率要低得多。

三．完成端口的相关概念

在开始编码之前，我们先来讨论一下和完成端口相关的一些概念，如果你没有耐心看完这段大段的文字的话，也可以跳过这一节直接去看下下一节的具体实现部分，但是这一节中涉及到的基本概念你还是有必要了解一下的，而且你也更能知道为什么有那么多的网络编程模式不用，非得要用这么又复杂又难以理解的完成端口呢？？也会坚定你继续学习下去的信心^_^

3.1 异步通信机制及其几种实现方式的比较

我们从前面的文字中了解到，高性能服务器程序使用异步通信机制是必须的。

而对于异步的概念，为了方便后面文字的理解，这里还是再次简单的描述一下：

异步通信就是在咱们与外部的I/O设备进行打交道的时候，我们都知道外部设备的I/O和CPU比起来简直是龟速，比如硬盘读写、网络通信等等，我们没有必要在咱们自己的线程里面等待着I/O操作完成再执行后续的代码，而是将这个请求交给设备的驱动程序自己去处理，我们的线程可以继续做其他更重要的事情，大体的流程如下图所示:

我可以从图中看到一个很明显的并行操作的过程，而“同步”的通信方式是在进行网络操作的时候，主线程就挂起了，主线程要等待网络操作完成之后，才能继续执行后续的代码，就是说要么执行主线程，要么执行网络操作，是没法这样并行的；

“异步”方式无疑比 “阻塞模式+多线程”的方式效率要高的多，这也是前者为什么叫“异步”，后者为什么叫“同步”的原因了，因为不需要等待网络操作完成再执行别的操作。

而在Windows中实现异步的机制同样有好几种，而这其中的区别，关键就在于图1中的最后一步“通知应用程序处理网络数据”上了，因为实现操作系统调用设备驱动程序去接收数据的操作都是一样的，关键就是在于如何去通知应用程序来拿数据。它们之间的具体区别我这里多讲几点，文字有点多，如果没兴趣深入研究的朋友可以跳过下一面的这一段，不影响的:)

(1) 设备内核对象，使用设备内核对象来协调数据的发送请求和接收数据协调，也就是说通过设置设备内核对象的状态，在设备接收数据完成后，马上触发这个内核对象，然后让接收数据的线程收到通知，但是这种方式太原始了，接收数据的线程为了能够知道内核对象是否被触发了，还是得不停的挂起等待，这简直是根本就没有用嘛，太低级了，有木有？所以在这里就略过不提了，各位读者要是没明白是怎么回事也不用深究了，总之没有什么用。

(2) 事件内核对象，利用事件内核对象来实现I/O操作完成的通知，其实这种方式其实就是我以前写文章的时候提到的《基于事件通知的重叠I/O模型》，链接在这里，这种机制就先进得多，可以同时等待多个I/O操作的完成，实现真正的异步，但是缺点也是很明显的，既然用WaitForMultipleObjects()来等待Event的话，就会受到64个Event等待上限的限制，但是这可不是说我们只能处理来自于64个客户端的Socket，而是这是属于在一个设备内核对象上等待的64个事件内核对象，也就是说，我们在一个线程内，可以同时监控64个重叠I/O操作的完成状态，当然我们同样可以使用多个线程的方式来满足无限多个重叠I/O的需求，比如如果想要支持3万个连接，就得需要500多个线程…用起来太麻烦让人感觉不爽；

(3) 使用APC( Asynchronous Procedure Call，异步过程调用)来完成，这个也就是我以前在文章里提到的《基于完成例程的重叠I/O模型》，链接在这里，这种方式的好处就是在于摆脱了基于事件通知方式的64个事件上限的限制，但是缺点也是有的，就是发出请求的线程必须得要自己去处理接收请求，哪怕是这个线程发出了很多发送或者接收数据的请求，但是其他的线程都闲着…，这个线程也还是得自己来处理自己发出去的这些请求，没有人来帮忙…这就有一个负载均衡问题，显然性能没有达到最优化。

(4) 完成端口，不用说大家也知道了，最后的压轴戏就是使用完成端口，对比上面几种机制，完成端口的做法是这样的：事先开好几个线程，你有几个CPU我就开几个，首先是避免了线程的上下文切换，因为线程想要执行的时候，总有CPU资源可用，然后让这几个线程等着，等到有用户请求来到的时候，就把这些请求都加入到一个公共消息队列中去，然后这几个开好的线程就排队逐一去从消息队列中取出消息并加以处理，这种方式就很优雅的实现了异步通信和负载均衡的问题，因为它提供了一种机制来使用几个线程“公平的”处理来自于多个客户端的输入/输出，并且线程如果没事干的时候也会被系统挂起，不会占用CPU周期，挺完美的一个解决方案，不是吗？哦，对了，这个关键的作为交换的消息队列，就是完成端口。

比较完毕之后，熟悉网络编程的朋友可能会问到，为什么没有提到WSAAsyncSelect或者是WSAEventSelect这两个异步模型呢，对于这两个模型，我不知道其内部是如何实现的，但是这其中一定没有用到Overlapped机制，就不能算作是真正的异步，可能是其内部自己在维护一个消息队列吧，总之这两个模式虽然实现了异步的接收，但是却不能进行异步的发送，这就很明显说明问题了，我想其内部的实现一定和完成端口是迥异的，并且，完成端口非常厚道，因为它是先把用户数据接收回来之后再通知用户直接来取就好了，而WSAAsyncSelect和WSAEventSelect之流只是会接收到数据到达的通知，而只能由应用程序自己再另外去recv数据，性能上的差距就更明显了。

最后，我的建议是，想要使用基于事件通知的重叠I/O和基于完成例程的重叠I/O的朋友，如果不是特别必要，就不要去使用了，因为这两种方式不仅使用和理解起来也不算简单，而且还有性能上的明显瓶颈，何不就再努力一下使用完成端口呢？

3.2 重叠结构(OVERLAPPED)

我们从上一小节中得知，要实现异步通信，必须要用到一个很风骚的I/O数据结构，叫重叠结构“Overlapped”，Windows里所有的异步通信都是基于它的，完成端口也不例外。

至于为什么叫Overlapped？Jeffrey Richter的解释是因为“执行I/O请求的时间与线程执行其他任务的时间是重叠(overlapped)的”，从这个名字我们也可能看得出来重叠结构发明的初衷了，对于重叠结构的内部细节我这里就不过多的解释了，就把它当成和其他内核对象一样，不需要深究其实现机制，只要会使用就可以了，想要了解更多重叠结构内部的朋友，请去翻阅Jeffrey Richter的《Windows via C/C++》 5^th 的292页，如果没有机会的话，也可以随便翻翻我以前写的Overlapped的东西，不过写得比较浅显……

这里我想要解释的是，这个重叠结构是异步通信机制实现的一个核心数据结构，因为你看到后面的代码你会发现，几乎所有的网络操作例如发送/接收之类的，都会用WSASend()和WSARecv()代替，参数里面都会附带一个重叠结构，这是为什么呢？因为重叠结构我们可以理解成为是一个网络操作的ID号，也就是说我们要利用重叠I/O提供的异步机制的话，每一个网络操作都要有一个唯一的ID号，因为进了系统内核，里面黑灯瞎火的，也不了解上面出了什么状况，一看到有重叠I/O的调用进来了，就会使用其异步机制，并且操作系统就只能靠这个重叠结构带有的ID号来区分是哪一个网络操作了，然后内核里面处理完毕之后，根据这个ID号，把对应的数据传上去。

你要是实在不理解这是个什么玩意，那就直接看后面的代码吧，慢慢就明白了……

3.3 完成端口(CompletionPort)

对于完成端口这个概念，我一直不知道为什么它的名字是叫“完成端口”，我个人的感觉应该叫它“完成队列”似乎更合适一些，总之这个“端口”和我们平常所说的用于网络通信的“端口”完全不是一个东西，我们不要混淆了。

首先，它之所以叫“完成”端口，就是说系统会在网络I/O操作“完成”之后才会通知我们，也就是说，我们在接到系统的通知的时候，其实网络操作已经完成了，就是比如说在系统通知我们的时候，并非是有数据从网络上到来，而是来自于网络上的数据已经接收完毕了；或者是客户端的连入请求已经被系统接入完毕了等等，我们只需要处理后面的事情就好了。

各位朋友可能会很开心，什么？已经处理完毕了才通知我们，那岂不是很爽？其实也没什么爽的，那是因为我们在之前给系统分派工作的时候，都嘱咐好了，我们会通过代码告诉系统“你给我做这个做那个，等待做完了再通知我”，只是这些工作是做在之前还是之后的区别而已。

其次，我们需要知道，所谓的完成端口，其实和HANDLE一样，也是一个内核对象，虽然Jeff Richter吓唬我们说：“完成端口可能是最为复杂的内核对象了”，但是我们也不用去管他，因为它具体的内部如何实现的和我们无关，只要我们能够学会用它相关的API把这个完成端口的框架搭建起来就可以了。我们暂时只用把它大体理解为一个容纳网络通信操作的队列就好了，它会把网络操作完成的通知，都放在这个队列里面，咱们只用从这个队列里面取就行了，取走一个就少一个…。

关于完成端口内核对象的具体更多内部细节我会在后面的“完成端口的基本原理”一节更详细的和朋友们一起来研究，当然，要是你们在文章中没有看到这一节的话，就是说明我又犯懒了没写…在后续的文章里我会补上。这里就暂时说这么多了，到时候我们也可以看到它的机制也并非有那么的复杂，可能只是因为操作系统其他的内核对象相比较而言实现起来太容易了吧^_^

四．使用完成端口的基本流程

说了这么多的废话，大家都等不及了吧，我们终于到了具体编码的时候了。

使用完成端口，说难也难，但是说简单，其实也简单 ---- 又说了一句废话=。=

大体上来讲，使用完成端口只用遵循如下几个步骤：

(1) 调用 CreateIoCompletionPort() 函数创建一个完成端口，而且在一般情况下，我们需要且只需要建立这一个完成端口，把它的句柄保存好，我们今后会经常用到它……

(2) 根据系统中有多少个处理器，就建立多少个工作者(为了醒目起见，下面直接说Worker)线程，这几个线程是专门用来和客户端进行通信的，目前暂时没什么工作；

(3) 下面就是接收连入的Socket连接了，这里有两种实现方式：一是和别的编程模型一样，还需要启动一个独立的线程，专门用来accept客户端的连接请求；二是用性能更高更好的异步AcceptEx()请求，因为各位对accept用法应该非常熟悉了，而且网上资料也会很多，所以为了更全面起见，本文采用的是性能更好的AcceptEx，至于两者代码编写上的区别，我接下来会详细的讲。

(4) 每当有客户端连入的时候，我们就还是得调用CreateIoCompletionPort()函数，这里却不是新建立完成端口了，而是把新连入的Socket(也就是前面所谓的设备句柄)，与目前的完成端口绑定在一起。

至此，我们其实就已经完成了完成端口的相关部署工作了，嗯，是的，完事了，后面的代码里我们就可以充分享受完成端口带给我们的巨大优势，坐享其成了，是不是很简单呢？

(5) 例如，客户端连入之后，我们可以在这个Socket上提交一个网络请求，例如WSARecv()，然后系统就会帮咱们乖乖的去执行接收数据的操作，我们大可以放心的去干别的事情了；

(6) 而此时，我们预先准备的那几个Worker线程就不能闲着了，我们在前面建立的几个Worker就要忙活起来了，都需要分别调用GetQueuedCompletionStatus() 函数在扫描完成端口的队列里是否有网络通信的请求存在(例如读取数据，发送数据等)，一旦有的话，就将这个请求从完成端口的队列中取回来，继续执行本线程中后面的处理代码，处理完毕之后，我们再继续投递下一个网络通信的请求就OK了，如此循环。

关于完成端口的使用步骤，用文字来表述就是这么多了，很简单吧？如果你还是不理解，我再配合一个流程图来表示一下：

当然，我这里假设你已经对网络编程的基本套路有了解了，所以略去了很多基本的细节，并且为了配合朋友们更好的理解我的代码，在流程图我标出了一些函数的名字，并且画得非常详细。

另外需要注意的是由于对于客户端的连入有两种方式，一种是普通阻塞的accept，另外一种是性能更好的AcceptEx，为了能够方面朋友们从别的网络编程的方式中过渡，我这里画了两种方式的流程图，方便朋友们对比学习，图a是使用accept的方式，当然配套的源代码我默认就不提供了，如果需要的话，我倒是也可以发上来；图b是使用AcceptEx的，并配有配套的源码。

采用accept方式的流程示意图如下：

采用AcceptEx方式的流程示意图如下：

两个图中最大的相同点是什么？是的，最大的相同点就是主线程无所事事，闲得蛋疼……

为什么呢？因为我们使用了异步的通信机制，这些琐碎重复的事情完全没有必要交给主线程自己来做了，只用在初始化的时候和Worker线程交待好就可以了，用一句话来形容就是，主线程永远也体会不到Worker线程有多忙，而Worker线程也永远体会不到主线程在初始化建立起这个通信框架的时候操了多少的心……

图a中是由 _AcceptThread()负责接入连接，并把连入的Socket和完成端口绑定，另外的多个_WorkerThread()就负责监控完成端口上的情况，一旦有情况了，就取出来处理，如果CPU有多核的话，就可以多个线程轮着来处理完成端口上的信息，很明显效率就提高了。

图b中最明显的区别，也就是AcceptEx和传统的accept之间最大的区别，就是取消了阻塞方式的accept调用，也就是说，AcceptEx也是通过完成端口来异步完成的，所以就取消了专门用于accept连接的线程，用了完成端口来进行异步的AcceptEx调用；然后在检索完成端口队列的Worker函数中，根据用户投递的完成操作的类型，再来找出其中的投递的Accept请求，加以对应的处理。

读者一定会问，这样做的好处在哪里？为什么还要异步的投递AcceptEx连接的操作呢？

首先，我可以很明确的告诉各位，如果短时间内客户端的并发连接请求不是特别多的话，用accept和AcceptEx在性能上来讲是没什么区别的。

按照我们目前主流的PC来讲，如果客户端只进行连接请求，而什么都不做的话，我们的Server只能接收大约3万-4万个左右的并发连接，然后客户端其余的连入请求就只能收到WSAENOBUFS (10055)了，因为系统来不及为新连入的客户端准备资源了。

需要准备什么资源？当然是准备Socket了……虽然我们创建Socket只用一行SOCKET s= socket(…) 这么一行的代码就OK了，但是系统内部建立一个Socket是相当耗费资源的，因为Winsock2是分层的机构体系，创建一个Socket需要到多个Provider之间进行处理，最终形成一个可用的套接字。总之，系统创建一个Socket的开销是相当高的，所以用accept的话，系统可能来不及为更多的并发客户端现场准备Socket了。

而AcceptEx比Accept又强大在哪里呢？是有三点：

(1) 这个好处是最关键的，是因为AcceptEx是在客户端连入之前，就把客户端的Socket建立好了，也就是说，AcceptEx是先建立的Socket，然后才发出的AcceptEx调用，也就是说，在进行客户端的通信之前，无论是否有客户端连入，Socket都是提前建立好了；而不需要像accept是在客户端连入了之后，再现场去花费时间建立Socket。如果各位不清楚是如何实现的，请看后面的实现部分。

(2) 相比accept只能阻塞方式建立一个连入的入口，对于大量的并发客户端来讲，入口实在是有点挤；而AcceptEx可以同时在完成端口上投递多个请求，这样有客户端连入的时候，就非常优雅而且从容不迫的边喝茶边处理连入请求了。

(3) AcceptEx还有一个非常体贴的优点，就是在投递AcceptEx的时候，我们还可以顺便在AcceptEx的同时，收取客户端发来的第一组数据，这个是同时进行的，也就是说，在我们收到AcceptEx完成的通知的时候，我们就已经把这第一组数据接完毕了；但是这也意味着，如果客户端只是连入但是不发送数据的话，我们就不会收到这个AcceptEx完成的通知……这个我们在后面的实现部分，也可以详细看到。

最后，各位要有一个心里准备，相比accept，异步的AcceptEx使用起来要麻烦得多……

五．完成端口的实现详解

又说了一节的废话，终于到了该动手实现的时候了……

这里我把完成端口的详细实现步骤以及会涉及到的函数，按照出现的先后步骤，都和大家详细的说明解释一下，当然，文档中为了让大家便于阅读，这里去掉了其中的错误处理的内容，当然，这些内容在示例代码中是会有的。

【第一步】创建一个完成端口

首先，我们先把完成端口建好再说。

我们正常情况下，我们需要且只需要建立这一个完成端口，代码很简单:

[cpp]view plaincopy 
    
 HANDLE m_hIOCompletionPort = CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 0 );  

呵呵，看到CreateIoCompletionPort()的参数不要奇怪，参数就是一个INVALID，一个NULL，两个0…，说白了就是一个-1，三个0……简直就和什么都没传一样，但是Windows系统内部却是好一顿忙活，把完成端口相关的资源和数据结构都已经定义好了(在后面的原理部分我们会看到，完成端口相关的数据结构大部分都是一些用来协调各种网络I/O的队列)，然后系统会给我们返回一个有意义的HANDLE，只要返回值不是NULL，就说明建立完成端口成功了，就这么简单，不是吗？

有的时候我真的很赞叹Windows API的封装，把很多其实是很复杂的事整得这么简单……

至于里面各个参数的具体含义，我会放到后面的步骤中去讲，反正这里只要知道创建我们唯一的这个完成端口，就只是需要这么几个参数。

但是对于最后一个参数 0，我这里要简单的说两句，这个0可不是一个普通的0，它代表的是NumberOfConcurrentThreads，也就是说，允许应用程序同时执行的线程数量。当然，我们这里为了避免上下文切换，最理想的状态就是每个处理器上只运行一个线程了，所以我们设置为0，就是说有多少个处理器，就允许同时多少个线程运行。

因为比如一台机器只有两个CPU（或者两个核心），如果让系统同时运行的线程多于本机的CPU数量的话，那其实是没有什么意义的事情，因为这样CPU就不得不在多个线程之间执行上下文切换，这会浪费宝贵的CPU周期，反而降低的效率，我们要牢记这个原则。

【第二步】根据系统中CPU核心的数量建立对应的Worker线程

我们前面已经提到，这个Worker线程很重要，是用来具体处理网络请求、具体和客户端通信的线程，而且对于线程数量的设置很有意思，要等于系统中CPU的数量，那么我们就要首先获取系统中CPU的数量，这个是基本功，我就不多说了，代码如下：

[cpp]view plaincopy 
    
 SYSTEM_INFO si;  
 GetSystemInfo(&si);  
   
 int m_nProcessors = si.dwNumberOfProcessors;  

这样我们根据系统中CPU的核心数量来建立对应的线程就好了，下图是在我的 i7 2600k CPU上初始化的情况，因为我的CPU是8核，一共启动了16个Worker线程，如下图所示

啊，等等！各位没发现什么问题么？为什么我8核的CPU却启动了16个线程？这个不是和我们第二步中说的原则自相矛盾了么？

哈哈，有个小秘密忘了告诉各位了，江湖上都流传着这么一个公式，就是：

我们最好是建立CPU核心数量*2那么多的线程，这样更可以充分利用CPU资源，因为完成端口的调度是非常智能的，比如我们的Worker线程有的时候可能会有Sleep()或者WaitForSingleObject()之类的情况，这样同一个CPU核心上的另一个线程就可以代替这个Sleep的线程执行了；因为完成端口的目标是要使得CPU满负荷的工作。

这里也有人说是建立 CPU“核心数量 * 2 +2”个线程，我想这个应该没有什么太大的区别，我就是按照我自己的习惯来了。

然后按照这个数量，来启动这么多个Worker线程就好可以了，接下来我们开始下一个步骤。

什么？Worker线程不会建？

…囧…

Worker线程和普通线程是一样一样一样的啊~~~，代码大致上如下：

[cpp]view plaincopy 
    
 // 根据CPU数量，建立*2的线程  
   m_nThreads = 2 * m_nProcessors;  
  HANDLE* m_phWorkerThreads = new HANDLE[m_nThreads];  
   
  for (int i = 0; i < m_nThreads; i++)  
  {  
      m_phWorkerThreads[i] = ::CreateThread(0, 0, _WorkerThread, …);  
  }  

其中，_WorkerThread是Worker线程的线程函数，线程函数的具体内容我们后面再讲。

【第三步】创建一个用于监听的Socket，绑定到完成端口上，然后开始在指定的端口上监听连接请求

最重要的完成端口建立完毕了，我们就可以利用这个完成端口来进行网络通信了。

首先，我们需要初始化Socket，这里和通常情况下使用Socket初始化的步骤都是一样的，大约就是如下的这么几个过程(详情参照我代码中的LoadSocketLib()和InitializeListenSocket()，这里只是挑出关键部分)：

[cpp]view plaincopy 
    
 // 初始化Socket库  
 WSADATA wsaData;  
 WSAStartup(MAKEWORD(2,2), &wsaData);  
 //初始化Socket  
 struct sockaddr_in ServerAddress;  
 // 这里需要特别注意，如果要使用重叠I/O的话，这里必须要使用WSASocket来初始化Socket  
 // 注意里面有个WSA_FLAG_OVERLAPPED参数  
 SOCKET m_sockListen = WSASocket(AF_INET, SOCK_STREAM, 0, NULL, 0, WSA_FLAG_OVERLAPPED);  
 // 填充地址结构信息  
 ZeroMemory((char *)&ServerAddress, sizeof(ServerAddress));  
 ServerAddress.sin_family = AF_INET;  
 // 这里可以选择绑定任何一个可用的地址，或者是自己指定的一个IP地址   
 //ServerAddress.sin_addr.s_addr = htonl(INADDR_ANY);                        
 ServerAddress.sin_addr.s_addr = inet_addr(“你的IP”);           
 ServerAddress.sin_port = htons(11111);                            
 // 绑定端口  
 if (SOCKET_ERROR == bind(m_sockListen, (struct sockaddr *) &ServerAddress, sizeof(ServerAddress)))   
 // 开始监听  
 listen(m_sockListen,SOMAXCONN))  

需要注意的地方有两点：

(1) 想要使用重叠I/O的话，初始化Socket的时候一定要使用WSASocket并带上WSA_FLAG_OVERLAPPED参数才可以(只有在服务器端需要这么做，在客户端是不需要的)；

(2) 注意到listen函数后面用的那个常量SOMAXCONN了吗？这个是在微软在WinSock2.h中定义的，并且还附赠了一条注释，Maximum queue length specifiable by listen.，所以说，不用白不用咯^_^

接下来有一个非常重要的动作：既然我们要使用完成端口来帮我们进行监听工作，那么我们一定要把这个监听Socket和完成端口绑定才可以的吧：

如何绑定呢？同样很简单，用 CreateIoCompletionPort()函数。

等等！大家没觉得这个函数很眼熟么？是的，这个和前面那个创建完成端口用的居然是同一个API！但是这里这个API可不是用来建立完成端口的，而是用于将Socket和以前创建的那个完成端口绑定的，大家可要看准了，不要被迷惑了，因为他们的参数是明显不一样的，前面那个的参数是一个-1，三个0，太好记了…

说实话，我感觉微软应该把这两个函数分开，弄个 CreateNewCompletionPort() 多好呢？

这里在详细讲解一下CreateIoCompletionPort()的几个参数：

[cpp]view plaincopy 
    
  HANDLE WINAPI CreateIoCompletionPort(  
     __in      HANDLE  FileHandle,             // 这里当然是连入的这个套接字句柄了  
      __in_opt  HANDLE  ExistingCompletionPort, // 这个就是前面创建的那个完成端口  
      __in      ULONG_PTR CompletionKey,        // 这个参数就是类似于线程参数一样，在  
                                                // 绑定的时候把自己定义的结构体指针传递  
                                                // 这样到了Worker线程中，也可以使用这个  
                                                // 结构体的数据了，相当于参数的传递  
      __in      DWORD NumberOfConcurrentThreads // 这里同样置0  
 );  

这些参数也没什么好讲的吧，用处一目了然了。而对于其中的那个CompletionKey，我们后面会详细提到。

到此才算是Socket全部初始化完毕了。

初始化Socket完毕之后，就可以在这个Socket上投递AcceptEx请求了。

【第四步】在这个监听Socket上投递AcceptEx请求

这里的处理比较复杂。

这个AcceptEx比较特别，而且这个是微软专门在Windows操作系统里面提供的扩展函数，也就是说这个不是Winsock2标准里面提供的，是微软为了方便咱们使用重叠I/O机制，额外提供的一些函数，所以在使用之前也还是需要进行些准备工作。

微软的实现是通过mswsock.dll中提供的，所以我们可以通过静态链接mswsock.lib来使用AcceptEx。但是这是一个不推荐的方式，我们应该用WSAIoctl 配合SIO_GET_EXTENSION_FUNCTION_POINTER参数来获取函数的指针，然后再调用AcceptEx。

这是为什么呢？因为我们在未取得函数指针的情况下就调用AcceptEx的开销是很大的，因为AcceptEx 实际上是存在于Winsock2结构体系之外的(因为是微软另外提供的)，所以如果我们直接调用AcceptEx的话，首先我们的代码就只能在微软的平台上用了，没有办法在其他平台上调用到该平台提供的AcceptEx的版本(如果有的话)，而且更糟糕的是，我们每次调用AcceptEx时，Service Provider都得要通过WSAIoctl()获取一次该函数指针，效率太低了，所以还不如我们自己直接在代码中直接去这么获取一下指针好了。

获取AcceptEx函数指针的代码大致如下：

[cpp]view plaincopy 
    
         
        LPFN_ACCEPTEX     m_lpfnAcceptEx;         // AcceptEx函数指针  
         GUID GuidAcceptEx = WSAID_ACCEPTEX;        // GUID，这个是识别AcceptEx函数必须的  
 DWORD dwBytes = 0;    
   
 WSAIoctl(  
     m_pListenContext->m_Socket,   
     SIO_GET_EXTENSION_FUNCTION_POINTER,   
     &GuidAcceptEx,   
     sizeof(GuidAcceptEx),   
     &m_lpfnAcceptEx,   
     sizeof(m_lpfnAcceptEx),   
     &dwBytes,   
     NULL,   
     NULL);  

具体实现就没什么可说的了，因为都是固定的套路，那个GUID是微软给定义好的，直接拿过来用就行了，WSAIoctl()就是通过这个找到AcceptEx的地址的，另外需要注意的是，通过WSAIoctl获取AcceptEx函数指针时，只需要随便传递给WSAIoctl()一个有效的SOCKET即可，该Socket的类型不会影响获取的AcceptEx函数指针。

然后，我们就可以通过其中的指针m_lpfnAcceptEx调用AcceptEx函数了。

AcceptEx函数的定义如下：

[cpp]view plaincopy 
    
 BOOL AcceptEx (       
                SOCKET sListenSocket,   
                SOCKET sAcceptSocket,   
                PVOID lpOutputBuffer,   
                DWORD dwReceiveDataLength,   
                DWORD dwLocalAddressLength,   
                DWORD dwRemoteAddressLength,   
                LPDWORD lpdwBytesReceived,   
                LPOVERLAPPED lpOverlapped   
 );  

乍一看起来参数很多，但是实际用起来也很简单：

参数1--sListenSocket, 这个就是那个唯一的用来监听的Socket了，没什么说的；
参数2--sAcceptSocket, 用于接受连接的socket，这个就是那个需要我们事先建好的，等有客户端连接进来直接把这个Socket拿给它用的那个，是AcceptEx高性能的关键所在。
参数3--lpOutputBuffer,接收缓冲区，这也是AcceptEx比较有特色的地方，既然AcceptEx不是普通的accpet函数，那么这个缓冲区也不是普通的缓冲区，这个缓冲区包含了三个信息：一是客户端发来的第一组数据，二是server的地址，三是client地址，都是精华啊…但是读取起来就会很麻烦，不过后面有一个更好的解决方案。
参数4--dwReceiveDataLength，前面那个参数lpOutputBuffer中用于存放数据的空间大小。如果此参数=0，则Accept时将不会待数据到来，而直接返回，如果此参数不为0，那么一定得等接收到数据了才会返回…… 所以通常当需要Accept接收数据时，就需要将该参数设成为：sizeof(lpOutputBuffer) - 2*(sizeof sockaddr_in +16)，也就是说总长度减去两个地址空间的长度就是了，看起来复杂，其实想明白了也没啥……
参数5--dwLocalAddressLength，存放本地址地址信息的空间大小；
参数6--dwRemoteAddressLength，存放本远端地址信息的空间大小；
参数7--lpdwBytesReceived，out参数，对我们来说没用，不用管；
参数8--lpOverlapped，本次重叠I/O所要用到的重叠结构。

这里面的参数倒是没什么，看起来复杂，但是咱们依旧可以一个一个传进去，然后在对应的IO操作完成之后，这些参数Windows内核自然就会帮咱们填满了。

但是非常悲催的是，我们这个是异步操作，我们是在线程启动的地方投递的这个操作，等我们再次见到这些个变量的时候，就已经是在Worker线程内部了，因为Windows会直接把操作完成的结果传递到Worker线程里，这样咱们在启动的时候投递了那么多的IO请求，这从Worker线程传回来的这些结果，到底是对应着哪个IO请求的呢？。。。。

聪明的你肯定想到了，是的，Windows内核也帮我们想到了：用一个标志来绑定每一个IO操作，这样到了Worker线程内部的时候，收到网络操作完成的通知之后，再通过这个标志来找出这组返回的数据到底对应的是哪个Io操作的。

这里的标志就是如下这样的结构体：

[cpp]view plaincopy 
    
    
 typedef struct _PER_IO_CONTEXT{  
   OVERLAPPED   m_Overlapped;          // 每一个重叠I/O网络操作都要有一个                
    SOCKET       m_sockAccept;          // 这个I/O操作所使用的Socket，每个连接的都是一样的  
    WSABUF       m_wsaBuf;              // 存储数据的缓冲区，用来给重叠操作传递参数的，关于WSABUF后面还会讲  
    char         m_szBuffer[MAX_BUFFER_LEN]; // 对应WSABUF里的缓冲区  
    OPERATION_TYPE  m_OpType;               // 标志这个重叠I/O操作是做什么的，例如Accept/Recv等  
   
  } PER_IO_CONTEXT, *PPER_IO_CONTEXT;  

这个结构体的成员当然是我们随便定义的，里面的成员你可以随意修改(除了OVERLAPPED那个之外……)。

但是AcceptEx不是普通的accept，buffer不是普通的buffer，那么这个结构体当然也不能是普通的结构体了……

在完成端口的世界里，这个结构体有个专属的名字“单IO数据”，是什么意思呢？也就是说每一个重叠I/O都要对应的这么一组参数，至于这个结构体怎么定义无所谓，而且这个结构体也不是必须要定义的，但是没它……还真是不行，我们可以把它理解为线程参数，就好比你使用线程的时候，线程参数也不是必须的，但是不传还真是不行……

除此以外，我们也还会想到，既然每一个I/O操作都有对应的PER_IO_CONTEXT结构体，而在每一个Socket上，我们会投递多个I/O请求的，例如我们就可以在监听Socket上投递多个AcceptEx请求，所以同样的，我们也还需要一个“单句柄数据”来管理这个句柄上所有的I/O请求，这里的“句柄”当然就是指的Socket了，我在代码中是这样定义的：

[cpp]view plaincopy 
    
      
 typedef struct _PER_SOCKET_CONTEXT  
 {    
   SOCKET                   m_Socket;              // 每一个客户端连接的Socket  
   SOCKADDR_IN              m_ClientAddr;          // 这个客户端的地址  
   CArray<_PER_IO_CONTEXT*>  m_arrayIoContext;   // 数组，所有客户端IO操作的参数，  
                                                         // 也就是说对于每一个客户端Socket  
                                                       // 是可以在上面同时投递多个IO请求的  
 } PER_SOCKET_CONTEXT, *PPER_SOCKET_CONTEXT;  

这也是比较好理解的，也就是说我们需要在一个Socket句柄上，管理在这个Socket上投递的每一个IO请求的_PER_IO_CONTEXT。

当然，同样的，各位对于这些也可以按照自己的想法来随便定义，只要能起到管理每一个IO请求上需要传递的网络参数的目的就好了，关键就是需要跟踪这些参数的状态，在必要的时候释放这些资源，不要造成内存泄漏，因为作为Server总是需要长时间运行的，所以如果有内存泄露的情况那是非常可怕的，一定要杜绝一丝一毫的内存泄漏。

至于具体这两个结构体参数是如何在Worker线程里大发神威的，我们后面再看。

以上就是我们全部的准备工作了，具体的实现各位可以配合我的流程图再看一下示例代码，相信应该会理解得比较快。

完成端口初始化的工作比起其他的模型来讲是要更复杂一些，所以说对于主线程来讲，它总觉得自己付出了很多，总觉得Worker线程是坐享其成，但是Worker自己的苦只有自己明白，Worker线程的工作一点也不比主线程少，相反还要更复杂一些，并且具体的通信工作全部都是Worker线程来完成的，Worker线程反而还觉得主线程是在旁边看热闹，只知道发号施令而已，但是大家终究还是谁也离不开谁，这也就和公司里老板和员工的微妙关系是一样的吧……

【第五步】我们再来看看Worker线程都做了些什么

_Worker线程的工作都是涉及到具体的通信事务问题，主要完成了如下的几个工作，让我们一步一步的来看。

(1) 使用 GetQueuedCompletionStatus() 监控完成端口

首先这个工作所要做的工作大家也能猜到，无非就是几个Worker线程哥几个一起排好队队来监视完成端口的队列中是否有完成的网络操作就好了，代码大体如下：

[cpp]view plaincopy 
    
       
 void *lpContext = NULL;  
 OVERLAPPED        *pOverlapped = NULL;  
 DWORD            dwBytesTransfered = 0;  
   
 BOOL bReturn  =  GetQueuedCompletionStatus(  
                                      pIOCPModel->m_hIOCompletionPort,  
                                          &dwBytesTransfered,  
                              (LPDWORD)&lpContext,  
                              &pOverlapped,  
                              INFINITE );  

各位留意到其中的GetQueuedCompletionStatus()函数了吗？这个就是Worker线程里第一件也是最重要的一件事了，这个函数的作用就是我在前面提到的，会让Worker线程进入不占用CPU的睡眠状态，直到完成端口上出现了需要处理的网络操作或者超出了等待的时间限制为止。

一旦完成端口上出现了已完成的I/O请求，那么等待的线程会被立刻唤醒，然后继续执行后续的代码。

至于这个神奇的函数，原型是这样的：

[cpp]view plaincopy 
    
       
 BOOL WINAPI GetQueuedCompletionStatus(  
     __in   HANDLE          CompletionPort,    // 这个就是我们建立的那个唯一的完成端口  
     __out  LPDWORD         lpNumberOfBytes,   //这个是操作完成后返回的字节数  
     __out  PULONG_PTR      lpCompletionKey,   // 这个是我们建立完成端口的时候绑定的那个自定义结构体参数  
     __out  LPOVERLAPPED    *lpOverlapped,     // 这个是我们在连入Socket的时候一起建立的那个重叠结构  
     __in   DWORD           dwMilliseconds     // 等待完成端口的超时时间，如果线程不需要做其他的事情，那就INFINITE就行了  
     );  

所以，如果这个函数突然返回了，那就说明有需要处理的网络操作了 --- 当然，在没有出现错误的情况下。

然后switch()一下，根据需要处理的操作类型，那我们来进行相应的处理。

但是如何知道操作是什么类型的呢？这就需要用到从外部传递进来的loContext参数，也就是我们封装的那个参数结构体，这个参数结构体里面会带有我们一开始投递这个操作的时候设置的操作类型，然后我们根据这个操作再来进行对应的处理。

但是还有问题，这个参数究竟是从哪里传进来的呢？传进来的时候内容都有些什么？

这个问题问得好！

首先，我们要知道两个关键点：

(1) 这个参数，是在你绑定Socket到一个完成端口的时候，用的CreateIoCompletionPort()函数，传入的那个CompletionKey参数，要是忘了的话，就翻到文档的“第三步”看看相关的内容；我们在这里传入的是定义的PER_SOCKET_CONTEXT，也就是说“单句柄数据”，因为我们绑定的是一个Socket，这里自然也就需要传入Socket相关的上下文，你是怎么传过去的，这里收到的就会是什么样子，也就是说这个lpCompletionKey就是我们的PER_SOCKET_CONTEXT，直接把里面的数据拿出来用就可以了。

(2) 另外还有一个很神奇的地方，里面的那个lpOverlapped参数，里面就带有我们的PER_IO_CONTEXT。这个参数是从哪里来的呢？我们去看看前面投递AcceptEx请求的时候，是不是传了一个重叠参数进去？这里就是它了，并且，我们可以使用一个很神奇的宏，把和它存储在一起的其他的变量，全部都读取出来，例如：

[cpp]view plaincopy 
    
 PER_IO_CONTEXT* pIoContext = CONTAINING_RECORD(lpOverlapped, PER_IO_CONTEXT, m_Overlapped);  

这个宏的含义，就是去传入的lpOverlapped变量里，找到和结构体中PER_IO_CONTEXT中m_Overlapped成员相关的数据。

你仔细想想，其实真的很神奇……

但是要做到这种神奇的效果，应该确保我们在结构体PER_IO_CONTEXT定义的时候，把Overlapped变量，定义为结构体中的第一个成员。

只要各位能弄清楚这个GetQueuedCompletionStatus()中各种奇怪的参数，那我们就离成功不远了。

既然我们可以获得PER_IO_CONTEXT结构体，那么我们就自然可以根据其中的m_OpType参数，得知这次收到的这个完成通知，是关于哪个Socket上的哪个I/O操作的，这样就分别进行对应处理就好了。

在我的示例代码里，在有AcceptEx请求完成的时候，我是执行的_DoAccept()函数，在有WSARecv请求完成的时候，执行的是_DoRecv()函数，下面我就分别讲解一下这两个函数的执行流程。

【第六步】当收到Accept通知时 _DoAccept()

在用户收到AcceptEx的完成通知时，需要后续代码并不多，但却是逻辑最为混乱，最容易出错的地方，这也是很多用户为什么宁愿用效率低下的accept()也不愿意去用AcceptEx的原因吧。

和普通的Socket通讯方式一样，在有客户端连入的时候，我们需要做三件事情：

(1) 为这个新连入的连接分配一个Socket；

(2) 在这个Socket上投递第一个异步的发送/接收请求；

(3) 继续监听。

其实都是一些很简单的事情但是由于“单句柄数据”和“单IO数据”的加入，事情就变得比较乱。因为是这样的，让我们一起缕一缕啊，最好是配合代码一起看，否则太抽象了……

(1) 首先，_Worker线程通过GetQueuedCompletionStatus()里会收到一个lpCompletionKey，这个也就是PER_SOCKET_CONTEXT，里面保存了与这个I/O相关的Socket和Overlapped还有客户端发来的第一组数据等等，对吧？但是这里得注意，这个SOCKET的上下文数据，是关于监听Socket的，而不是新连入的这个客户端Socket的，千万别弄混了……

(2) 所以，AcceptEx不是给咱们新连入的这个Socket早就建好了一个Socket吗？所以这里，我们需要再用这个新Socket重新为新客户端建立一个PER_SOCKET_CONTEXT，以及下面一系列的新PER_IO_CONTEXT，千万不要去动传入的这个Listen Socket上的PER_SOCKET_CONTEXT，也不要用传入的这个Overlapped信息，因为这个是属于AcceptEx I/O操作的，也不是属于你投递的那个Recv I/O操作的……，要不你下次继续监听的时候就悲剧了……

(3) 等到新的Socket准备完毕了，我们就赶紧还是用传入的这个Listen Socket上的PER_SOCKET_CONTEXT和PER_IO_CONTEXT去继续投递下一个AcceptEx，循环起来，留在这里太危险了，早晚得被人给改了……

(4) 而我们新的Socket的上下文数据和I/O操作数据都准备好了之后，我们要做两件事情：一件事情是把这个新的Socket和我们唯一的那个完成端口绑定，这个就不用细说了，和前面绑定监听Socket是一样的；然后就是在这个Socket上投递第一个I/O操作请求，在我的示例代码里投递的是WSARecv()。因为后续的WSARecv，就不是在这里投递的了，这里只负责第一个请求。

但是，至于WSARecv请求如何来投递的，我们放到下一节中去讲，这一节，我们还有一个很重要的事情，我得给大家提一下，就是在客户端连入的时候，我们如何来获取客户端的连入地址信息。

这里我们还需要引入另外一个很高端的函数，GetAcceptExSockAddrs()，它和AcceptEx()一样，都是微软提供的扩展函数，所以同样需要通过下面的方式来导入才可以使用……

[cpp]view plaincopy 
    
 WSAIoctl(  
     m_pListenContext->m_Socket,   
     SIO_GET_EXTENSION_FUNCTION_POINTER,   
     &GuidGetAcceptExSockAddrs,  
     sizeof(GuidGetAcceptExSockAddrs),   
     &m_lpfnGetAcceptExSockAddrs,   
     sizeof(m_lpfnGetAcceptExSockAddrs),     
     &dwBytes,   
     NULL,   
     NULL);  

和导出AcceptEx一样一样的，同样是需要用其GUID来获取对应的函数指针 m_lpfnGetAcceptExSockAddrs 。

说了这么多，这个函数究竟是干嘛用的呢？它是名副其实的“AcceptEx之友”，为什么这么说呢？因为我前面提起过AcceptEx有个很神奇的功能，就是附带一个神奇的缓冲区，这个缓冲区厉害了，包括了客户端发来的第一组数据、本地的地址信息、客户端的地址信息，三合一啊，你说神奇不神奇？

这个函数从它字面上的意思也基本可以看得出来，就是用来解码这个缓冲区的，是的，它不提供别的任何功能，就是专门用来解析AcceptEx缓冲区内容的。例如如下代码：

[cpp]view plaincopy 
    
            
 PER_IO_CONTEXT* pIoContext = 本次通信用的I/O Context  
   
 SOCKADDR_IN* ClientAddr = NULL;  
 SOCKADDR_IN* LocalAddr = NULL;    
 int remoteLen = sizeof(SOCKADDR_IN), localLen = sizeof(SOCKADDR_IN);    
   
 m_lpfnGetAcceptExSockAddrs(pIoContext->m_wsaBuf.buf, pIoContext->m_wsaBuf.len - ((sizeof(SOCKADDR_IN)+16)*2),  sizeof(SOCKADDR_IN)+16, sizeof(SOCKADDR_IN)+16, (LPSOCKADDR*)&LocalAddr, &localLen, (LPSOCKADDR*)&ClientAddr, &remoteLen);  

解码完毕之后，于是，我们就可以从如下的结构体指针中获得很多有趣的地址信息了：

inet_ntoa(ClientAddr->sin_addr) 是客户端IP地址

ntohs(ClientAddr->sin_port) 是客户端连入的端口

inet_ntoa(LocalAddr ->sin_addr) 是本地IP地址

ntohs(LocalAddr ->sin_port) 是本地通讯的端口

pIoContext->m_wsaBuf.buf 是存储客户端发来第一组数据的缓冲区

自从用了“AcceptEx之友”，一切都清净了….

【第七步】当收到Recv通知时, _DoRecv()

在讲解如何处理Recv请求之前，我们还是先讲一下如何投递WSARecv请求的。

WSARecv大体的代码如下，其实就一行，在代码中我们可以很清楚的看到我们用到了很多新建的PerIoContext的参数，这里再强调一下，注意一定要是自己另外新建的啊，一定不能是Worker线程里传入的那个PerIoContext，因为那个是监听Socket的，别给人弄坏了……：

[cpp]view plaincopy 
    
 int nBytesRecv = WSARecv(pIoContext->m_Socket, pIoContext ->p_wbuf, 1, &dwBytes, 0, pIoContext->p_ol, NULL);  

这里，我再把WSARev函数的原型再给各位讲一下

[cpp]view plaincopy 
    
       
 int WSARecv(  
     SOCKET s,                      // 当然是投递这个操作的套接字  
      LPWSABUF lpBuffers,            // 接收缓冲区   
                                         // 这里需要一个由WSABUF结构构成的数组  
      DWORD dwBufferCount,           // 数组中WSABUF结构的数量，设置为1即可  
      LPDWORD lpNumberOfBytesRecvd,  // 如果接收操作立即完成，这里会返回函数调用所接收到的字节数  
      LPDWORD lpFlags,               // 说来话长了，我们这里设置为0 即可  
      LPWSAOVERLAPPED lpOverlapped,  // 这个Socket对应的重叠结构  
      NULL                           // 这个参数只有完成例程模式才会用到，  
                                         // 完成端口中我们设置为NULL即可  
 );  

其实里面的参数，如果你们熟悉或者看过我以前的重叠I/O的文章，应该都比较熟悉，只需要注意其中的两个参数：

LPWSABUF lpBuffers;

这里是需要我们自己new 一个 WSABUF 的结构体传进去的；

如果你们非要追问 WSABUF 结构体是个什么东东？我就给各位多说两句，就是在ws2def.h中有定义的，定义如下：

[cpp]view plaincopy 
    
          
 typedef struct _WSABUF {  
                ULONG len; /* the length of the buffer */  
                __field_bcount(len) CHAR FAR *buf; /* the pointer to the buffer */  
   
         } WSABUF, FAR * LPWSABUF;  

而且好心的微软还附赠了注释，真不容易….

看到了吗？如果对于里面的一些奇怪符号你们看不懂的话，也不用管他，只用看到一个ULONG和一个CHAR*就可以了，这不就是一个是缓冲区长度，一个是缓冲区指针么？至于那个什么 FAR…..让他见鬼去吧，现在已经是32位和64位时代了……

这里需要注意的，我们的应用程序接到数据到达的通知的时候，其实数据已经被咱们的主机接收下来了，我们直接通过这个WSABUF指针去系统缓冲区拿数据就好了，而不像那些没用重叠I/O的模型，接收到有数据到达的通知的时候还得自己去另外recv，太低端了……这也是为什么重叠I/O比其他的I/O性能要好的原因之一。

LPWSAOVERLAPPED lpOverlapped

这个参数就是我们所谓的重叠结构了，就是这样定义，然后在有Socket连接进来的时候，生成并初始化一下，然后在投递第一个完成请求的时候，作为参数传递进去就可以，

[cpp]view plaincopy 
    
 OVERLAPPED* m_pol = new OVERLAPPED;  
   
 ZeroMemory(m_pol, sizeof(OVERLAPPED));  

在第一个重叠请求完毕之后，我们的这个OVERLAPPED 结构体里，就会被分配有效的系统参数了，并且我们是需要每一个Socket上的每一个I/O操作类型，都要有一个唯一的Overlapped结构去标识。

这样，投递一个WSARecv就讲完了，至于_DoRecv()需要做些什么呢？其实就是做两件事：

(1) 把WSARecv里这个缓冲区里收到的数据显示出来；

(2) 发出下一个WSARecv()；

Over……

至此，我们终于深深的喘口气了，完成端口的大部分工作我们也完成了，也非常感谢各位耐心的看我这么枯燥的文字一直看到这里，真是一个不容易的事情！！

【第八步】如何关闭完成端口

休息完毕，我们继续……

各位看官不要高兴得太早，虽然我们已经让我们的完成端口顺利运作起来了，但是在退出的时候如何释放资源咱们也是要知道的，否则岂不是功亏一篑…..

从前面的章节中，我们已经了解到，Worker线程一旦进入了GetQueuedCompletionStatus()的阶段，就会进入睡眠状态，INFINITE的等待完成端口中，如果完成端口上一直都没有已经完成的I/O请求，那么这些线程将无法被唤醒，这也意味着线程没法正常退出。

熟悉或者不熟悉多线程编程的朋友，都应该知道，如果在线程睡眠的时候，简单粗暴的就把线程关闭掉的话，那是会一个很可怕的事情，因为很多线程体内很多资源都来不及释放掉，无论是这些资源最后是否会被操作系统回收，我们作为一个C++程序员来讲，都不应该允许这样的事情出现。

所以我们必须得有一个很优雅的，让线程自己退出的办法。

这时会用到我们这次见到的与完成端口有关的最后一个API，叫 PostQueuedCompletionStatus()，从名字上也能看得出来，这个是和 GetQueuedCompletionStatus() 函数相对的，这个函数的用途就是可以让我们手动的添加一个完成端口I/O操作，这样处于睡眠等待的状态的线程就会有一个被唤醒，如果为我们每一个Worker线程都调用一次PostQueuedCompletionStatus()的话，那么所有的线程也就会因此而被唤醒了。

PostQueuedCompletionStatus()函数的原型是这样定义的：

[cpp]view plaincopy 
    
 BOOL WINAPI PostQueuedCompletionStatus(  
                    __in      HANDLE CompletionPort,  
                    __in      DWORD dwNumberOfBytesTransferred,  
                    __in      ULONG_PTR dwCompletionKey,  
                    __in_opt  LPOVERLAPPED lpOverlapped  
 );  

我们可以看到，这个函数的参数几乎和GetQueuedCompletionStatus()的一模一样，都是需要把我们建立的完成端口传进去，然后后面的三个参数是传输字节数、结构体参数、重叠结构的指针.

注意，这里也有一个很神奇的事情，正常情况下，GetQueuedCompletionStatus()获取回来的参数本来是应该是系统帮我们填充的，或者是在绑定完成端口时就有的，但是我们这里却可以直接使用PostQueuedCompletionStatus()直接将后面三个参数传递给GetQueuedCompletionStatus()，这样就非常方便了。

例如，我们为了能够实现通知线程退出的效果，可以自己定义一些约定，比如把这后面三个参数设置一个特殊的值，然后Worker线程接收到完成通知之后，通过判断这3个参数中是否出现了特殊的值，来决定是否是应该退出线程了。

例如我们在调用的时候，就可以这样：

[cpp]view plaincopy 
    
 for (int i = 0; i < m_nThreads; i++)  
 {  
       PostQueuedCompletionStatus(m_hIOCompletionPort, 0, (DWORD) NULL, NULL);  
 }  

为每一个线程都发送一个完成端口数据包，有几个线程就发送几遍，把其中的dwCompletionKey参数设置为NULL，这样每一个Worker线程在接收到这个完成通知的时候，再自己判断一下这个参数是否被设置成了NULL，因为正常情况下，这个参数总是会有一个非NULL的指针传入进来的，如果Worker发现这个参数被设置成了NULL，那么Worker线程就会知道，这是应用程序再向Worker线程发送的退出指令，这样Worker线程在内部就可以自己很“优雅”的退出了……

学会了吗？

但是这里有一个很明显的问题，聪明的朋友一定想到了，而且只有想到了这个问题的人，才算是真正看明白了这个方法。

我们只是发送了m_nThreads次，我们如何能确保每一个Worker线程正好就收到一个，然后所有的线程都正好退出呢？是的，我们没有办法保证，所以很有可能一个Worker线程处理完一个完成请求之后，发生了某些事情，结果又再次去循环接收下一个完成请求了，这样就会造成有的Worker线程没有办法接收到我们发出的退出通知。

所以，我们在退出的时候，一定要确保Worker线程只调用一次GetQueuedCompletionStatus()，这就需要我们自己想办法了，各位请参考我在Worker线程中实现的代码，我搭配了一个退出的Event，在退出的时候SetEvent一下，来确保Worker线程每次就只会调用一轮 GetQueuedCompletionStatus() ，这样就应该比较安全了。

另外，在Vista/Win7系统中，我们还有一个更简单的方式，我们可以直接CloseHandle关掉完成端口的句柄，这样所有在GetQueuedCompletionStatus()的线程都会被唤醒，并且返回FALSE，这时调用GetLastError()获取错误码时，会返回ERROR_INVALID_HANDLE，这样每一个Worker线程就可以通过这种方式轻松简单的知道自己该退出了。当然，如果我们不能保证我们的应用程序只在Vista/Win7中，那还是老老实实的PostQueuedCompletionStatus()吧。

最后，在系统释放资源的最后阶段，切记，因为完成端口同样也是一个Handle，所以也得用CloseHandle将这个句柄关闭，当然还要记得用closesocket关闭一系列的socket，还有别的各种指针什么的，这都是作为一个合格的C++程序员的基本功，在这里就不多说了，如果还是有不太清楚的朋友，请参考我的示例代码中的 StopListen() 和DeInitialize() 函数。

六．完成端口使用中的注意事项

终于到了文章的结尾了，不知道各位朋友是基本学会了完成端口的使用了呢，还是被完成端口以及我这么多口水的文章折磨得不行了……

最后再补充一些前面没有提到了，实际应用中的一些注意事项吧。

1. Socket的通信缓冲区设置成多大合适？

在x86的体系中，内存页面是以4KB为单位来锁定的，也就是说，就算是你投递WSARecv()的时候只用了1KB大小的缓冲区，系统还是得给你分4KB的内存。为了避免这种浪费，最好是把发送和接收数据的缓冲区直接设置成4KB的倍数。

2. 关于完成端口通知的次序问题

这个不用想也能知道，调用GetQueuedCompletionStatus() 获取I/O完成端口请求的时候，肯定是用先入先出的方式来进行的。

但是，咱们大家可能都想不到的是，唤醒那些调用了GetQueuedCompletionStatus()的线程是以后入先出的方式来进行的。

比如有4个线程在等待，如果出现了一个已经完成的I/O项，那么是最后一个调用GetQueuedCompletionStatus()的线程会被唤醒。平常这个次序倒是不重要，但是在对数据包顺序有要求的时候，比如传送大块数据的时候，是需要注意下这个先后次序的。

-- 微软之所以这么做，那当然是有道理的，这样如果反复只有一个I/O操作而不是多个操作完成的话，内核就只需要唤醒同一个线程就可以了，而不需要轮着唤醒多个线程，节约了资源，而且可以把其他长时间睡眠的线程换出内存，提到资源利用率。

3. 如果各位想要传输文件…

如果各位需要使用完成端口来传送文件的话，这里有个非常需要注意的地方。因为发送文件的做法，按照正常人的思路来讲，都会是先打开一个文件，然后不断的循环调用ReadFile()读取一块之后，然后再调用WSASend ()去发发送。

但是我们知道，ReadFile()的时候，是需要操作系统通过磁盘的驱动程序，到实际的物理硬盘上去读取文件的，这就会使得操作系统从用户态转换到内核态去调用驱动程序，然后再把读取的结果返回至用户态；同样的道理，WSARecv()也会涉及到从用户态到内核态切换的问题 --- 这样就使得我们不得不频繁的在用户态到内核态之间转换，效率低下……

而一个非常好的解决方案是使用微软提供的扩展函数TransmitFile()来传输文件，因为只需要传递给TransmitFile()一个文件的句柄和需要传输的字节数，程序就会整个切换至内核态，无论是读取数据还是发送文件，都是直接在内核态中执行的，直到文件传输完毕才会返回至用户态给主进程发送通知。这样效率就高多了。

4. 关于重叠结构数据释放的问题

我们既然使用的是异步通讯的方式，就得要习惯一点，就是我们投递出去的完成请求，不知道什么时候我们才能收到操作完成的通知，而在这段等待通知的时间，我们就得要千万注意得保证我们投递请求的时候所使用的变量在此期间都得是有效的。

例如我们发送WSARecv请求时候所使用的Overlapped变量，因为在操作完成的时候，这个结构里面会保存很多很重要的数据，对于设备驱动程序来讲，指示保存着我们这个Overlapped变量的指针，而在操作完成之后，驱动程序会将Buffer的指针、已经传输的字节数、错误码等等信息都写入到我们传递给它的那个Overlapped指针中去。如果我们已经不小心把Overlapped释放了，或者是又交给别的操作使用了的话，谁知道驱动程序会把这些东西写到哪里去呢？岂不是很崩溃……

暂时我想到的问题就是这么多吧，如果各位真的是要正儿八经写一个承受很大访问压力的Server的话，你慢慢就会发现，只用我附带的这个示例代码是不够的，还得需要在很多细节之处进行改进，例如用更好的数据结构来管理上下文数据，并且需要非常完善的异常处理机制等等，总之，非常期待大家的批评和指正。

谢谢大家看到这里！！！

转自：http://blog.csdn.net/piggyxp/article/details/6922277

liu5320102

关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
select epoll 完成端口

select、poll、epoll之间的区别总结[整理]　　select，poll，epoll都是IO多路复用的机制。I/O多路复用就通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/
复制链接

扫一扫