This article is mainly for the CasyncSocket class and CSocket classes in the MFC library, and the right is shallow and power. The problems listed here are mainly encountered in the process of recently preparing IP network-based voice chat programs, not necessarily representative, for reference and discussion. For those who engage in VoIP development work in Win32 platform, maybe a little useful value. 1. The CSocket class and the CasyncSocket class For multi-thread support issues Winsocks itself is support multi-threaded, with certain thread independence and security, but the CSocket class and the CasyncSocket class have some thread security issues. For example, if the CSocket object is transmitted between threads, the suggestion in the MSDN is to pass the DETACH, pass the Socket handle, and then ATTACH to a CSocket object in the target thread. This seems to show that CSocket (or CasyncSocket) has thread dependence. However, the situation is not absolute, the two cases of passing CasyncSocket or CSocket objects in my program have no exceptions, and there is no problem of running efficiency: (1) Creating and closing a CSocket blocking data settlement in the main thread Tag, use it in another thread to send data (Sendto). An exception occurs if it receives data (ReceiveFrom). (2) Creating and closing a CasyncSocket Non-blocking data settlement in the main thread, and there is no problem in retrieving data in another thread. In both cases, my feelings are unreasonable, but running on my machine is very stable. My suggestion is that if you use the CasyncSocket class and the CSocket class, try not to use it across threads (I will not take it in the future). 2. Blocking and non-blocking selection problems Blocking sockets are easy to use, but will affect the message response of the thread, which is more suitable for transmitting large amounts of data with flow sockets. For transmission of real-time voice data, the transmission is subject to the audio collection device. Once the data can be sent, the socket is called to send, so the blocking of the socket is not too large. (A packet in my program is only 20KB, the process of sending is very fast). At the receiver, the audio playback device is made by the receiving socket. When no data is accepted, the entire thread is on ReceiveForm (), and the normal message loop cannot be implemented. At this time, it will not be able to execute. Similarly, the audio collection device should also be non-blocking (asynchronous) in order to not block the message loop that does not block the transmission thread. Of course, if the audio playback and data reception are not placed in the same thread, it can also be used with blocking sockets, but this is another problem: two threads to share data, thus involving threads. Synchronize or mutually exclusive issues, while adding system overhead. 3, when maping the socket event to the window message: When using WSaAsyncselect to map the socket event to the window message, you should pay attention to the message blocking of the window can cause a socket error, such as the public dialog. Especially in the use of PretranslateMessage. 4, say two nonsense. MFC supports Windows Sockets1 but does not support Windows Sockets2. Therefore, some excellent performance will not be used, such as service quality (QoS), and have a root.
