IOCP 细节解说

【什么是IOCP】

是WINDOWS系统的一个内核对象。通过此对象，应用程序可以获得异步IO的完成通知。

这里有几个角色：

角色1：异步IO请求者线程。简单的说，就是调用WSAxxx()函数（例如函数WSARecv,WSASend）的某个线程。

           由于是“异步”的，当角色1线程看到WSAxxx()函数返回时，它并不能知道本次IO是否真的完成了。

           注：当WSAxxx返回成功true时，实际已经读到或发送完数据了（同步的获得IO结果了）。

           为了统一逻辑，我们还是要放到角色2线程中，统一处理IO结果。

           

角色2：异步IO完成事件处理线程。简单的说，就是调用GetQueuedCompletionStatu s函数的线程。

           角色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通过GetQueuedCompletionStatu s函数，读取到{IOCP完成队列C}中完成的IO请求。

【需要创建几个角色2线程呢】

CreateIoCompletionPort()函数创建一个完成端口，其中有一个参数是NumberOfConcurrentThread s。

这个参数的含义是：程序员期望的同时运行的角色2线程数。0代表默认为本机器的CPU个数。

程序员可以创建任意数量的角色2线程。

例如：NumberOfConcurrentThread s设置为2，而实际创建6个角色2线程，或100个，或0个。

如何理解这两个数的差异呢？

OS努力维持NumberOfConcurrentThread s个线程并发的运行，即使我创建100个角色2线程。

如果{IOCP完成队列C}中排队等待处理的{IO结果项}很少，角色2线程能很快处理完，则实际可能只有1个角色2线程在工作，其他线程都在睡眠（即使NumberOfConcurrentThread s设置成100，也只有一个线程在工作）。

如果{IOCP完成队列C}中排队等待处理的{IO结果项}很多，角色2线程处理需要很多CPU时间，则实际可能会有很多角色2线程会被唤醒工作。当然前提是我实际创建了很多角色2线程。极端情况下，如果角色2线程都退出了，则{IOCP完成队列C}可能会被挤爆了。

为什么一般情况下，NumberOfConcurrentThread s设置为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<R的时候。

如果我们的应用需要一次发送很大量的数据时，应该检查T是否小于R。当发送的字节数不足时，应该继续发送剩余的（未发送出去的）部分。

对于WSARecv接收数据，应接收多大的字节数呢？假如应用层协议规定，我们的数据长度不是固定的，这就是一个很棘手的问题。一般情况下，应用层协议规定，一段逻辑上是一组的数据，分包头部分和包体部分。包头是固定长度的，包体是变长的。包头含有如下信息：包体的长度字节数。我们先收一个固定长度的包头，从中解析出“包体长度信息”，然后我们再次发出一个WSARecv收包体。我称作这个方法为“包头包体两阶段接收法”。

【异步读写如何控制超时】

假如我们接受一个数据包，发出WSARecv{异步IO: X}。这个{异步IO: X}可能长时间无法获得结果。假如对方客户端恶意的不发送任何数据。IOCP本身机制不提供任何超时控制。只能我们程序员控制这个超时。我们发出一个WSARecv调用后，通过维护某种{数据结构: D}，记住此时的时间。在未来的某个时间我们的程序要检查这个{数据结构: D}, 判断这个WSARecv调用是否有结果了。当然此{数据结构: D}的状态改变由{角色2线程}负责。

如果{角色2线程}通过GetQueuedCompletionStatu s调用获得了{异步IO: X}的结果，则改变{数据结构: D}的状态。我们只要判断{数据结构: D}的某个状态未改变，则一定是这个{异步IO: X}未被完成（客户端没有发送任何数据）。

控制超时和控制字节数往往有关联。假如恶意的客户端只发送部分字节数，我们还要处理这种情况。

假如协议要求100个字节，客户端一次传来10个，我们可以毫不客气的干掉这个客户端。这个策略比较狠了些。我们需要温和一点的策略。可能因为网络原因，剩下的90个字节很快就能到来，我们可以继续在规定时间等接受剩余的90个字节。如果超时了，才把这个客户端干掉。

【IOCP系统资源耗尽的问题】

假如我们有10000个客户端socket连接，为了接收他们发送过来的数据，我们需要预先投递10000个WSARecv。

