关于IO 完成端口的一些困惑

最新推荐文章于 2025-03-10 22:02:03 发布

lxj434368832

最新推荐文章于 2025-03-10 22:02:03 发布

阅读量415

点赞数

分类专栏： C++ 网络

C++ 同时被 2 个专栏收录

56 篇文章

订阅专栏

网络

5 篇文章

订阅专栏

如何处理完成端口模型(IOCP)的超时问题.
作者: 阙荣文 2011/7/12

前言
完成端口(IOCP)是所有Windows I/O模型中最复杂,也是性能最好的一种.在关于IOCP的编程中,难点之一就是超时控制.
以下以HTTP服务器程序为例说一说.

其实超时控制也不是很难,问题是Windows的IOCP模型本身并没有提供关于超时的支持(也行以后的版本会有?),所以一切都要有程序员来完成.并且超时控制对于服务器程序来说是必须的: HTTP服务器程序对一个新的客户端连接需要在完成端口上投递一个 WSARecv() 操作,以接收客户端的请求,如果这个客户端连接一直不发送数据(所谓的恶意连接)那么投递的这个请求永远不会从完成端口队列中返回,占用了服务器资源.如果有大量的恶意连接,服务很快就会不堪重负.所以服务器程序必须为投递给完成端口的请求设置一个超时时间.

那么如何做超时控制呢?

一般有两种思路:
1. 创建一个单独的线程,每隔一段时间,轮询一次所有的I/O请求队列,发现有超时则取消这个I/O投递请求.
优点:
简单,一个线程,一个循环就可以了.

缺点:
精度和效率难以两全.比如设定的超时时间为60秒,如果每60秒轮询一次所有套接字,那么有可能出现 (60 - 1 + 60)秒后才被检测到的超时;而如果提高轮询频率,那么性能又会受到影响:轮询时,肯定要对套接字队列加锁.所以设置恰当的轮询间隔是个两难的选择.另外,有些程序采用 min heap 最小堆算法对轮询进行优化可以进一步提高效率.

为每一个I/O投递请求单独设定一个定时器.
优点:
精度高, Windows定时器大致能保证15毫秒左右的精度.

缺点:
资源消耗大,很明显如果有大量的连接,就需要同样数量的定时器.幸好,针对需要大量定时器的应用,Windows提供了 Timer Queue,相对于SetTimer()创建的定时器对象,用CreateTimerQueueTimer()创建的是经过优化的轻量级的对象,并且系统内部对Timer Queue也有优化,比如用线程池内的线程执行超时回调函数等.一个进程最多可以创建多少个 TimerQueueTimer也还不清楚,我在MSDN上也没找到相关的说明,这可能成为服务支持的最大连接数的瓶颈.(我在自己机器上(Win7 Home Basic + VS2010)测试过,第一次运行附录3的代码机器几乎失去响应,但是没出错.第二次加了几个条件断点,反正到3万个Timer的时候,超时函数都被执行了,机器响应还很快.所以TimerQueueTimer的数量应该没有限制或者是一个很大的数.没权威资料,还是不确定.)

两种方法都是可以的,具体怎么做还是取决于程序要求.
我在设计Que’s HTTP Server 时,用的是Timer Queue,根据需要,为每个socket都分配了两个TimerQueueTimer,一个设置会话超时(即一个socket最长可以和服务器保持多少时间的连接),一个设定为死连接超时,如果一个连接在指定的时间内,既没有发送数据也没有接收数据,就会被判定为是死连接而被关闭,服务器在每次接收或发送数据成功时,都调用ChangeTimerQueueTimer()重置该定时器.只可惜条件有限,没有在大压力环境下测试过.只在本机上跑过几天(极限200个左右的连接,80MB/s左右的带宽,每秒调用几百次ChangeTimerQueueTimer()重置定时器,超时误差在8到15个毫秒左右,完全可以接受.)

HTTP服务器编程中几个需要注意的点

