玩轉完成端口

手把手叫你玩轉網絡編程系列之三

   完成端口(Completion Port)詳解

                                                             ----- By PiggyXP(小豬)

前 言

        本系列裏完成端口的代碼在兩年前就已經寫好了，但是由於許久沒有寫東西了，不知該如何提筆，所以這篇文檔總是在醞釀之中……醞釀了兩年之後，終於決定開始動筆了，但願還不算晚…..

        這篇文檔我非常詳細並且圖文並茂的介紹了關於網絡編程模型中完成端口的方方面面的信息，從API的用法到使用的步驟，從完成端口的實現機理到實際使用的注意事項，都有所涉及，並且爲了讓朋友們更直觀的體會完成端口的用法，本文附帶了有詳盡註釋的使用MFC編寫的圖形界面的示例代碼。

        我的初衷是希望寫一份互聯網上能找到的最詳盡的關於完成端口的教學文檔，而且讓對Socket編程略有了解的人都能夠看得懂，都能學會如何來使用完成端口這麼優異的網絡編程模型，但是由於本人水平所限，不知道我的初衷是否實現了，但還是希望各位需要的朋友能夠喜歡。

        由於篇幅原因，本文假設你已經熟悉了利用Socket進行TCP/IP編程的基本原理，並且也熟練的掌握了多線程編程技術，太基本的概念我這裏就略過不提了，網上的資料應該遍地都是。

        本文檔凝聚着筆者心血，如要轉載，請指明原作者及出處，謝謝！不過代碼沒有版權，可以隨便散播使用，歡迎改進，特別是非常歡迎能夠幫助我發現Bug的朋友，以更好的造福大家。^_^

        本文配套的示例源碼下載地址（在我的下載空間裏，已經補充上了客戶端的代碼）

        http://piggyxp.download.csdn.net/

       (裏面的代碼包括VC++2008/VC++2010編寫的完成端口服務器端和客戶端的代碼，還包括一個對服務器端進行壓力測試的客戶端，都是經過我精心調試過，並且帶有非常詳盡的代碼註釋的。當然，作爲教學代碼，爲了能夠使得代碼結構清晰明瞭，我還是對代碼有所簡化，如果想要用於產品開發，最好還是需要自己再完善一下，另外我的工程是用2010編寫的，附帶的2008工程不知道有沒有問題，但是其中代碼都是一樣的，暫未測試)

        忘了囑咐一下了，文章篇幅很長很長，基本涉及到了與完成端口有關的方方面面，一次看不完可以分好幾次，中間注意休息，好身體纔是咱們程序員最大的本錢！

       對了，還忘了囑咐一下，因爲本人的水平有限，雖然我反覆修正了數遍，但文章和示例代碼裏肯定還有我沒發現的錯誤和紕漏，希望各位一定要指出來，拍磚、噴我，我都能Hold住，但是一定要指出來，我會及時修正，因爲我不想讓文中的錯誤傳遍互聯網，禍害大家。

      OK, Let’s go ! Have fun !

 

目錄：

1． 完成端口的優點

2． 完成端口程序的運行演示

3． 完成端口的相關概念

4． 完成端口的基本流程

5． 完成端口的使用詳解

6． 實際應用中應該要注意的地方

 

一． 完成端口的優點

        1. 我想只要是寫過或者想要寫C/S模式網絡服務器端的朋友，都應該或多或少的聽過完成端口的大名吧，完成端口會充分利用Windows內核來進行I/O的調度，是用於C/S通信模式中性能最好的網絡通信模型，沒有之一；甚至連和它性能接近的通信模型都沒有。

        2. 完成端口和其他網絡通信方式最大的區別在哪裏呢？

        (1) 首先，如果使用“同步”的方式來通信的話，這裏說的同步的方式就是說所有的操作都在一個線程內順序執行完成，這麼做缺點是很明顯的：因爲同步的通信操作會阻塞住來自同一個線程的任何其他操作，只有這個操作完成了之後，後續的操作纔可以完成；一個最明顯的例子就是咱們在MFC的界面代碼中，直接使用阻塞Socket調用的代碼，整個界面都會因此而阻塞住沒有響應！所以我們不得不爲每一個通信的Socket都要建立一個線程，多麻煩？這不坑爹呢麼？所以要寫高性能的服務器程序，要求通信一定要是異步的。

        (2) 各位讀者肯定知道，可以使用使用“同步通信(阻塞通信)+多線程”的方式來改善(1)的情況，那麼好，想一下，我們好不容易實現了讓服務器端在每一個客戶端連入之後，都要啓動一個新的Thread和客戶端進行通信，有多少個客戶端，就需要啓動多少個線程，對吧；但是由於這些線程都是處於運行狀態，所以系統不得不在所有可運行的線程之間進行上下文的切換，我們自己是沒啥感覺，但是CPU卻痛苦不堪了，因爲線程切換是相當浪費CPU時間的，如果客戶端的連入線程過多，這就會弄得CPU都忙着去切換線程了，根本沒有多少時間去執行線程體了，所以效率是非常低下的，承認坑爹了不？

        (3) 而微軟提出完成端口模型的初衷，就是爲了解決這種"one-thread-per-client"的缺點的，它充分利用內核對象的調度，只使用少量的幾個線程來處理和客戶端的所有通信，消除了無謂的線程上下文切換，最大限度的提高了網絡通信的性能，這種神奇的效果具體是如何實現的請看下文。

        3. 完成端口被廣泛的應用於各個高性能服務器程序上，例如著名的Apache….如果你想要編寫的服務器端需要同時處理的併發客戶端連接數量有數百上千個的話，那不用糾結了，就是它了。

 

二． 完成端口程序的運行演示

        首先，我們先來看一下完成端口在筆者的PC機上的運行表現，筆者的PC配置如下：

                        

        大體就是i7 2600 + 16GB內存，我以這臺PC作爲服務器，簡單的進行了如下的測試，通過Client生成3萬個併發線程同時連接至Server，然後每個線程每隔3秒鐘發送一次數據，一共發送3次，然後觀察服務器端的CPU和內存的佔用情況。

        如圖2所示，是客戶端3萬個併發線程發送共發送9萬條數據的log截圖

                             

        圖3是服務器端接收完畢3萬個併發線程和每個線程的3份數據後的log截圖

                               

        最關鍵是圖4，圖4是服務器端在接收到28000個併發線程的時候，CPU佔用率的截圖，使用的軟件是大名鼎鼎的Process Explorer，因爲相對來講這個比自帶的任務管理器要準確和精確一些。

                                   

         我們可以發現一個令人驚訝的結果，採用了完成端口的Server程序(藍色橫線所示)所佔用的CPU才爲 3.82%，整個運行過程中的峯值也沒有超過4%，是相當氣定神閒的……哦，對了，這還是在Debug環境下運行的情況，如果採用Release方式執行，性能肯定還會更高一些，除此以外，在UI上顯示信息也很大成都上影響了性能。

         相反採用了多個併發線程的Client程序(紫色橫線所示)居然佔用的CPU高達11.53%，甚至超過了Server程序的數倍……

         其實無論是哪種網絡操模型，對於內存佔用都是差不多的，真正的差別就在於CPU的佔用，其他的網絡模型都需要更多的CPU動力來支撐同樣的連接數據。

         雖然這遠遠算不上服務器極限壓力測試，但是從中也可以看出來完成端口的實力，而且這種方式比純粹靠多線程的方式實現併發資源佔用率要低得多。

 

