IOCP（转）
在你開發不同類型的軟件，不久之后或者更晚，你必須得面對客戶端/服務器端的發展。對程序員來說，寫一個全面的客戶端/服務器的代碼是很困難的。這篇文章提供了一個簡單的，但卻強大的客戶端/服務器源代碼，它能夠被擴展到許多客戶端/服務器的應用程序中。源代碼使用高級的IOCP技術，這種技術能高效的為多個客戶端提供服務。IOCP技術提供了一種對 一個線程—一個客戶端（one-thread-one client）這種瓶頸問題（很多中問題的一個）的有效解決方案。它使用很少的一直運行的線程和異步輸入/輸出，發送/接收。IOCP技術被廣泛應用于各自高性能的服務器，像Apache等。源代碼也提供了一系列的函數，在處理通信、客戶端/服務器接收/發送文件函數、還有線程池處理等方面都會經常用到。文章主要關注利用IOCP應用API函數的實際解決方案，也提供了一個全面的代碼文檔。此外，也為你呈現了一個能處理多個連接、同時能夠進行文件傳輸的簡單回復客戶端/服務器。
2.1. 介紹：
這片文章提供了一個類，它是一個應用于客戶端和服務器的源代碼，這個類使用IOCP和異步函數，我們稍后會進行介紹。這個源代碼是根據很多代碼和文章得到的。
利用這些簡單的源代碼，你能夠：
l 服務/連接多個客戶端和服務器。
l 異步發送和接收文件。
l 為了處理沉重的客戶端/服務器請求，創建并管理一個邏輯工作者線程池。（logical worker thread pool）。
我們很難找到充分的，但簡單的能夠應對客戶端/服務器通信的源代碼。在網上發現的源代碼即復雜（超過20個類），又不能提供足夠的功能。本問的代碼盡量簡單，也有好的文檔。我們將簡要介紹Winsock API 2.0提供的IOCP技術，編碼時遇到的疑難問題，以及這些問題的應對方案。
2.2. 異步輸入/輸出完成端口（IOCP）簡介
一個服務器應用程序，假如不能夠同時為多個客戶端提供服務，那它就沒有什么意義。通常的異步I/O調用，還有多線程都是這個目的。準確的說，一個異步I/O調用能夠立即返回，盡管有阻塞的I/O調用。同時，I/O異步調用的結果必須和主線程同步。這可以用很多種方法實現，同步可以通過下面方法實現：
l 利用事件——當異步調用完成時設定的信號。這種方法的優點是線程必須檢查和等待這個信號被設定。
l 使用GetOverlappedResult函數——這個方法和上面方法有相同的優點。
l 使用異步程序調用（APC）——這種方法有些缺點。第一，APC總是在正被調用的線程的上下文中被調用；第二，調用線程必須暫停，等待狀態的改變。
l 使用IOCP——這種方法的缺點是有些疑難問題必須解決。使用IOCP編碼多少有些挑戰。
2.2.1 為什么使用IOCP
使用IOCP，我們能夠克服 一個線程 —— 一個客戶端 問題。我們知道，假如軟件不是運行在一個真實的多處理器機器上，它的性能會嚴重下降。線程是系統的資源，它們即不是無限的，也不便宜。
IOCP提供了一種利用有限的（I/O工作線程）公平的處理多客戶端的輸入/輸出問題的解決辦法。線程并不被阻塞，在無事可作的情況下也不使CPU循環。
2.3. 什么是IOCP
我們已經知道，IOCP僅僅是一個線程同步對象，有點像信號量（semaphore），因此IOCP并不是一個難懂的概念。一個IOCP對象和很多支持異步I/O調用的I/O對象相聯系。線程有權阻塞IOCP對象，直到異步I/O調用完成。
3 IOCP如何工作
為了得到更多信息，建議你參考其它的文章（1, 2, 3, see References）。
使用IOCP，你必須處理3件事情。將一個套接字綁定到一個完成端口，使用異步I/O調用，和使線程同步。為了從異步I/O調用得到結果，并知道一些事情，像哪個客戶端進行的調用，我們必須傳遞兩個參數：CompletionKey參數，還有OVERLAPPED結構體。
3.1. CompletionKey參數
CompletionKey參數是第一個參數，是一個DWORD類型的變量。你可以給它傳遞你想要的任何值，這些值總是和這個參數聯系。通常，指向結構體的指針，或者包含客戶端指定對象的類的指針被傳遞給這個參數。在本文的源代碼中，一個ClientContext結構體的指針被傳遞給CompletionKey參數。
3.2. OVERLAPPED參數
這個參數通常被用來傳遞被異步I/O調用的內存。要重點強調的是，這個數據要被加鎖，并且不要超出物理內存頁，我們之后進行討論。
3.3. 將套接字和完成端口進行綁定
一旦創建了完成端口，通過調用CreateIoCompletionPort函數可以將一個套接字和完成端口進行綁定，像下面的方法：
BOOL IOCPS::AssociateSocketWithCompletionPort(SOCKET socket,
HANDLE hCompletionPort, DWORD dwCompletionKey)
{
HANDLE h = CreateIoCompletionPort((HANDLE) socket,
hCompletionPort, dwCompletionKey, m_nIOWorkers);
return h == hCompletionPort;
}
3.4. 進行異步I/O調用
通過調用WSASend, WSARecv函數，進行實際的異步調用。這些函數也需要包含將要被用到的內存指針的參數WSABUF。通常情況下，當服務器/客戶端想要執行一個I/O調用操作，它們并不直接去做，而是發送到完成端口，這些操作被I/O工作線程執行。這是因為，要公平的分配CPU。通過給完成端口傳遞一個狀態，進行I/O調用。象下面這樣：
BOOL bSuccess = PostQueuedCompletionStatus(m_hCompletionPort,
pOverlapBuff->GetUsed(),
(DWORD) pContext, &pOverlapBuff->m_ol);
3.5. 線程的同步
通過調用GetQueuedCompletionStatus函數進行線程的同步（看下面）。這個函數也提供了CompletionKey 參數 OVERLAPPED參數。
BOOL GetQueuedCompletionStatus(
HANDLE CompletionPort, // handle to completion port
LPDWORD lpNumberOfBytes, // bytes transferred
PULONG_PTR lpCompletionKey, // file completion key
LPOVERLAPPED *lpOverlapped, // buffer
DWORD dwMilliseconds // optional timeout value
);
3.6. 四個棘手的IOCP編碼問題和它們的對策
使用IOCP會遇到一些問題，有些問題并不直觀。在使用IOCP的多線程場景中，并不直接控制線程流，這是因為線程和通信之間并沒有聯系。在這部分，我們將提出四個不同的問題，在使用IOCP開發客戶端/服務器程序時會遇到它們。它們是：
l WSAENOBUFS出錯問題。
l 數據包的重排序問題。
l 訪問紊亂（access violation）問題
3.6.1 WSAENOBUFS出錯問題。
這個問題并不直觀，并且很難檢查。因為，乍一看，它很像普通的死鎖，或者內存泄露。假設你已經弄好了你的服務器并且能夠很好的運行。當你對服務器進行承受力測試的時候，它突然掛機了。如果你幸運，你會發現這和WSAENOBUFS出錯有關。
伴隨著每一次的重疊發送和接收操作，有數據的內存提交可能會被加鎖。當內存被鎖定時，它不能越過物理內存頁。操作系統會強行為能夠被鎖定的內存的大小設定一個上限。當達到上限時，重疊操作將失敗，并發送WSAENOBUFS錯誤。
假如一個服務器在在每個連接上提供了很多重疊接收，隨著連接數量的增長，很快就會達到這個極限。如果服務器能夠預計到要處理相當多的并發客戶端的話，服務器可以在每個連接上僅僅回復一個0字節的接收。這是因為沒有接收操作和內存無關，內存不需要被鎖定。利用這個方法，每一個套接字的接收內存都應該被完整的保留，這是因為，一旦0字節的接收操作完成，服務器僅僅為套接字的接收內存的所以數據內存返回一個非阻塞的接收。利用WSAEWOULDBLOCK，當非阻塞接收失敗時，也沒有數據被阻塞。這種設計的目的是，在犧牲數據吞吐量的情況下，能夠處理最大量的并發連接。當然，對于客戶端如何和服務器交互，你知道的越多越好。在以前的例子中，每當0字節的接收完成，返回存儲了的數據，馬上執行非阻塞接收。假如服務器知道客戶端突然發送數據，當0字節接收一旦完成，為防止客戶端發送一定數量的數據（大于每個套接字默認的8K內存大小），它可以投遞一個或多個重疊接收。
源代碼提供了一個簡單的解決WSAENOBUFS錯誤的可行方案。對于0字節內存，我們采用WSARead（）函數（見OnZeroByteRead（））。當調用完成，我們知道數據在TCP/IP棧中，通過采用幾個異步WSARead（）函數讀取MAXIMUMPACKAGESIZE的內存。這個方法在數據達到時僅僅鎖定物理內存，解決了WSAENOBUFS問題。但是這個方案降低了服務器的吞吐量（見第9部分的Q6和A6例子）。
3.6.2 數據包的重排序問題
在參考文獻3中也討論了這個問題。盡管使用IOCP，可以使數據按照它們被發送的順序被可靠的處理，但是線程表的結果是實際工作線程的完成順序是不確定的。例如，假如你有兩個I/O工作線程，并且你應該接收“字節數據塊1、字節數據塊2 、字節數據塊3”，你可以按照錯誤的順序處理它們，也就是“字節數據塊2、字節數據塊1 、字節數據塊3”。這也意味著，當你通過把發送請求投遞到IO完成端口來發送數據時，數據實際上是被重新排序后發送的。
這個問題的一個實際解決辦法是，為我們的內存類增加順序號，并按照順序號處理內存。意思是，具有不正確號的內存被保存備用，并且因為性能原因，我們將內存保存在希哈表中（例如m_SendBufferMap和m_ReadBufferMap）。
要想得到更多這個方案的信息，請查看源代碼，并在IOCPS類中查看下面的函數：
l GetNextSendBuffer (..) 和GetNextReadBuffer(..), 為了得到排序的發送或接收內存。
l IncreaseReadSequenceNumber(..)和IncreaseSendSequenceNumber(..), 為了增加順序號。
3.6.3 異步阻塞讀和字節塊包處理問題
大多數服務器協議是一個包，這個包的基礎是第一個X位的描述頭，它包含了完整包的長度等詳細信息。服務器可以解讀這個頭，可以算出還需要多少數據，并一直解讀，直到得到一個完整的包。在一個時間段內，服務器通過異步讀取調用是很好的。但是，假若我們想全部利用IOCP服務器的潛力，我們應該有很多的異步讀操作等待數據的到達。意思是很多異步讀無順序完成（像在3.6.2討論的），通過異步讀操作無序的返回字節塊流。還有，一個字節塊流（byte chunk streams）能包含一個或多個包，或者包的一部分，如圖1所示：
圖1
這個圖表明部分包（綠色）和完整的包（黃色）在字節塊流中是如何異步到達的。
這意味著我們要想成功解讀一個完整包，必須處理字節流數據塊（byte stream chunks）。還有，我們必須處理部分包，這使得字節塊包的處理更加困難。完整的方案可以在IOCP類里的ProcessPackage(..)函數中找到。
3.6.4 訪問紊亂（access violation）問題。
這是一個次要問題，是編碼設計的結果，而不是IOCP的特有問題。倘若客戶端連接丟失，并且一個I/O調用返回了一個錯誤標識，這樣我們知道客戶端已經不在了。在CompletionKey參數中，我們為它傳遞一個包含了客戶端特定數據的結構體的指針。假如我們釋放被ClientContext結構體占用的內存，被同一個客戶端執行I/O調用所返回的錯誤碼，我們為ClientContext指針傳遞雙字節的CompletionKey變量，試圖訪問或刪除CompletionKey參數，這些情況下會發生什么？一個訪問紊亂發生了。
這個問題的解決辦法是為ClientContext結構體增加一個阻塞I/O調用的計數(m_nNumberOfPendlingIO)，當我們知道沒有阻塞I/O調用時我們刪除這個結構體。EnterIoLoop(..) 函數和 ReleaseClientContext(..).函數就是這樣做的。
3.7 源代碼總攬
源代碼的目標是提供一些能處理與IOCP有關的問題的代碼。源代碼也提供了一些函數，它們在處理通信、客戶端/服務器接收/發送文件函數、還有線程池處理等方面會經常用到。
?
圖2 源代碼IOCPS類函數總攬
我們有很多I/O工作線程，它們通過完成端口（IOCP）處理異步I/O調用，這些工作線程調用一些能把需要大量計算的請求放到一個工作隊列著中的虛函數。邏輯工作線程從隊列中渠道任務，進行處理，并通過使用一些類提供的函數將結果返回。圖形用戶界面（GUI）通常使用Windows消息，通過函數調用，或者使用共享的變量，和主要類進行通信。
圖3
圖3顯示了類的總攬。
圖3中的類歸納如下：
l CIOCPBuffer：管理被異步I/O調用使用的內存的類。
l IOCPS：處理所有通信的主要類。
l JobItem：包含被邏輯工作線程所執行工作的結構體。
l ClientContext：保存客戶端特定信息的結構體（例如：狀態、數據 ）。
3.7.1 內存設計——CIOCPBuffer類
當使用異步I/O調用時，我們必須為I/O操作提供一個私有內存空間。當我們分配內存時要考慮下面一些情況：
l 分配和釋放內存是很費時間的，因此我們要反復利用分配好的內存。所以，我們像下面所示將內存保存在一個連接表中。
· // Free Buffer List..
·
· CCriticalSection m_FreeBufferListLock;
· CPtrList m_FreeBufferList;
· // OccupiedBuffer List.. (Buffers that is currently used)
· CCriticalSection m_BufferListLock;
· CPtrList m_BufferList;
· // Now we use the function AllocateBuffer(..)
·
// to allocate memory or reuse a buffer.
l 有時，當一個異步I/O調用完成時，我們可能在內存中有部分包，因此我們為了得到一個完整的消息，需要分離內存。在CIOCPS類中的函數SplitBuffer（）可以實現這一目標。我們有時也需要在兩個內存間復制信息， CIOCPS類中的AddAndFlush（）函數可以實現。
l 我們知道，我們為我們的內存增加序列號和狀態變量（IOZeroReadCompleted（））。
l 我們也需要字節流和數據相互轉換的方法，在CIOCPBuffer類中提供了這些函數。
在我們的CIOCPBuffer類中，有上面所有問題的解決辦法。
3.8 如何使用源代碼
從IOCP中派生你自己的類，使用虛函數，使用IOCPS類提供的函數（例如：線程池）。使用線程池，通過使用少數的線程，為你為各種服務器或客戶端高效的管理大量的連接提供了可能。
3.8.1 啟動和關閉服務器/客戶端
啟動服務器，調用下面的函數：
BOOL Start(int nPort=999,int iMaxNumConnections=1201,
int iMaxIOWorkers=1,int nOfWorkers=1,
int iMaxNumberOfFreeBuffer=0,
int iMaxNumberOfFreeContext=0,
BOOL bOrderedSend=TRUE,
BOOL bOrderedRead=TRUE,
int iNumberOfPendlingReads=4);
l nPortt ：服務器將監聽的端口號（在客戶端模式設為-1）。
l iMaxNumConnections：最多允許連接數。
l iMaxIOWorkers ：輸入/輸出工作線程數。
l nOfWorkers：邏輯工作者數（在運行時能被改變）。
l iMaxNumberOfFreeBuffer ：保留的重復利用的內存的最大數量（-1：無 ，0：無窮）。
l iMaxNumberOfFreeContext ：保留的重復利用的客戶端信息的最大數量（-1：無 ，0：無窮）。
l bOrderedRead ：用來進行順序讀。
l bOrderedSend ：用來進行順序發送。
l iNumberOfPendlingReads ：等待數據的異步讀循環的數量。在連接到一個遠端的連接時調用下面的函數：
Connect(const CString &strIPAddr, int nPort)
l strIPAddr ：遠端服務器的IP地址。
l nPort：端口。
關閉服務器，調用函數：ShutDown（）。
例如：
MyIOCP m_iocp;
if(!m_iocp.Start(-1,1210,2,1,0,0))
AfxMessageBox("Error could not start the Client");
….
m_iocp.ShutDown();
5.1 文件傳輸
使用Winsock 2.0的TransmitFile 函數傳輸文件。TransmitFile 函數在連接的套接字句柄上傳輸文件數據。此函數使用操作系統的緩沖管理機制接收文件數據，在套接字上提供高性能的文件傳輸。在異步文件傳輸上有以下幾個重要方面：
l 除非TransmitFile 函數返回，否則不能再對套接字執行 發送 或 寫入 操作，不然會破壞文件的傳輸。在執行PrepareSendFile(..) 函數后，所有對ASend函數的調用都是不允許的。
l 由于系統是連續讀文件數據，打開文件句柄的FILE_FLAG_SEQUENTIAL_SCAN特性可以提高緩存性能。
l 在發送文件（TF_USE_KERNEL_APC）時，我們使用內核的異步程序調用。TF_USE_KERNEL_APC的使用可以帶來明顯的性能提升。很可能（盡管不一定），帶有TransmitFile 的線程的上下文環境的初始化會有沉重的計算負擔；這種情況下可以防止反復執行APC（異步程序調用）。
文件傳輸的順序如下：服務器通過調用PrepareSendFile(..)函數初始化文件傳輸。客戶端接收到文件信息時，通過調用PrepareReceiveFile(..)函數準備接收，并且給服務器發送一個包來開始文件傳輸。在服務器收到包后，它調用使用高性能的TransmitFile函數的StartSendFile(..)函數傳輸指定的文件。
6 源代碼例子
提供的源代碼是一個模擬客戶端/服務器的例子，它也提供了文件傳輸功能。在源碼中，從類IOCP派生出的類MyIOCP處理客戶端和服務器端的通信。在4.1.1 部分提到了這個虛函數的用法。
在客戶端，或者服務器端的代碼中，虛函數NotifyReceivedPackage是重點。描述如下：
void MyIOCP::NotifyReceivedPackage(CIOCPBuffer *pOverlapBuff,
int nSize,ClientContext *pContext)
{
BYTE PackageType=pOverlapBuff->GetPackageType();
switch (PackageType)
{
case Job_SendText2Client :
Packagetext(pOverlapBuff,nSize,pContext);
break;
case Job_SendFileInfo :
PackageFileTransfer(pOverlapBuff,nSize,pContext);
break;
case Job_StartFileTransfer:
PackageStartFileTransfer(pOverlapBuff,nSize,pContext);
break;
case Job_AbortFileTransfer:
DisableSendFile(pContext);
break;};
}
這個函數處理進來的消息和遠程連接發送的請求。在這種情形下，它只不過進行一個簡單的回復或者傳輸文件。源代碼分為兩部分，IOCP和IOCPClient，
它們是連接的雙方。 6.1 編譯器問題
在使用VC++ 6.0 或者 .NT時，在處理類CFile時可能會出現一些奇怪的錯誤。像下面這樣：
“if (pContext->m_File.m_hFile !=
INVALID_HANDLE_VALUE) <-error C2446: '!=' : no conversion "
"from 'void *' to 'unsigned int'”
在你更新頭文件（*.h），或者更新你的VC++ 6.0版本后，或者只是改變類型轉換錯誤，都可能會解決這些問題。經過一些修改，這個客戶端/服務器的源代碼在沒有MFC的情況下也能使用。 7 注意點和解決規則
在你將此代碼用于其它類型的程序時，有一些編程的陷阱和源代碼有關，使用“多線程編程”可以避免。不確定的錯誤是那些隨時發生的錯誤，并且通過執行相同的出錯的任務的順序這種方式很難降低這些不確定的錯誤。這類錯誤是存在的最嚴重的錯誤，一般情況下，它們出錯是因為源代碼設計執行的內核的出錯上。當服務器運行多個IO工作線程時，為連接的客戶端服務，假如編程人員沒有考慮源代碼的多線程環境，就可能會發生像違反權限這種不確定的錯誤。
解決規則 #1：
像下面例子那樣，絕不在使用上下文 “鎖”之前鎖定客戶端的上下文（例如ClientContext）之前進行讀/寫。通知函數（像：Notify*(ClientContext *pContext)）已經是“線程安全的”，你訪問ClientContext的成員函數，而不考慮上下文的加鎖和解鎖。
//Do not do it in this way
// …
If(pContext->m_bSomeData)
pContext->m_iSomeData=0;
// …
// Do it in this way.
//….
pContext->m_ContextLock.Lock();
If(pContext->m_bSomeData)
pContext->m_iSomeData=0;
pContext->m_ContextLock.Unlock();
//…
當然，你要明白，當你鎖定一個上下文時，其他的線程或GUI都將等待它。
解決規則 #2：
要避免，或者“特別注意”使用那些有復雜的“上下文鎖”，或在一個“上下文鎖”中有其他類型的鎖的代碼。因為它們很容易導致“死鎖”。（例如：A等待B，B等待C，而C等待A => 死鎖）。
pContext-> m_ContextLock.Lock();
//… code code ..
pContext2-> m_ContextLock.Lock();
// code code..
pContext2-> m_ContextLock.Unlock();
// code code..
pContext-> m_ContextLock.Unlock();
上面的代碼可以導致一個死鎖。
解決規則 #3：
絕不要在通知函數（像Notify*(ClientContext *pContext)）的外面訪問一個客戶端的上下文。假如你必須這樣做，務必使用m_ContextMapLock.Lock(); … m_ContextMapLock.Unlock()對它進行封裝。如下面代碼所示：
ClientContext* pContext=NULL ;
m_ContextMapLock.Lock();
pContext = FindClient(ClientID);
// safe to access pContext, if it is not NULL
// and are Locked (Rule of thumbs#1:)
//code .. code..
m_ContextMapLock.Unlock();
// Here pContext can suddenly disappear because of disconnect.
// do not access pContext members here.
8 下一步的工作
下一步，代碼會被更新，在時間順序上會具有下面的特性：
1. 可以接受新的連接的AcceptEx(..)函數的應用將添加到源代碼中，用來處理短時的連接爆炸（short lived connection bursts）和DOS攻擊。
2. 源代碼可以很容易的用于其它平臺，像Win32, STL, 和 WTL。
說明：最近比較忙，各種事情應接不暇。終于弄完了，呵呵。
源代碼可以到網上下載，我分析了，很好，可以應用到我的項目中，嘿嘿。
總結
- 上一篇： 创建线程后为什么马上调用CloseHan
- 下一篇： IOCP配合AcceptEx的例子