IOCP调试总结

近半年来，采用了IOCP方式处理多连接问题，现在总结一下。

编程模型

1+n模式

一个接受线程R和n个工作线程W组合。
接受线程R负责接收新的连接请求，并将该连接的socket绑定到特定的IOCP端口上。
工作线程W负责响应收发完成消息，并按通信协议要求发起新的收发请求。
工作线程可以有多个。使用时，最好将IOCP端口和工作线程绑定。
如果一个IOCP端口和若干个工作线程绑定，就会导致一个socket在多个工作线程中挑来跳去，就必须使用一些同步对象来协调。

1+n+n模式

一个接受线程R加n个工作线程W加n个通信过程调度线程P（W和P一一对应）组合。相当于把工作线程一分为二。
接受线程R负责接收新的连接请求，并将该连接的socket绑定到特定的IOCP端口上。
工作线程W负责响应收发完成消息，更新socket接收/发送缓冲区的tail/head指针。
通信过程调度线程P负责按通信协议要求响应接收报文，发送响应报文。
同1+n模式一致，一个IOCP端口对应一个工作线程W和一个通信过程处理线程P。
之所有有这个模式，是因为在使用1+1模式处理100个连接请求中发现总是存在处理不及时的情况。
这个模式，将通信过程处理部分分离出来，逻辑更清晰，有利于后期代码维护。

遇到的问题

发完成消息延时过长甚至丢失

在1+1+1模式处理单连接通信中，发现通信中断。后来怀疑是发完成消息丢失，socket处于发送状态，新的发送一直在等待，造成通信中断。
后来在一次分析log中发现，十分钟内收到189个数据包，发送了189个数据包，发完成消息数为158。我们的报文中有时间值，检查报文时间与log记录时间，其差值达13s之久。
延时过长可能会造成发送重复报文。比如，上面通信中断问题，我的处理方案是，不检查socket的发送状态；如果将发送缓冲区内位响应的报文全部发送，就可能发送重复报文。