三． 完成端口的相關概念

         在開始編碼之前，我們先來討論一下和完成端口相關的一些概念，如果你沒有耐心看完這段大段的文字的話，也可以跳過這一節直接去看下下一節的具體實現部分，但是這一節中涉及到的基本概念你還是有必要了解一下的，而且你也更能知道爲什麼有那麼多的網絡編程模式不用，非得要用這麼又複雜又難以理解的完成端口呢？？也會堅定你繼續學習下去的信心^_^

         3.1 異步通信機制及其幾種實現方式的比較

         我們從前面的文字中瞭解到，高性能服務器程序使用異步通信機制是必須的。

         而對於異步的概念，爲了方便後面文字的理解，這裏還是再次簡單的描述一下：

         異步通信就是在咱們與外部的I/O設備進行打交道的時候，我們都知道外部設備的I/O和CPU比起來簡直是龜速，比如硬盤讀寫、網絡通信等等，我們沒有必要在咱們自己的線程裏面等待着I/O操作完成再執行後續的代碼，而是將這個請求交給設備的驅動程序自己去處理，我們的線程可以繼續做其他更重要的事情，大體的流程如下圖所示:

                        

        我可以從圖中看到一個很明顯的並行操作的過程，而“同步”的通信方式是在進行網絡操作的時候，主線程就掛起了，主線程要等待網絡操作完成之後，才能繼續執行後續的代碼，就是說要末執行主線程，要末執行網絡操作，是沒法這樣並行的；

        “異步”方式無疑比 “阻塞模式+多線程”的方式效率要高的多，這也是前者爲什麼叫“異步”，後者爲什麼叫“同步”的原因了，因爲不需要等待網絡操作完成再執行別的操作。

        而在Windows中實現異步的機制同樣有好幾種，而這其中的區別，關鍵就在於圖1中的最後一步“通知應用程序處理網絡數據”上了，因爲實現操作系統調用設備驅動程序去接收數據的操作都是一樣的，關鍵就是在於如何去通知應用程序來拿數據。它們之間的具體區別我這裏多講幾點，文字有點多，如果沒興趣深入研究的朋友可以跳過下一面的這一段，不影響的:)

        (1) 設備內核對象，使用設備內核對象來協調數據的發送請求和接收數據協調，也就是說通過設置設備內核對象的狀態，在設備接收數據完成後，馬上觸發這個內核對象，然後讓接收數據的線程收到通知，但是這種方式太原始了，接收數據的線程爲了能夠知道內核對象是否被觸發了，還是得不停的掛起等待，這簡直是根本就沒有用嘛，太低級了，有木有？所以在這裏就略過不提了，各位讀者要是沒明白是怎麼回事也不用深究了，總之沒有什麼用。

        (2) 事件內核對象，利用事件內核對象來實現I/O操作完成的通知，其實這種方式其實就是我以前寫文章的時候提到的《基於事件通知的重疊I/O模型》，鏈接在這裏，這種機制就先進得多，可以同時等待多個I/O操作的完成，實現真正的異步，但是缺點也是很明顯的，既然用WaitForMultipleObjects()來等待Event的話，就會受到64個Event等待上限的限制，但是這可不是說我們只能處理來自於64個客戶端的Socket，而是這是屬於在一個設備內核對象上等待的64個事件內核對象，也就是說，我們在一個線程內，可以同時監控64個重疊I/O操作的完成狀態，當然我們同樣可以使用多個線程的方式來滿足無限多個重疊I/O的需求，比如如果想要支持3萬個連接，就得需要500多個線程…用起來太麻煩讓人感覺不爽；

        (3) 使用APC( Asynchronous Procedure Call，異步過程調用)來完成，這個也就是我以前在文章裏提到的《基於完成例程的重疊I/O模型》，鏈接在這裏，這種方式的好處就是在於擺脫了基於事件通知方式的64個事件上限的限制，但是缺點也是有的，就是發出請求的線程必須得要自己去處理接收請求，哪怕是這個線程發出了很多發送或者接收數據的請求，但是其他的線程都閒着…，這個線程也還是得自己來處理自己發出去的這些請求，沒有人來幫忙…這就有一個負載均衡問題，顯然性能沒有達到最優化。

        (4) 完成端口，不用說大家也知道了，最後的壓軸戲就是使用完成端口，對比上面幾種機制，完成端口的做法是這樣的：事先開好幾個線程，你有幾個CPU我就開幾個，首先是避免了線程的上下文切換，因爲線程想要執行的時候，總有CPU資源可用，然後讓這幾個線程等着，等到有用戶請求來到的時候，就把這些請求都加入到一個公共消息隊列中去，然後這幾個開好的線程就排隊逐一去從消息隊列中取出消息並加以處理，這種方式就很優雅的實現了異步通信和負載均衡的問題，因爲它提供了一種機制來使用幾個線程“公平的”處理來自於多個客戶端的輸入/輸出，並且線程如果沒事幹的時候也會被系統掛起，不會佔用CPU週期，挺完美的一個解決方案，不是嗎？哦，對了，這個關鍵的作爲交換的消息隊列，就是完成端口。

        比較完畢之後，熟悉網絡編程的朋友可能會問到，爲什麼沒有提到WSAAsyncSelect或者是WSAEventSelect這兩個異步模型呢，對於這兩個模型，我不知道其內部是如何實現的，但是這其中一定沒有用到Overlapped機制，就不能算作是真正的異步，可能是其內部自己在維護一個消息隊列吧，總之這兩個模式雖然實現了異步的接收，但是卻不能進行異步的發送，這就很明顯說明問題了，我想其內部的實現一定和完成端口是迥異的，並且，完成端口非常厚道，因爲它是先把用戶數據接收回來之後再通知用戶直接來取就好了，而WSAAsyncSelect和WSAEventSelect之流只是會接收到數據到達的通知，而只能由應用程序自己再另外去recv數據，性能上的差距就更明顯了。

        最後，我的建議是，想要使用 基於事件通知的重疊I/O和基於完成例程的重疊I/O的朋友，如果不是特別必要，就不要去使用了，因爲這兩種方式不僅使用和理解起來也不算簡單，而且還有性能上的明顯瓶頸，何不就再努力一下使用完成端口呢？

        3.2 重疊結構(OVERLAPPED)

         我們從上一小節中得知，要實現異步通信，必須要用到一個很風騷的I/O數據結構，叫重疊結構“Overlapped”，Windows裏所有的異步通信都是基於它的，完成端口也不例外。

         至於爲什麼叫Overlapped？Jeffrey Richter的解釋是因爲“執行I/O請求的時間與線程執行其他任務的時間是重疊(overlapped)的”，從這個名字我們也可能看得出來重疊結構發明的初衷了，對於重疊結構的內部細節我這裏就不過多的解釋了，就把它當成和其他內核對象一樣，不需要深究其實現機制，只要會使用就可以了，想要了解更多重疊結構內部的朋友，請去翻閱Jeffrey Richter的《Windows via C/C++》 5^th 的292頁，如果沒有機會的話，也可以隨便翻翻我以前寫的Overlapped的東西，不過寫得比較淺顯……

         這裏我想要解釋的是，這個重疊結構是異步通信機制實現的一個核心數據結構，因爲你看到後面的代碼你會發現，幾乎所有的網絡操作例如發送/接收之類的，都會用WSASend()和WSARecv()代替，參數裏面都會附帶一個重疊結構，這是爲什麼呢？因爲重疊結構我們就可以理解成爲是一個網絡操作的ID號，也就是說我們要利用重疊I/O提供的異步機制的話，每一個網絡操作都要有一個唯一的ID號，因爲進了系統內核，裏面黑燈瞎火的，也不瞭解上面出了什麼狀況，一看到有重疊I/O的調用進來了，就會使用其異步機制，並且操作系統就只能靠這個重疊結構帶有的ID號來區分是哪一個網絡操作了，然後內核裏面處理完畢之後，根據這個ID號，把對應的數據傳上去。

         你要是實在不理解這是個什麼玩意，那就直接看後面的代碼吧，慢慢就明白了……

         3.3 完成端口(CompletionPort)

        對於完成端口這個概念，我一直不知道爲什麼它的名字是叫“完成端口”，我個人的感覺應該叫它“完成隊列”似乎更合適一些，總之這個“端口”和我們平常所說的用於網絡通信的“端口”完全不是一個東西，我們不要混淆了。

        首先，它之所以叫“完成”端口，就是說系統會在網絡I/O操作“完成”之後纔會通知我們，也就是說，我們在接到系統的通知的時候，其實網絡操作已經完成了，就是比如說在系統通知我們的時候，並非是有數據從網絡上到來，而是來自於網絡上的數據已經接收完畢了；或者是客戶端的連入請求已經被系統接入完畢了等等，我們只需要處理後面的事情就好了。

        各位朋友可能會很開心，什麼？已經處理完畢了才通知我們，那豈不是很爽？其實也沒什麼爽的，那是因爲我們在之前給系統分派工作的時候，都囑咐好了，我們會通過代碼告訴系統“你給我做這個做那個，等待做完了再通知我”，只是這些工作是做在之前還是之後的區別而已。

        其次，我們需要知道，所謂的完成端口，其實和HANDLE一樣，也是一個內核對象，雖然Jeff Richter嚇唬我們說：“完成端口可能是最爲複雜的內核對象了”，但是我們也不用去管他，因爲它具體的內部如何實現的和我們無關，只要我們能夠學會用它相關的API把這個完成端口的框架搭建起來就可以了。我們暫時只用把它大體理解爲一個容納網絡通信操作的隊列就好了，它會把網絡操作完成的通知，都放在這個隊列裏面，咱們只用從這個隊列裏面取就行了，取走一個就少一個…。

        關於完成端口內核對象的具體更多內部細節我會在後面的“完成端口的基本原理”一節更詳細的和朋友們一起來研究，當然，要是你們在文章中沒有看到這一節的話，就是說明我又犯懶了沒寫…在後續的文章裏我會補上。這裏就暫時說這麼多了，到時候我們也可以看到它的機制也並非有那麼的複雜，可能只是因爲操作系統其他的內核對象相比較而言實現起來太容易了吧^_^

 

