Posted on 2017-06-23 09:41 talenth 閱讀(7936) 評論(7) 編輯 收藏

修改自: http://blog.csdn.net/piggyxp/article/details/6922277

ps: 原作者很厲害了, 把一個iocp模型講解的這麼形象,不過在實踐過程中發現一些細節說得有問題, 在文中標紅指出, 另外刪掉了原文中一些我認為有些多餘的話

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

　　源地址已經失效了, 以下是原始檔的一份copy

　　https://files.cnblogs.com/files/talenth/PiggyStressTestClient.rar

　　https://files.cnblogs.com/files/talenth/IOCPExample_By_PiggyXP.rar

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

目錄：

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++》 5th 的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使用起來要麻煩得多……

五． 完成埠的實現詳解

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

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

       【第一步】建立一個完成埠

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

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

[cpp] view plaincopy

1. 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的數量，這個是基本功，我就不多說了，程式碼如下：

[cpp] view plaincopy

1. SYSTEM_INFO si;  
2. GetSystemInfo(&si);  
3. 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”個執行緒，我想這個應該沒有什麼太大的區別，我就是按照我自己的習慣來了。

　　上面的建立cpu核心數量*2的執行緒, 是msdn上建議的, 上面有解釋, 主要就是為了提高效能, 不是什麼江湖傳言!

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

        什麼？Worker執行緒不會建？

        …囧…

       Worker執行緒和普通執行緒是一樣一樣的啊~~~，程式碼大致上如下：

[cpp] view plaincopy

1. // 根據CPU數量，建立*2的執行緒  
2.   m_nThreads = 2 * m_nProcessors;  
3.  HANDLE* m_phWorkerThreads = new HANDLE[m_nThreads];  
4.  for (int i = 0; i < m_nThreads; i++)  
5.  {  
6.      m_phWorkerThreads[i] = ::CreateThread(0, 0, _WorkerThread, …);  
7.  }  

       其中，_WorkerThread是Worker執行緒的執行緒函式，執行緒函式的具體內容我們後面再講。

     【第三步】建立一個用於監聽的Socket，繫結到完成埠上，然後開始在指定的埠上監聽連線請求

       最重要的完成埠建立完畢了，我們就可以利用這個完成埠來進行網路通訊了。

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

[cpp] view plaincopy

1. // 初始化Socket庫  
2. WSADATA wsaData;  
3. WSAStartup(MAKEWORD(2,2), &wsaData);  
4. //初始化Socket  
5. struct sockaddr_in ServerAddress;  
6. // 這裡需要特別注意，如果要使用重疊I/O的話，這裡必須要使用WSASocket來初始化Socket  
7. // 注意裡面有個WSA_FLAG_OVERLAPPED引數  
8. SOCKET m_sockListen = WSASocket(AF_INET, SOCK_STREAM, 0, NULL, 0, WSA_FLAG_OVERLAPPED);  
9. // 填充地址結構資訊  
10. ZeroMemory((char *)&ServerAddress, sizeof(ServerAddress));  
11. ServerAddress.sin_family = AF_INET;  
12. // 這裡可以選擇繫結任何一個可用的地址，或者是自己指定的一個IP地址   
13. //ServerAddress.sin_addr.s_addr = htonl(INADDR_ANY);                        
14. ServerAddress.sin_addr.s_addr = inet_addr(“你的IP”);           
15. ServerAddress.sin_port = htons(11111);                            
16. // 繫結埠  
17. if (SOCKET_ERROR == bind(m_sockListen, (struct sockaddr *) &ServerAddress, sizeof(ServerAddress)))   
18. // 開始監聽  
19. 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()的幾個引數：

[cpp] view plaincopy

1.  HANDLE WINAPI CreateIoCompletionPort(  
2.     __in      HANDLE  FileHandle,             // 這裡當然是連入的這個套接字控制代碼了  
3.      __in_opt  HANDLE  ExistingCompletionPort, // 這個就是前面建立的那個完成埠  
4.      __in      ULONG_PTR CompletionKey,        // 這個引數就是類似於執行緒引數一樣，在  
5.                                                // 繫結的時候把自己定義的結構體指標傳遞  
6.                                                // 這樣到了Worker執行緒中，也可以使用這個  
7.                                                // 結構體的資料了，相當於引數的傳遞  
8.      __in      DWORD NumberOfConcurrentThreads // 這裡同樣置0  
9. );  

         這些引數也沒什麼好講的吧，用處一目瞭然了。而對於其中的那個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函式指標的程式碼大致如下：

[cpp] view plaincopy