假如每个异步读需要应用层程序员提供10k的缓冲区，则一共需要的用户缓冲区为 10000*10k=97M 内存。windows要求这97M数据必须被OS“锁定”，意思大体是需要占用大量的OS的资源了。所以程序很可能会因为10000个客户同时连接，而耗尽资源。WSAENOBUF错误同此有关。

解决方法是投递0字节数请求的WSARecv。伪代码如下：

WSABUF DataBuf;

DataBuf.len=0;

DataBuf.buf=0;

WSARecv(socket, &DataBuf, 1,...);

当有数据到来时，这个异步IO会从角色2线程中得到结果。由于它是0字节的读，所以它没有触碰任何socket缓冲区的到来的任何数据。我们付出很小的成本（大约每个连接节省了10k）就能知道哪个客户端的数据到来了。别小看了每个连接节省了这么点资源，连接数大了节约的总量就很可观了。如果客户端数量很少，这个技巧就没什么意思了。

当有数据到来时，我们再进行如下操作来开始正式的接收数据。

BYTE buff[1000] ={0};

WSABUF DataBuf;

DataBuf.len=1000;

DataBuf.buf=buff;

WSARecv(socket, &DataBuf, 1,...);

【优雅的杀死角色2线程】

PostQueuedCompletionStat us函数会向{IOCP完成队列C}中push进去一条记录。这样角色2线程就能获得这个“虚伪或模拟”的异步IO完成事件。为什么要“假冒”一条{IOCP完成队列C}的条目呢？用处吗，程序员自己去想吧（意思是用处多多了）。一般来说，我们用它“优雅的杀死角色2线程”。伪代码如下：

typedef struct

{

     OVERLAPPED Overlapped;

     OP_CODE op_type; 

     ...

} PER_IO_DATA;

PER_IO_DATA* PerIOData = ...

PerIOData->op_type = OP_KILL; //操作类型是杀死线程

PostQueuedCompletionStat us(...PerIOData...); 

//如果有N个角色2线程，则需要调用N次，这样{IOCP完成队列C}中才能有N个这个的条目。

角色2线程：

PER_IO_DATA* PerIOData=0;

GetQueuedCompletionStatu s(...&PerIOData...);

if (PerIOData->op_type == OP_KILL){   return ; } //从线程中自然return，就是优雅的退出线程。

【大头的错误处理】

GetQueuedCompletionStatu s函数的错误处理比较复杂。

1 如果GetQueuedCompletionStatu s返回false：

1.1 如果Overlapped指针非空

       恭喜你，你投递的异步IO获得结果了，只不过是失败的结果。好孬也终于回来个信儿了。

       这可能是socket连接断了等等。

       1.1.1 如果GetLastError获得的错误号为ERROR_OPERATION_ABORTED

                一定是有东西调用了CancelIO(socket)了。所有同这个socket相关的异步IO请求都会被取消。

       1.1.2 如果GetLastError 获得的错误号为其他的东西

                可能是IO没成功，如socket连接断开了等等。

1.2 如果Overlapped指针空

       这可不是好消息，因为这意味着IOCP本身有重大故障了。比如我们意外的把IOCP的句柄CloseHandle了。

       1.2.1 如果GetLastError获得的错误号为WAIT_TIMEOUT

                可能GetQueuedCompletionStatu s设置的超时参数dwMilliseconds不是INFINITE。我们继续调用GetQueuedCompletionStatu s重新等待吧。

       1.2.1 如果GetLastError获得的错误号ERROR_ABANDONED_WAIT_0, 或者其他

                IOCP本身都完蛋了，角色2线程应另找东家了，或者就地自我了断算了。

2 如果GetQueuedCompletionStatu s返回true：

    恭喜你，异步IO成功了。

    通过lpNumberOfBytes, lpCompletionKey, and lpOverlapped这三个参数获得详细信息。

    lpNumberOfBytes：实际传输的字节数。（可能比需要传输的字节数少）

    lpCompletionKey：这就是著名的PerHandleData，可以知道这是哪个socket连接的。

    lpOverlapped：    这就是著名的PER_IO_DATA, 同某次异步IO调用关联，

             比如某次WSASend(Overlapped参数=0x123)调用，这里能重新拿到lpOverlapped==0x123。

我们可以根据这个指针，得知这个IO结果是对应着哪次WSASend()调用的结果。             