四． 使用完成端口的基本流程

         說了這麼多的廢話，大家都等不及了吧，我們終於到了具體編碼的時候了。

        使用完成端口，說難也難，但是說簡單，其實也簡單 ---- 又說了一句廢話=。=

        大體上來講，使用完成端口只用遵循如下幾個步驟：

        (1) 調用 CreateIoCompletionPort() 函數創建一個完成端口，而且在一般情況下，我們需要且只需要建立這一個完成端口，把它的句柄保存好，我們今後會經常用到它……

        (2) 根據系統中有多少個處理器，就建立多少個工作者(爲了醒目起見，下面直接說Worker)線程，這幾個線程是專門用來和客戶端進行通信的，目前暫時沒什麼工作；

        (3) 下面就是接收連入的Socket連接了，這裏有兩種實現方式：一是和別的編程模型一樣，還需要啓動一個獨立的線程，專門用來accept客戶端的連接請求；二是用性能更高更好的異步AcceptEx()請求，因爲各位對accept用法應該非常熟悉了，而且網上資料也會很多，所以爲了更全面起見，本文采用的是性能更好的AcceptEx，至於兩者代碼編寫上的區別，我接下來會詳細的講。

        (4) 每當有客戶端連入的時候，我們就還是得調用CreateIoCompletionPort()函數，這裏卻不是新建立完成端口了，而是把新連入的Socket(也就是前面所謂的設備句柄)，與目前的完成端口綁定在一起。

        至此，我們其實就已經完成了完成端口的相關部署工作了，嗯，是的，完事了，後面的代碼裏我們就可以充分享受完成端口帶給我們的巨大優勢，坐享其成了，是不是很簡單呢？

       (5) 例如，客戶端連入之後，我們可以在這個Socket上提交一個網絡請求，例如WSARecv()，然後系統就會幫咱們乖乖的去執行接收數據的操作，我們大可以放心的去幹別的事情了；

       (6) 而此時，我們預先準備的那幾個Worker線程就不能閒着了， 我們在前面建立的幾個Worker就要忙活起來了，都需要分別調用GetQueuedCompletionStatus() 函數在掃描完成端口的隊列裏是否有網絡通信的請求存在(例如讀取數據，發送數據等)，一旦有的話，就將這個請求從完成端口的隊列中取回來，繼續執行本線程中後面的處理代碼，處理完畢之後，我們再繼續投遞下一個網絡通信的請求就OK了，如此循環。

        關於完成端口的使用步驟，用文字來表述就是這麼多了，很簡單吧？如果你還是不理解，我再配合一個流程圖來表示一下：

        當然，我這裏假設你已經對網絡編程的基本套路有了解了，所以略去了很多基本的細節，並且爲了配合朋友們更好的理解我的代碼，在流程圖我標出了一些函數的名字，並且畫得非常詳細。

        另外需要注意的是由於對於客戶端的連入有兩種方式，一種是普通阻塞的accept，另外一種是性能更好的AcceptEx，爲了能夠方面朋友們從別的網絡編程的方式中過渡，我這裏畫了兩種方式的流程圖，方便朋友們對比學習，圖a是使用accept的方式，當然配套的源代碼我默認就不提供了，如果需要的話，我倒是也可以發上來；圖b是使用AcceptEx的，並配有配套的源碼。

        採用accept方式的流程示意圖如下：

                          

         採用AcceptEx方式的流程示意圖如下：

                           

        

         兩個圖中最大的相同點是什麼？是的，最大的相同點就是主線程無所事事，閒得蛋疼……

         爲什麼呢？因爲我們使用了異步的通信機制，這些瑣碎重複的事情完全沒有必要交給主線程自己來做了，只用在初始化的時候和Worker線程交待好就可以了，用一句話來形容就是，主線程永遠也體會不到Worker線程有多忙，而Worker線程也永遠體會不到主線程在初始化建立起這個通信框架的時候操了多少的心……

         圖a中是由 _AcceptThread()負責接入連接，並把連入的Socket和完成端口綁定，另外的多個_WorkerThread()就負責監控完成端口上的情況，一旦有情況了，就取出來處理，如果CPU有多核的話，就可以多個線程輪着來處理完成端口上的信息，很明顯效率就提高了。

         圖b中最明顯的區別，也就是AcceptEx和傳統的accept之間最大的區別，就是取消了阻塞方式的accept調用，也就是說，AcceptEx也是通過完成端口來異步完成的，所以就取消了專門用於accept連接的線程，用了完成端口來進行異步的AcceptEx調用；然後在檢索完成端口隊列的Worker函數中，根據用戶投遞的完成操作的類型，再來找出其中的投遞的Accept請求，加以對應的處理。

         讀者一定會問，這樣做的好處在哪裏？爲什麼還要異步的投遞AcceptEx連接的操作呢？

         首先，我可以很明確的告訴各位，如果短時間內客戶端的併發連接請求不是特別多的話，用accept和AcceptEx在性能上來講是沒什麼區別的。

        按照我們目前主流的PC來講，如果客戶端只進行連接請求，而什麼都不做的話，我們的Server只能接收大約3萬-4萬個左右的併發連接，然後客戶端其餘的連入請求就只能收到WSAENOBUFS (10055)了，因爲系統來不及爲新連入的客戶端準備資源了。

        需要準備什麼資源？當然是準備Socket了……雖然我們創建Socket只用一行SOCKET s= socket(…) 這麼一行的代碼就OK了，但是系統內部建立一個Socket是相當耗費資源的，因爲Winsock2是分層的機構體系，創建一個Socket需要到多個Provider之間進行處理，最終形成一個可用的套接字。總之，系統創建一個Socket的開銷是相當高的，所以用accept的話，系統可能來不及爲更多的併發客戶端現場準備Socket了。

        而AcceptEx比Accept又強大在哪裏呢？是有三點：

         (1) 這個好處是最關鍵的，是因爲AcceptEx是在客戶端連入之前，就把客戶端的Socket建立好了，也就是說，AcceptEx是先建立的Socket，然後才發出的AcceptEx調用，也就是說，在進行客戶端的通信之前，無論是否有客戶端連入，Socket都是提前建立好了；而不需要像accept是在客戶端連入了之後，再現場去花費時間建立Socket。如果各位不清楚是如何實現的，請看後面的實現部分。

         (2) 相比accept只能阻塞方式建立一個連入的入口，對於大量的併發客戶端來講，入口實在是有點擠；而AcceptEx可以同時在完成端口上投遞多個請求，這樣有客戶端連入的時候，就非常優雅而且從容不迫的邊喝茶邊處理連入請求了。

         (3) AcceptEx還有一個非常體貼的優點，就是在投遞AcceptEx的時候，我們還可以順便在AcceptEx的同時，收取客戶端發來的第一組數據，這個是同時進行的，也就是說，在我們收到AcceptEx完成的通知的時候，我們就已經把這第一組數據接完畢了；但是這也意味着，如果客戶端只是連入但是不發送數據的話，我們就不會收到這個AcceptEx完成的通知……這個我們在後面的實現部分，也可以詳細看到。

         最後，各位要有一個心裏準備，相比accept，異步的AcceptEx使用起來要麻煩得多……

 

