IOCP

完成IO使用总结IOCP（I/O Completion Port，I/O完成端口）是性能最好的一种I/O模型。

它是应用程序使用线程池处理异步I/O请求的一种机制。

在处理多个并发的异步I/O请求时，以往的模型都是在接收请求是创建一个线程来应答请求。

这样就有很多的线程并行地运行在系统中。

而这些线程都是可运行的，Windows内核花费大量的时间在进行线程的上下文切换，并没有多少时间花在线程运行上。

再加上创建新线程的开销比较大，所以造成了效率的低下。

调用的步骤如下:抽象出一个完成端口大概的处理流程：1：创建一个完成端口。

2：创建一个线程A。

3：A线程循环调用GetQueuedCompletionStatus()函数来得到IO操作结果，这个函数是个阻塞函数。

4：主线程循环里调用accept等待客户端连接上来。

5：主线程里accept返回新连接建立以后，把这个新的套接字句柄用CreateIoCompletionPort 关联到完成端口，然后发出一个异步的WSASend或者WSARecv调用，因为是异步函数，WSASend/WSARecv会马上返回，实际的发送或者接收数据的操作由WINDOWS系统去做。

6：主线程继续下一次循环，阻塞在accept这里等待客户端连接。

7：WINDOWS系统完成WSASend或者WSArecv的操作，把结果发到完成端口。

8：A线程里的GetQueuedCompletionStatus()马上返回，并从完成端口取得刚完成的WSASend/WSARecv的结果。

9：在A线程里对这些数据进行处理(如果处理过程很耗时，需要新开线程处理)，然后接着发出WSASend/WSARecv，并继续下一次循环阻塞在GetQueuedCompletionStatus()这里。

归根到底概括完成端口模型一句话：我们不停地发出异步的WSASend/WSARecv IO操作，具体的IO处理过程由WINDOWS系统完成，WINDOWS系统完成实际的IO处理后，把结果送到完成端口上（如果有多个IO 都完成了，那么就在完成端口那里排成一个队列）。

我们在另外一个线程里从完成端口不断地取出IO操作结果，然后根据需要再发出WSASend/WSARecv IO操作。

而IOCP模型是事先开好了N个线程，存储在线程池中，让他们hold。

然后将所有用户的请求都投递到一个完成端口上，然后N个工作线程逐一地从完成端口中取得用户消息并加以处理。

这样就避免了为每个用户开一个线程。

既减少了线程资源，又提高了线程的利用率。

完成端口模型是怎样实现的呢？我们先创建一个完成端口（::CreateIoCompletioPort()）。

然后再创建一个或多个工作线程，并指定他们到这个完成端口上去读取数据。

我们再将远程连接的套接字句柄关联到这个完成端口（还是用::CreateIoCompletionPort()）。

一切就OK了。

工作线程都干些什么呢？首先是调用::GetQueuedCompletionStatus()函数在关联到这个完成端口上的所有套接字上等待I/O的完成。

再判断完成了什么类型的I/O。

一般来说，有三种类型的I/O，OP_ACCEPT，OP_READ和OP_WIRTE。

我们到数据缓冲区内读取数据后，再投递一个或是多个同类型的I/O即可（::AcceptEx()、::WSARecv()、::WSASend()）。

对读取到的数据，我们可以按照自己的需要来进行相应的处理。

为此，我们需要一个以OVERLAPPED（重叠I/O）结构为第一个字段的per-I/O数据自定义结构。