我满以为这个错误处理天衣无缝，直到有一次测试。我对一个socke投递了100个WSARecv。当我故意把客户端关闭后，这些异步IO不出意外的都在角色2线程的GetQueuedCompletionStatu s函数处获得结果了。令我吃惊的是，GetQueuedCompletionStatu s返回为TRUE!!!，并且GetLastError()返回值是0!!!

令我欣慰的是lpNumberOfBytes值为0（否则真见鬼了）。所以看到GetQueuedCompletionStatu s返回true，不要高兴的太早了。

2.1 把lpOverlapped指针解释成PER_IO_DATA数据结构。如果PerIOData->op_type == OP_KILL，可能这个是PostQueuedCompletionStat us伪造的一个IO完成事件。

2.2 判断是否(lpNumberOfBytes==0)。如果这个IO结果的确是某个WSAxxx()的结果，而不是PostQueuedCompletionStat us伪造的，则这个IO对应的socket可能断了。

2.3 (lpNumberOfBytes>0) ，这才是真正的IO完成的事件呢。可能99.9%的机会，分支跑到这里的。

 

【在同一个socket上一次投递多个异步IO】

一次投递多个WSASend(1234,&Buff1,...); WSASend(1234,&Buff2,...); ... 好像没问题。

如果一次投递多个WSARecv(1234,&Buff1,...);WSARecv(1234,&Buff2,...);好像有些需要阐明的问题。

第一：Windows保证按照你投递WSARecv的顺序，把网络上到达的数据按先后顺序放入Buff1,Buff2。

          如果网络上到来的数据为 AAAAUUUU, 假设Buff1长度4，Buff2长度4，

          则保证Buff1获得AAAA,Buff2获得UUUU

第二：如果有多个角色2线程，可能由于线程调度的“竞争条件race condition”，

          某线程首先执行Buff2的完成处理过程。

          如果我在角色2线程中，打印出收到的数据，可能打印出如下结果：UUUUAAAA。这绝不是违反了TCP协议，          而是多线程的问题。其实解决方案很简单。说者费事，上伪代码

typedef struct

{

     OVERLAPPED Overlapped;

     ...

     int Package_Number; //我对每一次IO，夹带本次调用顺序号

     ...

} PER_IO_DATA;

PER_IO_DATA* PerIOData1=...

PerIOData1->Package_Number = 1 ; //第一次调用

WSARecv(1234, &Buff1,...PerIOData1...);

PER_IO_DATA* PerIOData2=...

PerIOData1->Package_Number = 2 ; //第二次调用

WSARecv(1234, &Buff2,...PerIOData2...);

我们需要维护某种数据结构，记住我们发出了两个WSARecv。

当收到IO结果后，程序需要判断，只有1,2两个调用都从角色2线程获得结果后，才能按顺序把Buff1和Buff2拼接，就是符合顺序的AAAAUUUU。当然，还有其他更好的方式，这里只展示基本原理。

第三：真有必对同一个socket一次投递多个WSARecv吗？

          这个问题同【IOCP系统资源耗尽的问题】，不矛盾。我们假设在投递多个WSARecv时，已经预见到网络上将到来某个socket的大量数据。  根据网络资料介绍，这样可以充分发挥多CPU并发运算的能力。我想在双核CPU机器上，一个CPU处理Buff1，同时另一个CPU处理Buff2。

          如果是少量客户端连接，每个连接可能突然发生大量数据的传送，这个做法可能能加快从Socket缓冲区拷贝数据到应用程序Buff的速度（个人揣测）。

          如果是大量客户端（10000）连接，每个连接传送的数据量很少，这个做法我个人认为没什么意义。我想CPU数量就2个，不会轻易就闲下来吧？

          有一个重要原因，需要投递多个buffer给windows。假如我预计到某个socket一次传过来2M的数据，而

我没有2M大小的buffer，我只有1M大小的buffer。我需要先调用一次WSARecv,等待收完这1M数据后，再发一个

WSARecv。或者我用其他方法，提供给windows系统2个1M的buff。

第四：假设我们真需要一次投递多个Buff，接收数据，有必要用多次WSARecv调用吗？

          这里有个可能的替代做法，上伪代码：

          char *raw1 = new char[BUFF_SIZE];

          WSABUF[2] wsabuf;

          wsabuf[0].buf = raw1 ;

          wsabuf[0].len = BUFF_SIZE;

          char *raw2 = new c