五． 完成端口的實現詳解

        又說了一節的廢話，終於到了該動手實現的時候了……

        這裏我把完成端口的詳細實現步驟以及會涉及到的函數，按照出現的先後步驟，都和大家詳細的說明解釋一下，當然，文檔中爲了讓大家便於閱讀，這裏去掉了其中的錯誤處理的內容，當然，這些內容在示例代碼中是會有的。

       【第一步】創建一個完成端口

         首先，我們先把完成端口建好再說。

        我們正常情況下，我們需要且只需要建立這一個完成端口，代碼很簡單:

HANDLE m_hIOCompletionPort = CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 0 );

        呵呵，看到CreateIoCompletionPort()的參數不要奇怪，參數就是一個INVALID，一個NULL，兩個0…，說白了就是一個-1，三個0……簡直就和什麼都沒傳一樣，但是Windows系統內部卻是好一頓忙活，把完成端口相關的資源和數據結構都已經定義好了(在後面的原理部分我們會看到，完成端口相關的數據結構大部分都是一些用來協調各種網絡I/O的隊列)，然後系統會給我們返回一個有意義的HANDLE，只要返回值不是NULL，就說明建立完成端口成功了，就這麼簡單，不是嗎？

        有的時候我真的很讚歎Windows API的封裝，把很多其實是很複雜的事整得這麼簡單……

        至於裏面各個參數的具體含義，我會放到後面的步驟中去講，反正這裏只要知道創建我們唯一的這個完成端口，就只是需要這麼幾個參數。

        但是對於最後一個參數 0，我這裏要簡單的說兩句，這個0可不是一個普通的0，它代表的是NumberOfConcurrentThreads，也就是說，允許應用程序同時執行的線程數量。當然，我們這裏爲了避免上下文切換，最理想的狀態就是每個處理器上只運行一個線程了，所以我們設置爲0，就是說有多少個處理器，就允許同時多少個線程運行。

        因爲比如一臺機器只有兩個CPU（或者兩個核心），如果讓系統同時運行的線程多於本機的CPU數量的話，那其實是沒有什麼意義的事情，因爲這樣CPU就不得不在多個線程之間執行上下文切換，這會浪費寶貴的CPU週期，反而降低的效率，我們要牢記這個原則。

      【第二步】根據系統中CPU核心的數量建立對應的Worker線程

        我們前面已經提到，這個Worker線程很重要，是用來具體處理網絡請求、具體和客戶端通信的線程，而且對於線程數量的設置很有意思，要等於系統中CPU的數量，那麼我們就要首先獲取系統中CPU的數量，這個是基本功，我就不多說了，代碼如下：

SYSTEM_INFO si;
GetSystemInfo(&si);

int m_nProcessors = si.dwNumberOfProcessors;

        這樣我們根據系統中CPU的核心數量來建立對應的線程就好了，下圖是在我的 i7 2600k CPU上初始化的情況，因爲我的CPU是8核，一共啓動了16個Worker線程，如下圖所示

                 

         啊，等等！各位沒發現什麼問題麼？爲什麼我8核的CPU卻啓動了16個線程？這個不是和我們第二步中說的原則自相矛盾了麼？

         哈哈，有個小祕密忘了告訴各位了，江湖上都流傳着這麼一個公式，就是：

        我們最好是建立CPU核心數量*2那麼多的線程，這樣更可以充分利用CPU資源，因爲完成端口的調度是非常智能的，比如我們的Worker線程有的時候可能會有Sleep()或者WaitForSingleObject()之類的情況，這樣同一個CPU核心上的另一個線程就可以代替這個Sleep的線程執行了；因爲完成端口的目標是要使得CPU滿負荷的工作。

        這裏也有人說是建立 CPU“核心數量 * 2 +2”個線程，我想這個應該沒有什麼太大的區別，我就是按照我自己的習慣來了。

        然後按照這個數量，來啓動這麼多個Worker線程就好可以了，接下來我們開始下一個步驟。

        什麼？Worker線程不會建？

        …囧…

       Worker線程和普通線程是一樣一樣一樣的啊~~~，代碼大致上如下：

// 根據CPU數量，建立*2的線程
  m_nThreads = 2 * m_nProcessors;
 HANDLE* m_phWorkerThreads = new HANDLE[m_nThreads];

 for (int i = 0; i < m_nThreads; i++)
 {
     m_phWorkerThreads[i] = ::CreateThread(0, 0, _WorkerThread, …);
 }

       其中，_WorkerThread是Worker線程的線程函數，線程函數的具體內容我們後面再講。

     【第三步】創建一個用於監聽的Socket，綁定到完成端口上，然後開始在指定的端口上監聽連接請求

       最重要的完成端口建立完畢了，我們就可以利用這個完成端口來進行網絡通信了。

       首先，我們需要初始化Socket，這裏和通常情況下使用Socket初始化的步驟都是一樣的，大約就是如下的這麼幾個過程(詳情參照我代碼中的LoadSocketLib()和InitializeListenSocket()，這裏只是挑出關鍵部分)：

// 初始化Socket庫
WSADATA wsaData;
WSAStartup(MAKEWORD(2,2), &wsaData);
//初始化Socket
struct sockaddr_in ServerAddress;
// 這裏需要特別注意，如果要使用重疊I/O的話，這裏必須要使用WSASocket來初始化Socket
// 注意裏面有個WSA_FLAG_OVERLAPPED參數
SOCKET m_sockListen = WSASocket(AF_INET, SOCK_STREAM, 0, NULL, 0, WSA_FLAG_OVERLAPPED);
// 填充地址結構信息
ZeroMemory((char *)&ServerAddress, sizeof(ServerAddress));
ServerAddress.sin_family = AF_INET;
// 這裏可以選擇綁定任何一個可用的地址，或者是自己指定的一個IP地址
//ServerAddress.sin_addr.s_addr = htonl(INADDR_ANY);
ServerAddress.sin_addr.s_addr = inet_addr(“你的IP”);
ServerAddress.sin_port = htons(11111);
// 綁定端口
if (SOCKET_ERROR == bind(m_sockListen, (struct sockaddr *) &ServerAddress, sizeof(ServerAddress)))
// 開始監聽
listen(m_sockListen,SOMAXCONN))

        需要注意的地方有兩點：

        (1) 想要使用重疊I/O的話，初始化Socket的時候一定要使用WSASocket並帶上WSA_FLAG_OVERLAPPED參數纔可以(只有在服務器端需要這麼做，在客戶端是不需要的)；

        (2) 注意到listen函數後面用的那個常量SOMAXCONN了嗎？這個是在微軟在WinSock2.h中定義的，並且還附贈了一條註釋，Maximum queue length specifiable by listen.，所以說，不用白不用咯^_^

        接下來有一個非常重要的動作：既然我們要使用完成端口來幫我們進行監聽工作，那麼我們一定要把這個監聽Socket和完成端口綁定纔可以的吧：

        如何綁定呢？同樣很簡單，用 CreateIoCompletionPort()函數。

        等等！大家沒覺得這個函數很眼熟麼？是的，這個和前面那個創建完成端口用的居然是同一個API！但是這裏這個API可不是用來建立完成端口的，而是用於將Socket和以前創建的那個完成端口綁定的，大家可要看準了，不要被迷惑了，因爲他們的參數是明顯不一樣的，前面那個的參數是一個-1，三個0，太好記了…

        說實話，我感覺微軟應該把這兩個函數分開，弄個 CreateNewCompletionPort() 多好呢？

        這裏在詳細講解一下CreateIoCompletionPort()的幾個參數：

 HANDLE WINAPI CreateIoCompletionPort(
    __in      HANDLE  FileHandle,             // 這裏當然是連入的這個套接字句柄了
     __in_opt  HANDLE  ExistingCompletionPort, // 這個就是前面創建的那個完成端口
     __in      ULONG_PTR CompletionKey,        // 這個參數就是類似於線程參數一樣，在
                                               // 綁定的時候把自己定義的結構體指針傳遞
                                               // 這樣到了Worker線程中，也可以使用這個
                                               // 結構體的數據了，相當於參數的傳遞
     __in      DWORD NumberOfConcurrentThreads // 這裏同樣置0
);

         這些參數也沒什麼好講的吧，用處一目瞭然了。而對於其中的那個CompletionKey，我們後面會詳細提到。

         到此纔算是Socket全部初始化完畢了。

        初始化Socket完畢之後，就可以在這個Socket上投遞AcceptEx請求了。

      【第四步】在這個監聽Socket上投遞AcceptEx請求

        這裏的處理比較複雜。

        這個AcceptEx比較特別，而且這個是微軟專門在Windows操作系統裏面提供的擴展函數，也就是說這個不是Winsock2標準裏面提供的，是微軟爲了方便咱們使用重疊I/O機制，額外提供的一些函數，所以在使用之前也還是需要進行些準備工作。

        微軟的實現是通過mswsock.dll中提供的，所以我們可以通過靜態鏈接mswsock.lib來使用AcceptEx。但是這是一個不推薦的方式，我們應該用WSAIoctl 配合SIO_GET_EXTENSION_FUNCTION_POINTER參數來獲取函數的指針，然後再調用AcceptEx。

        這是爲什麼呢？因爲我們在未取得函數指針的情況下就調用AcceptEx的開銷是很大的，因爲AcceptEx 實際上是存在於Winsock2結構體系之外的(因爲是微軟另外提供的)，所以如果我們直接調用AcceptEx的話，首先我們的代碼就只能在微軟的平臺上用了，沒有辦法在其他平臺上調用到該平臺提供的AcceptEx的版本(如果有的話)， 而且更糟糕的是，我們每次調用AcceptEx時，Service Provider都得要通過WSAIoctl()獲取一次該函數指針，效率太低了，所以還不如我們自己直接在代碼中直接去這麼獲取一下指針好了。

        獲取AcceptEx函數指針的代碼大致如下：

 

       LPFN_ACCEPTEX     m_lpfnAcceptEx;         // AcceptEx函數指針
        GUID GuidAcceptEx = WSAID_ACCEPTEX;        // GUID，這個是識別AcceptEx函數必須的
