Windows Socket && Socket In MFC

  最近工作中要調查一段程式從Windows 2000遷移到Windows Vista環境中，該程式是一個典型的用戶端/伺服器程式. 用戶端為Windows. 伺服器為Linux. Linux伺服器提供了FTP/Telent服務.
   用戶端需要經常到Linux伺服器上通過FTP上傳和下載檔案資料.當用戶端運行在win2000/XP環境中時，一切運行良好，但在Vista環境中，則兩者之間的通訊受阻，而具體原因通過抓包分析，則是Windows Socket API在發送FTP包時，在Vista機器中，資料包發送交是原生hostname，而非IP地址.
   於是，需要對程式中涉及到Windows Socket 及MFC中的CAsyncSocket的繼承類進行分析，並排查.究竟是哪地方出現問題。
   這篇文章，把最近關於在Windows中進行網路編程所涉及的基礎知識記錄下來. 希望能夠近期解決以上問題.
   另，Windows Vista實在實在實在是太BT了........................不斷的彈對話方塊提示框要把人逼瘋！ 通訊端的定義

通訊端是一個通訊終結點，它是 Windows Sockets 應用程式用來在網路上發送或接收資料包的對象。通訊端具有類型，與正在啟動並執行進程相關聯，並且可以有名稱。目前，通訊端一般只與使用網際協議組的同一“通訊域”中的其他通訊端交換資料。

可用的通訊端類型有以下兩種：

• 流式通訊端

  流式通訊端提供沒有記錄邊界的資料流，即位元組流。位元組流能確保以正確的順序無重複地被送達。

• 資料文報通訊端

  資料文報通訊端支援面向記錄的資料流，但不能確保能被送達，也無法確保按照發送順序或不重複。

SOCKET 資料類型

每一個 MFC 通訊端對象封裝一個 Windows Sockets 對象的控制代碼。該控制代碼的資料類型為 SOCKET。SOCKET 控制代碼類似於視窗的 HWND。MFC 通訊端類提供對封裝控制代碼的操作。

通訊端編程模型

• CAsyncSocket

  該類封裝 Windows Sockets API。CAsyncSocket 是為那些瞭解網路編程並希望能夠靈活地對通訊端 API 直接編程，同時還希望方便地使用回呼函數以進行網路事件通知的程式員提供的。除了將通訊端打包為物件導向的形式以用於 C++ 外，此類提供的唯一附加抽象化是將某些與通訊端相關的 Windows 訊息轉換為回調。有關更多資訊，請參見 Windows Sockets：通訊端通知。

• CSocket

  此類由 CAsyncSocket 所派生，它通過 MFC CArchive 對象提供與通訊端一起使用的更進階的抽象化。使用帶存檔的通訊端與使用 MFC 的檔案序列化協議非常相似。這使它比 CAsyncSocket 模型更便於使用。CSocket 從 CAsyncSocket（它封裝 Windows Sockets API）繼承了許多成員函數；您將必須使用其中一些函數並一般性地瞭解通訊端編程。而 CSocket 則管理著必須由您自己使用原始 API 或 CAsyncSocket 類來管理的通訊的許多方面。最重要的是，CSocket 使用 Windows 訊息的幕後處理來提供阻塞，這對 CArchive 的同步操作非常關鍵。

 

Windows Sockets：流式通訊端

 流式通訊端一般用於TCP協議蔟中，如建立FTP，TELNET應用程式都使用流式通訊端，建立流式通訊端為SOCK_STREAM.
流通訊端適合檔案傳輸通訊協定 (FTP) 這類實現，此協議有利於傳輸任意大小的 ASCII 或二進位檔案。

如果必須保證資料送達而且資料大小很大時，流式通訊端優於資料文報通訊端。

此例可詳見：MFC 樣本 CHATTER 和 CHATSRVR

流式通訊端通訊的操作順序

在構造 CSocketFile 對象之前，下面的順序對 CAsyncSocket 和 CSocket 都是準確的（只有少數幾個參數不同）。從構造 CSocketFile 對象開始，順序只適用於 CSocket。下表闡釋了在用戶端和伺服器之間設定通訊的操作順序。

設定伺服器和用戶端之間的通訊

伺服器	用戶端
// construct a socket CSocket sockSrvr;	// construct a socket CSocket sockClient;
// create the SOCKET sockSrvr.Create(nPort);1,2	// create the SOCKET sockClient.Create( );2
// start listening sockSrvr.Listen( );
	// seek a connection sockClient.Connect(strAddr, nPort);3,4
// construct a new, empty socket CSocket sockRecv; // accept connection sockSrvr.Accept( sockRecv ); 5
// construct file object CSocketFile file(&sockRecv);	// construct file object CSocketFile file(&sockClient);
// construct an archive CArchive arIn(&file,          CArchive::load); - 或 - CArchive arOut(&file,          CArchive::store); - 或兩者 -	// construct an archive CArchive arIn(&file,          CArchive::load); - 或 - CArchive arOut(&file,          CArchive::store); - 或兩者 -
// use the archive to pass data: arIn >> dwValue; - 或 - arOut << dwValue;6	// use the archive to pass data: arIn >> dwValue; - 或 - arOut << dwValue;6

1. 這裡的 nPort 是連接埠號碼。有關連接埠的詳細資料，請參見 Windows Sockets：連接埠和通訊端地址。

2. 伺服器必須始終指定一個連接埠，以便用戶端可以串連。Create 調用有時也指定地址。在用戶端使用預設參數，這些參數要求 MFC 使用任何可用連接埠。

3. 這裡的 nPort 是連接埠號碼，strAddr 是電腦地址或網際協議 (IP) 地址。

4. 電腦地址可以採用幾種形式：“ftp.microsoft.com”、“microsoft.com”。IP 位址採用“以點分隔的數字”形式，如“127.54.67.32”。Connect 函數查看地址是否為以點分隔的數字（但它不確保該數字是網路上的有效電腦）。如果不是，則 Connect 使用其他某種形式的電腦名稱。

5. 當在伺服器端調用 Accept 時，傳遞對新通訊端對象的引用。必須首先構造該對象，但不對它調用 Create。注意，如果此通訊端對象超出範圍，則串連關閉。MFC 將新對象串連到 SOCKET 控制代碼。可以在堆棧上構造此通訊端（如表中所示）或在堆上構造。

6. 存檔和通訊端檔案在超出範圍時將被關閉。通訊端對象超出範圍或被刪除時，對象的解構函式也對此通訊端對象調用 Close 成員函數。

有關順序的其他說明

上表中顯示的調用順序適用於流式通訊端。資料文報通訊端是不需連線的，不需要 CAsyncSocket::Connect、Listen 和 Accept 調用（但可有選擇地使用 Connect）。相反，如果正在使用 CAsyncSocket 類，則資料文報通訊端使用 CAsyncSocket::SendTo 和 ReceiveFrom 成員函數。（如果對資料文報通訊端使用 Connect，則使用 Send 和 Receive。）因為 CArchive 不適用於資料文報，如果通訊端是資料文報，則不要使用帶存檔的 CSocket。

CSocketFile 並不支援 CFile 的所有功能，CFile 成員（如 Seek）對通訊端通訊沒有意義，是停用。因此，某些預設 MFC Serialize 函數與 CSocketFile 不相容。這對於 CEditView 類更是如此。不要試圖使用 CEditView::SerializeRaw 通過附加到 CSocketFile 對象的 CArchive 對象來序列化 CEditView 資料，而應使用 CEditView::Serialize（無出處）。SerializeRaw 函數預期檔案對象具有 CSocketFile 不支援的函數，如 Seek。