深入 CSocket 程式設計之阻塞和非阻塞模式

有時，花上幾個小時閱讀、調試、跟蹤優秀的源碼程式，能夠更快地掌握某些技術關鍵點和精髓。當然，前提是對這些技術大緻上有一個了解。

　　我通過幾個采用 CSocket 類編寫并基于 Client/Server （用戶端 / 服務端）的網絡聊天和傳輸檔案的程式 ( 詳見： 源代碼參考 ) ，在調試這些程式的過程中，追蹤深入至 CSocket 類核心源碼 Sockcore.cpp ， 對于CSocket 類的運作機制可謂是一覽無遺，并且對于阻塞和非阻塞方式下的 socket 程式的編寫也是稍有體會。

閱讀本文請先注意：

　　這裡的阻塞和非阻塞的概念僅适用于 Server 端 socket 程式。socket 意為套接字，它與 Socket 不同，請注意首字母的大小寫。

　　用戶端與服務端的通信簡單來講：服務端 socket 負責監聽，應答，接收和發送消息，而用戶端 socket 隻是連接配接，應答，接收，發送消息。此外，如果你對于采用 CSocket 類編寫 Client/Server 網絡程式的原理不是很了解，請先查詢一下（ 詳見：參考書籍和線上幫助 ）。 

在此之前，有必要先講述一下： 網絡傳輸服務提供者， ws2_32.dll ， socket 事件 和 socket window 。

1、網絡傳輸服務提供者（網絡傳輸服務程序）， Socket 事件， Socket Window

　　網絡傳輸服務提供者 （ transport service provider ）是以 DLL 的形式存在的，在 windows 作業系統啟動時由服務程序 svchost.exe 加載。當 socket 被建立時，調用 API 函數 Socket （在 ws2_32.dll 中）， Socket 函數會傳遞三個參數 : 位址族，套接字類型 ( 注 2 ) 和協定，這三個參數決定了是由哪一個類型的 網絡傳輸服務提供者 來啟動網絡傳輸服務功能。所有的網絡通信正是由網絡傳輸服務提供者完成 , 這裡将 網絡傳輸服務提供者 稱為 網絡傳輸服務程序 更有助于了解，因為前文已提到 網絡傳輸服務提供者 是由 svchost.exe 服務程序所加載的。 

　　下圖描述了網絡應用程式、 CSocket （ WSock32.dll ）、 Socket API(ws2_32.dll) 和 網絡傳輸服務程序 之間的接口層次關系：

　　當 Client 端 socket 與 Server 端 socket 互相通信時，兩端均會觸發 socket 事件。這裡僅簡要說明兩個 socket 事件：

　　FD_CONNECT: 連接配接事件 , 通常 Client 端 socket 調用 socket API 函數 Connect 時所觸發，這個事件發生在 Client 端。 

　　FD_ACCEPT ：正在引入的連接配接事件，通常 Server 端 socket 正在接收來自 Client 端 socket 連接配接時觸發，這個事件發生在 Server 端。 

　　網絡傳輸服務程序 将 socket 事件 儲存至 socket 的事件隊列中。此外， 網絡傳輸服務程序 還會向 socket window 發送消息 WM_SOCKET_NOTIFY , 通知有 socket 事件 産生，見下文對 socket window 的詳細說明。

　　調用 CSocket::Create 函數後，socket 被建立。 socket 建立過程中調用 CAsyncSocket::AttachHandle(SOCKET hSocket, CAsyncSocket* pSocket, BOOL bDead) 。該函數的作用是： 将 socket 執行個體句柄和 socket 指針添加至 目前子產品狀态 （ 注 1 ）的一個映射表變量 m_pmapSocketHandle 中。 

　　在 AttachHandle 過程中，會 new 一個 CSocketWnd 執行個體 ( 基于 CWnd 派生 ) ，這裡将這個執行個體稱之為 socket window ，進一步了解為它是存放所有 sockets 的消息池 （ window 消息），請仔細檢視，這裡 socket 後多加了一個 s ，表示建立的多個 socket 将共享一個 消息池 。 

　　當 Client 端 socket 與 Server 端互相通信時 , 此時 網絡傳輸服務程序 向 socket window 發送消息 WM_SOCKET_NOTIFY ，需要說明的是 CSocketWnd 視窗句柄儲存在 目前子產品狀态 的 m_hSocketWindow 變量中。 

2、阻塞模式

　　阻塞模式下 Server 端與 Client 端之間的通信處于同步狀态下。在 Server 端直接執行個體化 CSocket 類，調用 Create 方法建立 socket ，然後調用方法 Listen 開始偵聽，最後用一個 while 循環阻塞調用 Accept 函數用于等待來自 Client 端的連接配接，如果這個 socket 在主線程（主程式）中運作，這将導緻主線程的阻塞。是以，需要建立一個新的線程以運作 socket 服務。 

調試跟蹤至 CSocket::Accept 函數源碼：

while(!Accept(...))

{ 

　　　　　// The socket is marked as nonblocking and no connections are present to be accepted. 

if (GetLastError() == WSAEWOULDBLOCK) 　PumpMessage(FD_ACCEPT); 

else 

return FALSE; 

}