DWORD dwBytes = 0;

WSAIoctl(
    m_pListenContext->m_Socket,
    SIO_GET_EXTENSION_FUNCTION_POINTER,
    &GuidAcceptEx,
    sizeof(GuidAcceptEx),
    &m_lpfnAcceptEx,
    sizeof(m_lpfnAcceptEx),
    &dwBytes,
    NULL,
    NULL);

   

        具體實現就沒什麼可說的了，因爲都是固定的套路，那個GUID是微軟給定義好的，直接拿過來用就行了，WSAIoctl()就是通過這個找到AcceptEx的地址的，另外需要注意的是，通過WSAIoctl獲取AcceptEx函數指針時，只需要隨便傳遞給WSAIoctl()一個有效的SOCKET即可，該Socket的類型不會影響獲取的AcceptEx函數指針。

        然後，我們就可以通過其中的指針m_lpfnAcceptEx調用AcceptEx函數了。

       AcceptEx函數的定義如下：

BOOL AcceptEx (
               SOCKET sListenSocket,
               SOCKET sAcceptSocket,
               PVOID lpOutputBuffer,
               DWORD dwReceiveDataLength,
               DWORD dwLocalAddressLength,
               DWORD dwRemoteAddressLength,
               LPDWORD lpdwBytesReceived,
               LPOVERLAPPED lpOverlapped
);

        乍一看起來參數很多，但是實際用起來也很簡單：

• 參數1--sListenSocket, 這個就是那個唯一的用來監聽的Socket了，沒什麼說的；
• 參數2--sAcceptSocket, 用於接受連接的socket，這個就是那個需要我們事先建好的，等有客戶端連接進來直接把這個Socket拿給它用的那個，是AcceptEx高性能的關鍵所在。
• 參數3--lpOutputBuffer,接收緩衝區，這也是AcceptEx比較有特色的地方，既然AcceptEx不是普通的accpet函數，那麼這個緩衝區也不是普通的緩衝區，這個緩衝區包含了三個信息：一是客戶端發來的第一組數據，二是server的地址，三是client地址，都是精華啊…但是讀取起來就會很麻煩，不過後面有一個更好的解決方案。
• 參數4--dwReceiveDataLength，前面那個參數lpOutputBuffer中用於存放數據的空間大小。如果此參數=0，則Accept時將不會待數據到來，而直接返回，如果此參數不爲0，那麼一定得等接收到數據了纔會返回…… 所以通常當需要Accept接收數據時，就需要將該參數設成爲：sizeof(lpOutputBuffer) - 2*(sizeof sockaddr_in +16)，也就是說總長度減去兩個地址空間的長度就是了，看起來複雜，其實想明白了也沒啥……
• 參數5--dwLocalAddressLength，存放本地址地址信息的空間大小；
• 參數6--dwRemoteAddressLength，存放本遠端地址信息的空間大小；
• 參數7--lpdwBytesReceived，out參數，對我們來說沒用，不用管；
• 參數8--lpOverlapped，本次重疊I/O所要用到的重疊結構。

        這裏面的參數倒是沒什麼，看起來複雜，但是咱們依舊可以一個一個傳進去，然後在對應的IO操作完成之後，這些參數Windows內核自然就會幫咱們填滿了。

        但是非常悲催的是，我們這個是異步操作，我們是在線程啓動的地方投遞的這個操作， 等我們再次見到這些個變量的時候，就已經是在Worker線程內部了，因爲Windows會直接把操作完成的結果傳遞到Worker線程裏，這樣咱們在啓動的時候投遞了那麼多的IO請求，這從Worker線程傳回來的這些結果，到底是對應着哪個IO請求的呢？。。。。

        聰明的你肯定想到了，是的，Windows內核也幫我們想到了：用一個標誌來綁定每一個IO操作，這樣到了Worker線程內部的時候，收到網絡操作完成的通知之後，再通過這個標誌來找出這組返回的數據到底對應的是哪個Io操作的。

        這裏的標誌就是如下這樣的結構體：

typedef struct _PER_IO_CONTEXT{
  OVERLAPPED   m_Overlapped;          // 每一個重疊I/O網絡操作都要有一個
   SOCKET       m_sockAccept;          // 這個I/O操作所使用的Socket，每個連接的都是一樣的
   WSABUF       m_wsaBuf;              // 存儲數據的緩衝區，用來給重疊操作傳遞參數的，關於WSABUF後面還會講
   char         m_szBuffer[MAX_BUFFER_LEN]; // 對應WSABUF裏的緩衝區
   OPERATION_TYPE  m_OpType;               // 標誌這個重疊I/O操作是做什麼的，例如Accept/Recv等

 } PER_IO_CONTEXT, *PPER_IO_CONTEXT;

        這個結構體的成員當然是我們隨便定義的，裏面的成員你可以隨意修改(除了OVERLAPPED那個之外……)。

       但是AcceptEx不是普通的accept，buffer不是普通的buffer，那麼這個結構體當然也不能是普通的結構體了……

        在完成端口的世界裏，這個結構體有個專屬的名字“單IO數據”，是什麼意思呢？也就是說每一個重疊I/O都要對應的這麼一組參數，至於這個結構體怎麼定義無所謂，而且這個結構體也不是必須要定義的，但是沒它……還真是不行，我們可以把它理解爲線程參數，就好比你使用線程的時候，線程參數也不是必須的，但是不傳還真是不行……

        除此以外，我們也還會想到，既然每一個I/O操作都有對應的PER_IO_CONTEXT結構體，而在每一個Socket上，我們會投遞多個I/O請求的，例如我們就可以在監聽Socket上投遞多個AcceptEx請求，所以同樣的，我們也還需要一個“單句柄數據”來管理這個句柄上所有的I/O請求，這裏的“句柄”當然就是指的Socket了，我在代碼中是這樣定義的：

