[zz]CompletionPort 完成連接埠 用完成連接埠開發大響應規模的Winsock應用程式

CompletionPort 完成連接埠2007-08-15 10:57

用完成連接埠開發大響應規模的Winsock應用程式   通常要開發網路應用程式並不是一件輕鬆的事情，不過，實際上只要掌握幾個關鍵的原則也就可以了——建立和串連一個通訊端，嘗試進行串連，然後收發資料。真正難的是要寫出一個可以接納少則一個，多則數千個串連的網路應用程式。本文將討論如何通過Winsock2在Windows NT? 和 Windows 2000上開發高擴充能力的Winsock應用程式。文章主要的焦點在客戶機/伺服器模型的伺服器這一方，當然，其中的許多要點對模型的雙方都適用。 API與響應規模通過Win32的重疊I/O機制，應用程式可以提請一項I/O操作，重疊的操作請求在後台完成，而同一時間提請操作的線程去做其他的事情。等重疊操作完成後線程收到有關的通知。這種機制對那些耗時的操作而言特別有用。不過，像Windows 3.1上的WSAAsyncSelect()及Unix下的select()那樣的函數雖然便於使用，但是它們不能滿足響應規模的需要。而完成連接埠機制是針對作業系統內部進行了最佳化，在Windows NT 和 Windows 2000上，使用了完成連接埠的重疊I/O機制才能夠真正擴大系統的響應規模。 完成連接埠 一個完成連接埠其實就是一個通知隊列，由作業系統把已經完成的重疊I/O請求的通知放入其中。當某項I/O操作一旦完成，某個可以對該操作結果進行處理的工作者線程就會收到一則通知。而通訊端在被建立後，可以在任何時候與某個完成連接埠進行關聯。通常情況下，我們會在應用程式中建立一定數量的工作者線程來處理這些通知。線程數量取決於應用程式的特定需要。理想的情況是，線程數量等於處理器的數量，不過這也要求任何線程都不應該執行諸如同步讀寫、等待事件通知等阻塞型的操作，以免線程阻塞。每個線程都將分到一定的CPU時間，在此期間該線程可以運行，然後另一個線程將分到一個時間片並開始執行。如果某個線程執行了阻塞型的操作，作業系統將剝奪其未使用的剩餘時間片並讓其它線程開始執行。也就是說，前一個線程沒有充分使用其時間片，當發生這樣的情況時，應用程式應該準備其它線程來充分利用這些時間片。 完成連接埠的使用分為兩步。首先建立完成連接埠，如以下代碼所示： HANDLE　　hIocp; hIocp = CreateIoCompletionPort( 　　INVALID_HANDLE_value, 　　NULL, 　　(ULONG_PTR)0, 　　0); if (hIocp == NULL) { 　　// Error } 完成連接埠建立後，要把將使用該完成連接埠的通訊端與之關聯起來。方法是再次調用CreateIoCompletionPort ()函數，第一個參數FileHandle設為通訊端的控制代碼，第二個參數ExistingCompletionPort 設為剛剛建立的那個完成連接埠的控制代碼。 以下代碼建立了一個通訊端，並把它和前面建立的完成連接埠關聯起來： SOCKET　　s; s = socket(AF_INET, SOCK_STREAM, 0); if (s == INVALID_SOCKET) { 　　// Error if (CreateIoCompletionPort((HANDLE)s, 　　　　　　　　　　　　　 hIocp, 　　　　　　　　　　　　　 (ULONG_PTR)0, 　　　　　　　　　　　　　 0) == NULL) { // Error } ??? } 這時就完成了通訊端與完成連接埠的關聯操作。在這個通訊端上進行的任何重疊操作都將通過完成連接埠發出完成通知。注意，CreateIoCompletionPort()函數中的第三個參數用來設定一個與該通訊端相關的“完成鍵(completion key)”(譯者註：完成鍵可以是任何資料類型)。每當完成通知到來時，應用程式可以讀取相應的完成鍵，因此，完成鍵可用來給通訊端傳遞一些背景資訊。 在建立了完成連接埠、將一個或多個通訊端與之相關聯之後，我們就要建立若干個線程來處理完成通知。這些線程不斷迴圈調用GetQueuedCompletionStatus ()函數並返回完成通知。下面，我們先來看看應用程式如何跟蹤這些重疊操作。當應用程式調用一個重疊操作函數時，要把指向一個overlapped結構的指標包括在其參數中。當操作完成後，我們可以通過GetQueuedCompletionStatus()函數中拿回這個指標。不過，單是根據這個指標所指向的overlapped結構，應用程式並不能分辨究竟完成的是哪個操作。要實現對操作的跟蹤，你可以自己定義一個OVERLAPPED結構，在其中加入所需的跟蹤資訊。無論何時調用重疊操作函數時，總是會通過其lpOverlapped參數傳遞一個OVERLAPPEDPLUS結構(例如WSASend、 WSARecv等函數)。這就允許你為每一個重疊叫用作業設定某些操作狀態資訊，當操作結束後，你可以通過GetQueuedCompletionStatus()函數獲得你自訂結構的指標。注意OVERLAPPED欄位不要求一定是這個擴充後的結構的第一個欄位。當得到了指向OVERLAPPED結構的指標以後，可以用CONTAINING_RECORD宏取出其中指向擴充結構的指標。OVERLAPPED 結構的定義如下： 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)變數的內容，是在把完成連接埠與通訊端進行關聯時所設定的完成鍵參數；Overlap參數返回的是一個指向發出重疊操作時所使用的那個OVERLAPPEDPLUS結構的指標。要記住，如果重疊操作調用失敗時(也就是說，傳回值是SOCKET_ERROR，並且錯誤原因不是WSA_IO_PENDING)，那麼完成連接埠將不會收到任何完成通知。如果重疊操作調用成功，或者發生原因是WSA_IO_PENDING的錯誤時，完成連接埠將總是能夠收到完成通知。 Windows NT和Windows 2000的通訊端架構 對於開發大響應規模的Winsock應用程式而言，對Windows NT和Windows 2000的通訊端架構有基本的瞭解是很有協助的。與其它類型作業系統不同，Windows NT和Windows 2000的傳輸協議沒有一種風格像通訊端那樣的、可以和應用程式直接交談的介面，而是採用了一種更為底層的API，叫做傳輸驅動程式介面(Transport Driver Interface,TDI)。Winsock的核心模式驅動程式負責串連和緩衝區管理，以便嚮應用程式提供通訊端模擬(在AFD.SYS檔案中實現)，同時負責與底層傳輸驅動程式對話。 誰來負責管理緩衝區？ 正如上面所說的，應用程式通過Winsock來和傳輸協議驅動程式交談，而AFD.SYS負責為應用程式進行緩衝區管理。也就是說，當應用程式調用send()或WSASend()函數來發送資料時，AFD.SYS將把資料拷貝進它自己的內部緩衝區(取決於SO_SNDBUF設定值)，然後send()或WSASend()函數立即返回。也可以這麼說，AFD.SYS在後台負責把資料發送出去。不過，如果應用程式要求發出的資料超過了SO_SNDBUF設定的緩衝區大小，那麼WSASend()函數會阻塞，直至所有資料發送完畢。從遠程用戶端接收資料的情況也類似。只要不用從應用程式那裡接收大量的資料，而且沒有超出SO_RCVBUF設定的值，AFD.SYS將把資料先拷貝到其內部緩衝區中。當應用程式調用recv()或WSARecv()函數時，資料將從內部緩衝拷貝到應用程式提供的緩衝區。多數情況下，這樣的架構運行良好，特別在是應用程式採用傳統的通訊端下非重疊的send()和receive()模式編寫的時候。不過程式員要小心的是，儘管可以通過setsockopt()這個API來把SO_SNDBUF和SO_RCVBUF選項值設成0(關閉內部緩衝區)，但是程式員必須十分清楚把AFD.SYS的內部緩衝區關掉會造成什麼後果，避免收發資料時有關的緩衝區拷貝可能引起的系統崩潰。舉例來說，一個應用程式通過設定SO_SNDBUF為0把緩衝區關閉，然後發出一個阻塞send()調用。在這樣的情況下，系統核心會把應用程式的緩衝區鎖定，直到接收方確認收到了整個緩衝區後send()調用才返回。似乎這是一種判定你的資料是否已經為對方全部收到的簡潔的方法，實際上卻並非如此。想想看，即使遠端TCP通知數據已經收到，其實也根本不代表資料已經成功送給用戶端應用程式，比如對方可能發生資源不足的情況，導致AFD.SYS不能把資料拷貝給應用程式。另一個更要緊的問題是，在每個線程中每次只能進行一次發送調用，效率極其低下。把SO_RCVBUF設為0，關閉AFD.SYS的接收緩衝區也不能讓效能得到提升，這隻會迫使接收到的資料在比Winsock更低的層次進行緩衝，當你發出receive調用時，同樣要進行緩衝區拷貝，因此你本來想避免緩衝區拷貝的企圖不會得逞。    現在我們應該清楚了，關閉緩衝區對於多數應用程式而言並不是什麼好主意。只要要應用程式注意隨時在某個串連上保持幾個WSARecvs重疊調用，那麼通常沒有必要關閉接收緩衝區。如果AFD.SYS總是有由應用程式提供的緩衝區可用，那麼它將沒有必要使用內部緩衝區。高效能的伺服器應用程式可以關閉發送緩衝區，同時不會損失效能。不過，這樣的應用程式必須十分小心，保證它總是發出多個重疊發送調用，而不是等待某個重疊發送結束了才發出下一個。如果應用程式是按一個發完再發下一個的順序來操作，那浪費掉兩次發送中間的空檔時間，總之是要保證傳輸驅動程式在發送完一個緩衝區後，立刻可以轉向另一個緩衝區。 資源的限制條件 在設計任何伺服器應用程式時，其強健性是主要的目標。也就是說，你的應用程式要能夠應對任何突發的問題，例如並發客戶請求數達到峰值、可用記憶體臨時出現不足、以及其它短時間的現象。這就要求程式的設計者注意Windows NT和2000系統下的資源限制條件的問題，從容地處理突發性事件。你可以直接控制的、最基本的資源就是網路頻寬。通常，使用使用者資料包通訊協定(UDP)的應用程式都可能會比較注意頻寬方面的限制，以最大限度地減少包的丟失。然而，在使用TCP串連時，伺服器必須十分小心地控制好，防止網路頻寬過載超過一定的時間，否則將需要重發大量的包或造成大量串連中斷。關於頻寬管理的方法應根據不同的應用程式而定，這超出了本文討論的範圍。     虛擬記憶體的使用也必須很小心地管理。通過謹慎地申請和釋放記憶體，或者應用lookaside lists(一種快取)技術來重新使用已指派的記憶體，將有助於控制伺服器應用程式的記憶體開銷(原文為“讓伺服器應用程式留下的腳印小一點”)，避免作業系統頻繁地將應用程式申請的實體記憶體交換到虛擬記憶體中(原文為“讓作業系統能夠總是把更多的應用程式地址空間更多地保留在記憶體中”)。你也可以通過SetWorkingSetSize()這個Win32 API讓作業系統分配給你的應用程式更多的實體記憶體。在使用Winsock時還可能碰到另外兩個非直接的資源不足情況。一個是被鎖定的記憶體頁面的極限。如果你把AFD.SYS的緩衝關閉，當應用程式收發資料時，應用程式緩衝區的所有頁面將被鎖定到實體記憶體中。這是因為核心驅動程式需要訪問這些記憶體，在此期間這些頁面不能交換出去。如果作業系統需要給其它應用程式分配一些可分頁的實體記憶體，而又沒有足夠的記憶體時就會發生問題。我們的目標是要防止寫出一個病態的、鎖定所有實體記憶體、讓系統崩潰的程式。也就是說，你的程式鎖定記憶體時，不要超出系統規定的記憶體分頁極限。 在Windows NT和2000系統上，所有應用程式總共可以鎖定的記憶體大約是實體記憶體的1/8(不過這隻是一個大概的估計，不是你計算記憶體的依據)。如果你的應用程式不注意這一點，當你的發出太多的重疊收發調用，而且I/O沒來得及完成時，就可能偶爾發生ERROR_INSUFFICIENT_RESOURCES的錯誤。在這種情況下你要避免過度鎖定記憶體。同時要注意，系統會鎖定包含你的緩衝區所在的整個記憶體頁面，因此緩衝區靠近頁邊界時是有代價的(譯者理解，緩衝區如果正好超過頁面邊界，那怕是1個位元組，超出的這個位元組所在的頁面也會被鎖定)。另外一個限制是你的程式可能會遇到系統未分頁池資源不足的情況。所謂未分頁池是一塊永遠不被交換出去的記憶體地區，這塊記憶體用來儲存一些供各種核心組件訪問的資料，其中有的核心組件是不能訪問那些被交換出去的頁面空間的。Windows NT和2000的驅動程式能夠從這個特定的未分頁池分配記憶體。當應用程式建立一個通訊端(或者是類似的開啟某個檔案)時，核心會從未分頁池中分配一定數量的記憶體，而且在綁定、串連通訊端時，核心又會從未分頁池中再分配一些記憶體。當你注意觀察這種行為時你將發現，如果你發出某些I/O請求時(例如收發資料)，你會從未分頁池裡再分配多一些記憶體(比如要追蹤某個待決的I/O操作，你可能需要給這個操作添加一個自訂結構，如前文所提及的)。最後這就可能會造成一定的問題，作業系統會限制未分頁記憶體的用量。 在Windows NT和2000這兩種作業系統上，給每個串連分配的未分頁記憶體的具體數量是不同的，未來版本的Windows很可能也不同。為了使應用程式的生命期更長，你就不應該計算對未分頁池記憶體的具體需求量。你的程式必須防止消耗到未分頁池的極限。當系統中未分頁池剩餘空間太小時，某些與你的應用程式毫無關係的核心驅動就會發瘋，甚至造成系統崩潰，特別是當系統中有第三方裝置或驅動程式時，更容易發生這樣的慘劇(而且無法預測)。同時你還要記住，同一台電腦上還可能運行有其它同樣消耗未分頁池的其它應用程式，因此在設計你的應用程式時，對資源量的預估要特別保守和謹慎。處理資源不足的問題是十分複雜的，因為發生上述情況時你不會收到特別的錯誤碼，通常你只能收到一般性的WSAENOBUFS或者ERROR_INSUFFICIENT_RESOURCES 錯誤。要處理這些錯誤，首先，把你的應用程式工作配置調整到合理的最大值(譯者註：所謂工作配置，是指應用程式各部分運行中所需的記憶體用量，請參考 http://msdn.microsoft.com/msdnmag/issues/1000/Bugslayer/Bugslayer1000.asp ，關於記憶體最佳化，譯者另有譯文)，如果錯誤繼續出現，那麼注意檢查是否是網路頻寬不足的問題。之後，請確認你沒有同時發出太多的收發調用。最後，如果還是收到資源不足的錯誤，那就很可能是遇到了未分頁記憶體池不足的問題了。要釋放未分頁記憶體池空間，請關閉應用程式中相當部分的串連，等待系統自行渡過和修正這個瞬時的錯誤。 接受串連請求 伺服器要做的最普通的事情之一就是接受來自用戶端的串連請求。在通訊端上使用重疊I/O接受串連的惟一API就是AcceptEx()函數。有趣的是，通常的同步接受函數accept()的傳回值是一個新的通訊端，而AcceptEx()函數則需要另外一個通訊端作為它的參數之一。這是因為AcceptEx()是一個重疊操作，所以你需要事先建立一個通訊端(但不要綁定或串連它)，並把這個通訊端通過參數傳給AcceptEx()。以下是一小段典型的使用AcceptEx()的虛擬碼： do { 　　-等待上一個 AcceptEx 完成 　　-建立一個新通訊端並與完成連接埠進行關聯 　　-設定背景結構等等 　　-發出一個 AcceptEx 請求 }while(TRUE); 作為一個高響應能力的伺服器，它必鬚髮出足夠的AcceptEx調用，守候著，一旦出現用戶端串連請求就立刻響應。至於發出多少個AcceptEx才夠，就取決於你的伺服器程式所期待的通訊交通類型。比如，如果進入串連率高的情況(因為串連期間較短，或者出現交通高峰)，那麼所需要守候的AcceptEx當然要比那些偶爾進入的用戶端串連的情況要多。聰明的做法是，由應用程式來分析交通狀況，並調整AcceptEx守候的數量，而不是固定在某個數量上。對於Windows2000，Winsock提供了一些機制，協助你判定AcceptEx的數量是否足夠。這就是，在建立監聽通訊端時建立一個事件，通過WSAEventSelect()這個API並註冊FD_ACCEPT事件通知來把通訊端和這個事件關聯起來。一旦系統收到一個串連請求，如果系統中沒有AcceptEx()正在等待接受串連，那麼上面的事件將收到一個訊號。通過這個事件，你就可以判斷你有沒有發出足夠的AcceptEx()，或者檢測出一個非正常的客戶請求(下文述)。這種機制對Windows NT 4.0不適用。使用AcceptEx()的一大好處是，你可以通過一次調用就完成接受用戶端串連請求和接受資料(通過傳送lpOutputBuffer參數)兩件事情。也就是說，如果用戶端在發出串連的同時傳輸資料，你的AcceptEx()調用在串連建立並接收了用戶端資料後就可以立刻返回。這樣可能是很有用的，但是也可能會引發問題，因為AcceptEx()必須等全部用戶端資料都收到了才返回。具體來說，如果你在發出AcceptEx()調用的同時傳遞了lpOutputBuffer參數，那麼AcceptEx()不再是一項原子型的操作，而是分成了兩步：接受客戶串連，等待接收資料。當缺少一種機制來通知你的應用程式所發生的這種情況：“串連已經建立了，正在等待用戶端資料”，這將意味著有可能出現用戶端只發出串連請求，但是不發送資料。如果你的伺服器收到太多這種類型的串連時，它將拒絕串連更多的合法用戶端請求。這就是駭客進行“拒絕服務”攻擊的常見手法。要預防此類攻擊，接受串連的線程應該不時地通過調用getsockopt()函數(選項參數為SO_CONNECT_TIME)來檢查AcceptEx()裡守候的通訊端。getsockopt()函數的選項值將被設定為通訊端被串連的時間，或者設定為-1(代表通訊端尚未建立串連)。這時，WSAEventSelect()的特性就可以很好地利用來做這種檢查。如果發現串連已經建立，但是很久都沒有收到資料的情況，那麼就應該終止串連，方法就是關閉作為參數提供給AcceptEx()的那個通訊端。注意，在多數非緊急情況下，如果通訊端已經傳遞給AcceptEx()並開始守候，但還未建立串連，那麼你的應用程式不應該關閉它們。這是因為即使關閉了這些通訊端，出於提高系統效能的考慮，在串連進入之前，或者監聽通訊端自身被關閉之前，相應的核心模式的資料結構也不會被乾淨地清除。發出AcceptEx()調用的線程，似乎與那個進行完成連接埠關聯操作、處理其它I/O完成通知的線程是同一個，但是，別忘記線程裡應該儘力避免執行阻塞型的操作。Winsock2分層結構的一個副作用是調用socket()或WSASocket() API的上層架構可能很重要(譯者不太明白原文意思，抱歉)。每個AcceptEx()調用都需要建立一個新通訊端，所以最好有一個獨立的線程專門調用AcceptEx()，而不參與其它I/O處理。你也可以利用這個線程來執行其它任務，比如事件記錄。有關AcceptEx()的最後一個注意事項：要實現這些API，並不需要其它供應商提供的Winsock2實現。這一點對微軟特有的其它API也同樣適用，比如TransmitFile()和GetAcceptExSockAddrs()，以及其它可能會被加入到新版Windows的API. 在Windows NT和2000上，這些API是在微軟的底層提供者DLL(mswsock.dll)中實現的，可通過與mswsock.lib編譯串連進行調用，或者通過WSAIoctl() (選項參數為SIO_GET_EXTENSION_FUNCTION_POINTER)動態獲得函數的指標。如果在沒有事先獲得函數指標的情況下直接調用函數(也就是說，編譯時間靜態串連mswsock.lib，在程式中直接調用函數)，那麼效能將很受影響。因為AcceptEx()被置於Winsock2架構之外，每次調用時它都被迫通過WSAIoctl()取得函數指標。要避免這種效能損失，需要使用這些API的應用程式應該通過調用WSAIoctl()直接從底層的提供者那裡取得函數的指標。 參見Figure 3 通訊端架構： application 　|| /||/ 　// winsock 2.0 dll (ws2_32.dll) 　|| /||/ 　// layered/Base Providers RSVP | Proxy | Default Microsoft Providers (mswsock.dll/msafd.dll) 　|| /||/ 　// Windows Sockets kernel-mode driver (afd.sys) 　|| /||/ 　// Tramsport Protocols TCP/IP | ATM | Other TransmitFile 和 TransmitPackets Winsock 提供兩個專門為檔案和記憶體資料轉送進行了最佳化的函數。其中TransmitFile()這個API函數在Windows NT 4.0 和 Windows 2000上都可以使用，而TransmitPackets()則將在未來版本的Windows中實現。TransmitFile()用來把檔案內容通過Winsock進行傳輸。通常傳送檔案的做法是，先調用CreateFile()開啟一個檔案，然後不斷迴圈調用ReadFile() 和WSASend ()直至資料發送完畢。但是這種方法很沒有效率，因為每次調用ReadFile() 和 WSASend ()都會涉及一次從使用者模式到核心模式的轉換。如果換成TransmitFile()，那麼只需要給它一個已開啟檔案的控制代碼和要發送的位元組數，而所涉及的模式轉換操作將只在調用CreateFile()開啟檔案時發生一次，然後TransmitFile()時再發生一次。這樣效率就高多了。TransmitPackets()比TransmitFile()更進一步，它允許使用者只調用一次就可以發送指定的多個檔案和記憶體緩衝區。函數原型如下： BOOL TransmitPackets( 　SOCKET hSocket,　　　　　　　　　　　　　　 　LPTRANSMIT_PACKET_ELEMENT lpPacketArray, 　DWORD nElementCount,　　　　　　　　 　DWORD nSendSize,　　　　　　　　 　LPOVERLAPPED lpOverlapped,　　　　　　　　　 　DWORD dwFlags　　　　　　　　　　　　　　　 ); 其中，lpPacketArray是一個結構的數組，其中的每個元素既可以是一個檔案控制代碼或者記憶體緩衝區，該結構 定義如下： typedef struct _TRANSMIT_PACKETS_ELEMENT { 　　DWORD dwElFlags; 　　DWORD cLength; 　　union { 　　　　struct { 　　　　　　LARGE_INTEGER　　 nFileOffset; 　　　　　　HANDLE　　　　　　hFile; 　　　　　　}; 　　　　　　PVOID　　　　　　 pBuffer; 　　}; } TRANSMIT_FILE_BUFFERS; 其中各欄位是自描述型的(self explanatory)。 dwElFlags欄位：指定當前元素是一個檔案控制代碼還是記憶體緩衝區(分別通過常量TF_ELEMENT_FILE 和TF_ELEMENT_MEMORY指定)；cLength欄位：指定將從資料來源發送的位元組數(如果是檔案，這個欄位值為0表示發送整個檔案)；結構中的無名聯合體：包含檔案控制代碼的記憶體緩衝區(以及可能的位移量)。使用這兩個API的另一個好處，是可以通過指定TF_REUSE_SOCKET和TF_DISCONNECT標誌來重用通訊端控制代碼。每當API完成資料的傳輸工作後，就會在傳輸層層級中斷連線，這樣這個通訊端就又可以重新提供給AcceptEx()使用。採用這種最佳化的方法編程，將減輕那個專門做接受操作的線程建立通訊端的壓力(前文述及)。 這兩個API也都有一個共同的弱點：Windows NT Workstation 或 Windows 2000 專業版中，函數每次只能處理兩個調用請求，只有在Windows NT、Windows 2000伺服器版、Windows 2000進階伺服器版或 Windows 2000 Data Center中才獲得完全支援。    放在一起看看以上各節中，我們討論了開發高效能的、大響應規模的應用程式所需的函數、方法和可能遇到的資源瓶頸問題。這些對你意味著什麼呢？其實，這取決於你如何構造你的伺服器和用戶端。當你能夠在伺服器和用戶端設計上進行更好地控制時，那麼你越能夠避開瓶頸問題。來看一個示範的環境。我們要設計一個伺服器來響應用戶端的串連、發送請求、接收資料以及中斷連線。那麼，伺服器將需要建立一個監聽通訊端，把它與某個完成連接埠進行關聯，為每顆CPU建立一個背景工作執行緒。再建立一個線程專門用來發出AcceptEx()。我們知道用戶端會在發出串連請求後立刻傳送資料，所以如果我們準備好接收緩衝區會使事情變得更為容易。當然，不要忘記不時地輪詢AcceptEx()調用中使用的通訊端(使用SO_CONNECT_TIME選項參數)來確保沒有惡意逾時的串連。該設計中有一個重要的問題要考慮，我們應該允許多少個AcceptEx()進行守候。這是因為，每發出一個AcceptEx()時我們都同時需要為它提供一個接收緩衝區，那麼記憶體中將會出現很多被鎖定的頁面(前文說過了，每個重疊操作都會消耗一小部分未分頁記憶體池，同時還會鎖定所有涉及的緩衝區)。這個問題很難回答，沒有一個確切的答案。最好的方法是把這個值做成可以調整的，通過反覆做效能測試，你就可以得出在 典型應用環境中最佳的值。 好了，當你測算清楚後，下面就是發送資料的問題了，考慮的重點是你希望伺服器同時處理多少個並發的串連。通常情況下，伺服器應該限制並發串連的數量以及等候處理的發送調用。因為並發串連數量越多，所消耗的未分頁記憶體池也越多；等候處理的發送調用越多，被鎖定的記憶體頁面也越多(小心別超過了極限)。這同樣也需要反覆測試才知道答案。對於上述環境，通常不需要關閉單個通訊端的緩衝區，因為只在AcceptEx()中有一次接收資料的操作，而要保證給每個到來的串連提供接收緩衝區並不是太難的事情。但是，如果客戶機與伺服器互動的方式變一變，客戶機在發送了一次資料之後，還需要發送更多的資料，在這種情況下關閉接收緩衝就不太妙了，除非你想辦法保證在每個串連上都發出了重疊接收調用來接收更多的資料。 結論    開發大響應規模的Winsock伺服器並不是很可怕，其實也就是設定一個監聽通訊端、接受串連請求和進行重疊收發調用。通過設定合理的進行守候的重疊調用的數量，防止出現未分頁記憶體池被耗盡，這才是最主要的挑戰。按照我們前面討論的一些原則，你就可以開發出大響應規模的伺服器應用程式。