本文主要针对MFC库中的CAsyncSocket类和CSocket类，才疏学浅，权当做抛砖引玉。
这里所列出的问题主要是在最近编写基于IP网的语音聊天程序的过程中碰到的，不一定很
具代表性，仅供参考和讨论。对于从事Win32平台的VOIP开发工作的朋友们，或许会有点利
用价值。
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、将套接字事件映射到窗口消息上时应注意：
当用WSAAsyncSelect将套接字事件映射到窗口消息上时，应注意窗口的消息阻塞可能会造
成套接字错误，如公用对话框。特别是在用PreTranslateMessage时极可能出问题。
4、再说两句废话。MFC支持Windows Sockets1但不支持Windows Sockets2。因而一些优良
的性能将不能使用，如服务质量（QoS）、有根多播。而在某些功能，如IP网多播的使用上
，Windows Sockets1和Windows Sockets2是有一些区别的。
