Precautions for using MFC Windows Sockets

This article focuses on the casyncsocket class and csocket class in the MFC library, which is not easy to learn.

The problems listed here are mainly encountered in the process of preparing an IP-based voice chat program recently.
Representative, for reference and discussion only. For those who are engaged in VoIP development on the Win32 platform, it may be a bit beneficial.
Use value.

1. multi-thread support issues of the csocket class and casyncsocket class
Winsocks itself supports multiple threads and has a certain degree of thread independence and security, but the csocket class and casyn
The csocket class has some thread security issues. For example, passing the csocket object between threads will cause exceptions, MS
In DN, we recommend that you pass the pre-detach, pass the socket handle, and attach it to a csocket pair in the target thread.
Image. This seems to indicate that csocket (or casyncsocket) is thread dependent.
However, this is not an absolute situation. either of the two cases in my program that pass the casyncsocket or csocket object does not exist.
There is an exception and there is no running efficiency problem:
(1) Create and close a csocket-blocking datagram socket in the main thread, and use it to send data in another thread
(Sendto ). If it is used to receive data (receivefrom), an exception occurs.
(2) create and close a casyncsocket non-blocking datagram socket in the main thread, and use it in another thread
There is no problem with receiving data (receivefrom.
In the above two cases, I feel that there is no reason, but it runs very stably on my machine. My suggestions
Yes. If the casyncsocket and csocket classes are used, try not to use them across threads (I will not leave the risk in the future
).

2. Selection of blocking and non-blocking
Blocking sockets are convenient to use, but will affect the message response of the thread. It is more suitable for transmitting a large number of messages using streaming sockets.
Data.
For the transmission of real-time voice data, data transmission is subject to audio collection equipment. Once data can be sent
The socket is called for sending, so the blocking of the socket does not occupy much of the running time of the thread (in my program
The size of a data packet is only 20 KB, And the sending process is very fast ). In the receiver, the audio playback device is subject to receiving
Socket. When no data is received, the entire thread is stuck on receiveform (), which cannot be eliminated normally.
Cycle. If a wm_quit message is sent to the thread at this time, it cannot be executed. Similarly, in the sender
The message loop of the sending thread is blocked, and the audio collection device should also be non-blocking (asynchronous.
Of course, if you do not put audio playback and data reception in the same thread, you can also use a blocking socket.
There is another problem: the two threads need to share data, so they need to involve synchronization or mutual exclusion between threads,
At the same time, the system overhead is increased.

3. Note the following when you map a socket event to a window message:
When wsaasyncselect is used to map a socket event to a window message, note that message blocking in the window may cause
A socket error occurs, such as a public dialog box. Especially when pretranslatemessage is used, problems are very likely.

4. Let's talk nonsense. MFC supports windows sockets1 but does not support Windows sockets2. Therefore, some excellent
Such as QoS and root multicast. Some functions, such as the use of IP Multicast
Windows sockets1 and Windows sockets2 have some differences.