Windows Sockets：操作順序
本文以對照方式闡釋了伺服器套接字和客戶端套接字的操作順序。因為這些套接字使用 CArchive 物件，所以它們必然是流式套接字。流式套接字通訊的操作順序
在構造 CSocketFile 物件之前，下面的順序對 CAsyncSocket 和 CSocket 都是準確的（只有少數幾個引數不同）。從構造 CSocketFile 物件開始，順序只適用於 CSocket 。下表闡釋了在客戶端和伺服器之間設定通訊的操作順序。
設定伺服器和客戶端之間的通訊 -
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 。
有關更多資訊，請參見： Windows Sockets：使用帶存檔的套接字 Windows Sockets：使用 CAsyncSocket 類 Windows Sockets：埠和套接字地址 Windows Sockets：流式套接字 Windows Sockets：資料文報套接字