用完成端口開發大響應規模的Winsock應用程序

時間 2019-11-11

標籤完成端口開發響應規模 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結構，在其中加入所需的跟蹤信息。app

不管什麼時候調用重疊操做函數時，老是會經過其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;
    // 其它有用的信息
} OVERLAPPEDPLUS;

#define OP_READ     0
#define OP_WRITE    1
#define OP_ACCEPT   2

下面讓咱們來看看工做者線程的狀況。工做線程WorkerThread代碼：

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 2000中的Winsock架構：

與其它類型操做系統不一樣，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()直接從底層的提供者那裏取得函數的指針。

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()中有一次接收數據的操做，而要保證給每一個到來的鏈接提供接收緩衝區並非太難的事情。但是，若是客戶機與服務器交互的方式變一變，客戶機在發送了一次數據以後，還須要發送更多的數據，在這種狀況下關閉接收緩衝就不太妙了，除非你想辦法保證在每一個鏈接上都發出了重疊接收調用來接收更多的數據。