异步IO网络服务器设计(一) IO模型

说到异步IO网络服务器，全国人民都知道：“Windows下用iocp，Linux下用epoll”。无数的高手写过文章来讲IOCP和epoll相关的文章。本人分别使用epoll和iocp开发过网络库，也使用过boost.asio，试归纳如下：

 epoll：

1.通过epoll_ctl向异步IO注册注册（亦可修改、删除）事件与相应的事件处理方法。

2.在IO线程中通过epoll_wait等待异步IO事件就绪，根据就绪的IO事件类型进行相应的Accept、recv、send操作。

3.处理完毕后，重新注册事件并开始新一轮等待。

 iocp：

1.在IO线程中通过GQCS（GetQueuedCompletionStatus）等待在完成队列上。

2.无需关心IO是否就绪，直接通过WSAAccept、WSASend、WSARecv等向异步IO投递接受连接、读、写等操作。

3.在GQCS得到异步操作的完成情况并处理完毕之后，重新开始下一轮等待。

 

以上两种方式也代表了reactor模式和proactor模式。

boost.asio在linux下巧妙的用epoll模拟了proactor，把对异步IO的操作封装成io_service类，通过io_service方便的进行异步IO创建、等待，通过模板函数进行投递/处理事件等操作。并且可以方便的与线程绑定。读过asio之后我立刻采用了类似的方式改写了自己以前的代码，减低了异步IO与IO线程之间的耦合。不过io_service的iocp版本实现中，GQCS指定了超时时间gqcs_timeout为500毫秒。个人认为这样会带来一个问题：若同时有N个线程等待在同一个异步IO上，那么每隔gqcs_timeout单位时间，每一个线程将会因为GQCS超时而被唤醒，产生额外的线程切换。这样会失去IOCP自动减少线程切换带来的高效。