typedef struct _PER_IO_DA TA{OVERLAPPED ol; // 重叠I/O结构char buf[BUFFER_SIZE]; // 数据缓冲区int nOperationType; //I/O操作类型#define OP_READ 1#define OP_WRITE 2#define OP_ACCEPT 3} PER_IO_DA TA, *PPER_IO_DA TA;将一个PER_IO_DA TA结构强制转化成一个OVERLAPPED结构传给::GetQueuedCompletionStatus()函数，返回的这个PER_IO_DA TA结构的的nOperationType 就是I/O操作的类型。

当然，这些类型都是在投递I/O请求时自己设置的。

这样一个IOCP服务器的框架就出来了。

当然，要做一个好的IOCP服务器，还有考虑很多问题，如内存资源管理、接受连接的方法、恶意的客户连接、包的重排序等等。

以上是个人对于IOCP模型的一些理解与看法，还有待完善。

另外各Winsock API的用法参见MSDN。

完成端口中的单句柄数据结构与单IO数据结构的理解与设计完成端口模型，针对于win平台的其它异步网络模型而言，最大的好处，除了性能方面的卓越外，还在于完成端口在传递网络事件的通知时，可以一并传递与此事件相关的应用层数据。

这个应用层数据，体现在两个方面：一是单句柄数据，二是单io数据。

getqueuedcompletionstatus函数的原型如下：winbaseapiboolwinapigetqueuedcompletionstatus(in handle completionport,out lpdword lpnumberofbytestransferred,out pulong_ptr lpcompletionkey,out lpoverlapped *lpoverlapped,in dword dwmilliseconds);其中，我们把第三个参数lpcompletionkey称为完成键，由它传递的数据称为单句柄数据。

我们把第四个参数lpoverlapped称为重叠结构体，由它传递的数据称为单io数据。

以字面的意思来理解，lpcompletionkey内包容的东西应该是与各个socket一一对应的，而lpoverlapped是与每一次的wsarecv或wsasend操作一一对应的。

在网络模型的常见设计中，当一个客户端连接到服务器后，服务器会通过accept或acceptex创建一个socket，而应用层为了保存与此socket相关的其它信息（比如：该socket 所对应的sockaddr_in结构体数据，该结构体内含客户端ip等信息，以及为便于客户端的逻辑包整理而准备的数据整理缓冲区等），往往需要创建一个与该socket一一对应的客户端底层通信对象，这个对象可以负责保存仅在网络层需要处理的数据成员和方法，然后我们需要将此客户端底层通信对象放入一个类似于list或map的容器中，待到需要使用的时候，使用容器的查找算法根据socket值找到它所对应的对象然后进行我们所需要的操作。

让人非常高兴的是，完成端口“体贴入微”，它已经帮我们在每次的完成事件通知时，稍带着把该socket所对应的底层通信对象的指针送给了我们，这个指针就是lpcompletionkey。

也就是说，当我们从getqueuedcompletionstatus函数取得一个数据接收完成的通知，需要将此次收到的数据放到该socket所对应的通信对象整理缓冲区内对数据进行整理时，我们已经不需要去执行list或map等的查找算法，而是可以直接定位这个对象了，当客户端连接量很大时，频繁查表还是很影响效率的。

哇哦，太帅了，不是吗？呵呵。

基于以上的认识，我们的lpcompletionkey对象可以设计如下：typedef struct per_handle_data{socket socket;//本结构体对应的socket值sockaddr_in addr;//用于存放客户端ip等信息char databuf[ 2*max_buffer_size ];//整理缓冲区,用于存放每次整理时的数据}per_handle_data与socket的绑定，通过createiocompletionport完成，将该结构体地址作为该函数的第三个参数传入即可。

而per_handle_data结构体中addr成员，是在accept执行成功后进行赋值的。

databuf则可以在每次wsarecv操作完成，需要整理缓冲区数据时使用。

下面我们再来看看完成端口的收、发操作中所使用到的重叠结构体overlapped。

关于重叠io的知识，请自行google相关资料。

简单地说，overlapped是应用层与核心层交互共享的数据单元，如果要执行一个重叠io操作，必须带有overlapped结构。

在完成端口中，它允许应用层对overlapped结构进行扩展和自定义，允许应用层根据自己的需要在overlapped的基础上形成新的扩展overlapped结构。

一般地，扩展的overlapped结构中，要求放在第一个的数据成员是原overlapped结构。

我们可以形如以下方式定义自己的扩展overlapped结构：typedef struct per_io_data{overlapped ovl;wsabuf buf;char recvdatabuf[ max_buffer_size ]; //接收缓冲区char senddatabuf[ max_buffer_size ]; //发送缓冲区optype optype; //操作类型：发送、接收或关闭等}在执行wsasend和wsarecv操作时，应用层会将扩展overlapped结构的地址传给核心，核心完成相应的操作后，仍然通过原有的这个结构传递操作结果，比如“接收”操作完成后，recvdatabuf里存放便是此次接收下来的数据。

根据各自应用的不同，不同的完成端口设计者可能会设计出不同的per_handle_data和per_io_data，我这里给出的设计也只是针对自己的应用场合的，不一定就适合你。

但我想，最主要的还是要搞明白per_handle_data和per_io_data两种结构体的含义、用途，以及调用流程。

对CRITICAL_SECTION理解的总结很多人对CRITICAL_SECTION的理解是错误的，认为CRITICAL_SECTION是锁定了资源，其实，CRITICAL_SECTION是不能够“锁定”资源的，它能够完成的功能，是同步不同线程的代码段。

简单说，当一个线程执行了EnterCritialSection之后，cs里面的信息便被修改了，以指明哪一个线程占用了它。

而此时，并没有任何资源被“锁定”。

不管什么资源，其它线程都还是可以访问的（当然，执行的结果可能是错误的）。

只不过，在这个线程尚未执行LeaveCriticalSection之前，其它线程碰到EnterCritialSection语句的话，就会处于等待状态，相当于线程被挂起了。