通常要開發(fā)網(wǎng)絡(luò)應(yīng)用程序并不是一件輕松的事情，不過，實(shí)際上只要掌握幾個(gè)關(guān)鍵的原則也就可以了——創(chuàng)建和連接一個(gè)套接字，嘗試進(jìn)行連接，然后收發(fā)數(shù)據(jù)。真正難的是要寫出一個(gè)可以接納少則一個(gè)，多則數(shù)千個(gè)連接的網(wǎng)絡(luò)應(yīng)用程序。本文將討論如何通過Winsock2在Windows NT和Windows 2000上開發(fā)高擴(kuò)展能力的Winsock應(yīng)用程序。文章主要的焦點(diǎn)在客戶機(jī)/服務(wù)器模型的服務(wù)器這一方，當(dāng)然，其中的許多要點(diǎn)對(duì)模型的雙方都適用。

API與響應(yīng)規(guī)模
通過 Win32 的重疊 I/O 機(jī)制，應(yīng)用程序可以提請(qǐng)一項(xiàng) I/O 操作，重疊的操作請(qǐng)求在后臺(tái)完成，而同一時(shí)間提請(qǐng)操作的線程去做其他的事情。等重疊操作完成后線程收到有關(guān)的通知。這種機(jī)制對(duì)那些耗時(shí)的操作而言特別有用。不過，像 Windows 3.1 上的 WSAAsyncSelect() 及 Unix 下的 select() 那樣的函數(shù)雖然易于使用，但是它們不能滿足響應(yīng)規(guī)模的需要。而完成端口機(jī)制是針對(duì)操作系統(tǒng)內(nèi)部進(jìn)行了優(yōu)化，在 Windows NT 和 Windows 2000 上，使用了完成端口的重疊 I/O 機(jī)制才能夠真正擴(kuò)大系統(tǒng)的響應(yīng)規(guī)模。
完成端口
一個(gè)完成端口其實(shí)就是一個(gè)通知隊(duì)列，由操作系統(tǒng)把已經(jīng)完成的重疊 I/O 請(qǐng)求的通知放入其中。當(dāng)某項(xiàng) I/O 操作一旦完成，某個(gè)可以對(duì)該操作結(jié)果進(jìn)行處理的工作者線程就會(huì)收到一則通知。而套接字在被創(chuàng)建后，可以在任何時(shí)候與某個(gè)完成端口進(jìn)行關(guān)聯(lián)。
通常情況下，我們會(huì)在應(yīng)用程序中創(chuàng)建一定數(shù)量的工作者線程來處理這些通知。線程數(shù)量取決于應(yīng)用程序的特定需要。理想的情況是，線程數(shù)量等于處理器的數(shù)量，不過這也要求任何線程都不應(yīng)該執(zhí)行諸如同步讀寫、等待事件通知等阻塞型的操作，以免線程阻塞。每個(gè)線程都將分到一定的 CPU 時(shí)間，在此期間該線程可以運(yùn)行，然后另一個(gè)線程將分到一個(gè)時(shí)間片并開始執(zhí)行。如果某個(gè)線程執(zhí)行了阻塞型的操作，操作系統(tǒng)將剝奪其未使用的剩余時(shí)間片并讓其它線程開始執(zhí)行。也就是說，前一個(gè)線程沒有充分使用其時(shí)間片，當(dāng)發(fā)生這樣的情況時(shí)，應(yīng)用程序應(yīng)該準(zhǔn)備其它線程來充分利用這些時(shí)間片。
完成端口的使用分為兩步。首先創(chuàng)建完成端口，如以下代碼所示：

HANDLE??? hIocp;

hIocp = CreateIoCompletionPort(

??? INVALID_HANDLE_VALUE,

??? NULL,

??? (ULONG_PTR)0,

??? 0);

if (hIocp == NULL) {

???// Error

}

完成端口創(chuàng)建后，要把將使用該完成端口的套接字與之關(guān)聯(lián)起來。方法是再次調(diào)用 CreateIoCompletionPort () 函數(shù)，第一個(gè)參數(shù) FileHandle 設(shè)為套接字的句柄，第二個(gè)參數(shù) ExistingCompletionPort 設(shè)為剛剛創(chuàng)建的那個(gè)完成端口的句柄。
以下代碼創(chuàng)建了一個(gè)套接字，并把它和前面創(chuàng)建的完成端口關(guān)聯(lián)起來：

SOCKET??? s;

s = socket(AF_INET, SOCK_STREAM, 0);

