近半年來，採用了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的發送狀態；如果將發送緩衝區內位響應的報文全部發送，就可能發送重複報文。
