IOCP以其高效的性能受到服務(wù)器開(kāi)發(fā)者的青睞，本人有幸在當(dāng)前的項(xiàng)目中使用了該異步模型，修改調(diào)試之余，總結(jié)出開(kāi)發(fā)過(guò)程中的經(jīng)驗(yàn)若干，供大家借鑒。
首先是需要注意的是OVERLAPPED結(jié)構(gòu)。想必該結(jié)構(gòu)大多數(shù)人都是自定義新的結(jié)構(gòu)體，將OVERLAPPED成員放置在第一位，然后后置其他成員。
在函數(shù) WSASend, WSARecv, PostQueuedCompletionStatus 以及GetQueuedCompletionStatus 中都有LPOVERLAPPED的參數(shù)，其中在前面三個(gè)函數(shù)中是輸入?yún)?shù)，后面一個(gè)函數(shù)中是輸出參數(shù)。對(duì)于輸入?yún)?shù)可以傳入強(qiáng)制轉(zhuǎn)換的自定義結(jié)構(gòu)體指針(不需要取地址)，也可以傳入自定義結(jié)構(gòu)體中OVERLAPPED成員的地址(需要取地址)；對(duì)于輸出參數(shù)，將要傳出的是前三個(gè)函數(shù)中輸入?yún)?shù)的地址。在開(kāi)發(fā)過(guò)程中，對(duì)于該結(jié)構(gòu)地址的操作需要細(xì)心。
形如以下的代碼都是正確的：
WSASend(pClientData->IoSocket, &(pPerIoData->WsaSendDataBuff), 1, &dwSendBytes, 0, (LPOVERLAPPED)pPerIoData, NULL);
WSASend(pClientData->IoSocket, &(pPerIoData->WsaSendDataBuff), 1, &dwSendBytes, 0, &(pPerIoData->overlaped), NULL);
GetQueuedCompletionStatus(pThis->m_hIOCP, &dwBytesTransferred,(LPDWORD)&pPerHandleData, (LPOVERLAPPED *)&pPerIoData, INFINITE); 其次需要注意的是PostQueuedCompletionStatus 函數(shù)。該函數(shù)向IOCP發(fā)送三個(gè)參數(shù)(DWORD dwNumberOfBytesTransferred, ULONG_PTR dwCompletionKey, LPOVERLAPPED lpOverlapped)，GetQueuedCompletionStatus 函數(shù)將接收到這三個(gè)參數(shù)。IOCP將不會(huì)對(duì)這三個(gè)參數(shù)做任何操作。
在實(shí)際應(yīng)用中，該函數(shù)一般用于控制IOCP接收線程的退出。其實(shí)，該函數(shù)的用法遠(yuǎn)不止于此，它還可以作為消息來(lái)使用。通過(guò)定義特定的dwNumberOfBytesTransferred消息值，然后通過(guò)PostQueuedCompletionStatus函數(shù)向IOCP中POST該消息，GetQueuedCompletionStatus 函數(shù)就可以捕獲該消息。自定義的dwNumberOfBytesTransferred消息值一定要大于接收BUFFER和發(fā)送BUFFER的最大長(zhǎng)度，否則作為消息就沒(méi)有意義了。
還有一個(gè)需要注意的是WSARecv函數(shù)。在IOCP中多次調(diào)用該函數(shù)是有后果的，嚴(yán)重的會(huì)導(dǎo)致接收緩沖區(qū)被塞滿，就算沒(méi)有塞滿接收緩沖區(qū)，如果客戶端意外斷開(kāi)連接，GetQueuedCompletionStatus 函數(shù)會(huì)接到與調(diào)用次數(shù)一樣多次數(shù)的返回錯(cuò)誤，想必大家一定都不希望這些情況發(fā)生。要避免這種問(wèn)題一定要謹(jǐn)慎的調(diào)用WSARecv函數(shù)，最好在GetQueuedCompletionStatus 函數(shù)接收到數(shù)據(jù)后再考慮再次調(diào)用WSARecv。
今天又測(cè)出一個(gè)潛在的BUG，先貼代碼：
首先是定義：
typedef enum _IO_OPERATION
{
IoRecv, //WSARecv
IoSend, //WSASend
IoQuit
}IO_OPERATION, *PIO_OPERATION;
typedef struct _PER_IO_CONTEXT
{
WSAOVERLAPPED ol;
WSABUF WsaRecvDataBuff;
WSABUF WsaSendDataBuff;
char strRecvBuffer[DATA_MAX_BUFFERSIZE]; //接收BUFFER
char strSendBuffer[DATA_MAX_BUFFERSIZE]; //發(fā)送BUFFER
IO_OPERATION IoType;
}PER_IO_CONTEXT, *LPPER_IO_CONTEXT;
這里的IO_OPERATION定義了三種類型，分別表示接收、發(fā)送和退出，GetQueuedCompletionStatus函數(shù)在接收到消息時(shí)，可以通過(guò)檢測(cè)IoType的類型來(lái)判斷IOCP剛剛完成的操作是接收操作還是發(fā)送操作亦或是退出操作。
在一次操作中（比如接收到數(shù)據(jù)后的操作），先后調(diào)用WSASend和WSARecv，來(lái)實(shí)現(xiàn)發(fā)送數(shù)據(jù)，然后繼續(xù)Recv的動(dòng)作，這樣做可行嗎？答案是否定的。分析：調(diào)用WSASend之前，設(shè)置IoType為IoSend，標(biāo)志本次操作是發(fā)送操作；然后在調(diào)用WSARecv前，設(shè)置IoType為IoRecv，標(biāo)志本次操作是接收操作。IOCP在處理消息隊(duì)列時(shí)，首先應(yīng)該接收到的是發(fā)送操作，由于IoType已經(jīng)被設(shè)置成了IoRecv，在判斷時(shí)就會(huì)將這次操作判斷成接收操作，去檢測(cè)接收BUFFER，這樣顯然就出錯(cuò)了；然后會(huì)接收到接收操作，此時(shí)IoType是IoRecv，仍然判斷為接收操作，此時(shí)檢測(cè)接收BUFFER，是正確的。這樣做的直觀表現(xiàn)就是接收事件明顯變多了。
以上的這個(gè)例子，說(shuō)明處理IOCP時(shí)一定要細(xì)心，要注意那些變量是易變的，那些是不易變的。可能上面的這個(gè)看起來(lái)很明顯，但是如果程序復(fù)雜了，這種BUG就不易察覺(jué)。