if (s == INVALID_SOCKET) {

???// Error

if (CreateIoCompletionPort((HANDLE)s,??// Socket handle

?????????????????????????? hIocp,???????// Existing Completion Port Handle

?????????????????????????? (ULONG_PTR)0,

?????????????????????????? 0) == NULL)

{

// Error

}

// Other Operation

這時(shí)就完成了套接字與完成端口的關(guān)聯(lián)操作。在這個(gè)套接字上進(jìn)行的任何重疊操作都將通過完成端口發(fā)出完成通知。注意， CreateIoCompletionPort() 函數(shù)中的第三個(gè)參數(shù)用來設(shè)置一個(gè)與該套接字相關(guān)的 “ 完成鍵 ( completion key )”( 譯者注：完成鍵可以是任何數(shù)據(jù)類型 ) 。每當(dāng)完成通知到來時(shí)，應(yīng)用程序可以讀取相應(yīng)的完成鍵，因此，完成鍵可用來給套接字傳遞一些背景信息。 (RedFox: 完成鍵對(duì)對(duì)應(yīng)於 Socket 句柄 ) 在創(chuàng)建了完成端口、將一個(gè)或多個(gè)套接字與之相關(guān)聯(lián)之后，我們就要?jiǎng)?chuàng)建若干個(gè)線程來處理完成通知。這些線程不斷循環(huán)調(diào)用 GetQueuedCompletionStatus () 函數(shù)并返回完成通知。
下面，我們先來看看應(yīng)用程序如何跟蹤這些重疊操作。當(dāng)應(yīng)用程序調(diào)用一個(gè)重疊操作函數(shù)時(shí)，要把指向一個(gè) overlapped 結(jié)構(gòu)的指針包括在其參數(shù)中。當(dāng)操作完成后，我們可以通過 GetQueuedCompletionStatus() 函數(shù)中拿回這個(gè)指針。不過，單是根據(jù)這個(gè)指針?biāo)赶虻?overlapped 結(jié)構(gòu)，應(yīng)用程序并不能分辨究竟完成的是哪個(gè)操作。要實(shí)現(xiàn)對(duì)操作的跟蹤，你可以自己定義一個(gè) OVERLAPPED 結(jié)構(gòu)，在其中加入所需的跟蹤信息。
無論何時(shí)調(diào)用重疊操作函數(shù)時(shí)，總是會(huì)通過其 lpOverlapped 參數(shù)傳遞一個(gè) OVERLAPPEDPLUS 結(jié)構(gòu) ( 例如 WSASend 、 WSARecv 等函數(shù) ) 。這就允許你為每一個(gè)重疊調(diào)用操作設(shè)置某些操作狀態(tài)信息，當(dāng)操作結(jié)束后，你可以通過 GetQueuedCompletionStatus() 函數(shù)獲得你自定義結(jié)構(gòu)的指針。注意 OVERLAPPED 字段不要求一定是這個(gè)擴(kuò)展后的結(jié)構(gòu)的第一個(gè)字段。當(dāng)?shù)玫搅酥赶?OVERLAPPED 結(jié)構(gòu)的指針以后，可以用 CONTAINING_RECORD 宏取出其中指向擴(kuò)展結(jié)構(gòu)的指針 ( RedFox : 數(shù)據(jù)稍帶，因?yàn)樗鼈兌加猛粋€(gè)地址空間 ) 。
OVERLAPPED 結(jié)構(gòu)的定義如下：

typedef struct _OVERLAPPEDPLUS {

??? OVERLAPPED??????? ol;

??? SOCKET??????????? s, sclient;

??? int?????????????? OpCode;

??? WSABUF??????????? wbuf;

??? DWORD???????????? dwBytes, dwFlags;

???// other useful information

} OVERLAPPEDPLUS;

#define OP_READ???? 0

#define OP_WRITE??? 1

#define OP_ACCEPT?? 2

下面讓我們來看看 Figure2 里工作者線程的情況。
Figure 2 Worker Thread

DWORD WINAPI WorkerThread(LPVOID lpParam)

{???

??? ULONG_PTR?????? *PerHandleKey;

??? OVERLAPPED????? *Overlap;

??? OVERLAPPEDPLUS? *OverlapPlus,

??????????????????? *newolp;

??? DWORD?????????? dwBytesXfered;

??? while (1)

??? {

??????? ret = GetQueuedCompletionStatus(

??????????? hIocp,

??????????? &dwBytesXfered,

??????????? (PULONG_PTR)&PerHandleKey,

??????????? &Overlap,

??????????? INFINITE);

??????? if (ret == 0)

??????? {

??????????? // Operation failed

??????????? continue;

??????? }

??????? OverlapPlus = CONTAINING_RECORD(Overlap, OVERLAPPEDPLUS, ol);

???

??? switch (OverlapPlus->OpCode)

??? {

??? case OP_ACCEPT:

??????? // Client socket is contained in OverlapPlus.sclient

??????? // Add client to completion port

??????????? CreateIoCompletionPort(

??????????????? (HANDLE)OverlapPlus->sclient,

??????????????? hIocp,

??????????????? (ULONG_PTR)0,

??????????????? 0);

??????? //? Need a new OVERLAPPEDPLUS structure

??????? //? for the newly accepted socket. Perhaps

??????? //? keep a look aside list of free structures.

??????? newolp = AllocateOverlappedPlus();

??????? if (!newolp)

??????? {

??????????? // Error

??????? }

??????? newolp->s = OverlapPlus->sclient;

??????? newolp->OpCode = OP_READ;

??????? // This function prepares the data to be sent

??????? PrepareSendBuffer(&newolp->wbuf);

?

??????? ret = WSASend(

??????????????? newolp->s,

??????????????? &newolp->wbuf,

??????????????? 1,

??????????????? &newolp->dwBytes,

??????????????? 0,

??????????????? &newolp.ol,

??????????????? NULL);

???????

??????? if (ret == SOCKET_ERROR)

??????? {

??????????? if (WSAGetLastError() != WSA_IO_PENDING)

??????????? {

??????????? // Error

??????????? }

??????? }

??????? // Put structure in look aside list for later use

??????? FreeOverlappedPlus(OverlapPlus);

??????? // Signal accept thread to issue another AcceptEx

??????? SetEvent(hAcceptThread);

??????? break;

??? case OP_READ:

??????? // Process the data read???

??????? // ???

??????? // Repost the read if necessary, reusing the same

??????? // receive buffer as before

??????? memset(&OverlapPlus->ol, 0, sizeof(OVERLAPPED));

??????? ret = WSARecv(

????????????? OverlapPlus->s,

????????????? &OverlapPlus->wbuf,

????????????? 1,

????????????? &OverlapPlus->dwBytes,

????????????? &OverlapPlus->dwFlags,

????????????? &OverlapPlus->ol,

????????????? NULL);

??????? if (ret == SOCKET_ERROR)

??????? {

??????????? if (WSAGetLastError() != WSA_IO_PENDING)

??????????? {

??????????????? // Error

??????????? }

??????? }

??????? break;

??? case OP_WRITE:

??????? // Process the data sent, etc.

??????? break;

??? } // switch

??? } // while

}? // WorkerThread