typedef struct _PER_SOCKET_CONTEXT
{
  SOCKET                   m_Socket;              // 每一個客戶端連接的Socket
  SOCKADDR_IN              m_ClientAddr;          // 這個客戶端的地址
  CArray<_PER_IO_CONTEXT*>  m_arrayIoContext;   // 數組，所有客戶端IO操作的參數，
                                                        // 也就是說對於每一個客戶端Socket
                                                      // 是可以在上面同時投遞多個IO請求的
} PER_SOCKET_CONTEXT, *PPER_SOCKET_CONTEXT;

         這也是比較好理解的，也就是說我們需要在一個Socket句柄上，管理在這個Socket上投遞的每一個IO請求的_PER_IO_CONTEXT。

         當然，同樣的，各位對於這些也可以按照自己的想法來隨便定義，只要能起到管理每一個IO請求上需要傳遞的網絡參數的目的就好了，關鍵就是需要跟蹤這些參數的狀態，在必要的時候釋放這些資源，不要造成內存泄漏，因爲作爲Server總是需要長時間運行的，所以如果有內存泄露的情況那是非常可怕的，一定要杜絕一絲一毫的內存泄漏。

        至於具體這兩個結構體參數是如何在Worker線程裏大發神威的，我們後面再看。

         以上就是我們全部的準備工作了，具體的實現各位可以配合我的流程圖再看一下示例代碼，相信應該會理解得比較快。

        完成端口初始化的工作比起其他的模型來講是要更復雜一些，所以說對於主線程來講，它總覺得自己付出了很多，總覺得Worker線程是坐享其成，但是Worker自己的苦只有自己明白，Worker線程的工作一點也不比主線程少，相反還要更復雜一些，並且具體的通信工作全部都是Worker線程來完成的，Worker線程反而還覺得主線程是在旁邊看熱鬧，只知道發號施令而已，但是大家終究還是誰也離不開誰，這也就和公司里老板和員工的微妙關係是一樣的吧……

        【第五步】我們再來看看Worker線程都做了些什麼

        _Worker線程的工作都是涉及到具體的通信事務問題，主要完成了如下的幾個工作，讓我們一步一步的來看。

        (1) 使用 GetQueuedCompletionStatus() 監控完成端口

        首先這個工作所要做的工作大家也能猜到，無非就是幾個Worker線程哥幾個一起排好隊隊來監視完成端口的隊列中是否有完成的網絡操作就好了，代碼大體如下：

void *lpContext = NULL;
OVERLAPPED        *pOverlapped = NULL;
DWORD            dwBytesTransfered = 0;

BOOL bReturn  =  GetQueuedCompletionStatus(
                                     pIOCPModel->m_hIOCompletionPort,
                                         &dwBytesTransfered,
                             (LPDWORD)&lpContext,
                             &pOverlapped,
                             INFINITE );

        各位留意到其中的GetQueuedCompletionStatus()函數了嗎？這個就是Worker線程裏第一件也是最重要的一件事了，這個函數的作用就是我在前面提到的，會讓Worker線程進入不佔用CPU的睡眠狀態，直到完成端口上出現了需要處理的網絡操作或者超出了等待的時間限制爲止。

        一旦完成端口上出現了已完成的I/O請求，那麼等待的線程會被立刻喚醒，然後繼續執行後續的代碼。

       至於這個神奇的函數，原型是這樣的：

BOOL WINAPI GetQueuedCompletionStatus(
    __in   HANDLE          CompletionPort,    // 這個就是我們建立的那個唯一的完成端口
    __out  LPDWORD         lpNumberOfBytes,   //這個是操作完成後返回的字節數
    __out  PULONG_PTR      lpCompletionKey,   // 這個是我們建立完成端口的時候綁定的那個自定義結構體參數
    __out  LPOVERLAPPED    *lpOverlapped,     // 這個是我們在連入Socket的時候一起建立的那個重疊結構
    __in   DWORD           dwMilliseconds     // 等待完成端口的超時時間，如果線程不需要做其他的事情，那就INFINITE就行了
    );

        所以，如果這個函數突然返回了，那就說明有需要處理的網絡操作了 --- 當然，在沒有出現錯誤的情況下。

        然後switch()一下，根據需要處理的操作類型，那我們來進行相應的處理。

        但是如何知道操作是什麼類型的呢？這就需要用到從外部傳遞進來的loContext參數，也就是我們封裝的那個參數結構體，這個參數結構體裏面會帶有我們一開始投遞這個操作的時候設置的操作類型，然後我們根據這個操作再來進行對應的處理。

        但是還有問題，這個參數究竟是從哪裏傳進來的呢？傳進來的時候內容都有些什麼？

        這個問題問得好！

        首先，我們要知道兩個關鍵點：

        (1) 這個參數，是在你綁定Socket到一個完成端口的時候，用的CreateIoCompletionPort()函數，傳入的那個CompletionKey參數，要是忘了的話，就翻到文檔的“第三步”看看相關的內容；我們在這裏傳入的是定義的PER_SOCKET_CONTEXT，也就是說“單句柄數據”，因爲我們綁定的是一個Socket，這裏自然也就需要傳入Socket相關的上下文，你是怎麼傳過去的，這裏收到的就會是什麼樣子，也就是說這個lpCompletionKey就是我們的PER_SOCKET_CONTEXT，直接把裏面的數據拿出來用就可以了。

       (2) 另外還有一個很神奇的地方，裏面的那個lpOverlapped參數，裏面就帶有我們的PER_IO_CONTEXT。這個參數是從哪裏來的呢？我們去看看前面投遞AcceptEx請求的時候，是不是傳了一個重疊參數進去？這裏就是它了，並且，我們可以使用一個很神奇的宏，把和它存儲在一起的其他的變量，全部都讀取出來，例如：

PER_IO_CONTEXT* pIoContext = CONTAINING_RECORD(lpOverlapped, PER_IO_CONTEXT, m_Overlapped);

         這個宏的含義，就是去傳入的lpOverlapped變量裏，找到和結構體中PER_IO_CONTEXT中m_Overlapped成員相關的數據。

         你仔細想想，其實真的很神奇……

         但是要做到這種神奇的效果，應該確保我們在結構體PER_IO_CONTEXT定義的時候，把Overlapped變量，定義爲結構體中的第一個成員。

         只要各位能弄清楚這個GetQueuedCompletionStatus()中各種奇怪的參數，那我們就離成功不遠了。

         既然我們可以獲得PER_IO_CONTEXT結構體，那麼我們就自然可以根據其中的m_OpType參數，得知這次收到的這個完成通知，是關於哪個Socket上的哪個I/O操作的，這樣就分別進行對應處理就好了。

        在我的示例代碼裏，在有AcceptEx請求完成的時候，我是執行的_DoAccept()函數，在有WSARecv請求完成的時候，執行的是_DoRecv()函數，下面我就分別講解一下這兩個函數的執行流程。

       【第六步】當收到Accept通知時 _DoAccept()

        在用戶收到AcceptEx的完成通知時，需要後續代碼並不多，但卻是邏輯最爲混亂，最容易出錯的地方，這也是很多用戶爲什麼寧願用效率低下的accept()也不願意去用AcceptEx的原因吧。

       和普通的Socket通訊方式一樣，在有客戶端連入的時候，我們需要做三件事情：

       (1) 爲這個新連入的連接分配一個Socket；

       (2) 在這個Socket上投遞第一個異步的發送/接收請求；

       (3) 繼續監聽。

        其實都是一些很簡單的事情但是由於“單句柄數據”和“單IO數據”的加入，事情就變得比較亂。因爲是這樣的，讓我們一起縷一縷啊，最好是配合代碼一起看，否則太抽象了……

        (1) 首先，_Worker線程通過GetQueuedCompletionStatus()裏會收到一個lpCompletionKey，這個也就是PER_SOCKET_CONTEXT，裏面保存了與這個I/O相關的Socket和Overlapped還有客戶端發來的第一組數據等等，對吧？但是這裏得注意，這個SOCKET的上下文數據，是關於監聽Socket的，而不是新連入的這個客戶端Socket的，千萬別弄混了……

        (2) 所以，AcceptEx不是給咱們新連入的這個Socket早就建好了一個Socket嗎？所以這裏，我們需要再用這個新Socket重新爲新客戶端建立一個PER_SOCKET_CONTEXT，以及下面一系列的新PER_IO_CONTEXT，千萬不要去動傳入的這個Listen Socket上的PER_SOCKET_CONTEXT，也不要用傳入的這個Overlapped信息，因爲這個是屬於AcceptEx I/O操作的，也不是屬於你投遞的那個Recv I/O操作的……，要不你下次繼續監聽的時候就悲劇了……

        (3) 等到新的Socket準備完畢了，我們就趕緊還是用傳入的這個Listen Socket上的PER_SOCKET_CONTEXT和PER_IO_CONTEXT去繼續投遞下一個AcceptEx，循環起來，留在這裏太危險了，早晚得被人給改了……

        (4) 而我們新的Socket的上下文數據和I/O操作數據都準備好了之後，我們要做兩件事情：一件事情是把這個新的Socket和我們唯一的那個完成端口綁定，這個就不用細說了，和前面綁定監聽Socket是一樣的；然後就是在這個Socket上投遞第一個I/O操作請求，在我的示例代碼裏投遞的是WSARecv()。因爲後續的WSARecv，就不是在這裏投遞的了，這裏只負責第一個請求。

        但是，至於WSARecv請求如何來投遞的，我們放到下一節中去講，這一節，我們還有一個很重要的事情，我得給大家提一下，就是在客戶端連入的時候，我們如何來獲取客戶端的連入地址信息。

         這裏我們還需要引入另外一個很高端的函數，GetAcceptExSockAddrs()，它和AcceptEx()一樣，都是微軟提供的擴展函數，所以同樣需要通過下面的方式來導入纔可以使用……