　　它不斷調用 CAsyncSocket::Accept （ CSocket 派生自 CAsyncSocket 類）判斷 Server 端 socket 的事件隊列中是否存在正在引入的連接配接事件 - FD_ACCEPT （見 1 ），換句話說，就是判斷是否有來自 Client 端 socket 的連接配接請求。 

　　如果目前 Server 端 socket 的事件隊列中存在正在引入的連接配接事件， Accept 傳回一個非 0 值。否則， Accept 傳回 0，此時調用 GetLastError 将傳回錯誤代碼 WSAEWOULDBLOCK ，表示隊列中無任何連接配接請求。注意到在循環體内有一句代碼： PumpMessage(FD_ACCEPT); 

　　PumpMessage 作為一個消息泵使得 socket window 中的消息能夠維持在活動狀态。實際跟蹤進入 PumpMessage 中，發現這個消息泵與 Accept 函數的調用并不相關，它隻是使很少的 socket window 消息（典型的是 WM_PAINT 視窗重繪消息）處于活動狀态，而絕大部分的 socket window 消息被阻塞，被阻塞的消息中含有 WM_SOCKET_NOTIFY。

　　很顯然，如果沒有來自 Client 端 socket 的連接配接請求， CSocket 就會不斷調用 Accept 産生循環阻塞，直到有來自 Client 端 socket 的連接配接請求而解除阻塞。 

　　阻塞解除後，表示 Server 端 socket 和 Client 端 socket 已成功連接配接， Server 端與 Client 端彼此互相調用 Send 和 Receive 方法開始通信。

3、非阻塞模式

　　在非阻塞模式下 利用 socket 事件 的消息機制， Server 端與 Client 端之間的通信處于異步狀态下。

　　通常需要從 CSocket 類派生一個新類，派生新類的目的是重載 socket 事件 的消息函數，然後在 socket 事件 的消息函數中添入合适的代碼以完成 Client 端與 Server 端之間的通信，與阻塞模式相比，非阻塞模式無需建立一個新線程。 

　　這裡将讨論當 Server 端 socket 事件 － FD_ACCEPT 被觸發後，該事件的處理函數 OnAccept 是如何進一步被觸發的。其它事件的處理函數如 OnConnect, OnReceive 等的觸發方式與此類似。 

　　在 1 中已提到 Client/Server 端通信時， Server 端 socket 正在接收來自 Client 端 socket 連接配接請求，這将會觸發 FD_ACCEPT 事件，同時 Server 端的 網絡傳輸服務程序 向 Server 端的 socket window (CSocketWnd ）發送事件通知消息 WM_SOCKET_NOTIFY , 通知有 FD_ACCEPT 事件産生 , CsocketWnd 在收到事件通知消息後，調用消息處理函數 OnSocketNotify:

LRESULT CSocketWnd::OnSocketNotify(WPARAM wParam, LPARAM lParam) 

CSocket::AuxQueueAdd(WM_SOCKET_NOTIFY, wParam, lParam); 

CSocket::ProcessAuxQueue(); 

return 0L ; 

　　消息參數 wParam 是 socket 的句柄， lParam 是 socket 事件 。這裡稍作解釋一下，CSocketWnd 類是作為 CSocket 類的 友元類 ，這意味着它可以通路 CSocket 類中的保護和私有成員函數和變量， AuxQueueAdd 和 ProcessAuxQueue 是 CSocket 類的靜态成員函數，如果你對友元不熟悉，請迅速找本有關 C++ 書看一下友元的使用方法吧！ 

　　ProcessAuxQueue 是實質處理 socket 事件的函數，在該函數中有這樣一句代碼： CAsyncSocket* pSocket = CAsyncSocket::LookupHandle((SOCKET)wParam, TRUE); 

　　其實也就是由 socket 句柄得到發送事件通知消息的 socket 指針 pSocket：從 m_pmapSocketHandle 中查找！ 

　　最後， WSAGETSELECTEVENT(lParam) 會取出事件類型，在一個簡單的 switch 語句中判斷事件類型并調用事件處理函數。在這裡，事件類型是 FD_ACCEPT ，當然就調用 pSocket->OnAccept ！

結束語 

　　Server 端 socket 處于阻塞調用模式下，它必須在一個新建立的線程中工作，防止主線程被阻塞。 

　　當有多個 Client 端 socket 與 Server 端 socket 連接配接及通信時， Server 端采用阻塞模式就顯得不适合了，應該采用非阻塞模式 , 利用 socket 事件 的消息機制來接受多個 Client 端 socket 的連接配接請求并進行通信。 

　　在非阻塞模式下，利用 CSocketWnd 作為所有 sockets 的消息池，是實作 socket 事件 的消息機制的關鍵技術。文中存在用詞不妥和可能存在的技術問題，請大家原諒，也請批評指正，謝謝！

注：

　　目前子產品狀态——用于儲存目前線程和子產品狀态的一個結構，可以通過 AfxGetThreadModule() 獲得。AFX_MODULE_THREAD_STATE 在 CSocket 重新定義為 _AFX_SOCK_THREAD_STATE 。 

　　socket 類型——在 TCP/IP 協定中， Client/Server 網絡程式采用 TCP 協定：即 socket 類型為 SOCK_STREAM ，它是可靠的連接配接方式。在這裡不采用 UDP 協定：即 socket 類型為 SOCK_DGRAM ，它是不可靠的連接配接方式。