1.        LPFN_ACCEPTEX     m_lpfnAcceptEx;         // AcceptEx函式指標  
2.         GUID GuidAcceptEx = WSAID_ACCEPTEX;        // GUID，這個是識別AcceptEx函式必須的  
3. DWORD dwBytes = 0;    
4. WSAIoctl(  
5.     m_pListenContext->m_Socket,   
6.     SIO_GET_EXTENSION_FUNCTION_POINTER,   
7.     &GuidAcceptEx,   
8.     sizeof(GuidAcceptEx),   
9.     &m_lpfnAcceptEx,   
10.     sizeof(m_lpfnAcceptEx),   
11.     &dwBytes,   
12.     NULL,   
13.     NULL);  

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

        然後，我們就可以通過其中的指標m_lpfnAcceptEx呼叫AcceptEx函數了。

       AcceptEx函式的定義如下：

[cpp] view plaincopy 

1. BOOL AcceptEx (       
2.                SOCKET sListenSocket,   
3.                SOCKET sAcceptSocket,   
4.                PVOID lpOutputBuffer,   
5.                DWORD dwReceiveDataLength,   
6.                DWORD dwLocalAddressLength,   
7.                DWORD dwRemoteAddressLength,   
8.                LPDWORD lpdwBytesReceived,   
9.                LPOVERLAPPED lpOverlapped   
10. );  

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

• 引數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)，也就是說總長度減去兩個地址空間的長度就是了，看起來複雜，其實想明白了也沒啥……（這裡有兩個問題,1 這個16是微軟規定的, 必須是地址長度+16; 2 這個buf在返回的時候是存放監聽地址, 客戶端的連入地址, 還有可能接收到的資料, 也就是說這個變數賦的值是buf長度減去兩個地址的長度）

• 引數5--dwLocalAddressLength，存放本地址地址資訊的空間大小；

• 引數6--dwRemoteAddressLength，存放本遠端地址資訊的空間大小；

• 引數7--lpdwBytesReceived，out引數，對我們來說沒用，不用管；

• 引數8--lpOverlapped，本次重疊I/O所要用到的重疊結構。

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

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

        聰明的你肯定想到了，是的，Windows核心也幫我們想到了：用一個標誌來繫結每一個IO操作，這樣到了Worker執行緒內部的時候，收到網路操作完成的通知之後，再通過這個標誌來找出這組返回的資料到底對應的是哪個Io操作的。

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

1. typedef struct _PER_IO_CONTEXT{  
2.   OVERLAPPED   m_Overlapped;          // 每一個重疊I/O網路操作都要有一個                
3.    SOCKET       m_sockAccept;          // 這個I/O操作所使用的Socket，每個連線的都是一樣的  
4.    WSABUF       m_wsaBuf;              // 儲存資料的緩衝區，用來給重疊操作傳遞引數的，關於WSABUF後面還會講  
5.    char         m_szBuffer[MAX_BUFFER_LEN]; // 對應WSABUF裡的緩衝區  
6.    OPERATION_TYPE  m_OpType;               // 標誌這個重疊I/O操作是做什麼的，例如Accept/Recv等  
7.  } 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了，我在程式碼中是這樣定義的：

1. typedef struct _PER_SOCKET_CONTEXT  
2. {    
3.   SOCKET                   m_Socket;              // 每一個客戶端連線的Socket  
4.   SOCKADDR_IN              m_ClientAddr;          // 這個客戶端的地址  
5.   CArray<_PER_IO_CONTEXT*>  m_arrayIoContext;   // 陣列，所有客戶端IO操作的引數，  
6.                                                         // 也就是說對於每一個客戶端Socket  
7.                                                       // 是可以在上面同時投遞多個IO請求的  
8. } PER_SOCKET_CONTEXT, *PPER_SOCKET_CONTEXT;  

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

         當然，同樣的，各位對於這些也可以按照自己的想法來隨便定義，只要能起到管理每一個IO請求上需要傳遞的網路引數的目的就好了，關鍵就是需要跟蹤這些引數的狀態，在必要的時候釋放這些資源，不要造成記憶體洩漏，因為作為Server總是需要長時間執行的，所以如果有記憶體洩露的情況那是非常可怕的，一定要杜絕一絲一毫的記憶體洩漏。（ps：程式碼中有很多記憶體洩露的地方...）

        至於具體這兩個結構體引數是如何在Worker執行緒裡大發神威的，我們後面再看。

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

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

        【第五步】我們再來看看Worker執行緒都做了些什麼

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

        (1) 使用 GetQueuedCompletionStatus() 監控完成埠

        首先這個工作所要做的工作大家也能猜到，無非就是幾個Worker執行緒哥幾個一起排好隊隊來監視完成埠的佇列中是否有完成的網路操作就好了，程式碼大體如下：

1. void *lpContext = NULL;  
2. OVERLAPPED        *pOverlapped = NULL;  
3. DWORD            dwBytesTransfered = 0;  
4. BOOL bReturn  =  GetQueuedCompletionStatus(  
5.                                      pIOCPModel->m_hIOCompletionPort,  
6.                              　　&dwBytesTransfered,  
7.                                      (LPDWORD)&lpContext,  
8.                                     &pOverlapped,  
9.                                     INFINITE );  

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

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

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

