使用MFC的Windows 套接字應注意的幾個問題 (轉)

使用MFC的Windows 套接字應注意的幾個問題 (轉)[@more@]本文主要針對MFC庫中的CAsyncSocket類和CSocket類，才疏學淺，權當做拋磚引玉。

這裡所列出的問題主要是在最近編寫基於IP網的語音的過程中碰到的，不一定很
具代表性，僅供參考和討論。對於從事平臺的開發工作的朋友們，或許會有點利
用價值。

1． CSocket類和CAsyncSocket類對多執行緒的支援問題
Winsocks本身是支援多執行緒的，具有一定的執行緒獨立性和性，但CSocket類以及CAsyn
cSocket類都有一些執行緒安全性問題。比如線上程之間傳遞CSocket就會發生異常，MS
DN中的建議是，傳遞前Detach，傳遞socket控制程式碼，在目標執行緒中再Attach到一個CSocket對
象上。這似乎說明CSocket（或CAsyncSocket）具有執行緒依賴性。
然而情況並不是絕對的，我的程式中出現的兩種傳遞CAsyncSocket或CSocket物件的情況沒
有發生異常，也沒有執行的問題：
(1) 在主執行緒中建立和關閉一個CSocket阻塞型資料包套接字，在另一執行緒中用它傳送資料
（SendTo）。若用它接收資料（ReceiveFrom）則出現異常。
(2) 在主執行緒中建立和關閉一個CAsyncSocket非阻塞型資料包套接字，在另一執行緒中用它
接收資料（ReceiveFrom）也沒有問題了。
上述兩種情況，我的感覺是毫無道理可言，但在我的機器上執行卻是非常穩定。我的建議
是，如果使用CAsyncSocket類和CSocket類，儘量不要跨執行緒使用（我以後也不會鋌而走險
了）。

2． 阻塞和非阻塞的選擇問題
阻塞套接字使用方便，但會影響到執行緒的訊息響應，比較適合於用流式套接字傳送大量數
據的情況。
對於實時語音資料的傳送來說，資料的傳送受制於採集裝置，一旦有資料可傳送，才
套接字來傳送，因而套接字的阻塞與否對執行緒的執行時間佔用不會太大（我的程式中
一個資料包的大小隻有20KB，傳送的過程很快）。而在接收方，音訊回放裝置受制於接收
套接字。在沒有接受到任何資料時，整個執行緒卻卡在ReceiveForm()上，無法實現正常的消
息迴圈，如此時向該執行緒發出WM_QUIT訊息，它將無法得到。同樣，在傳送方，為了不
阻塞傳送執行緒的訊息迴圈，音訊採集裝置也應該是非阻塞（非同步）的。
當然，如果不將音訊回放和資料接收放在同一執行緒中，則也可以用阻塞型套接字，但是這
又帶來另一個問題：兩個執行緒間要共享資料，於是又要涉及到執行緒間同步或互斥的問題，
同時增加了開銷。

3、將套接字事件對映到視窗訊息上時應注意：
當用WSAAsync將套接字事件對映到視窗訊息上時，應注意視窗的訊息阻塞可能會造
成套接字錯誤，如公用對話方塊。特別是在用PreTranslateMessage時極可能出問題。

4、再說兩句廢話。MFC支援 Sockets1但不支援Windows Sockets2。因而一些優良
的將不能使用，如服務質量（QoS）、有根多播。而在某些功能，如IP網多播的使用上
，Windows Sockets1和Windows Sockets2是有一些區別的。