如果一个IO请求正在处理中,则一定要确保传人的 LPWSAOVERLAPPED 指针的有效性.这是在程序设计时无条件要保证的,否则肯定会崩溃.至于怎么保证这点,是程序员的事,而不是IOCP的问题.要释放LPWSAOVERLAPPED 指向的结构只能等到 I/O 操作从完成端口队列返回之后才可以进行. 即只有在GetQueuedCompletionStatus()返回之后.如果在多个I/O请求中用了同一个 WSAOVERLAPPED 结构,可以设置一个引用计数,每次从GetQueuedCompletionStatus()返回计数减一,到零时可以释放(最好避免这种设计).
如何取消已经投递的I/O请求?
答案是没办法取消.当然,关闭完成端口的句柄可以取消所有的I/O请求,但是这只适用于程序退出时.不过,针对HTTP服务器,关闭套接字,可以使该套接字相关的所有I/O请求都被标记为失败,并从 GetQueuedCompletionStatus() 中返回(返回值不一定为FALSE,详见下节)).这样,只要在超时回调函数中关闭对应的套接字,不释放任何资源,完成端口服务线程就是从 GetQueuedCompletionStatus()返回,在确保这个套接字对应的所有I/O请求都从完成端口队列中清除后,就可以回收资源了(主要是投递请求时传人的 LPWSAOVERLAPPED 指针,现在可以放心大胆的删除了).
2011-12-09更正: 用 CancelIoEx(hSocket, NULL) 可以取消一个套接字的所有未决的I/O操作.当然,如上文说的那样直接关闭套接字句柄也会导致所有未决I/O操作失败从而达到”取消”一样的效果.
GetQueuedCompletionStatus()函数返回值研究(参考MSDN),原型如下:
BOOL WINAPI GetQueuedCompletionStatus(
__in HANDLE CompletionPort,
__out LPDWORD lpNumberOfBytes,
__out PULONG_PTR lpCompletionKey,
__out LPOVERLAPPED *lpOverlapped,
__in DWORD dwMilliseconds
);

(1) 如果I/O操作(WSASend() / WSARecv())成功完成,那么返回值为TRUE,并且 lpNumberOfBytes 为已传送的字节数.注意,已传送的字节数有可能小于你请求发送/接收的字节数.
(2) 如果对方关闭了套接字,那么有两种情况
(a) I/O操作已经完成了一部分,比如WSASend()请求发送1K字节,并且其中的512字节已经发送完成,则返回值为TRUE, lpNumberOfBytes 指向的值为512, lpOverlapped 有效.
(b) I/O操作没有完成,那么返回值为FALSE, lpNumberOfBytes 指向的值为0, lpCompletionKey, lpOverlapped 有效.
(3) 如果我们程序这方主动关闭了套接字,则和(2)的情况一样,没有区别.
(4) 如果发生了其它错误,则返回值为FALSE,并且 lpCompletionKey, lpOverlapped = NULL,在这种情况下,应该调用 GetLastError() 查看错误信息,并且退出等待

GetQueuedCompletionStatus()的循环.

每次调用网络函数(WSARecv(), WSASend()等)都要检查返回值,并作相应处理.网络事件相当复杂,什么情况都有可能出现,只有检测每个函数的返回值,程序才会健壮.

后记
我在学习IOCP的过程中,在网上搜看了很多相关的文章,帖子,挑两篇附在后面,感谢原作者.

附录:1. http://club.itqun.net/showtopic-82514.html
帖子中网友 WinEggDrop 第36楼说的非常清楚,赞同

最后一贴关于这个讨论的,主要是说下我说过的几种方法.顶楼所说的,主要就是一种超时检测机制,很多服务器程序都需要这样的机制,因为太多空闲的连接还是使用一定量的系统资源的,有些服务器,象FTP服务器,有时还限制了最大登陆的连接数,万一有人恶意大量地连接,但这些连接不被系统定时断开的话,那么正常的用户有可能无法登陆FTP服务器(因为连接数到达上限)

1.使用setsockopt设置SO_RCVTIMEO
这种方法简单好用,但缺点是只用于阻塞的socket,而且有时因为对方的非正常断开而无法检测到.

2.在接收数据前使用select(),select()返回可读才调用recv()等API.
这种方法一样简单好用,但缺点还是主要适用于阻塞socket,一般非阻塞socket也可用,只不过要调用个死循环不断地检测select()返回值,很是浪费资源.

3.定时扫描所有客户socket的方法(楼主正采用的方法).这方法就是记录每次每个socket数据通讯时的时间,然后在扫描时再和当前时间比较,如果时间差高于超时机制的限制时间,

就将socket断开.
这种方法使用起来也是很简单的,只要建一个线程定时地扫描所有客户socket列表.适用性很强,所有socket模式都可兼容的.需要注意的是这方法临界要做好,不然是挺容易出现问题(在扫描期间有socket正常的断开时资源被释放时,扫描列表时如果没做临界,那么扫描时就很有可能访问了非法的内存).这方法有个缺点就是超时机制的误差比较高,因为如果超时检测的时间设置为N,那么是有可能出现N-1秒的误差的.设置检测的时间越长,出现的误差时间就越长.由于每次都要扫描所有的客户socket列表,如果socket比较多时,设置这个检测时间就是个”鸡肋”.检测时间设置得过短,频烦的扫描对系统资源和程序性能必然多少有是影响;而设置时间过长,又令误差时间过大.

