用完成埠開發大響應規模的Winsock應用程式(5/完) (轉)

用完成埠開發大響應規模的Winsock應用程式(5/完) (轉)[@more@]

TransmitFile 和 TransmitPackets

Winsock 提供兩個專門為和資料傳輸進行了的。其中TransmitFile()這個函式在 NT 4.0 和 上都可以使用，而TransmitPackets()則將在未來版本的Windows中實現。

TransmitFile()用來把檔案內容透過Winsock進行傳輸。通常傳送檔案的做法是，先CreateFile()開啟一個檔案，然後不斷迴圈呼叫ReadFile() 和Wend ()直至資料傳送完畢。但是這種方法很沒有，因為每次呼叫ReadFile() 和 WSASend ()都會涉及一次從到核心模式的轉換。如果換成TransmitFile()，那麼只需要給它一個已開啟檔案的控制程式碼和要傳送的位元組數，而所涉及的模式轉換操作將只在呼叫CreateFile()開啟檔案時發生一次，然後TransmitFile()時再發生一次。這樣效率就高多了。

TransmitPackets()比TransmitFile()更進一步，它允許使用者只呼叫一次就可以傳送指定的多個檔案和記憶體緩衝區。函式原型如下：
BOOL TransmitPackets(
  SOCKET hSocket, 
  LPTRANSMIT_PACKET_ELEMENT lpPacketArray,
  D 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_DINNECT標誌來重用套接字控制程式碼。每當API完成資料的傳輸工作後，就會在傳輸層級別斷開連線，這樣這個套接字就又可以重新提供給AcceptEx()使用。採用這種最佳化的方法，將減輕那個專門做接受操作的執行緒建立套接字的壓力(前文述及)。

這兩個API也都有一個共同的弱點： Workstation 或 Windows 2000 專業版中，函式每次只能處理兩個呼叫請求，只有在Windows NT、Windows 2000版、Windows 2000高階伺服器版或 Windows 2000 Data Center中才獲得完全支援。

放在一起看看

以上各節中，我們討論了開發高的、大響應規模的應用所需的函式、方法和可能遇到的資源瓶頸問題。這些對你意味著什麼呢？其實，這取決於你如何構造你的伺服器和客戶端。當你能夠在伺服器和客戶端設計上進行更好地控制時，那麼你越能夠避開瓶頸問題。

來看一個示範的環境。我們要設計一個伺服器來響應客戶端的連線、傳送請求、接收資料以及斷開連線。那麼，伺服器將需要建立一個套接字，把它與某個完成埠進行關聯，為每顆建立一個工作執行緒。再建立一個執行緒專門用來發出AcceptEx()。我們知道客戶端會在發出連線請求後立刻傳送資料，所以如果我們準備好接收緩衝區會使事情變得更為容易。當然，不要忘記不時地輪詢AcceptEx()呼叫中使用的套接字(使用SO_CONNECT_TIME選項引數)來確保沒有惡意超時的連線。

該設計中有一個重要的問題要考慮，我們應該允許多少個AcceptEx()進行守候。這是因為，每發出一個AcceptEx()時我們都同時需要為它提供一個接收緩衝區，那麼記憶體中將會出現很多被鎖定的頁面(前文說過了，每個重疊操作都會消耗一小部分未分頁記憶體池，同時還會鎖定所有涉及的緩衝區)。這個問題很難回答，沒有一個確切的答案。最好的方法是把這個值做成可以調整的，透過反覆做效能測試，你就可以得出在典型應用環境中最佳的值。

好了，當你測算清楚後，下面就是傳送資料的問題了，考慮的重點是你希望伺服器同時處理多少個併發的連線。通常情況下，伺服器應該限制併發連線的數量以及等候處理的傳送呼叫。因為併發連線數量越多，所消耗的未分頁記憶體池也越多；等候處理的傳送呼叫越多，被鎖定的記憶體頁面也越多(小心別超過了極限)。這同樣也需要反覆測試才知道答案。

對於上述環境，通常不需要關閉單個套接字的緩衝區，因為只在AcceptEx()中有一次接收資料的操作，而要保證給每個到來的連線提供接收緩衝區並不是太難的事情。但是，如果客戶機與伺服器互動的方式變一變，客戶機在傳送了一次資料之後，還需要傳送更多的資料，在這種情況下關閉接收緩衝就不太妙了，除非你想辦法保證在每個連線上都發出了重疊接收呼叫來接收更多的資料。

結論

開發大響應規模的Winsock伺服器並不是很可怕，其實也就是設定一個監聽套接字、接受連線請求和進行重疊收發呼叫。透過設定合理的進行守候的重疊呼叫的數量，防止出現未分頁記憶體池被耗盡，這才是最主要的挑戰。按照我們前面討論的一些原則，你就可以開發出大響應規模的伺服器應用程式。

(譯者) 劉西齊 to:sickid10001@21cn.com">sickid10001@21cn.com