WSAIoctl(
    m_pListenContext->m_Socket,
    SIO_GET_EXTENSION_FUNCTION_POINTER,
    &GuidGetAcceptExSockAddrs,
    sizeof(GuidGetAcceptExSockAddrs),
    &m_lpfnGetAcceptExSockAddrs,
    sizeof(m_lpfnGetAcceptExSockAddrs),
    &dwBytes,
    NULL,
    NULL);

        和導出AcceptEx一樣一樣的，同樣是需要用其GUID來獲取對應的函數指針 m_lpfnGetAcceptExSockAddrs 。

        說了這麼多，這個函數究竟是幹嘛用的呢？它是名副其實的“AcceptEx之友”，爲什麼這麼說呢？因爲我前面提起過AcceptEx有個很神奇的功能，就是附帶一個神奇的緩衝區，這個緩衝區厲害了，包括了客戶端發來的第一組數據、本地的地址信息、客戶端的地址信息，三合一啊，你說神奇不神奇？

        這個函數從它字面上的意思也基本可以看得出來，就是用來解碼這個緩衝區的，是的，它不提供別的任何功能，就是專門用來解析AcceptEx緩衝區內容的。例如如下代碼：

PER_IO_CONTEXT* pIoContext = 本次通信用的I/O Context

SOCKADDR_IN* ClientAddr = NULL;
SOCKADDR_IN* LocalAddr = NULL;
int remoteLen = sizeof(SOCKADDR_IN), localLen = sizeof(SOCKADDR_IN);

m_lpfnGetAcceptExSockAddrs(pIoContext->m_wsaBuf.buf, pIoContext->m_wsaBuf.len - ((sizeof(SOCKADDR_IN)+16)*2),  sizeof(SOCKADDR_IN)+16, sizeof(SOCKADDR_IN)+16, (LPSOCKADDR*)&LocalAddr, &localLen, (LPSOCKADDR*)&ClientAddr, &remoteLen);

        解碼完畢之後，於是，我們就可以從如下的結構體指針中獲得很多有趣的地址信息了：

inet_ntoa(ClientAddr->sin_addr) 是客戶端IP地址

ntohs(ClientAddr->sin_port) 是客戶端連入的端口

inet_ntoa(LocalAddr ->sin_addr) 是本地IP地址

ntohs(LocalAddr ->sin_port) 是本地通訊的端口

pIoContext->m_wsaBuf.buf 是存儲客戶端發來第一組數據的緩衝區

 

自從用了“AcceptEx之友”，一切都清淨了….

         【第七步】當收到Recv通知時, _DoRecv()

         在講解如何處理Recv請求之前，我們還是先講一下如何投遞WSARecv請求的。

         WSARecv大體的代碼如下，其實就一行，在代碼中我們可以很清楚的看到我們用到了很多新建的PerIoContext的參數，這裏再強調一下，注意一定要是自己另外新建的啊，一定不能是Worker線程裏傳入的那個PerIoContext，因爲那個是監聽Socket的，別給人弄壞了……：

int nBytesRecv = WSARecv(pIoContext->m_Socket, pIoContext ->p_wbuf, 1, &dwBytes, 0, pIoContext->p_ol, NULL);

        這裏，我再把WSARev函數的原型再給各位講一下

int WSARecv(
    SOCKET s,                      // 當然是投遞這個操作的套接字
     LPWSABUF lpBuffers,            // 接收緩衝區
                                        // 這裏需要一個由WSABUF結構構成的數組
     DWORD dwBufferCount,           // 數組中WSABUF結構的數量，設置爲1即可
     LPDWORD lpNumberOfBytesRecvd,  // 如果接收操作立即完成，這裏會返回函數調用所接收到的字節數
     LPDWORD lpFlags,               // 說來話長了，我們這裏設置爲0 即可
     LPWSAOVERLAPPED lpOverlapped,  // 這個Socket對應的重疊結構
     NULL                           // 這個參數只有完成例程模式纔會用到，
                                        // 完成端口中我們設置爲NULL即可
);

         其實裏面的參數，如果你們熟悉或者看過我以前的重疊I/O的文章，應該都比較熟悉，只需要注意其中的兩個參數：

• LPWSABUF lpBuffers;

        這裏是需要我們自己new 一個 WSABUF 的結構體傳進去的；

        如果你們非要追問 WSABUF 結構體是個什麼東東？我就給各位多說兩句，就是在ws2def.h中有定義的，定義如下：

typedef struct _WSABUF {
               ULONG len; /* the length of the buffer */
               __field_bcount(len) CHAR FAR *buf; /* the pointer to the buffer */

        } WSABUF, FAR * LPWSABUF;

         而且好心的微軟還附贈了註釋，真不容易….

         看到了嗎？如果對於裏面的一些奇怪符號你們看不懂的話，也不用管他，只用看到一個ULONG和一個CHAR*就可以了，這不就是一個是緩衝區長度，一個是緩衝區指針麼？至於那個什麼 FAR…..讓他見鬼去吧，現在已經是32位和64位時代了……

        這裏需要注意的，我們的應用程序接到數據到達的通知的時候，其實數據已經被咱們的主機接收下來了，我們直接通過這個WSABUF指針去系統緩衝區拿數據就好了，而不像那些沒用重疊I/O的模型，接收到有數據到達的通知的時候還得自己去另外recv，太低端了……這也是爲什麼重疊I/O比其他的I/O性能要好的原因之一。

• LPWSAOVERLAPPED lpOverlapped

         這個參數就是我們所謂的重疊結構了，就是這樣定義，然後在有Socket連接進來的時候，生成並初始化一下，然後在投遞第一個完成請求的時候，作爲參數傳遞進去就可以，

OVERLAPPED* m_pol = new OVERLAPPED;

eroMemory(m_pol, sizeof(OVERLAPPED));

        在第一個重疊請求完畢之後，我們的這個OVERLAPPED 結構體裏，就會被分配有效的系統參數了，並且我們是需要每一個Socket上的每一個I/O操作類型，都要有一個唯一的Overlapped結構去標識。

        這樣，投遞一個WSARecv就講完了，至於_DoRecv()需要做些什麼呢？其實就是做兩件事：

        (1) 把WSARecv裏這個緩衝區裏收到的數據顯示出來；

        (2) 發出下一個WSARecv()；

        Over……

        至此，我們終於深深的喘口氣了，完成端口的大部分工作我們也完成了，也非常感謝各位耐心的看我這麼枯燥的文字一直看到這裏，真是一個不容易的事情！！

       【第八步】如何關閉完成端口

        休息完畢，我們繼續……

        各位看官不要高興得太早，雖然我們已經讓我們的完成端口順利運作起來了，但是在退出的時候如何釋放資源咱們也是要知道的，否則豈不是功虧一簣…..

        從前面的章節中，我們已經瞭解到，Worker線程一旦進入了GetQueuedCompletionStatus()的階段，就會進入睡眠狀態，INFINITE的等待完成端口中，如果完成端口上一直都沒有已經完成的I/O請求，那麼這些線程將無法被喚醒，這也意味着線程沒法正常退出。

        熟悉或者不熟悉多線程編程的朋友，都應該知道，如果在線程睡眠的時候，簡單粗暴的就把線程關閉掉的話，那是會一個很可怕的事情，因爲很多線程體內很多資源都來不及釋放掉，無論是這些資源最後是否會被操作系統回收，我們作爲一個C++程序員來講，都不應該允許這樣的事情出現。

        所以我們必須得有一個很優雅的，讓線程自己退出的辦法。

       這時會用到我們這次見到的與完成端口有關的最後一個API，叫 PostQueuedCompletionStatus()，從名字上也能看得出來，這個是和 GetQueuedCompletionStatus() 函數相對的，這個函數的用途就是可以讓我們手動的添加一個完成端口I/O操作，這樣處於睡眠等待的狀態的線程就會有一個被喚醒，如果爲我們每一個Worker線程都調用一次PostQueuedCompletionStatus()的話，那麼所有的線程也就會因此而被喚醒了。

       PostQueuedCompletionStatus()函數的原型是這樣定義的：