4.使用系统的Timer
标准的Timer:使用SetTimer()设置Timer,使用KillTimer()删除Timer.优点是适用于所有系统,也适用于所有socket模型.缺点是精确度不高,而且是消息机制的,如果太多消息要处理,Timer触发时间会被延迟.NT系统内核Timer.优点是精确度高,缺点是只能用于NT系统.

所有上面的方法我都在以前写的服务器程序中尝试过,最终我是选用了NT系统内核Timer那种方法.这种方法是不是最高效的,我也不清楚,只是我自己倾向于这方法,自认为是比较高效的方法(事实上是不是高效的,我也无法测试).

附录2. http://blog.sina.com.cn/s/blog_62b4e3ff0100nu84.html
学习笔记：神秘的 IOCP 完成端口
(2010-12-19 15:53:36)
转载
标签：
it

【什么是IOCP】
是WINDOWS系统的一个内核对象。通过此对象，应用程序可以获得异步IO的完成通知。
这里有几个角色：
角色1：异步IO请求者线程。简单的说，就是调用WSAxxx()函数（例如函数WSARecv,WSASend）的某个线程。
由于是“异步”的，当角色1线程看到WSAxxx()函数返回时，它并不能知道本次IO是否真的完成了。
注：当WSAxxx返回成功true时，实际已经读到或发送完数据了（同步的获得IO结果了）。
为了统一逻辑，我们还是要放到角色2线程中，统一处理IO结果。

角色2：异步IO完成事件处理线程。简单的说，就是调用GetQueuedCompletionStatus函数的线程。
角色1投递的某个异步IO请求M，角色2线程一定能获得M的处理结果（无非是IO成功或失败）
角色3：操作系统。负责角色1和角色2的沟通。OS接收角色1的所有异步IO请求。
OS处理（实际的IO读写）排队的很多异步IO请求。OS的程序员是很牛的，他们能最大化利用CPU和网络。
OS把所有IO结果放入{IOCP完成队列C}中。
OS能调度角色2线程的运行和睡眠，能控制角色2线程同时运行的线程个数。
角色2通过GetQueuedCompletionStatus函数，读取到{IOCP完成队列C}中完成的IO请求。

【需要创建几个角色2线程呢】
CreateIoCompletionPort()函数创建一个完成端口，其中有一个参数是NumberOfConcurrentThreads。
这个参数的含义是：程序员期望的同时运行的角色2线程数。0代表默认为本机器的CPU个数。
程序员可以创建任意数量的角色2线程。
例如：NumberOfConcurrentThreads设置为2，而实际创建6个角色2线程，或100个，或0个。

如何理解这两个数的差异呢？
OS努力维持NumberOfConcurrentThreads个线程并发的运行，即使我创建100个角色2线程。
如果{IOCP完成队列C}中排队等待处理的{IO结果项}很少，角色2线程能很快处理完，则实际可能只有1个角色2线程在工作，其他线程都在睡眠（即使NumberOfConcurrentThreads设置成100，也只有一个线程在工作）。
如果{IOCP完成队列C}中排队等待处理的{IO结果项}很多，角色2线程处理需要很多CPU时间，则实际可能会有很多角色2线程会被唤醒工作。当然前提是我实际创建了很多角色2线程。极端情况下，如果角色2线程都退出了，则{IOCP完成队列C}可能会被挤爆了。

为什么一般情况下，NumberOfConcurrentThreads设置为2，而实际创建6个角色2线程呢？
考虑到我们的角色2线程不只是CPU计算，它还可能去读写日志文件，调用Sleep，或访问某个Mutex对象（造成线程被调度为睡眠）。这样，OS会启用一些“后备军”角色2线程去处理{IOCP完成队列C}。所以实际创建6个角色2线程，有几个可能是后备军线程。如果我们的角色2线程是纯CPU密集计算型的（可能有少量的临界区访问，也不会轻易放弃CPU控制权），那么我们只需要实际创建角色2线程数=CPU个数，多创建了也没益处（但也没坏处，可能OS让他们一直都睡眠，做后备军）。

【异步读写如何控制字节数】

或曰，某个WSASend调用，在网络正常的情况下，{实际发送字节数}（简称T）就是{需要发送的字节数}（简称R）。我试验了一下，从1M的buff,2M的buff…当开到很大的buff时，终于出现T