1. BOOL WINAPI GetQueuedCompletionStatus(  
2.     __in   HANDLE          CompletionPort,    // 這個就是我們建立的那個唯一的完成埠  
3.     __out  LPDWORD         lpNumberOfBytes,   //這個是操作完成後返回的位元組數  
4.     __out  PULONG_PTR      lpCompletionKey,   // 這個是我們建立完成埠的時候繫結的那個自定義結構體引數  
5.     __out  LPOVERLAPPED    *lpOverlapped,     // 這個是我們在連入Socket的時候一起建立的那個重疊結構  
6.     __in   DWORD           dwMilliseconds     // 等待完成埠的超時時間，如果執行緒不需要做其他的事情，那就INFINITE就行了  
7.     ); 

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

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

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

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

        這個問題問得好！

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

        (1) 這個引數，是在你繫結Socket到一個完成埠的時候，用的CreateIoCompletionPort()函式，傳入的那個CompletionKey引數，要是忘了的話，就翻到文件的“第三步”看看相關的內容；我們在這裡傳入的是定義的PER_SOCKET_CONTEXT，也就是說“單控制代碼資料”，因為我們繫結的是一個Socket，這裡自然也就需要傳入Socket相關的上下文，你是怎麼傳過去的，這裡收到的就會是什麼樣子，也就是說這個lpCompletionKey就是我們的PER_SOCKET_CONTEXT，直接把裡面的資料拿出來用就可以了。

(簡單來說就是, 你在呼叫CreateIoCompletionPort把socket繫結到iocp時傳入的第三個引數是什麼, GetQueuedCompletionStatus第三個引數就會返回什麼)

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

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

         這個巨集的含義，就是去傳入的lpOverlapped變數裡，找到和結構體中PER_IO_CONTEXT中m_Overlapped成員相關的資料。

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

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

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

（這個跟上面的有點類似， 就是你在投遞非同步操作， 像非同步accpet，非同步收， 非同步發的時候， 會傳入一個Overlapped的指標, 這裡就會返回當時的指標,上面那個巨集, 會根據這個指標, 以及這個變數在io_context的位置, 計算出io_context結構體的指標, 這也就是io_context為什麼需要包含Overlapped型別的變數的原因, 但是Overlapped不必定義為io_context的第一個成員, 這個在上面的巨集實現裡面可以看出來, 如果不明白巨集實現的原理, 請使用bing）

       【第六步】當收到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

        (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()一樣，都是微軟提供的擴充套件函式，所以同樣需要通過下面的方式來匯入才可以使用……

1. WSAIoctl(  
2.     m_pListenContext->m_Socket,   
3.     SIO_GET_EXTENSION_FUNCTION_POINTER,   
4.     &GuidGetAcceptExSockAddrs,  
5.     sizeof(GuidGetAcceptExSockAddrs),   
6.     &m_lpfnGetAcceptExSockAddrs,   
7.     sizeof(m_lpfnGetAcceptExSockAddrs),     
8.     &dwBytes,   
9.     NULL,   
10.     NULL);  

        和匯出AcceptEx一樣一樣的，同樣是需要用其GUID來獲取對應的函式指標 m_lpfnGetAcceptExSockAddrs 。

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

(神奇個蛋, 這個就是把兩個網路地址資料拷貝出來的函式, 自己寫兩行程式碼就搞定了, 不過這裡需要注意是, 在buf裡面這兩個網路地址資料在buf中的起始地址是之前投遞非同步accept時的buf起始地址+那個dwReceiveDataLength值, 簡單來說就是說在buf的末尾存放兩個網路地址資料, 因此呼叫函式的時候要與之前投遞非同步accept時候的相關引數對應, 另外還有一點就是 此時 lpNumberOfBytes 指向的dword儲存的是除兩個地址資料以外受到的資料的位元組數)

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

1. PER_IO_CONTEXT* pIoContext = 本次通訊用的I/O Context  
2. SOCKADDR_IN* ClientAddr = NULL;  
3. SOCKADDR_IN* LocalAddr = NULL;    
4. int remoteLen = sizeof(SOCKADDR_IN), localLen = sizeof(SOCKADDR_IN);    
5. 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的引數

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

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

1. int WSARecv(  
2.     SOCKET s,                      // 當然是投遞這個操作的套接字  
3.      LPWSABUF lpBuffers,            // 接收緩衝區   
4.                                         // 這裡需要一個由WSABUF結構構成的陣列  
5.      DWORD dwBufferCount,           // 陣列中WSABUF結構的數量，設定為1即可  
6.      LPDWORD lpNumberOfBytesRecvd,  // 如果接收操作立即完成，這裡會返回函式呼叫所接收到的位元組數  
7.      LPDWORD lpFlags,               // 說來話長了，我們這裡設定為0 即可  
8.