Use the web application developed by Socket, running on XP. Now moved to a new machine, the new machine XP is upgraded to SP2, and the server program of the network application system is frequent, it is very strange.
Later, after tracking discovery, in a new environment, the RECV function has an error, although the RECV function is blocking, but the new MSDN said that the RECV and send functions will return immediately in some cases, and set an error
WSaewouldblock ..
Here is the description of the MSDN of Microsoft's MSDN:
As in the case of the select function, WSAAsyncSelect will frequently be used to determine when a data transfer operation (send or recv) can be issued with the expectation of immediate success. Nevertheless, a robust application must be prepared for the possibility that it can Receive a Message and Issue A Windows Sockets 2 Call That Returns Wsaewouldblock Immedierately. for Example, The Following Sequence of Events IS Possible:
Data arrives on socket s; Windows Sockets 2 posts WSAAsyncSelect messageApplication processes some other messageWhile processing, application issues an ioctlsocket (s, FIONREAD ...) and notices that there is data ready to be readApplication issues a recv (s, ...) to read the dataApplication loops to process next message, eventually reaching the WSAAsyncSelect message indicating that data is ready to readApplication issues recv (s, ...), which fails with the error WSAEWOULDBLOCK.
Other sequences are also possible.
The WS2_32.DLL will not continually flood an application with messages for a particular network event. Having successfully posted notification of a particular event to an application window, no further message (s) for that network event will be posted to the application window until the Application Makes The Function Call That Implicitly Reenables Notification of That Network Event.
So check if it is wrong in the network application and is WSAEWOULDBLOCK, and related processing. But it can be used normally before SP2.