其中每句柄鍵 ( PerHandleKey ) 變量的內(nèi)容，是在把完成端口與套接字進(jìn)行關(guān)聯(lián)時(shí)所設(shè)置的完成鍵參數(shù)； Overlap 參數(shù)返回的是一個(gè)指向發(fā)出重疊操作時(shí)所使用的那個(gè) OVERLAPPEDPLUS 結(jié)構(gòu)的指針。
要記住，如果重疊操作調(diào)用失敗時(shí) ( 也就是說，返回值是 SOCKET_ERROR ，并且錯(cuò)誤原因不是 WSA_IO_PENDING ) ，那么完成端口將不會(huì)收到任何完成通知。如果重疊操作調(diào)用成功，或者發(fā)生原因是 WSA_IO_PENDING 的錯(cuò)誤時(shí)，完成端口將總是能夠收到完成通知。 ( 如果不返回 SOCKET_ERROR 呢？表示成功讀到數(shù)據(jù)了？ need to test ) Windows NT和Windows 2000的套接字架構(gòu)
對(duì)于開發(fā)大響應(yīng)規(guī)模的 Winsock 應(yīng)用程序而言，對(duì) Windows NT 和 Windows 2000 的套接字架構(gòu)有基本的了解是很有幫助的。
與其它類型操作系統(tǒng)不同， Windows NT 和 Windows 2000 的傳輸協(xié)議沒有一種風(fēng)格像套接字那樣的、可以和應(yīng)用程序直接交談的界面，而是采用了一種更為底層的 API ，叫做傳輸驅(qū)動(dòng)程序界面 ( Transport Driver Interface,TDI ) 。 Winsock 的核心模式驅(qū)動(dòng)程序負(fù)責(zé)連接和緩沖區(qū)管理，以便向應(yīng)用程序提供套接字仿真 ( 在 AFD.SYS 文件中實(shí)現(xiàn) ) ，同時(shí)負(fù)責(zé)與底層傳輸驅(qū)動(dòng)程序?qū)υ挕?br /> 誰來負(fù)責(zé)管理緩沖區(qū)？
正如上面所說的，應(yīng)用程序通過 Winsock 來和傳輸協(xié)議驅(qū)動(dòng)程序交談，而 AFD.SYS 負(fù)責(zé)為應(yīng)用程序進(jìn)行緩沖區(qū)管理。也就是說，當(dāng)應(yīng)用程序調(diào)用 send() 或 WSASend() 函數(shù)來發(fā)送數(shù)據(jù)時(shí)， AFD.SYS 將把數(shù)據(jù)拷貝進(jìn)它自己的內(nèi)部緩沖區(qū) ( 取決于 SO_SNDBUF 設(shè)定值 ) ，然后 send() 或 WSASend() 函數(shù)立即返回。也可以這么說， AFD.SYS 在后臺(tái)負(fù)責(zé)把數(shù)據(jù)發(fā)送出去。不過，如果應(yīng)用程序要求發(fā)出的數(shù)據(jù)超過了 SO_SNDBUF 設(shè)定的緩沖區(qū)大小，那么 WSASend() 函數(shù)會(huì)阻塞，直至所有數(shù)據(jù)發(fā)送完畢。
從遠(yuǎn)程客戶端接收數(shù)據(jù)的情況也類似。只要不用從應(yīng)用程序那里接收大量的數(shù)據(jù)，而且沒有超出 SO_RCVBUF 設(shè)定的值， AFD.SYS 將把數(shù)據(jù)先拷貝到其內(nèi)部緩沖區(qū)中。當(dāng)應(yīng)用程序調(diào)用 recv() 或 WSARecv() 函數(shù)時(shí)，數(shù)據(jù)將從內(nèi)部緩沖拷貝到應(yīng)用程序提供的緩沖區(qū)。
多數(shù)情況下，這樣的架構(gòu)運(yùn)行良好，特別在是應(yīng)用程序采用傳統(tǒng)的套接字下非重疊的 send() 和 receive() 模式編寫的時(shí)候。不過程序員要小心的是，盡管可以通過 setsockopt() 這個(gè) API 來把 SO_SNDBUF 和 SO_RCVBUF 選項(xiàng)值設(shè)成 0( 關(guān)閉內(nèi)部緩沖區(qū) ) ，但是程序員必須十分清楚把 AFD.SYS 的內(nèi)部緩沖區(qū)關(guān)掉會(huì)造成什么后果，避免收發(fā)數(shù)據(jù)時(shí)有關(guān)的緩沖區(qū)拷貝可能引起的系統(tǒng)崩潰。
舉例來說，一個(gè)應(yīng)用程序通過設(shè)定 SO_SNDBUF 為 0 把緩沖區(qū)關(guān)閉，然后發(fā)出一個(gè)阻塞 send() 調(diào)用。在這樣的情況下，系統(tǒng)內(nèi)核會(huì)把應(yīng)用程序的緩沖區(qū)鎖定，直到接收方確認(rèn)收到了整個(gè)緩沖區(qū)后 send() 調(diào)用才返回。似乎這是一種判定你的數(shù)據(jù)是否已經(jīng)為對(duì)方全部收到的簡(jiǎn)潔的方法，實(shí)際上卻并非如此。想想看，即使遠(yuǎn)端 TCP 通知數(shù)據(jù)已經(jīng)收到，其實(shí)也根本不代表數(shù)據(jù)已經(jīng)成功送給客戶端應(yīng)用程序，比如對(duì)方可能發(fā)生資源不足的情況，導(dǎo)致 AFD.SYS 不能把數(shù)據(jù)拷貝給應(yīng)用程序。另一個(gè)更要緊的問題是，在每個(gè)線程中每次只能進(jìn)行一次發(fā)送調(diào)用，效率極其低下。
把 SO_RCVBUF 設(shè)為 0 ，關(guān)閉 AFD.SYS 的接收緩沖區(qū)也不能讓性能得到提升，這只會(huì)迫使接收到的數(shù)據(jù)在比 Winsock 更低的層次進(jìn)行緩沖，當(dāng)你發(fā)出 receive 調(diào)用時(shí)，同樣要進(jìn)行緩沖區(qū)拷貝，因此你本來想避免緩沖區(qū)拷貝的陰謀不會(huì)得逞。
現(xiàn)在我們應(yīng)該清楚了，關(guān)閉緩沖區(qū)對(duì)于多數(shù)應(yīng)用程序而言并不是什么好主意。只要要應(yīng)用程序注意隨時(shí)在某個(gè)連接上保持幾個(gè) WSARecvs 重疊調(diào)用，那么通常沒有必要關(guān)閉接收緩沖區(qū)。如果 AFD.SYS 總是有由應(yīng)用程序提供的緩沖區(qū)可用，那么它將沒有必要使用內(nèi)部緩沖區(qū)。
高性能的服務(wù)器應(yīng)用程序可以關(guān)閉發(fā)送緩沖區(qū)，同時(shí)不會(huì)損失性能。不過，這樣的應(yīng)用程序必須十分小心，保證它總是發(fā)出多個(gè)重疊發(fā)送調(diào)用，而不是等待某個(gè)重疊發(fā)送結(jié)束了才發(fā)出下一個(gè)。如果應(yīng)用程序是按一個(gè)發(fā)完再發(fā)下一個(gè)的順序來操作，那浪費(fèi)掉兩次發(fā)送中間的空檔時(shí)間，總之是要保證傳輸驅(qū)動(dòng)程序在發(fā)送完一個(gè)緩沖區(qū)后，立刻可以轉(zhuǎn)向另一個(gè)緩沖區(qū)。
資源的限制條件
在設(shè)計(jì)任何服務(wù)器應(yīng)用程序時(shí)，其強(qiáng)健性是主要的目標(biāo)。也就是說， 你的應(yīng)用程序要能夠應(yīng)對(duì)任何突發(fā)的問題，例如并發(fā)客戶請(qǐng)求數(shù)達(dá)到峰值、可用內(nèi)存臨時(shí)出現(xiàn)不足、以及其它短時(shí)間的現(xiàn)象。這就要求程序的設(shè)計(jì)者注意 Windows NT 和 2000 系統(tǒng)下的資源限制條件的問題，從容地處理突發(fā)性事件。
你可以直接控制的、最基本的資源就是網(wǎng)絡(luò)帶寬。通常，使用用戶數(shù)據(jù)報(bào)協(xié)議 (UDP) 的應(yīng)用程序都可能會(huì)比較注意帶寬方面的限制，以最大限度地減少包的丟失。然而，在使用 TCP 連接時(shí)，服務(wù)器必須十分小心地控制好，防止網(wǎng)絡(luò)帶寬過載超過一定的時(shí)間，否則將需要重發(fā)大量的包或造成大量連接中斷。關(guān)于帶寬管理的方法應(yīng)根據(jù)不同的應(yīng)用程序而定，這超出了本文討論的范圍。
虛擬內(nèi)存的使用也必須很小心地管理。通過謹(jǐn)慎地申請(qǐng)和釋放內(nèi)存，或者應(yīng)用 lookaside lists ( 一種高速緩存 ) 技術(shù)來重新使用已分配的內(nèi)存，將有助于控制服務(wù)器應(yīng)用程序的內(nèi)存開銷 ( 原文為 “ 讓服務(wù)器應(yīng)用程序留下的腳印小一點(diǎn) ”) ，避免操作系統(tǒng)頻繁地將應(yīng)用程序申請(qǐng)的物理內(nèi)存交換到虛擬內(nèi)存中 ( 原文為 “ 讓操作系統(tǒng)能夠總是把更多的應(yīng)用程序地址空間更多地保留在內(nèi)存中 ”) 。你也可以通過 SetWorkingSetSize() 這個(gè) Win32 API 讓操作系統(tǒng)分配給你的應(yīng)用程序更多的物理內(nèi)存。
在使用 Winsock 時(shí)還可能碰到另外兩個(gè)非直接的資源不足情況。一個(gè)是被鎖定的內(nèi)存頁(yè)面的極限。如果你把 AFD.SYS 的緩沖關(guān)閉，當(dāng)應(yīng)用程序收發(fā)數(shù)據(jù)時(shí)，應(yīng)用程序緩沖區(qū)的所有頁(yè)面將被鎖定到物理內(nèi)存中。這是因?yàn)閮?nèi)核驅(qū)動(dòng)程序需要訪問這些內(nèi)存，在此期間這些頁(yè)面不能交換出去。如果操作系統(tǒng)需要給其它應(yīng)用程序分配一些可分頁(yè)的物理內(nèi)存，而又沒有足夠的內(nèi)存時(shí)就會(huì)發(fā)生問題。我們的目標(biāo)是要防止寫出一個(gè)病態(tài)的、鎖定所有物理內(nèi)存、讓系統(tǒng)崩潰的程序。也就是說，你的程序鎖定內(nèi)存時(shí)，不要超出系統(tǒng)規(guī)定的內(nèi)存分頁(yè)極限。
在 Windows NT 和 2000 系統(tǒng)上，所有應(yīng)用程序總共可以鎖定的內(nèi)存大約是物理內(nèi)存的 1/8( 不過這只是一個(gè)大概的估計(jì)，不是你計(jì)算內(nèi)存的依據(jù) ) 。如果你的應(yīng)用程序不注意這一點(diǎn)，當(dāng)你的發(fā)出太多的重疊收發(fā)調(diào)用，而且 I/O 沒來得及完成時(shí)，就可能偶爾發(fā)生 ERROR_INSUFFICIENT_RESOURCES 的錯(cuò)誤。在這種情況下你要避免過度鎖定內(nèi)存。同時(shí)要注意，系統(tǒng)會(huì)鎖定包含你的緩沖區(qū)所在的整個(gè)內(nèi)存頁(yè)面，因此緩沖區(qū)靠近頁(yè)邊界時(shí)是有代價(jià)的 ( 譯者理解，緩沖區(qū)如果正好超過頁(yè)面邊界，那怕是 1 個(gè)字節(jié)，超出的這個(gè)字節(jié)所在的頁(yè)面也會(huì)被鎖定 ) 。
另外一個(gè)限制是你的程序可能會(huì)遇到系統(tǒng)未分頁(yè)池資源不足的情況。所謂未分頁(yè)池是一塊永遠(yuǎn)不被交換出去的內(nèi)存區(qū)域，這塊內(nèi)存用來存儲(chǔ)一些供各種內(nèi)核組件訪問的數(shù)據(jù)，其中有的內(nèi)核組件是不能訪問那些被交換出去的頁(yè)面空間的。 Windows NT 和 2000 的驅(qū)動(dòng)程序能夠從這個(gè)特定的未分頁(yè)池分配內(nèi)存。
當(dāng)應(yīng)用程序創(chuàng)建一個(gè)套接字 ( 或者是類似的打開某個(gè)文件 ) 時(shí)，內(nèi)核會(huì)從未分頁(yè)池中分配一定數(shù)量的內(nèi)存，而且在綁定、連接套接字時(shí)，內(nèi)核又會(huì)從未分頁(yè)池中再分配一些內(nèi)存。當(dāng)你注意觀察這種行為時(shí)你將發(fā)現(xiàn)，如果你發(fā)出某些 I/O 請(qǐng)求時(shí) ( 例如收發(fā)數(shù)據(jù) ) ，你會(huì)從未分頁(yè)池里再分配多一些內(nèi)存 ( 比如要追蹤某個(gè)待決的 I/O 操作，你可能需要給這個(gè)操作添加一個(gè)自定義結(jié)構(gòu)，如前文所提及的 ) 。最后這就可能會(huì)造成一定的問題，操作系統(tǒng)會(huì)限制未分頁(yè)內(nèi)存的用量。
在 Windows NT 和 2000 這兩種操作系統(tǒng)上，給每個(gè)連接分配的未分頁(yè)內(nèi)存的具體數(shù)量是不同的，未來版本的 Windows 很可能也不同。為了使應(yīng)用程序的生命期更長(zhǎng)，你就不應(yīng)該計(jì)算對(duì)未分頁(yè)池內(nèi)存的具體需求量。
你的程序必須防止消耗到未分頁(yè)池的極限。當(dāng)系統(tǒng)中未分頁(yè)池剩余空間太小時(shí)，某些與你的應(yīng)用程序毫無關(guān)系的內(nèi)核驅(qū)動(dòng)就會(huì)發(fā)瘋，甚至造成系統(tǒng)崩潰，特別是當(dāng)系統(tǒng)中有第三方設(shè)備或驅(qū)動(dòng)程序時(shí)，更容易發(fā)生這樣的慘劇 ( 而且無法預(yù)測(cè) ) 。同時(shí)你還要記住，同一臺(tái)電腦上還可能運(yùn)行有其它同樣消耗未分頁(yè)池的其它應(yīng)用程序，因此在設(shè)計(jì)你的應(yīng)用程序時(shí)，對(duì)資源量的預(yù)估要特別保守和謹(jǐn)慎。
處理資源不足的問題是十分復(fù)雜的，因?yàn)榘l(fā)生上述情況時(shí)你不會(huì)收到特別的錯(cuò)誤代碼，通常你只能收到一般性的 WSAENOBUFS 或者 ERROR_INSUFFICIENT_RESOURCES 錯(cuò)誤。要處理這些錯(cuò)誤，首先，把你的應(yīng)用程序工作配置調(diào)整到合理的最大值 ( 譯者注：所謂工作配置，是指應(yīng)用程序各部分運(yùn)行中所需的內(nèi)存用量，請(qǐng)參考 http://msdn.microsoft.com/msdnmag/issues/1000/Bugslayer/Bugslayer1000.asp ，關(guān)于內(nèi)存優(yōu)化，譯者另有譯文 ) ，如果錯(cuò)誤繼續(xù)出現(xiàn)，那么注意檢查是否是網(wǎng)絡(luò)帶寬不足的問題。之后，請(qǐng)確認(rèn)你沒有同時(shí)發(fā)出太多的收發(fā)調(diào)用。最后，如果還是收到資源不足的錯(cuò)誤，那就很可能是遇到了未分頁(yè)內(nèi)存池不足的問題了。要釋放未分頁(yè)內(nèi)存池空間，請(qǐng)關(guān)閉應(yīng)用程序中相當(dāng)部分的連接，等待系統(tǒng)自行渡過和修正這個(gè)瞬時(shí)的錯(cuò)誤。 接受連接請(qǐng)求
服務(wù)器要做的最普通的事情之一就是接受來自客戶端的連接請(qǐng)求。在套接字上使用重疊 I/O 接受連接的惟一 API 就是 AcceptEx() 函數(shù)。有趣的是，通常的同步接受函數(shù) accept() 的返回值是一個(gè)新的套接字，而 AcceptEx() 函數(shù)則需要另外一個(gè)套接字作為它的參數(shù)之一。這是因?yàn)?AcceptEx() 是一個(gè)重疊操作，所以你需要事先創(chuàng)建一個(gè)套接字 ( 但不要綁定或連接它 ) ，并把這個(gè)套接字通過參數(shù)傳給 AcceptEx() 。以下是一小段典型的使用 AcceptEx() 的偽代碼： ? do { - 等待上一個(gè) AcceptEx 完成 - 創(chuàng)建一個(gè)新套接字并與完成端口進(jìn)行關(guān)聯(lián) - 設(shè)置背景結(jié)構(gòu)等等 - 發(fā)出一個(gè) AcceptEx 請(qǐng)求 }while(TRUE);
作為一個(gè)高響應(yīng)能力的服務(wù)器，它必須發(fā)出足夠的 AcceptEx 調(diào)用，守候著，一旦出現(xiàn)客戶端連接請(qǐng)求就立刻響應(yīng)。至于發(fā)出多少個(gè) AcceptEx 才夠，就取決于你的服務(wù)器程序所期待的通信交通類型。比如，如果進(jìn)入連接率高的情況 ( 因?yàn)檫B接持續(xù)時(shí)間較短，或者出現(xiàn)交通高峰 ) ，那么所需要守候的 AcceptEx 當(dāng)然要比那些偶爾進(jìn)入的客戶端連接的情況要多。聰明的做法是，由應(yīng)用程序來分析交通狀況，并調(diào)整 AcceptEx 守候的數(shù)量，而不是固定在某個(gè)數(shù)量上。
對(duì)于 Windows2000 ， Winsock 提供了一些機(jī)制，幫助你判定 AcceptEx 的數(shù)量是否足夠。這就是，在創(chuàng)建監(jiān)聽套接字時(shí)創(chuàng)建一個(gè)事件，通過 WSAEventSelect() 這個(gè) API 并注冊(cè) FD_ACCEPT 事件通知來把套接字和這個(gè)事件關(guān)聯(lián)起來。一旦系統(tǒng)收到一個(gè)連接請(qǐng)求，如果系統(tǒng)中沒有 AcceptEx() 正在等待接受連接，那么上面的事件將收到一個(gè)信號(hào)。通過這個(gè)事件，你就可以判斷你有沒有發(fā)出足夠的 AcceptEx() ，或者檢測(cè)出一個(gè)非正常的客戶請(qǐng)求 ( 下文述 ) 。這種機(jī)制對(duì) Windows NT 4.0 不適用。
使用 AcceptEx() 的一大好處是，你可以通過一次調(diào)用就完成接受客戶端連接請(qǐng)求和接受數(shù)據(jù) ( 通過傳送 lpOutputBuffer 參數(shù) ) 兩件事情。也就是說，如果客戶端在發(fā)出連接的同時(shí)傳輸數(shù)據(jù)，你的 AcceptEx() 調(diào)用在連接創(chuàng)建并接收了客戶端數(shù)據(jù)后就可以立刻返回。這樣可能是很有用的，但是也可能會(huì)引發(fā)問題，因?yàn)?AcceptEx() 必須等全部客戶端數(shù)據(jù)都收到了才返回。具體來說，如果你在發(fā)出 AcceptEx() 調(diào)用的同時(shí)傳遞了 lpOutputBuffer 參數(shù)，那么 AcceptEx() 不再是一項(xiàng)原子型的操作，而是分成了兩步：接受客戶連接，等待接收數(shù)據(jù)。當(dāng)缺少一種機(jī)制來通知你的應(yīng)用程序所發(fā)生的這種情況： “ 連接已經(jīng)建立了，正在等待客戶端數(shù)據(jù) ” ，這將意味著有可能出現(xiàn)客戶端只發(fā)出連接請(qǐng)求，但是不發(fā)送數(shù)據(jù)。如果你的服務(wù)器收到太多這種類型的連接時(shí)，它將拒絕連接更多的合法客戶端請(qǐng)求。這就是黑客進(jìn)行 “ 拒絕服務(wù) ” 攻擊的常見手法。
要預(yù)防此類攻擊，接受連接的線程應(yīng)該不時(shí)地通過調(diào)用 getsockopt() 函數(shù) ( 選項(xiàng)參數(shù)為 SO_CONNECT_TIME ) 來檢查 AcceptEx() 里守候的套接字。 getsockopt() 函數(shù)的選項(xiàng)值將被設(shè)置為套接字被連接的時(shí)間，或者設(shè)置為 -1( 代表套接字尚未建立連接 ) 。這時(shí)， WSAEventSelect() 的特性就可以很好地利用來做這種檢查。如果發(fā)現(xiàn)連接已經(jīng)建立，但是很久都沒有收到數(shù)據(jù)的情況，那么就應(yīng)該終止連接，方法就是關(guān)閉作為參數(shù)提供給 AcceptEx() 的那個(gè)套接字。注意，在多數(shù)非緊急情況下，如果套接字已經(jīng)傳遞給 AcceptEx() 并開始守候，但還未建立連接，那么你的應(yīng)用程序不應(yīng)該關(guān)閉它們。這是因?yàn)榧词龟P(guān)閉了這些套接字，出于提高系統(tǒng)性能的考慮，在連接進(jìn)入之前，或者監(jiān)聽套接字自身被關(guān)閉之前，相應(yīng)的內(nèi)核模式的數(shù)據(jù)結(jié)構(gòu)也不會(huì)被干凈地清除。 發(fā)出 AcceptEx() 調(diào)用的線程，似乎與那個(gè)進(jìn)行完成端口關(guān)聯(lián)操作、處理其它 I/O 完成通知的線程是同一個(gè)，但是，別忘記線程里應(yīng)該盡力避免執(zhí)行阻塞型的操作。 Winsock2 分層結(jié)構(gòu)的一個(gè)副作用是調(diào)用 socket() 或 WSASocket() API 的上層架構(gòu)可能很重要 ( 譯者不太明白原文意思，抱歉 ) 。每個(gè) AcceptEx() 調(diào)用都需要?jiǎng)?chuàng)建一個(gè)新套接字，所以最好有一個(gè)獨(dú)立的線程專門調(diào)用 AcceptEx() ，而不參與其它 I/O 處理。你也可以利用這個(gè)線程來執(zhí)行其它任務(wù)，比如事件記錄。
有關(guān) AcceptEx() 的最后一個(gè)注意事項(xiàng)：要實(shí)現(xiàn)這些 API ，并不需要其它提供商提供的 Winsock2 實(shí)現(xiàn)。這一點(diǎn)對(duì)微軟特有的其它 API 也同樣適用，比如 TransmitFile() 和 GetAcceptExSockAddrs() ，以及其它可能會(huì)被加入到新版 Windows 的 API. 在 Windows NT 和 2000 上，這些 API 是在微軟的底層提供者 DLL(mswsock.dll) 中實(shí)現(xiàn)的，可通過與 mswsock.lib 編譯連接進(jìn)行調(diào)用，或者通過 WSAIoctl() ( 選項(xiàng)參數(shù)為 SIO_GET_EXTENSION_FUNCTION_POINTER) 動(dòng)態(tài)獲得函數(shù)的指針。
如果在沒有事先獲得函數(shù)指針的情況下直接調(diào)用函數(shù) ( 也就是說，編譯時(shí)靜態(tài)連接 mswsock.lib ，在程序中直接調(diào)用函數(shù) ) ，那么性能將很受影響。因?yàn)?AcceptEx() 被置于 Winsock2 架構(gòu)之外，每次調(diào)用時(shí)它都被迫通過 WSAIoctl() 取得函數(shù)指針。要避免這種性能損失，需要使用這些 API 的應(yīng)用程序應(yīng)該通過調(diào)用 WSAIoctl() 直接從底層的提供者那里取得函數(shù)的指針。 參見 Figure 3 套接字架構(gòu)： ? TransmitFile和TransmitPackets Winsock 提供兩個(gè)專門為文件和內(nèi)存數(shù)據(jù)傳輸進(jìn)行了優(yōu)化的函數(shù)。其中 TransmitFile() 這個(gè) API 函數(shù)在 Windows NT 4.0 和 Windows 2000 上都可以使用，而 TransmitPackets() 則將在未來版本的 Windows 中實(shí)現(xiàn)。
TransmitFile() 用來把文件內(nèi)容通過 Winsock 進(jìn)行傳輸。通常發(fā)送文件的做法是，先調(diào)用 CreateFile() 打開一個(gè)文件，然后不斷循環(huán)調(diào)用 ReadFile() 和 WSASend () 直至數(shù)據(jù)發(fā)送完畢。但是這種方法很沒有效率，因?yàn)槊看握{(diào)用 ReadFile() 和 WSASend () 都會(huì)涉及一次從用戶模式到內(nèi)核模式的轉(zhuǎn)換。如果換成 TransmitFile() ，那么只需要給它一個(gè)已打開文件的句柄和要發(fā)送的字節(jié)數(shù)，而所涉及的模式轉(zhuǎn)換操作將只在調(diào)用 CreateFile() 打開文件時(shí)發(fā)生一次，然后 TransmitFile() 時(shí)再發(fā)生一次。這樣效率就高多了。 TransmitPackets() 比 TransmitFile() 更進(jìn)一步，它允許用戶只調(diào)用一次就可以發(fā)送指定的多個(gè)文件和內(nèi)存緩沖區(qū)。函數(shù)原型如下： BOOL TransmitPackets( SOCKET hSocket, LPTRANSMIT_PACKET_ELEMENT lpPacketArray, DWORD nElementCount, DWORD nSendSize, LPOVERLAPPED lpOverlapped,? DWORD dwFlags );
其中， lpPacketArray 是一個(gè)結(jié)構(gòu)的數(shù)組，其中的每個(gè)元素既可以是一個(gè)文件句柄或者內(nèi)存緩沖區(qū)，該結(jié)構(gòu)定義如下： typedef struct _TRANSMIT_PACKETS_ELEMENT { DWORD dwElFlags; DWORD cLength; union { struct { LARGE_INTEGER???? nFileOffset; HANDLE??????????? hFile; }; PVOID???????????? pBuffer; }; } TRANSMIT_FILE_BUFFERS;
其中各字段是自描述型的 (self explanatory) 。
dwElFlags字段： 指定當(dāng)前元素是一個(gè)文件句柄還是內(nèi)存緩沖區(qū) ( 分別通過常量 TF_ELEMENT_FILE 和 TF_ELEMENT_MEMORY 指定 ) ；
cLength字段： 指定將從數(shù)據(jù)源發(fā)送的字節(jié)數(shù) ( 如果是文件，這個(gè)字段值為 0 表示發(fā)送整個(gè)文件 ) ；
結(jié)構(gòu)中的無名聯(lián)合體： 包含文件句柄的內(nèi)存緩沖區(qū) ( 以及可能的偏移量 ) 。 使用這兩個(gè) API 的另一個(gè)好處，是可以通過指定 TF_REUSE_SOCKET 和 TF_DISCONNECT 標(biāo)志來重用套接字句柄。每當(dāng) API 完成數(shù)據(jù)的傳輸工作后，就會(huì)在傳輸層級(jí)別斷開連接，這樣這個(gè)套接字就又可以重新提供給 AcceptEx() 使用。采用這種優(yōu)化的方法編程，將減輕那個(gè)專門做接受操作的線程創(chuàng)建套接字的壓力 ( 前文述及 ) 。
這兩個(gè) API 也都有一個(gè)共同的弱點(diǎn)： Windows NT Workstation 或 Windows 2000 專業(yè)版中，函數(shù)每次只能處理兩個(gè)調(diào)用請(qǐng)求，只有在 Windows NT 、 Windows 2000 服務(wù)器版、 Windows 2000 高級(jí)服務(wù)器版或 Windows 2000 Data Center 中才獲得完全支持。 放在一起看看 以上各節(jié)中，我們討論了開發(fā)高性能的、大響應(yīng)規(guī)模的應(yīng)用程序所需的函數(shù)、方法和可能遇到的資源瓶頸問題。這些對(duì)你意味著什么呢？其實(shí)，這取決于你如何構(gòu)造你的服務(wù)器和客戶端。當(dāng)你能夠在服務(wù)器和客戶端設(shè)計(jì)上進(jìn)行更好地控制時(shí)，那么你越能夠避開瓶頸問題。
來看一個(gè)示范的環(huán)境。我們要設(shè)計(jì)一個(gè)服務(wù)器來響應(yīng)客戶端的連接、發(fā)送請(qǐng)求、接收數(shù)據(jù)以及斷開連接。那么，服務(wù)器將需要?jiǎng)?chuàng)建一個(gè)監(jiān)聽套接字，把它與某個(gè)完成端口進(jìn)行關(guān)聯(lián)，為每顆 CPU 創(chuàng)建一個(gè)工作線程。再創(chuàng)建一個(gè)線程專門用來發(fā)出 AcceptEx() 。我們知道客戶端會(huì)在發(fā)出連接請(qǐng)求后立刻傳送數(shù)據(jù)，所以如果我們準(zhǔn)備好接收緩沖區(qū)會(huì)使事情變得更為容易。當(dāng)然，不要忘記不時(shí)地輪詢 AcceptEx() 調(diào)用中使用的套接字 ( 使用 SO_CONNECT_TIME 選項(xiàng)參數(shù) ) 來確保沒有惡意超時(shí)的連接。
該設(shè)計(jì)中有一個(gè)重要的問題要考慮，我們應(yīng)該允許多少個(gè) AcceptEx() 進(jìn)行守候。這是因?yàn)?#xff0c;每發(fā)出一個(gè) AcceptEx() 時(shí)我們都同時(shí)需要為它提供一個(gè)接收緩沖區(qū)，那么內(nèi)存中將會(huì)出現(xiàn)很多被鎖定的頁(yè)面 ( 前文說過了，每個(gè)重疊操作都會(huì)消耗一小部分未分頁(yè)內(nèi)存池，同時(shí)還會(huì)鎖定所有涉及的緩沖區(qū) ) 。這個(gè)問題很難回答，沒有一個(gè)確切的答案。最好的方法是把這個(gè)值做成可以調(diào)整的，通過反復(fù)做性能測(cè)試，你就可以得出在典型應(yīng)用環(huán)境中最佳的值。
好了，當(dāng)你測(cè)算清楚后，下面就是發(fā)送數(shù)據(jù)的問題了，考慮的重點(diǎn)是你希望服務(wù)器同時(shí)處理多少個(gè)并發(fā)的連接。通常情況下，服務(wù)器應(yīng)該限制并發(fā)連接的數(shù)量以及等候處理的發(fā)送調(diào)用。因?yàn)椴l(fā)連接數(shù)量越多，所消耗的未分頁(yè)內(nèi)存池也越多；等候處理的發(fā)送調(diào)用越多，被鎖定的內(nèi)存頁(yè)面也越多 ( 小心別超過了極限 ) 。這同樣也需要反復(fù)測(cè)試才知道答案。
對(duì)于上述環(huán)境，通常不需要關(guān)閉單個(gè)套接字的緩沖區(qū)，因?yàn)橹辉?AcceptEx() 中有一次接收數(shù)據(jù)的操作，而要保證給每個(gè)到來的連接提供接收緩沖區(qū)并不是太難的事情。但是，如果客戶機(jī)與服務(wù)器交互的方式變一變，客戶機(jī)在發(fā)送了一次數(shù)據(jù)之后，還需要發(fā)送更多的數(shù)據(jù)，在這種情況下關(guān)閉接收緩沖就不太妙了，除非你想辦法保證在每個(gè)連接上都發(fā)出了重疊接收調(diào)用來接收更多的數(shù)據(jù)。
結(jié)論 開發(fā)大響應(yīng)規(guī)模的 Winsock 服務(wù)器并不是很可怕，其實(shí)也就是設(shè)置一個(gè)監(jiān)聽套接字、接受連接請(qǐng)求和進(jìn)行重疊收發(fā)調(diào)用。通過設(shè)置合理的進(jìn)行守候的重疊調(diào)用的數(shù)量，防止出現(xiàn)未分頁(yè)內(nèi)存池被耗盡，這才是最主要的挑戰(zhàn)。按照我們前面討論的一些原則，你就可以開發(fā)出大響應(yīng)規(guī)模的服務(wù)器應(yīng)用程序。?

總結(jié)

以上是生活随笔為你收集整理的用完成端口开发大响应规模的Winsock应用程序的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。