手把手教你玩转SOCKET模型：完成端口(Completion Port)详解
? ? 這篇文檔我非常詳細(xì)并且圖文并茂的介紹了關(guān)于網(wǎng)絡(luò)編程模型中完成端口的方方面面的信息，從API的用法到使用的步驟，從完成端口的實現(xiàn)機(jī)理到實際使用的注意事項，都有所涉及，并且為了讓朋友們更直觀的體會完成端口的用法，本文附帶了有詳盡注釋的使用MFC編寫的圖形界面的示例代碼。
??? 我的初衷是希望寫一份互聯(lián)網(wǎng)上能找到的最詳盡的關(guān)于完成端口的教學(xué)文檔，而且讓對Socket編程略有了解的人都能夠看得懂，都能學(xué)會如何來使用完成端口這么優(yōu)異的網(wǎng)絡(luò)編程模型，但是由于本人水平所限，不知道我的初衷是否實現(xiàn)了，但還是希望各位需要的朋友能夠喜歡。
相關(guān)閱讀----
????1）手把手教你玩轉(zhuǎn)SOCKET模型：重疊I/O篇
????2）手把手教你玩轉(zhuǎn)SOCKET模型：完成例程(Completion Routine)篇
??????? 由于篇幅原因，本文假設(shè)你已經(jīng)熟悉了利用Socket進(jìn)行TCP/IP編程的基本原理，并且也熟練的掌握了多線程編程技術(shù)，太基本的概念我這里就略過不提了，網(wǎng)上的資料應(yīng)該遍地都是。
??????? 本文檔凝聚著筆者心血，如要轉(zhuǎn)載，請指明原作者及出處，謝謝！不過代碼沒有版權(quán)，可以隨便散播使用，歡迎改進(jìn)，特別是非常歡迎能夠幫助我發(fā)現(xiàn)Bug的朋友，以更好的造福大家。^_^
??????? 忘了囑咐一下了，文章篇幅很長很長，基本涉及到了與完成端口有關(guān)的方方面面，一次看不完可以分好幾次，中間注意休息，好身體才是咱們程序員最大的本錢！
?????? 對了，還忘了囑咐一下，因為本人的水平有限，雖然我反復(fù)修正了數(shù)遍，但文章和示例代碼里肯定還有我沒發(fā)現(xiàn)的錯誤和紕漏，希望各位一定要指出來，拍磚、噴我，我都能Hold住，但是一定要指出來，我會及時修正，因為我不想讓文中的錯誤傳遍互聯(lián)網(wǎng)，禍害大家。
????? OK, Let’s go ! Have fun !
目錄：
1． 完成端口的優(yōu)點
2． 完成端口程序的運行演示
3． 完成端口的相關(guān)概念
4． 完成端口的基本流程
5． 完成端口的使用詳解
6． 實際應(yīng)用中應(yīng)該要注意的地方
一． 完成端口的優(yōu)點
??????? 1. 我想只要是寫過或者想要寫C/S模式網(wǎng)絡(luò)服務(wù)器端的朋友，都應(yīng)該或多或少的聽過完成端口的大名吧，完成端口會充分利用Windows內(nèi)核來進(jìn)行I/O的調(diào)度，是用于C/S通信模式中性能最好的網(wǎng)絡(luò)通信模型，沒有之一；甚至連和它性能接近的通信模型都沒有。
??????? 2. 完成端口和其他網(wǎng)絡(luò)通信方式最大的區(qū)別在哪里呢？
??????? (1) 首先，如果使用“同步”的方式來通信的話，這里說的同步的方式就是說所有的操作都在一個線程內(nèi)順序執(zhí)行完成，這么做缺點是很明顯的：因為同步的通信操作會阻塞住來自同一個線程的任何其他操作，只有這個操作完成了之后，后續(xù)的操作才可以完成；一個最明顯的例子就是咱們在MFC的界面代碼中，直接使用阻塞Socket調(diào)用的代碼，整個界面都會因此而阻塞住沒有響應(yīng)！所以我們不得不為每一個通信的Socket都要建立一個線程，多麻煩？這不坑爹呢么？所以要寫高性能的服務(wù)器程序，要求通信一定要是異步的。
??????? (2) 各位讀者肯定知道，可以使用使用“同步通信(阻塞通信)+多線程”的方式來改善(1)的情況，那么好，想一下，我們好不容易實現(xiàn)了讓服務(wù)器端在每一個客戶端連入之后，都要啟動一個新的Thread和客戶端進(jìn)行通信，有多少個客戶端，就需要啟動多少個線程，對吧；但是由于這些線程都是處于運行狀態(tài)，所以系統(tǒng)不得不在所有可運行的線程之間進(jìn)行上下文的切換，我們自己是沒啥感覺，但是CPU卻痛苦不堪了，因為線程切換是相當(dāng)浪費CPU時間的，如果客戶端的連入線程過多，這就會弄得CPU都忙著去切換線程了，根本沒有多少時間去執(zhí)行線程體了，所以效率是非常低下的，承認(rèn)坑爹了不？
??????? (3) 而微軟提出完成端口模型的初衷，就是為了解決這種"one-thread-per-client"的缺點的，它充分利用內(nèi)核對象的調(diào)度，只使用少量的幾個線程來處理和客戶端的所有通信，消除了無謂的線程上下文切換，最大限度的提高了網(wǎng)絡(luò)通信的性能，這種神奇的效果具體是如何實現(xiàn)的請看下文。
??????? 3. 完成端口被廣泛的應(yīng)用于各個高性能服務(wù)器程序上，例如著名的Apache….如果你想要編寫的服務(wù)器端需要同時處理的并發(fā)客戶端連接數(shù)量有數(shù)百上千個的話，那不用糾結(jié)了，就是它了。
二． 完成端口程序的運行演示
??????? 首先，我們先來看一下完成端口在筆者的PC機(jī)上的運行表現(xiàn)，筆者的PC配置如下：
??????? 大體就是i7 2600 + 16GB內(nèi)存，我以這臺PC作為服務(wù)器，簡單的進(jìn)行了如下的測試，通過Client生成3萬個并發(fā)線程同時連接至Server，然后每個線程每隔3秒鐘發(fā)送一次數(shù)據(jù)，一共發(fā)送3次，然后觀察服務(wù)器端的CPU和內(nèi)存的占用情況。
??????? 如圖2所示，是客戶端3萬個并發(fā)線程發(fā)送共發(fā)送9萬條數(shù)據(jù)的log截圖
??????? 圖3是服務(wù)器端接收完畢3萬個并發(fā)線程和每個線程的3份數(shù)據(jù)后的log截圖
??????? 最關(guān)鍵是圖4，圖4是服務(wù)器端在接收到28000個并發(fā)線程的時候，CPU占用率的截圖，使用的軟件是大名鼎鼎的Process Explorer，因為相對來講這個比自帶的任務(wù)管理器要準(zhǔn)確和精確一些。
???????? 我們可以發(fā)現(xiàn)一個令人驚訝的結(jié)果，采用了完成端口的Server程序(藍(lán)色橫線所示)所占用的CPU才為 3.82%，整個運行過程中的峰值也沒有超過4%，是相當(dāng)氣定神閑的……哦，對了，這還是在Debug環(huán)境下運行的情況，如果采用Release方式執(zhí)行，性能肯定還會更高一些，除此以外，在UI上顯示信息也很大成都上影響了性能。
???????? 相反采用了多個并發(fā)線程的Client程序(紫色橫線所示)居然占用的CPU高達(dá)11.53%，甚至超過了Server程序的數(shù)倍……
???????? 其實無論是哪種網(wǎng)絡(luò)操模型，對于內(nèi)存占用都是差不多的，真正的差別就在于CPU的占用，其他的網(wǎng)絡(luò)模型都需要更多的CPU動力來支撐同樣的連接數(shù)據(jù)。
???????? 雖然這遠(yuǎn)遠(yuǎn)算不上服務(wù)器極限壓力測試，但是從中也可以看出來完成端口的實力，而且這種方式比純粹靠多線程的方式實現(xiàn)并發(fā)資源占用率要低得多。
三． 完成端口的相關(guān)概念
???????? 在開始編碼之前，我們先來討論一下和完成端口相關(guān)的一些概念，如果你沒有耐心看完這段大段的文字的話，也可以跳過這一節(jié)直接去看下下一節(jié)的具體實現(xiàn)部分，但是這一節(jié)中涉及到的基本概念你還是有必要了解一下的，而且你也更能知道為什么有那么多的網(wǎng)絡(luò)編程模式不用，非得要用這么又復(fù)雜又難以理解的完成端口呢？？也會堅定你繼續(xù)學(xué)習(xí)下去的信心^_^
???????? 3.1 異步通信機(jī)制及其幾種實現(xiàn)方式的比較
???????? 我們從前面的文字中了解到，高性能服務(wù)器程序使用異步通信機(jī)制是必須的。
???????? 而對于異步的概念，為了方便后面文字的理解，這里還是再次簡單的描述一下：
???????? 異步通信就是在咱們與外部的I/O設(shè)備進(jìn)行打交道的時候，我們都知道外部設(shè)備的I/O和CPU比起來簡直是龜速，比如硬盤讀寫、網(wǎng)絡(luò)通信等等，我們沒有必要在咱們自己的線程里面等待著I/O操作完成再執(zhí)行后續(xù)的代碼，而是將這個請求交給設(shè)備的驅(qū)動程序自己去處理，我們的線程可以繼續(xù)做其他更重要的事情，大體的流程如下圖所示:
??????? 我可以從圖中看到一個很明顯的并行操作的過程，而“同步”的通信方式是在進(jìn)行網(wǎng)絡(luò)操作的時候，主線程就掛起了，主線程要等待網(wǎng)絡(luò)操作完成之后，才能繼續(xù)執(zhí)行后續(xù)的代碼，就是說要末執(zhí)行主線程，要末執(zhí)行網(wǎng)絡(luò)操作，是沒法這樣并行的；
??????? “異步”方式無疑比 “阻塞模式+多線程”的方式效率要高的多，這也是前者為什么叫“異步”，后者為什么叫“同步”的原因了，因為不需要等待網(wǎng)絡(luò)操作完成再執(zhí)行別的操作。
而在Windows中實現(xiàn)異步的機(jī)制同樣有好幾種，而這其中的區(qū)別，關(guān)鍵就在于圖1中的最后一步“通知應(yīng)用程序處理網(wǎng)絡(luò)數(shù)據(jù)”上了，因為實現(xiàn)操作系統(tǒng)調(diào)用設(shè)備驅(qū)動程序去接收數(shù)據(jù)的操作都是一樣的，關(guān)鍵就是在于如何去通知應(yīng)用程序來拿數(shù)據(jù)。它們之間的具體區(qū)別我這里多講幾點，文字有點多，如果沒興趣深入研究的朋友可以跳過下一面的這一段，不影響的:)
??????? (1)?設(shè)備內(nèi)核對象，使用設(shè)備內(nèi)核對象來協(xié)調(diào)數(shù)據(jù)的發(fā)送請求和接收數(shù)據(jù)協(xié)調(diào)，也就是說通過設(shè)置設(shè)備內(nèi)核對象的狀態(tài)，在設(shè)備接收數(shù)據(jù)完成后，馬上觸發(fā)這個內(nèi)核對象，然后讓接收數(shù)據(jù)的線程收到通知，但是這種方式太原始了，接收數(shù)據(jù)的線程為了能夠知道內(nèi)核對象是否被觸發(fā)了，還是得不停的掛起等待，這簡直是根本就沒有用嘛，太低級了，有木有？所以在這里就略過不提了，各位讀者要是沒明白是怎么回事也不用深究了，總之沒有什么用。
??????? (2)?事件內(nèi)核對象，利用事件內(nèi)核對象來實現(xiàn)I/O操作完成的通知，其實這種方式其實就是我以前寫文章的時候提到的《基于事件通知的重疊I/O模型》，鏈接在這里，這種機(jī)制就先進(jìn)得多，可以同時等待多個I/O操作的完成，實現(xiàn)真正的異步，但是缺點也是很明顯的，既然用WaitForMultipleObjects()來等待Event的話，就會受到64個Event等待上限的限制，但是這可不是說我們只能處理來自于64個客戶端的Socket，而是這是屬于在一個設(shè)備內(nèi)核對象上等待的64個事件內(nèi)核對象，也就是說，我們在一個線程內(nèi)，可以同時監(jiān)控64個重疊I/O操作的完成狀態(tài)，當(dāng)然我們同樣可以使用多個線程的方式來滿足無限多個重疊I/O的需求，比如如果想要支持3萬個連接，就得需要500多個線程…用起來太麻煩讓人感覺不爽；
??????? (3) 使用APC( Asynchronous Procedure Call，異步過程調(diào)用)來完成，這個也就是我以前在文章里提到的《基于完成例程的重疊I/O模型》，鏈接在這里，這種方式的好處就是在于擺脫了基于事件通知方式的64個事件上限的限制，但是缺點也是有的，就是發(fā)出請求的線程必須得要自己去處理接收請求，哪怕是這個線程發(fā)出了很多發(fā)送或者接收數(shù)據(jù)的請求，但是其他的線程都閑著…，這個線程也還是得自己來處理自己發(fā)出去的這些請求，沒有人來幫忙…這就有一個負(fù)載均衡問題，顯然性能沒有達(dá)到最優(yōu)化。
??????? (4)?完成端口，不用說大家也知道了，最后的壓軸戲就是使用完成端口，對比上面幾種機(jī)制，完成端口的做法是這樣的：事先開好幾個線程，你有幾個CPU我就開幾個，首先是避免了線程的上下文切換，因為線程想要執(zhí)行的時候，總有CPU資源可用，然后讓這幾個線程等著，等到有用戶請求來到的時候，就把這些請求都加入到一個公共消息隊列中去，然后這幾個開好的線程就排隊逐一去從消息隊列中取出消息并加以處理，這種方式就很優(yōu)雅的實現(xiàn)了異步通信和負(fù)載均衡的問題，因為它提供了一種機(jī)制來使用幾個線程“公平的”處理來自于多個客戶端的輸入/輸出，并且線程如果沒事干的時候也會被系統(tǒng)掛起，不會占用CPU周期，挺完美的一個解決方案，不是嗎？哦，對了，這個關(guān)鍵的作為交換的消息隊列，就是完成端口。
??????? 比較完畢之后，熟悉網(wǎng)絡(luò)編程的朋友可能會問到，為什么沒有提到WSAAsyncSelect或者是WSAEventSelect這兩個異步模型呢，對于這兩個模型，我不知道其內(nèi)部是如何實現(xiàn)的，但是這其中一定沒有用到Overlapped機(jī)制，就不能算作是真正的異步，可能是其內(nèi)部自己在維護(hù)一個消息隊列吧，總之這兩個模式雖然實現(xiàn)了異步的接收，但是卻不能進(jìn)行異步的發(fā)送，這就很明顯說明問題了，我想其內(nèi)部的實現(xiàn)一定和完成端口是迥異的，并且，完成端口非常厚道，因為它是先把用戶數(shù)據(jù)接收回來之后再通知用戶直接來取就好了，而WSAAsyncSelect和WSAEventSelect之流只是會接收到數(shù)據(jù)到達(dá)的通知，而只能由應(yīng)用程序自己再另外去recv數(shù)據(jù)，性能上的差距就更明顯了。
??????? 最后，我的建議是，想要使用 基于事件通知的重疊I/O和基于完成例程的重疊I/O的朋友，如果不是特別必要，就不要去使用了，因為這兩種方式不僅使用和理解起來也不算簡單，而且還有性能上的明顯瓶頸，何不就再努力一下使用完成端口呢？
??????? 3.2 重疊結(jié)構(gòu)(OVERLAPPED)
???????? 我們從上一小節(jié)中得知，要實現(xiàn)異步通信，必須要用到一個很風(fēng)騷的I/O數(shù)據(jù)結(jié)構(gòu)，叫重疊結(jié)構(gòu)“Overlapped”，Windows里所有的異步通信都是基于它的，完成端口也不例外。
???????? 至于為什么叫Overlapped？Jeffrey Richter的解釋是因為“執(zhí)行I/O請求的時間與線程執(zhí)行其他任務(wù)的時間是重疊(overlapped)的”，從這個名字我們也可能看得出來重疊結(jié)構(gòu)發(fā)明的初衷了，對于重疊結(jié)構(gòu)的內(nèi)部細(xì)節(jié)我這里就不過多的解釋了，就把它當(dāng)成和其他內(nèi)核對象一樣，不需要深究其實現(xiàn)機(jī)制，只要會使用就可以了，想要了解更多重疊結(jié)構(gòu)內(nèi)部的朋友，請去翻閱Jeffrey Richter的《Windows via C/C++》 5th?的292頁，如果沒有機(jī)會的話，也可以隨便翻翻我以前寫的Overlapped的東西，不過寫得比較淺顯……
???????? 這里我想要解釋的是，這個重疊結(jié)構(gòu)是異步通信機(jī)制實現(xiàn)的一個核心數(shù)據(jù)結(jié)構(gòu)，因為你看到后面的代碼你會發(fā)現(xiàn)，幾乎所有的網(wǎng)絡(luò)操作例如發(fā)送/接收之類的，都會用WSASend()和WSARecv()代替，參數(shù)里面都會附帶一個重疊結(jié)構(gòu)，這是為什么呢？因為重疊結(jié)構(gòu)我們就可以理解成為是一個網(wǎng)絡(luò)操作的ID號，也就是說我們要利用重疊I/O提供的異步機(jī)制的話，每一個網(wǎng)絡(luò)操作都要有一個唯一的ID號，因為進(jìn)了系統(tǒng)內(nèi)核，里面黑燈瞎火的，也不了解上面出了什么狀況，一看到有重疊I/O的調(diào)用進(jìn)來了，就會使用其異步機(jī)制，并且操作系統(tǒng)就只能靠這個重疊結(jié)構(gòu)帶有的ID號來區(qū)分是哪一個網(wǎng)絡(luò)操作了，然后內(nèi)核里面處理完畢之后，根據(jù)這個ID號，把對應(yīng)的數(shù)據(jù)傳上去。
???????? 你要是實在不理解這是個什么玩意，那就直接看后面的代碼吧，慢慢就明白了……
???????? 3.3 完成端口(CompletionPort)
??????? 對于完成端口這個概念，我一直不知道為什么它的名字是叫“完成端口”，我個人的感覺應(yīng)該叫它“完成隊列”似乎更合適一些，總之這個“端口”和我們平常所說的用于網(wǎng)絡(luò)通信的“端口”完全不是一個東西，我們不要混淆了。
??????? 首先，它之所以叫“完成”端口，就是說系統(tǒng)會在網(wǎng)絡(luò)I/O操作“完成”之后才會通知我們，也就是說，我們在接到系統(tǒng)的通知的時候，其實網(wǎng)絡(luò)操作已經(jīng)完成了，就是比如說在系統(tǒng)通知我們的時候，并非是有數(shù)據(jù)從網(wǎng)絡(luò)上到來，而是來自于網(wǎng)絡(luò)上的數(shù)據(jù)已經(jīng)接收完畢了；或者是客戶端的連入請求已經(jīng)被系統(tǒng)接入完畢了等等，我們只需要處理后面的事情就好了。
??????? 各位朋友可能會很開心，什么？已經(jīng)處理完畢了才通知我們，那豈不是很爽？其實也沒什么爽的，那是因為我們在之前給系統(tǒng)分派工作的時候，都囑咐好了，我們會通過代碼告訴系統(tǒng)“你給我做這個做那個，等待做完了再通知我”，只是這些工作是做在之前還是之后的區(qū)別而已。
??????? 其次，我們需要知道，所謂的完成端口，其實和HANDLE一樣，也是一個內(nèi)核對象，雖然Jeff Richter嚇唬我們說：“完成端口可能是最為復(fù)雜的內(nèi)核對象了”，但是我們也不用去管他，因為它具體的內(nèi)部如何實現(xiàn)的和我們無關(guān)，只要我們能夠?qū)W會用它相關(guān)的API把這個完成端口的框架搭建起來就可以了。我們暫時只用把它大體理解為一個容納網(wǎng)絡(luò)通信操作的隊列就好了，它會把網(wǎng)絡(luò)操作完成的通知，都放在這個隊列里面，咱們只用從這個隊列里面取就行了，取走一個就少一個…。
??????? 關(guān)于完成端口內(nèi)核對象的具體更多內(nèi)部細(xì)節(jié)我會在后面的“完成端口的基本原理”一節(jié)更詳細(xì)的和朋友們一起來研究，當(dāng)然，要是你們在文章中沒有看到這一節(jié)的話，就是說明我又犯懶了沒寫…在后續(xù)的文章里我會補(bǔ)上。這里就暫時說這么多了，到時候我們也可以看到它的機(jī)制也并非有那么的復(fù)雜，可能只是因為操作系統(tǒng)其他的內(nèi)核對象相比較而言實現(xiàn)起來太容易了吧^_^
四． 使用完成端口的基本流程
???????? 說了這么多的廢話，大家都等不及了吧，我們終于到了具體編碼的時候了。
??????? 使用完成端口，說難也難，但是說簡單，其實也簡單 ---- 又說了一句廢話=。=
??????? 大體上來講，使用完成端口只用遵循如下幾個步驟：
??????? (1) 調(diào)用 CreateIoCompletionPort() 函數(shù)創(chuàng)建一個完成端口，而且在一般情況下，我們需要且只需要建立這一個完成端口，把它的句柄保存好，我們今后會經(jīng)常用到它……
??????? (2) 根據(jù)系統(tǒng)中有多少個處理器，就建立多少個工作者(為了醒目起見，下面直接說Worker)線程，這幾個線程是專門用來和客戶端進(jìn)行通信的，目前暫時沒什么工作；
??????? (3) 下面就是接收連入的Socket連接了，這里有兩種實現(xiàn)方式：一是和別的編程模型一樣，還需要啟動一個獨立的線程，專門用來accept客戶端的連接請求；二是用性能更高更好的異步AcceptEx()請求，因為各位對accept用法應(yīng)該非常熟悉了，而且網(wǎng)上資料也會很多，所以為了更全面起見，本文采用的是性能更好的AcceptEx，至于兩者代碼編寫上的區(qū)別，我接下來會詳細(xì)的講。
??????? (4) 每當(dāng)有客戶端連入的時候，我們就還是得調(diào)用CreateIoCompletionPort()函數(shù)，這里卻不是新建立完成端口了，而是把新連入的Socket(也就是前面所謂的設(shè)備句柄)，與目前的完成端口綁定在一起。
??????? 至此，我們其實就已經(jīng)完成了完成端口的相關(guān)部署工作了，嗯，是的，完事了，后面的代碼里我們就可以充分享受完成端口帶給我們的巨大優(yōu)勢，坐享其成了，是不是很簡單呢？
?????? (5) 例如，客戶端連入之后，我們可以在這個Socket上提交一個網(wǎng)絡(luò)請求，例如WSARecv()，然后系統(tǒng)就會幫咱們乖乖的去執(zhí)行接收數(shù)據(jù)的操作，我們大可以放心的去干別的事情了；
?????? (6) 而此時，我們預(yù)先準(zhǔn)備的那幾個Worker線程就不能閑著了， 我們在前面建立的幾個Worker就要忙活起來了，都需要分別調(diào)用GetQueuedCompletionStatus() 函數(shù)在掃描完成端口的隊列里是否有網(wǎng)絡(luò)通信的請求存在(例如讀取數(shù)據(jù)，發(fā)送數(shù)據(jù)等)，一旦有的話，就將這個請求從完成端口的隊列中取回來，繼續(xù)執(zhí)行本線程中后面的處理代碼，處理完畢之后，我們再繼續(xù)投遞下一個網(wǎng)絡(luò)通信的請求就OK了，如此循環(huán)。
??????? 關(guān)于完成端口的使用步驟，用文字來表述就是這么多了，很簡單吧？如果你還是不理解，我再配合一個流程圖來表示一下：
??????? 當(dāng)然，我這里假設(shè)你已經(jīng)對網(wǎng)絡(luò)編程的基本套路有了解了，所以略去了很多基本的細(xì)節(jié)，并且為了配合朋友們更好的理解我的代碼，在流程圖我標(biāo)出了一些函數(shù)的名字，并且畫得非常詳細(xì)。
??????? 另外需要注意的是由于對于客戶端的連入有兩種方式，一種是普通阻塞的accept，另外一種是性能更好的AcceptEx，為了能夠方面朋友們從別的網(wǎng)絡(luò)編程的方式中過渡，我這里畫了兩種方式的流程圖，方便朋友們對比學(xué)習(xí)，圖a是使用accept的方式，當(dāng)然配套的源代碼我默認(rèn)就不提供了，如果需要的話，我倒是也可以發(fā)上來；圖b是使用AcceptEx的，并配有配套的源碼。
??????? 采用accept方式的流程示意圖如下：
???????? 采用AcceptEx方式的流程示意圖如下：
???????? 兩個圖中最大的相同點是什么？是的，最大的相同點就是主線程無所事事，閑得蛋疼……
???????? 為什么呢？因為我們使用了異步的通信機(jī)制，這些瑣碎重復(fù)的事情完全沒有必要交給主線程自己來做了，只用在初始化的時候和Worker線程交待好就可以了，用一句話來形容就是，主線程永遠(yuǎn)也體會不到Worker線程有多忙，而Worker線程也永遠(yuǎn)體會不到主線程在初始化建立起這個通信框架的時候操了多少的心……
???????? 圖a中是由 _AcceptThread()負(fù)責(zé)接入連接，并把連入的Socket和完成端口綁定，另外的多個_WorkerThread()就負(fù)責(zé)監(jiān)控完成端口上的情況，一旦有情況了，就取出來處理，如果CPU有多核的話，就可以多個線程輪著來處理完成端口上的信息，很明顯效率就提高了。
???????? 圖b中最明顯的區(qū)別，也就是AcceptEx和傳統(tǒng)的accept之間最大的區(qū)別，就是取消了阻塞方式的accept調(diào)用，也就是說，AcceptEx也是通過完成端口來異步完成的，所以就取消了專門用于accept連接的線程，用了完成端口來進(jìn)行異步的AcceptEx調(diào)用；然后在檢索完成端口隊列的Worker函數(shù)中，根據(jù)用戶投遞的完成操作的類型，再來找出其中的投遞的Accept請求，加以對應(yīng)的處理。
???????? 讀者一定會問，這樣做的好處在哪里？為什么還要異步的投遞AcceptEx連接的操作呢？
???????? 首先，我可以很明確的告訴各位，如果短時間內(nèi)客戶端的并發(fā)連接請求不是特別多的話，用accept和AcceptEx在性能上來講是沒什么區(qū)別的。
??????? 按照我們目前主流的PC來講，如果客戶端只進(jìn)行連接請求，而什么都不做的話，我們的Server只能接收大約3萬-4萬個左右的并發(fā)連接，然后客戶端其余的連入請求就只能收到WSAENOBUFS (10055)了，因為系統(tǒng)來不及為新連入的客戶端準(zhǔn)備資源了。
??????? 需要準(zhǔn)備什么資源？當(dāng)然是準(zhǔn)備Socket了……雖然我們創(chuàng)建Socket只用一行SOCKET s= socket(…) 這么一行的代碼就OK了，但是系統(tǒng)內(nèi)部建立一個Socket是相當(dāng)耗費資源的，因為Winsock2是分層的機(jī)構(gòu)體系，創(chuàng)建一個Socket需要到多個Provider之間進(jìn)行處理，最終形成一個可用的套接字。總之，系統(tǒng)創(chuàng)建一個Socket的開銷是相當(dāng)高的，所以用accept的話，系統(tǒng)可能來不及為更多的并發(fā)客戶端現(xiàn)場準(zhǔn)備Socket了。
??????? 而AcceptEx比Accept又強(qiáng)大在哪里呢？是有三點：
???????? (1) 這個好處是最關(guān)鍵的，是因為AcceptEx是在客戶端連入之前，就把客戶端的Socket建立好了，也就是說，AcceptEx是先建立的Socket，然后才發(fā)出的AcceptEx調(diào)用，也就是說，在進(jìn)行客戶端的通信之前，無論是否有客戶端連入，Socket都是提前建立好了；而不需要像accept是在客戶端連入了之后，再現(xiàn)場去花費時間建立Socket。如果各位不清楚是如何實現(xiàn)的，請看后面的實現(xiàn)部分。
???????? (2) 相比accept只能阻塞方式建立一個連入的入口，對于大量的并發(fā)客戶端來講，入口實在是有點擠；而AcceptEx可以同時在完成端口上投遞多個請求，這樣有客戶端連入的時候，就非常優(yōu)雅而且從容不迫的邊喝茶邊處理連入請求了。
???????? (3) AcceptEx還有一個非常體貼的優(yōu)點，就是在投遞AcceptEx的時候，我們還可以順便在AcceptEx的同時，收取客戶端發(fā)來的第一組數(shù)據(jù)，這個是同時進(jìn)行的，也就是說，在我們收到AcceptEx完成的通知的時候，我們就已經(jīng)把這第一組數(shù)據(jù)接完畢了；但是這也意味著，如果客戶端只是連入但是不發(fā)送數(shù)據(jù)的話，我們就不會收到這個AcceptEx完成的通知……這個我們在后面的實現(xiàn)部分，也可以詳細(xì)看到。
???????? 最后，各位要有一個心里準(zhǔn)備，相比accept，異步的AcceptEx使用起來要麻煩得多……
五． 完成端口的實現(xiàn)詳解
??????? 又說了一節(jié)的廢話，終于到了該動手實現(xiàn)的時候了……
??????? 這里我把完成端口的詳細(xì)實現(xiàn)步驟以及會涉及到的函數(shù)，按照出現(xiàn)的先后步驟，都和大家詳細(xì)的說明解釋一下，當(dāng)然，文檔中為了讓大家便于閱讀，這里去掉了其中的錯誤處理的內(nèi)容，當(dāng)然，這些內(nèi)容在示例代碼中是會有的。
?????? 【第一步】創(chuàng)建一個完成端口
???????? 首先，我們先把完成端口建好再說。
??????? 我們正常情況下，我們需要且只需要建立這一個完成端口，代碼很簡單:
HANDLE m_hIOCompletionPort = CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 0 );?
??????? 呵呵，看到CreateIoCompletionPort()的參數(shù)不要奇怪，參數(shù)就是一個INVALID，一個NULL，兩個0…，說白了就是一個-1，三個0……簡直就和什么都沒傳一樣，但是Windows系統(tǒng)內(nèi)部卻是好一頓忙活，把完成端口相關(guān)的資源和數(shù)據(jù)結(jié)構(gòu)都已經(jīng)定義好了(在后面的原理部分我們會看到，完成端口相關(guān)的數(shù)據(jù)結(jié)構(gòu)大部分都是一些用來協(xié)調(diào)各種網(wǎng)絡(luò)I/O的隊列)，然后系統(tǒng)會給我們返回一個有意義的HANDLE，只要返回值不是NULL，就說明建立完成端口成功了，就這么簡單，不是嗎？
??????? 有的時候我真的很贊嘆Windows API的封裝，把很多其實是很復(fù)雜的事整得這么簡單……
??????? 至于里面各個參數(shù)的具體含義，我會放到后面的步驟中去講，反正這里只要知道創(chuàng)建我們唯一的這個完成端口，就只是需要這么幾個參數(shù)。
??????? 但是對于最后一個參數(shù) 0，我這里要簡單的說兩句，這個0可不是一個普通的0，它代表的是NumberOfConcurrentThreads，也就是說，允許應(yīng)用程序同時執(zhí)行的線程數(shù)量。當(dāng)然，我們這里為了避免上下文切換，最理想的狀態(tài)就是每個處理器上只運行一個線程了，所以我們設(shè)置為0，就是說有多少個處理器，就允許同時多少個線程運行。
??????? 因為比如一臺機(jī)器只有兩個CPU（或者兩個核心），如果讓系統(tǒng)同時運行的線程多于本機(jī)的CPU數(shù)量的話，那其實是沒有什么意義的事情，因為這樣CPU就不得不在多個線程之間執(zhí)行上下文切換，這會浪費寶貴的CPU周期，反而降低的效率，我們要牢記這個原則。
????? 【第二步】根據(jù)系統(tǒng)中CPU核心的數(shù)量建立對應(yīng)的Worker線程
??????? 我們前面已經(jīng)提到，這個Worker線程很重要，是用來具體處理網(wǎng)絡(luò)請求、具體和客戶端通信的線程，而且對于線程數(shù)量的設(shè)置很有意思，要等于系統(tǒng)中CPU的數(shù)量，那么我們就要首先獲取系統(tǒng)中CPU的數(shù)量，這個是基本功，我就不多說了，代碼如下：
SYSTEM_INFO si;?
GetSystemInfo(&si);?
int m_nProcessors = si.dwNumberOfProcessors;?
??????? 這樣我們根據(jù)系統(tǒng)中CPU的核心數(shù)量來建立對應(yīng)的線程就好了，下圖是在我的 i7 2600k CPU上初始化的情況，因為我的CPU是8核，一共啟動了16個Worker線程，如下圖所示
???????? 啊，等等！各位沒發(fā)現(xiàn)什么問題么？為什么我8核的CPU卻啟動了16個線程？這個不是和我們第二步中說的原則自相矛盾了么？
???????? 哈哈，有個小秘密忘了告訴各位了，江湖上都流傳著這么一個公式，就是：
??????? 我們最好是建立CPU核心數(shù)量*2那么多的線程，這樣更可以充分利用CPU資源，因為完成端口的調(diào)度是非常智能的，比如我們的Worker線程有的時候可能會有Sleep()或者WaitForSingleObject()之類的情況，這樣同一個CPU核心上的另一個線程就可以代替這個Sleep的線程執(zhí)行了；因為完成端口的目標(biāo)是要使得CPU滿負(fù)荷的工作。
??????? 這里也有人說是建立 CPU“核心數(shù)量 * 2 +2”個線程，我想這個應(yīng)該沒有什么太大的區(qū)別，我就是按照我自己的習(xí)慣來了。
??????? 然后按照這個數(shù)量，來啟動這么多個Worker線程就好可以了，接下來我們開始下一個步驟。
??????? 什么？Worker線程不會建？
??????? …囧…
?????? Worker線程和普通線程是一樣一樣一樣的啊~~~，代碼大致上如下：
// 根據(jù)CPU數(shù)量，建立*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線程的線程函數(shù)，線程函數(shù)的具體內(nèi)容我們后面再講。
???? 【第三步】創(chuàng)建一個用于監(jiān)聽的Socket，綁定到完成端口上，然后開始在指定的端口上監(jiān)聽連接請求
?????? 最重要的完成端口建立完畢了，我們就可以利用這個完成端口來進(jìn)行網(wǎng)絡(luò)通信了。
?????? 首先，我們需要初始化Socket，這里和通常情況下使用Socket初始化的步驟都是一樣的，大約就是如下的這么幾個過程(詳情參照我代碼中的LoadSocketLib()和InitializeListenSocket()，這里只是挑出關(guān)鍵部分)：
// 初始化Socket庫
WSADATA wsaData;?
WSAStartup(MAKEWORD(2,2), &wsaData);?
//初始化Socket
struct sockaddr_in ServerAddress;?
// 這里需要特別注意，如果要使用重疊I/O的話，這里必須要使用WSASocket來初始化Socket
// 注意里面有個WSA_FLAG_OVERLAPPED參數(shù)
SOCKET m_sockListen = WSASocket(AF_INET, SOCK_STREAM, 0, NULL, 0, WSA_FLAG_OVERLAPPED);?
// 填充地址結(jié)構(gòu)信息
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)))??
// 開始監(jiān)聽
listen(m_sockListen,SOMAXCONN))?
??????? 需要注意的地方有兩點：
??????? (1) 想要使用重疊I/O的話，初始化Socket的時候一定要使用WSASocket并帶上WSA_FLAG_OVERLAPPED參數(shù)才可以(只有在服務(wù)器端需要這么做，在客戶端是不需要的)；
??????? (2) 注意到listen函數(shù)后面用的那個常量SOMAXCONN了嗎？這個是在微軟在WinSock2.h中定義的，并且還附贈了一條注釋，Maximum queue length specifiable by listen.，所以說，不用白不用咯^_^
??????? 接下來有一個非常重要的動作：既然我們要使用完成端口來幫我們進(jìn)行監(jiān)聽工作，那么我們一定要把這個監(jiān)聽Socket和完成端口綁定才可以的吧：
??????? 如何綁定呢？同樣很簡單，用?CreateIoCompletionPort()函數(shù)。
??????? 等等！大家沒覺得這個函數(shù)很眼熟么？是的，這個和前面那個創(chuàng)建完成端口用的居然是同一個API！但是這里這個API可不是用來建立完成端口的，而是用于將Socket和以前創(chuàng)建的那個完成端口綁定的，大家可要看準(zhǔn)了，不要被迷惑了，因為他們的參數(shù)是明顯不一樣的，前面那個的參數(shù)是一個-1，三個0，太好記了…
??????? 說實話，我感覺微軟應(yīng)該把這兩個函數(shù)分開，弄個 CreateNewCompletionPort() 多好呢？
??????? 這里在詳細(xì)講解一下CreateIoCompletionPort()的幾個參數(shù)：
HANDLE WINAPI CreateIoCompletionPort(?
??? __in????? HANDLE? FileHandle,???????????? // 這里當(dāng)然是連入的這個套接字句柄了
???? __in_opt? HANDLE? ExistingCompletionPort, // 這個就是前面創(chuàng)建的那個完成端口
???? __in????? ULONG_PTR CompletionKey,??????? // 這個參數(shù)就是類似于線程參數(shù)一樣，在
// 綁定的時候把自己定義的結(jié)構(gòu)體指針傳遞
// 這樣到了Worker線程中，也可以使用這個
// 結(jié)構(gòu)體的數(shù)據(jù)了，相當(dāng)于參數(shù)的傳遞
???? __in????? DWORD NumberOfConcurrentThreads // 這里同樣置0
);?
???????? 這些參數(shù)也沒什么好講的吧，用處一目了然了。而對于其中的那個CompletionKey，我們后面會詳細(xì)提到。
???????? 到此才算是Socket全部初始化完畢了。
??????? 初始化Socket完畢之后，就可以在這個Socket上投遞AcceptEx請求了。
????? 【第四步】在這個監(jiān)聽Socket上投遞AcceptEx請求
??????? 這里的處理比較復(fù)雜。
??????? 這個AcceptEx比較特別，而且這個是微軟專門在Windows操作系統(tǒng)里面提供的擴(kuò)展函數(shù)，也就是說這個不是Winsock2標(biāo)準(zhǔn)里面提供的，是微軟為了方便咱們使用重疊I/O機(jī)制，額外提供的一些函數(shù)，所以在使用之前也還是需要進(jìn)行些準(zhǔn)備工作。
??????? 微軟的實現(xiàn)是通過mswsock.dll中提供的，所以我們可以通過靜態(tài)鏈接mswsock.lib來使用AcceptEx。但是這是一個不推薦的方式，我們應(yīng)該用WSAIoctl 配合SIO_GET_EXTENSION_FUNCTION_POINTER參數(shù)來獲取函數(shù)的指針，然后再調(diào)用AcceptEx。
??????? 這是為什么呢？因為我們在未取得函數(shù)指針的情況下就調(diào)用AcceptEx的開銷是很大的，因為AcceptEx 實際上是存在于Winsock2結(jié)構(gòu)體系之外的(因為是微軟另外提供的)，所以如果我們直接調(diào)用AcceptEx的話，首先我們的代碼就只能在微軟的平臺上用了，沒有辦法在其他平臺上調(diào)用到該平臺提供的AcceptEx的版本(如果有的話)， 而且更糟糕的是，我們每次調(diào)用AcceptEx時，Service Provider都得要通過WSAIoctl()獲取一次該函數(shù)指針，效率太低了，所以還不如我們自己直接在代碼中直接去這么獲取一下指針好了。
??????? 獲取AcceptEx函數(shù)指針的代碼大致如下：
?????? LPFN_ACCEPTEX???? m_lpfnAcceptEx;???????? // AcceptEx函數(shù)指針
??????? GUID GuidAcceptEx = WSAID_ACCEPTEX;??????? // GUID，這個是識別AcceptEx函數(shù)必須的
DWORD dwBytes = 0;???
WSAIoctl(?
??? m_pListenContext->m_Socket,??
??? SIO_GET_EXTENSION_FUNCTION_POINTER,??
??? &GuidAcceptEx,??
sizeof(GuidAcceptEx),??
??? &m_lpfnAcceptEx,??
sizeof(m_lpfnAcceptEx),??
??? &dwBytes,??
??? NULL,??
??? NULL);?
??????? 具體實現(xiàn)就沒什么可說的了，因為都是固定的套路，那個GUID是微軟給定義好的，直接拿過來用就行了，WSAIoctl()就是通過這個找到AcceptEx的地址的，另外需要注意的是，通過WSAIoctl獲取AcceptEx函數(shù)指針時，只需要隨便傳遞給WSAIoctl()一個有效的SOCKET即可，該Socket的類型不會影響獲取的AcceptEx函數(shù)指針。
??????? 然后，我們就可以通過其中的指針m_lpfnAcceptEx調(diào)用AcceptEx函數(shù)了。
?????? AcceptEx函數(shù)的定義如下：
BOOL AcceptEx (??????
?????????????? SOCKET sListenSocket,??
?????????????? SOCKET sAcceptSocket,??
PVOID lpOutputBuffer,??
DWORD dwReceiveDataLength,??
DWORD dwLocalAddressLength,??
DWORD dwRemoteAddressLength,??
LPDWORD lpdwBytesReceived,??
?????????????? LPOVERLAPPED lpOverlapped??
);?
??????? 乍一看起來參數(shù)很多，但是實際用起來也很簡單：
-
參數(shù)1--sListenSocket, 這個就是那個唯一的用來監(jiān)聽的Socket了，沒什么說的；
-
參數(shù)2--sAcceptSocket, 用于接受連接的socket，這個就是那個需要我們事先建好的，等有客戶端連接進(jìn)來直接把這個Socket拿給它用的那個，是AcceptEx高性能的關(guān)鍵所在。
-
參數(shù)3--lpOutputBuffer,接收緩沖區(qū)，這也是AcceptEx比較有特色的地方，既然AcceptEx不是普通的accpet函數(shù)，那么這個緩沖區(qū)也不是普通的緩沖區(qū)，這個緩沖區(qū)包含了三個信息：一是客戶端發(fā)來的第一組數(shù)據(jù)，二是server的地址，三是client地址，都是精華啊…但是讀取起來就會很麻煩，不過后面有一個更好的解決方案。
-
參數(shù)4--dwReceiveDataLength，前面那個參數(shù)lpOutputBuffer中用于存放數(shù)據(jù)的空間大小。如果此參數(shù)=0，則Accept時將不會待數(shù)據(jù)到來，而直接返回，如果此參數(shù)不為0，那么一定得等接收到數(shù)據(jù)了才會返回……所以通常當(dāng)需要Accept接收數(shù)據(jù)時，就需要將該參數(shù)設(shè)成為：sizeof(lpOutputBuffer) - 2*(sizeof sockaddr_in +16)，也就是說總長度減去兩個地址空間的長度就是了，看起來復(fù)雜，其實想明白了也沒啥……
-
參數(shù)5--dwLocalAddressLength，存放本地址地址信息的空間大小；
-
參數(shù)6--dwRemoteAddressLength，存放本遠(yuǎn)端地址信息的空間大小；
-
參數(shù)7--lpdwBytesReceived，out參數(shù)，對我們來說沒用，不用管；
-
參數(shù)8--lpOverlapped，本次重疊I/O所要用到的重疊結(jié)構(gòu)。
??????? 這里面的參數(shù)倒是沒什么，看起來復(fù)雜，但是咱們依舊可以一個一個傳進(jìn)去，然后在對應(yīng)的IO操作完成之后，這些參數(shù)Windows內(nèi)核自然就會幫咱們填滿了。
??????? 但是非常悲催的是，我們這個是異步操作，我們是在線程啟動的地方投遞的這個操作， 等我們再次見到這些個變量的時候，就已經(jīng)是在Worker線程內(nèi)部了，因為Windows會直接把操作完成的結(jié)果傳遞到Worker線程里，這樣咱們在啟動的時候投遞了那么多的IO請求，這從Worker線程傳回來的這些結(jié)果，到底是對應(yīng)著哪個IO請求的呢？。。。。
??????? 聰明的你肯定想到了，是的，Windows內(nèi)核也幫我們想到了：用一個標(biāo)志來綁定每一個IO操作，這樣到了Worker線程內(nèi)部的時候，收到網(wǎng)絡(luò)操作完成的通知之后，再通過這個標(biāo)志來找出這組返回的數(shù)據(jù)到底對應(yīng)的是哪個Io操作的。
??????? 這里的標(biāo)志就是如下這樣的結(jié)構(gòu)體：
typedef struct _PER_IO_CONTEXT{?
? OVERLAPPED?? m_Overlapped;????????? // 每一個重疊I/O網(wǎng)絡(luò)操作都要有一個?????????????
?? SOCKET?????? m_sockAccept;????????? // 這個I/O操作所使用的Socket，每個連接的都是一樣的
?? WSABUF?????? m_wsaBuf;????????????? // 存儲數(shù)據(jù)的緩沖區(qū)，用來給重疊操作傳遞參數(shù)的，關(guān)于WSABUF后面還會講
char???????? m_szBuffer[MAX_BUFFER_LEN]; // 對應(yīng)WSABUF里的緩沖區(qū)
?? OPERATION_TYPE? m_OpType;?????????????? // 標(biāo)志這個重疊I/O操作是做什么的，例如Accept/Recv等
} PER_IO_CONTEXT, *PPER_IO_CONTEXT;?
??????? 這個結(jié)構(gòu)體的成員當(dāng)然是我們隨便定義的，里面的成員你可以隨意修改(除了OVERLAPPED那個之外……)。
?????? 但是AcceptEx不是普通的accept，buffer不是普通的buffer，那么這個結(jié)構(gòu)體當(dāng)然也不能是普通的結(jié)構(gòu)體了……
??????? 在完成端口的世界里，這個結(jié)構(gòu)體有個專屬的名字“單IO數(shù)據(jù)”，是什么意思呢？也就是說每一個重疊I/O都要對應(yīng)的這么一組參數(shù)，至于這個結(jié)構(gòu)體怎么定義無所謂，而且這個結(jié)構(gòu)體也不是必須要定義的，但是沒它……還真是不行，我們可以把它理解為線程參數(shù)，就好比你使用線程的時候，線程參數(shù)也不是必須的，但是不傳還真是不行……
??????? 除此以外，我們也還會想到，既然每一個I/O操作都有對應(yīng)的PER_IO_CONTEXT結(jié)構(gòu)體，而在每一個Socket上，我們會投遞多個I/O請求的，例如我們就可以在監(jiān)聽Socket上投遞多個AcceptEx請求，所以同樣的，我們也還需要一個“單句柄數(shù)據(jù)”來管理這個句柄上所有的I/O請求，這里的“句柄”當(dāng)然就是指的Socket了，我在代碼中是這樣定義的：
?
typedef struct _PER_SOCKET_CONTEXT?
{???
? SOCKET?????????????????? m_Socket;????????????? // 每一個客戶端連接的Socket
? SOCKADDR_IN????????????? m_ClientAddr;????????? // 這個客戶端的地址
? CArray<_PER_IO_CONTEXT*>? m_arrayIoContext;?? // 數(shù)組，所有客戶端IO操作的參數(shù)，
// 也就是說對于每一個客戶端Socket
// 是可以在上面同時投遞多個IO請求的
} PER_SOCKET_CONTEXT, *PPER_SOCKET_CONTEXT;?
???????? 這也是比較好理解的，也就是說我們需要在一個Socket句柄上，管理在這個Socket上投遞的每一個IO請求的_PER_IO_CONTEXT。
???????? 當(dāng)然，同樣的，各位對于這些也可以按照自己的想法來隨便定義，只要能起到管理每一個IO請求上需要傳遞的網(wǎng)絡(luò)參數(shù)的目的就好了，關(guān)鍵就是需要跟蹤這些參數(shù)的狀態(tài)，在必要的時候釋放這些資源，不要造成內(nèi)存泄漏，因為作為Server總是需要長時間運行的，所以如果有內(nèi)存泄露的情況那是非常可怕的，一定要杜絕一絲一毫的內(nèi)存泄漏。
??????? 至于具體這兩個結(jié)構(gòu)體參數(shù)是如何在Worker線程里大發(fā)神威的，我們后面再看。
???????? 以上就是我們?nèi)康臏?zhǔn)備工作了，具體的實現(xiàn)各位可以配合我的流程圖再看一下示例代碼，相信應(yīng)該會理解得比較快。
??????? 完成端口初始化的工作比起其他的模型來講是要更復(fù)雜一些，所以說對于主線程來講，它總覺得自己付出了很多，總覺得Worker線程是坐享其成，但是Worker自己的苦只有自己明白，Worker線程的工作一點也不比主線程少，相反還要更復(fù)雜一些，并且具體的通信工作全部都是Worker線程來完成的，Worker線程反而還覺得主線程是在旁邊看熱鬧，只知道發(fā)號施令而已，但是大家終究還是誰也離不開誰，這也就和公司里老板和員工的微妙關(guān)系是一樣的吧……
??????? 【第五步】我們再來看看Worker線程都做了些什么
??????? _Worker線程的工作都是涉及到具體的通信事務(wù)問題，主要完成了如下的幾個工作，讓我們一步一步的來看。
??????? (1) 使用 GetQueuedCompletionStatus() 監(jiān)控完成端口
??????? 首先這個工作所要做的工作大家也能猜到，無非就是幾個Worker線程哥幾個一起排好隊隊來監(jiān)視完成端口的隊列中是否有完成的網(wǎng)絡(luò)操作就好了，代碼大體如下：
?
void *lpContext = NULL;?
OVERLAPPED??????? *pOverlapped = NULL;?
DWORD??????????? dwBytesTransfered = 0;?
BOOL bReturn? =? GetQueuedCompletionStatus(?
???????????????????????????????????? pIOCPModel->m_hIOCompletionPort,?
???????????????????????????????????????? &dwBytesTransfered,?
???????????????????????????? (LPDWORD)&lpContext,?
???????????????????????????? &pOverlapped,?
???????????????????????????? INFINITE );?
??????? 各位留意到其中的GetQueuedCompletionStatus()函數(shù)了嗎？這個就是Worker線程里第一件也是最重要的一件事了，這個函數(shù)的作用就是我在前面提到的，會讓W(xué)orker線程進(jìn)入不占用CPU的睡眠狀態(tài)，直到完成端口上出現(xiàn)了需要處理的網(wǎng)絡(luò)操作或者超出了等待的時間限制為止。
??????? 一旦完成端口上出現(xiàn)了已完成的I/O請求，那么等待的線程會被立刻喚醒，然后繼續(xù)執(zhí)行后續(xù)的代碼。
?????? 至于這個神奇的函數(shù)，原型是這樣的：
BOOL WINAPI GetQueuedCompletionStatus(?
??? __in?? HANDLE????????? CompletionPort,??? // 這個就是我們建立的那個唯一的完成端口
??? __out? LPDWORD???????? lpNumberOfBytes,?? //這個是操作完成后返回的字節(jié)數(shù)
??? __out? PULONG_PTR????? lpCompletionKey,?? // 這個是我們建立完成端口的時候綁定的那個自定義結(jié)構(gòu)體參數(shù)
??? __out? LPOVERLAPPED??? *lpOverlapped,???? // 這個是我們在連入Socket的時候一起建立的那個重疊結(jié)構(gòu)
??? __in?? DWORD?????????? dwMilliseconds???? // 等待完成端口的超時時間，如果線程不需要做其他的事情，那就INFINITE就行了
??? );?
??????? 所以，如果這個函數(shù)突然返回了，那就說明有需要處理的網(wǎng)絡(luò)操作了 --- 當(dāng)然，在沒有出現(xiàn)錯誤的情況下。
??????? 然后switch()一下，根據(jù)需要處理的操作類型，那我們來進(jìn)行相應(yīng)的處理。
??????? 但是如何知道操作是什么類型的呢？這就需要用到從外部傳遞進(jìn)來的loContext參數(shù)，也就是我們封裝的那個參數(shù)結(jié)構(gòu)體，這個參數(shù)結(jié)構(gòu)體里面會帶有我們一開始投遞這個操作的時候設(shè)置的操作類型，然后我們根據(jù)這個操作再來進(jìn)行對應(yīng)的處理。
??????? 但是還有問題，這個參數(shù)究竟是從哪里傳進(jìn)來的呢？傳進(jìn)來的時候內(nèi)容都有些什么？
??????? 這個問題問得好！
??????? 首先，我們要知道兩個關(guān)鍵點：
??????? (1) 這個參數(shù)，是在你綁定Socket到一個完成端口的時候，用的CreateIoCompletionPort()函數(shù)，傳入的那個CompletionKey參數(shù)，要是忘了的話，就翻到文檔的“第三步”看看相關(guān)的內(nèi)容；我們在這里傳入的是定義的PER_SOCKET_CONTEXT，也就是說“單句柄數(shù)據(jù)”，因為我們綁定的是一個Socket，這里自然也就需要傳入Socket相關(guān)的上下文，你是怎么傳過去的，這里收到的就會是什么樣子，也就是說這個lpCompletionKey就是我們的PER_SOCKET_CONTEXT，直接把里面的數(shù)據(jù)拿出來用就可以了。
?????? (2) 另外還有一個很神奇的地方，里面的那個lpOverlapped參數(shù)，里面就帶有我們的PER_IO_CONTEXT。這個參數(shù)是從哪里來的呢？我們?nèi)タ纯辞懊嫱哆fAcceptEx請求的時候，是不是傳了一個重疊參數(shù)進(jìn)去？這里就是它了，并且，我們可以使用一個很神奇的宏，把和它存儲在一起的其他的變量，全部都讀取出來，例如：
PER_IO_CONTEXT* pIoContext = CONTAINING_RECORD(lpOverlapped, PER_IO_CONTEXT, m_Overlapped);?
???????? 這個宏的含義，就是去傳入的lpOverlapped變量里，找到和結(jié)構(gòu)體中PER_IO_CONTEXT中m_Overlapped成員相關(guān)的數(shù)據(jù)。
???????? 你仔細(xì)想想，其實真的很神奇……
???????? 但是要做到這種神奇的效果，應(yīng)該確保我們在結(jié)構(gòu)體PER_IO_CONTEXT定義的時候，把Overlapped變量，定義為結(jié)構(gòu)體中的第一個成員。
???????? 只要各位能弄清楚這個GetQueuedCompletionStatus()中各種奇怪的參數(shù)，那我們就離成功不遠(yuǎn)了。
???????? 既然我們可以獲得PER_IO_CONTEXT結(jié)構(gòu)體，那么我們就自然可以根據(jù)其中的m_OpType參數(shù)，得知這次收到的這個完成通知，是關(guān)于哪個Socket上的哪個I/O操作的，這樣就分別進(jìn)行對應(yīng)處理就好了。
??????? 在我的示例代碼里，在有AcceptEx請求完成的時候，我是執(zhí)行的_DoAccept()函數(shù)，在有WSARecv請求完成的時候，執(zhí)行的是_DoRecv()函數(shù)，下面我就分別講解一下這兩個函數(shù)的執(zhí)行流程。
?????? 【第六步】當(dāng)收到Accept通知時 _DoAccept()
??????? 在用戶收到AcceptEx的完成通知時，需要后續(xù)代碼并不多，但卻是邏輯最為混亂，最容易出錯的地方，這也是很多用戶為什么寧愿用效率低下的accept()也不愿意去用AcceptEx的原因吧。
?????? 和普通的Socket通訊方式一樣，在有客戶端連入的時候，我們需要做三件事情：
?????? (1) 為這個新連入的連接分配一個Socket；
?????? (2) 在這個Socket上投遞第一個異步的發(fā)送/接收請求；
?????? (3) 繼續(xù)監(jiān)聽。
??????? 其實都是一些很簡單的事情但是由于“單句柄數(shù)據(jù)”和“單IO數(shù)據(jù)”的加入，事情就變得比較亂。因為是這樣的，讓我們一起縷一縷啊，最好是配合代碼一起看，否則太抽象了……
??????? (1) 首先，_Worker線程通過GetQueuedCompletionStatus()里會收到一個lpCompletionKey，這個也就是PER_SOCKET_CONTEXT，里面保存了與這個I/O相關(guān)的Socket和Overlapped還有客戶端發(fā)來的第一組數(shù)據(jù)等等，對吧？但是這里得注意，這個SOCKET的上下文數(shù)據(jù)，是關(guān)于監(jiān)聽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操作的……，要不你下次繼續(xù)監(jiān)聽的時候就悲劇了……
??????? (3) 等到新的Socket準(zhǔn)備完畢了，我們就趕緊還是用傳入的這個Listen Socket上的PER_SOCKET_CONTEXT和PER_IO_CONTEXT去繼續(xù)投遞下一個AcceptEx，循環(huán)起來，留在這里太危險了，早晚得被人給改了……
??????? (4) 而我們新的Socket的上下文數(shù)據(jù)和I/O操作數(shù)據(jù)都準(zhǔn)備好了之后，我們要做兩件事情：一件事情是把這個新的Socket和我們唯一的那個完成端口綁定，這個就不用細(xì)說了，和前面綁定監(jiān)聽Socket是一樣的；然后就是在這個Socket上投遞第一個I/O操作請求，在我的示例代碼里投遞的是WSARecv()。因為后續(xù)的WSARecv，就不是在這里投遞的了，這里只負(fù)責(zé)第一個請求。
??????? 但是，至于WSARecv請求如何來投遞的，我們放到下一節(jié)中去講，這一節(jié)，我們還有一個很重要的事情，我得給大家提一下，就是在客戶端連入的時候，我們?nèi)绾蝸慝@取客戶端的連入地址信息。
???????? 這里我們還需要引入另外一個很高端的函數(shù)，GetAcceptExSockAddrs()，它和AcceptEx()一樣，都是微軟提供的擴(kuò)展函數(shù)，所以同樣需要通過下面的方式來導(dǎo)入才可以使用……
WSAIoctl(?
??? m_pListenContext->m_Socket,??
??? SIO_GET_EXTENSION_FUNCTION_POINTER,??
??? &GuidGetAcceptExSockAddrs,?
sizeof(GuidGetAcceptExSockAddrs),??
??? &m_lpfnGetAcceptExSockAddrs,??
sizeof(m_lpfnGetAcceptExSockAddrs),????
??? &dwBytes,??
??? NULL,??
??? NULL);?
??????? 和導(dǎo)出AcceptEx一樣一樣的，同樣是需要用其GUID來獲取對應(yīng)的函數(shù)指針 m_lpfnGetAcceptExSockAddrs 。
??????? 說了這么多，這個函數(shù)究竟是干嘛用的呢？它是名副其實的“AcceptEx之友”，為什么這么說呢？因為我前面提起過AcceptEx有個很神奇的功能，就是附帶一個神奇的緩沖區(qū)，這個緩沖區(qū)厲害了，包括了客戶端發(fā)來的第一組數(shù)據(jù)、本地的地址信息、客戶端的地址信息，三合一啊，你說神奇不神奇？
??????? 這個函數(shù)從它字面上的意思也基本可以看得出來，就是用來解碼這個緩沖區(qū)的，是的，它不提供別的任何功能，就是專門用來解析AcceptEx緩沖區(qū)內(nèi)容的。例如如下代碼：
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);?
??????? 解碼完畢之后，于是，我們就可以從如下的結(jié)構(gòu)體指針中獲得很多有趣的地址信息了：
inet_ntoa(ClientAddr->sin_addr) 是客戶端IP地址
ntohs(ClientAddr->sin_port) 是客戶端連入的端口
inet_ntoa(LocalAddr ->sin_addr) 是本地IP地址
ntohs(LocalAddr ->sin_port) 是本地通訊的端口
pIoContext->m_wsaBuf.buf 是存儲客戶端發(fā)來第一組數(shù)據(jù)的緩沖區(qū)
自從用了“AcceptEx之友”，一切都清凈了….
???????? 【第七步】當(dāng)收到Recv通知時, _DoRecv()
???????? 在講解如何處理Recv請求之前，我們還是先講一下如何投遞WSARecv請求的。
???????? WSARecv大體的代碼如下，其實就一行，在代碼中我們可以很清楚的看到我們用到了很多新建的PerIoContext的參數(shù)，這里再強(qiáng)調(diào)一下，注意一定要是自己另外新建的啊，一定不能是Worker線程里傳入的那個PerIoContext，因為那個是監(jiān)聽Socket的，別給人弄壞了……：
int nBytesRecv = WSARecv(pIoContext->m_Socket, pIoContext ->p_wbuf, 1, &dwBytes, 0, pIoContext->p_ol, NULL);?
??????? 這里，我再把WSARev函數(shù)的原型再給各位講一下
int WSARecv(?
??? SOCKET s,????????????????????? // 當(dāng)然是投遞這個操作的套接字
???? LPWSABUF lpBuffers,??????????? // 接收緩沖區(qū)
// 這里需要一個由WSABUF結(jié)構(gòu)構(gòu)成的數(shù)組
DWORD dwBufferCount,?????????? // 數(shù)組中WSABUF結(jié)構(gòu)的數(shù)量，設(shè)置為1即可
LPDWORD lpNumberOfBytesRecvd,? // 如果接收操作立即完成，這里會返回函數(shù)調(diào)用所接收到的字節(jié)數(shù)
LPDWORD lpFlags,?????????????? // 說來話長了，我們這里設(shè)置為0 即可
???? LPWSAOVERLAPPED lpOverlapped,? // 這個Socket對應(yīng)的重疊結(jié)構(gòu)
???? NULL?????????????????????????? // 這個參數(shù)只有完成例程模式才會用到，
// 完成端口中我們設(shè)置為NULL即可
);?
???????? 其實里面的參數(shù)，如果你們熟悉或者看過我以前的重疊I/O的文章，應(yīng)該都比較熟悉，只需要注意其中的兩個參數(shù)：
-
LPWSABUF?lpBuffers;
??????? 這里是需要我們自己new 一個 WSABUF 的結(jié)構(gòu)體傳進(jìn)去的；
??????? 如果你們非要追問 WSABUF 結(jié)構(gòu)體是個什么東東？我就給各位多說兩句，就是在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*就可以了，這不就是一個是緩沖區(qū)長度，一個是緩沖區(qū)指針么？至于那個什么 FAR…..讓他見鬼去吧，現(xiàn)在已經(jīng)是32位和64位時代了……
??????? 這里需要注意的，我們的應(yīng)用程序接到數(shù)據(jù)到達(dá)的通知的時候，其實數(shù)據(jù)已經(jīng)被咱們的主機(jī)接收下來了，我們直接通過這個WSABUF指針去系統(tǒng)緩沖區(qū)拿數(shù)據(jù)就好了，而不像那些沒用重疊I/O的模型，接收到有數(shù)據(jù)到達(dá)的通知的時候還得自己去另外recv，太低端了……這也是為什么重疊I/O比其他的I/O性能要好的原因之一。
-
LPWSAOVERLAPPED?lpOverlapped
???????? 這個參數(shù)就是我們所謂的重疊結(jié)構(gòu)了，就是這樣定義，然后在有Socket連接進(jìn)來的時候，生成并初始化一下，然后在投遞第一個完成請求的時候，作為參數(shù)傳遞進(jìn)去就可以，
OVERLAPPED* m_pol = new OVERLAPPED;?
eroMemory(m_pol, sizeof(OVERLAPPED));?
??????? 在第一個重疊請求完畢之后，我們的這個OVERLAPPED 結(jié)構(gòu)體里，就會被分配有效的系統(tǒng)參數(shù)了，并且我們是需要每一個Socket上的每一個I/O操作類型，都要有一個唯一的Overlapped結(jié)構(gòu)去標(biāo)識。
??????? 這樣，投遞一個WSARecv就講完了，至于_DoRecv()需要做些什么呢？其實就是做兩件事：
??????? (1) 把WSARecv里這個緩沖區(qū)里收到的數(shù)據(jù)顯示出來；
??????? (2) 發(fā)出下一個WSARecv()；
??????? Over……
??????? 至此，我們終于深深的喘口氣了，完成端口的大部分工作我們也完成了，也非常感謝各位耐心的看我這么枯燥的文字一直看到這里，真是一個不容易的事情！！
?????? 【第八步】如何關(guān)閉完成端口
??????? 休息完畢，我們繼續(xù)……
??????? 各位看官不要高興得太早，雖然我們已經(jīng)讓我們的完成端口順利運作起來了，但是在退出的時候如何釋放資源咱們也是要知道的，否則豈不是功虧一簣…..
??????? 從前面的章節(jié)中，我們已經(jīng)了解到，Worker線程一旦進(jìn)入了GetQueuedCompletionStatus()的階段，就會進(jìn)入睡眠狀態(tài)，INFINITE的等待完成端口中，如果完成端口上一直都沒有已經(jīng)完成的I/O請求，那么這些線程將無法被喚醒，這也意味著線程沒法正常退出。
??????? 熟悉或者不熟悉多線程編程的朋友，都應(yīng)該知道，如果在線程睡眠的時候，簡單粗暴的就把線程關(guān)閉掉的話，那是會一個很可怕的事情，因為很多線程體內(nèi)很多資源都來不及釋放掉，無論是這些資源最后是否會被操作系統(tǒng)回收，我們作為一個C++程序員來講，都不應(yīng)該允許這樣的事情出現(xiàn)。
??????? 所以我們必須得有一個很優(yōu)雅的，讓線程自己退出的辦法。
?????? 這時會用到我們這次見到的與完成端口有關(guān)的最后一個API，叫 PostQueuedCompletionStatus()，從名字上也能看得出來，這個是和 GetQueuedCompletionStatus() 函數(shù)相對的，這個函數(shù)的用途就是可以讓我們手動的添加一個完成端口I/O操作，這樣處于睡眠等待的狀態(tài)的線程就會有一個被喚醒，如果為我們每一個Worker線程都調(diào)用一次PostQueuedCompletionStatus()的話，那么所有的線程也就會因此而被喚醒了。
?????? PostQueuedCompletionStatus()函數(shù)的原型是這樣定義的：
BOOL WINAPI PostQueuedCompletionStatus(?
?????????????????? __in????? HANDLE CompletionPort,?
?????????????????? __in????? DWORD dwNumberOfBytesTransferred,?
?????????????????? __in????? ULONG_PTR dwCompletionKey,?
?????????????????? __in_opt? LPOVERLAPPED lpOverlapped?
);?
??????? 我們可以看到，這個函數(shù)的參數(shù)幾乎和GetQueuedCompletionStatus()的一模一樣，都是需要把我們建立的完成端口傳進(jìn)去，然后后面的三個參數(shù)是 傳輸字節(jié)數(shù)、結(jié)構(gòu)體參數(shù)、重疊結(jié)構(gòu)的指針.
?????? 注意，這里也有一個很神奇的事情，正常情況下，GetQueuedCompletionStatus()獲取回來的參數(shù)本來是應(yīng)該是系統(tǒng)幫我們填充的，或者是在綁定完成端口時就有的，但是我們這里卻可以直接使用PostQueuedCompletionStatus()直接將后面三個參數(shù)傳遞給GetQueuedCompletionStatus()，這樣就非常方便了。
?????? 例如，我們?yōu)榱四軌驅(qū)崿F(xiàn)通知線程退出的效果，可以自己定義一些約定，比如把這后面三個參數(shù)設(shè)置一個特殊的值，然后Worker線程接收到完成通知之后，通過判斷這3個參數(shù)中是否出現(xiàn)了特殊的值，來決定是否是應(yīng)該退出線程了。
?????? 例如我們在調(diào)用的時候，就可以這樣：
for (int i = 0; i < m_nThreads; i++)?
{?
????? PostQueuedCompletionStatus(m_hIOCompletionPort, 0, (DWORD) NULL, NULL);?
}?
??????? 為每一個線程都發(fā)送一個完成端口數(shù)據(jù)包，有幾個線程就發(fā)送幾遍，把其中的dwCompletionKey參數(shù)設(shè)置為NULL，這樣每一個Worker線程在接收到這個完成通知的時候，再自己判斷一下這個參數(shù)是否被設(shè)置成了NULL，因為正常情況下，這個參數(shù)總是會有一個非NULL的指針傳入進(jìn)來的，如果Worker發(fā)現(xiàn)這個參數(shù)被設(shè)置成了NULL，那么Worker線程就會知道，這是應(yīng)用程序再向Worker線程發(fā)送的退出指令，這樣Worker線程在內(nèi)部就可以自己很“優(yōu)雅”的退出了……
??????? 學(xué)會了嗎？
??????? 但是這里有一個很明顯的問題，聰明的朋友一定想到了，而且只有想到了這個問題的人，才算是真正看明白了這個方法。
??????? 我們只是發(fā)送了m_nThreads次，我們?nèi)绾文艽_保每一個Worker線程正好就收到一個，然后所有的線程都正好退出呢？是的，我們沒有辦法保證，所以很有可能一個Worker線程處理完一個完成請求之后，發(fā)生了某些事情，結(jié)果又再次去循環(huán)接收下一個完成請求了，這樣就會造成有的Worker線程沒有辦法接收到我們發(fā)出的退出通知。
??????? 所以，我們在退出的時候，一定要確保Worker線程只調(diào)用一次GetQueuedCompletionStatus()，這就需要我們自己想辦法了，各位請參考我在Worker線程中實現(xiàn)的代碼，我搭配了一個退出的Event，在退出的時候SetEvent一下，來確保Worker線程每次就只會調(diào)用一輪 GetQueuedCompletionStatus() ，這樣就應(yīng)該比較安全了。
??????? 另外，在Vista/Win7系統(tǒng)中，我們還有一個更簡單的方式，我們可以直接CloseHandle關(guān)掉完成端口的句柄，這樣所有在GetQueuedCompletionStatus()的線程都會被喚醒，并且返回FALSE，這時調(diào)用GetLastError()獲取錯誤碼時，會返回ERROR_INVALID_HANDLE，這樣每一個Worker線程就可以通過這種方式輕松簡單的知道自己該退出了。當(dāng)然，如果我們不能保證我們的應(yīng)用程序只在Vista/Win7中，那還是老老實實的PostQueuedCompletionStatus()吧。
??????? 最后，在系統(tǒng)釋放資源的最后階段，切記，因為完成端口同樣也是一個Handle，所以也得用CloseHandle將這個句柄關(guān)閉，當(dāng)然還要記得用closesocket關(guān)閉一系列的socket，還有別的各種指針什么的，這都是作為一個合格的C++程序員的基本功，在這里就不多說了，如果還是有不太清楚的朋友，請參考我的示例代碼中的 StopListen() 和DeInitialize() 函數(shù)。
六． 完成端口使用中的注意事項
??????? 終于到了文章的結(jié)尾了，不知道各位朋友是基本學(xué)會了完成端口的使用了呢，還是被完成端口以及我這么多口水的文章折磨得不行了……
??????? 最后再補(bǔ)充一些前面沒有提到了，實際應(yīng)用中的一些注意事項吧。
?????? 1. Socket的通信緩沖區(qū)設(shè)置成多大合適？
??????? 在x86的體系中，內(nèi)存頁面是以4KB為單位來鎖定的，也就是說，就算是你投遞WSARecv()的時候只用了1KB大小的緩沖區(qū)，系統(tǒng)還是得給你分4KB的內(nèi)存。為了避免這種浪費，最好是把發(fā)送和接收數(shù)據(jù)的緩沖區(qū)直接設(shè)置成4KB的倍數(shù)。
?????? 2.? 關(guān)于完成端口通知的次序問題
??????? 這個不用想也能知道，調(diào)用GetQueuedCompletionStatus() 獲取I/O完成端口請求的時候，肯定是用先入先出的方式來進(jìn)行的。
??????? 但是，咱們大家可能都想不到的是，喚醒那些調(diào)用了GetQueuedCompletionStatus()的線程是以后入先出的方式來進(jìn)行的。
??????? 比如有4個線程在等待，如果出現(xiàn)了一個已經(jīng)完成的I/O項，那么是最后一個調(diào)用GetQueuedCompletionStatus()的線程會被喚醒。平常這個次序倒是不重要，但是在對數(shù)據(jù)包順序有要求的時候，比如傳送大塊數(shù)據(jù)的時候，是需要注意下這個先后次序的。
??????? -- 微軟之所以這么做，那當(dāng)然是有道理的，這樣如果反復(fù)只有一個I/O操作而不是多個操作完成的話，內(nèi)核就只需要喚醒同一個線程就可以了，而不需要輪著喚醒多個線程，節(jié)約了資源，而且可以把其他長時間睡眠的線程換出內(nèi)存，提到資源利用率。
?????? 3.? 如果各位想要傳輸文件…
??????? 如果各位需要使用完成端口來傳送文件的話，這里有個非常需要注意的地方。因為發(fā)送文件的做法，按照正常人的思路來講，都會是先打開一個文件，然后不斷的循環(huán)調(diào)用ReadFile()讀取一塊之后，然后再調(diào)用WSASend ()去發(fā)發(fā)送。
??????? 但是我們知道，ReadFile()的時候，是需要操作系統(tǒng)通過磁盤的驅(qū)動程序，到實際的物理硬盤上去讀取文件的，這就會使得操作系統(tǒng)從用戶態(tài)轉(zhuǎn)換到內(nèi)核態(tài)去調(diào)用驅(qū)動程序，然后再把讀取的結(jié)果返回至用戶態(tài)；同樣的道理，WSARecv()也會涉及到從用戶態(tài)到內(nèi)核態(tài)切換的問題 --- 這樣就使得我們不得不頻繁的在用戶態(tài)到內(nèi)核態(tài)之間轉(zhuǎn)換，效率低下……
??????? 而一個非常好的解決方案是使用微軟提供的擴(kuò)展函數(shù)TransmitFile()來傳輸文件，因為只需要傳遞給TransmitFile()一個文件的句柄和需要傳輸?shù)淖止?jié)數(shù)，程序就會整個切換至內(nèi)核態(tài)，無論是讀取數(shù)據(jù)還是發(fā)送文件，都是直接在內(nèi)核態(tài)中執(zhí)行的，直到文件傳輸完畢才會返回至用戶態(tài)給主進(jìn)程發(fā)送通知。這樣效率就高多了。
?????? 4. 關(guān)于重疊結(jié)構(gòu)數(shù)據(jù)釋放的問題
??????? 我們既然使用的是異步通訊的方式，就得要習(xí)慣一點，就是我們投遞出去的完成請求，不知道什么時候我們才能收到操作完成的通知，而在這段等待通知的時間，我們就得要千萬注意得保證我們投遞請求的時候所使用的變量在此期間都得是有效的。
??????? 例如我們發(fā)送WSARecv請求時候所使用的Overlapped變量，因為在操作完成的時候，這個結(jié)構(gòu)里面會保存很多很重要的數(shù)據(jù)，對于設(shè)備驅(qū)動程序來講，指示保存著我們這個Overlapped變量的指針，而在操作完成之后，驅(qū)動程序會將Buffer的指針、已經(jīng)傳輸?shù)淖止?jié)數(shù)、錯誤碼等等信息都寫入到我們傳遞給它的那個Overlapped指針中去。如果我們已經(jīng)不小心把Overlapped釋放了，或者是又交給別的操作使用了的話，誰知道驅(qū)動程序會把這些東西寫到哪里去呢？豈不是很崩潰……
??????? 暫時我想到的問題就是這么多吧，如果各位真的是要正兒八經(jīng)寫一個承受很大訪問壓力的Server的話，你慢慢就會發(fā)現(xiàn)，只用我附帶的這個示例代碼是不夠的，還得需要在很多細(xì)節(jié)之處進(jìn)行改進(jìn)，例如用更好的數(shù)據(jù)結(jié)構(gòu)來管理上下文數(shù)據(jù)，并且需要非常完善的異常處理機(jī)制等等，總之，非常期待大家的批評和指正。
??????? 謝謝大家看到這里！！！
?????????????????????????????????????????????????????????????????????????????????????????????? ------ Finished in DLUT
?????????????????????????????????????????????????????????????????????????????????????????????? ------ 2011-9-31
總結(jié)
以上是生活随笔為你收集整理的手把手教你玩转SOCKET模型：完成端口(Completion Port)详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： HeapAlloc与malloc的区别
- 下一篇： 手把手教你玩转SOCKET模型：完成例程