BOOL WINAPI PostQueuedCompletionStatus(
                   __in      HANDLE CompletionPort,
                   __in      DWORD dwNumberOfBytesTransferred,
                   __in      ULONG_PTR dwCompletionKey,
                   __in_opt  LPOVERLAPPED lpOverlapped
);

        我們可以看到，這個函數的參數幾乎和GetQueuedCompletionStatus()的一模一樣，都是需要把我們建立的完成端口傳進去，然後後面的三個參數是 傳輸字節數、結構體參數、重疊結構的指針.

       注意，這裏也有一個很神奇的事情，正常情況下，GetQueuedCompletionStatus()獲取回來的參數本來是應該是系統幫我們填充的，或者是在綁定完成端口時就有的，但是我們這裏卻可以直接使用PostQueuedCompletionStatus()直接將後面三個參數傳遞給GetQueuedCompletionStatus()，這樣就非常方便了。

       例如，我們爲了能夠實現通知線程退出的效果，可以自己定義一些約定，比如把這後面三個參數設置一個特殊的值，然後Worker線程接收到完成通知之後，通過判斷這3個參數中是否出現了特殊的值，來決定是否是應該退出線程了。

       例如我們在調用的時候，就可以這樣：

for (int i = 0; i < m_nThreads; i++)
{
      PostQueuedCompletionStatus(m_hIOCompletionPort, 0, (DWORD) NULL, NULL);
}

        爲每一個線程都發送一個完成端口數據包，有幾個線程就發送幾遍，把其中的dwCompletionKey參數設置爲NULL，這樣每一個Worker線程在接收到這個完成通知的時候，再自己判斷一下這個參數是否被設置成了NULL，因爲正常情況下，這個參數總是會有一個非NULL的指針傳入進來的，如果Worker發現這個參數被設置成了NULL，那麼Worker線程就會知道，這是應用程序再向Worker線程發送的退出指令，這樣Worker線程在內部就可以自己很“優雅”的退出了……

        學會了嗎？

        但是這裏有一個很明顯的問題，聰明的朋友一定想到了，而且只有想到了這個問題的人，纔算是真正看明白了這個方法。

        我們只是發送了m_nThreads次，我們如何能確保每一個Worker線程正好就收到一個，然後所有的線程都正好退出呢？是的，我們沒有辦法保證，所以很有可能一個Worker線程處理完一個完成請求之後，發生了某些事情，結果又再次去循環接收下一個完成請求了，這樣就會造成有的Worker線程沒有辦法接收到我們發出的退出通知。

        所以，我們在退出的時候，一定要確保Worker線程只調用一次GetQueuedCompletionStatus()，這就需要我們自己想辦法了，各位請參考我在Worker線程中實現的代碼，我搭配了一個退出的Event，在退出的時候SetEvent一下，來確保Worker線程每次就只會調用一輪 GetQueuedCompletionStatus() ，這樣就應該比較安全了。

        另外，在Vista/Win7系統中，我們還有一個更簡單的方式，我們可以直接CloseHandle關掉完成端口的句柄，這樣所有在GetQueuedCompletionStatus()的線程都會被喚醒，並且返回FALSE，這時調用GetLastError()獲取錯誤碼時，會返回ERROR_INVALID_HANDLE，這樣每一個Worker線程就可以通過這種方式輕鬆簡單的知道自己該退出了。當然，如果我們不能保證我們的應用程序只在Vista/Win7中，那還是老老實實的PostQueuedCompletionStatus()吧。

        最後，在系統釋放資源的最後階段，切記，因爲完成端口同樣也是一個Handle，所以也得用CloseHandle將這個句柄關閉，當然還要記得用closesocket關閉一系列的socket，還有別的各種指針什麼的，這都是作爲一個合格的C++程序員的基本功，在這裏就不多說了，如果還是有不太清楚的朋友，請參考我的示例代碼中的 StopListen() 和DeInitialize() 函數。

 

六． 完成端口使用中的注意事項

        終於到了文章的結尾了，不知道各位朋友是基本學會了完成端口的使用了呢，還是被完成端口以及我這麼多口水的文章折磨得不行了……

        最後再補充一些前面沒有提到了，實際應用中的一些注意事項吧。

       1. Socket的通信緩衝區設置成多大合適？

        在x86的體系中，內存頁面是以4KB爲單位來鎖定的，也就是說，就算是你投遞WSARecv()的時候只用了1KB大小的緩衝區，系統還是得給你分4KB的內存。爲了避免這種浪費，最好是把發送和接收數據的緩衝區直接設置成4KB的倍數。

       2.  關於完成端口通知的次序問題

        這個不用想也能知道，調用GetQueuedCompletionStatus() 獲取I/O完成端口請求的時候，肯定是用先入先出的方式來進行的。

        但是，咱們大家可能都想不到的是，喚醒那些調用了GetQueuedCompletionStatus()的線程是以後入先出的方式來進行的。

        比如有4個線程在等待，如果出現了一個已經完成的I/O項，那麼是最後一個調用GetQueuedCompletionStatus()的線程會被喚醒。平常這個次序倒是不重要，但是在對數據包順序有要求的時候，比如傳送大塊數據的時候，是需要注意下這個先後次序的。

        -- 微軟之所以這麼做，那當然是有道理的，這樣如果反覆只有一個I/O操作而不是多個操作完成的話，內核就只需要喚醒同一個線程就可以了，而不需要輪着喚醒多個線程，節約了資源，而且可以把其他長時間睡眠的線程換出內存，提到資源利用率。

       3.  如果各位想要傳輸文件…

        如果各位需要使用完成端口來傳送文件的話，這裏有個非常需要注意的地方。因爲發送文件的做法，按照正常人的思路來講，都會是先打開一個文件，然後不斷的循環調用ReadFile()讀取一塊之後，然後再調用WSASend ()去發發送。

        但是我們知道，ReadFile()的時候，是需要操作系統通過磁盤的驅動程序，到實際的物理硬盤上去讀取文件的，這就會使得操作系統從用戶態轉換到內核態去調用驅動程序，然後再把讀取的結果返回至用戶態；同樣的道理，WSARecv()也會涉及到從用戶態到內核態切換的問題 --- 這樣就使得我們不得不頻繁的在用戶態到內核態之間轉換，效率低下……

        而一個非常好的解決方案是使用微軟提供的擴展函數TransmitFile()來傳輸文件，因爲只需要傳遞給TransmitFile()一個文件的句柄和需要傳輸的字節數，程序就會整個切換至內核態，無論是讀取數據還是發送文件，都是直接在內核態中執行的，直到文件傳輸完畢纔會返回至用戶態給主進程發送通知。這樣效率就高多了。

       4. 關於重疊結構數據釋放的問題

        我們既然使用的是異步通訊的方式，就得要習慣一點，就是我們投遞出去的完成請求，不知道什麼時候我們才能收到操作完成的通知，而在這段等待通知的時間，我們就得要千萬注意得保證我們投遞請求的時候所使用的變量在此期間都得是有效的。

        例如我們發送WSARecv請求時候所使用的Overlapped變量，因爲在操作完成的時候，這個結構裏面會保存很多很重要的數據，對於設備驅動程序來講，指示保存着我們這個Overlapped變量的指針，而在操作完成之後，驅動程序會將Buffer的指針、已經傳輸的字節數、錯誤碼等等信息都寫入到我們傳遞給它的那個Overlapped指針中去。如果我們已經不小心把Overlapped釋放了，或者是又交給別的操作使用了的話，誰知道驅動程序會把這些東西寫到哪裏去呢？豈不是很崩潰……

        暫時我想到的問題就是這麼多吧，如果各位真的是要正兒八經寫一個承受很大訪問壓力的Server的話，你慢慢就會發現，只用我附帶的這個示例代碼是不夠的，還得需要在很多細節之處進行改進，例如用更好的數據結構來管理上下文數據，並且需要非常完善的異常處理機制等等，總之，非常期待大家的批評和指正。

        謝謝大家看到這裏！！！