Contents  Introduction  Architecture  On to WinSock  The Basics  Socket Types  Error Checking  The price you  pay...  Rock, Paper,  Scissor, Shoot!  How to use  the demo  A word on lag  Conclusion  Demo  Printable version

The price you pay for using asynchronous sockets

There is one disadvantage when using asynchronous sockets. Say you decide to send something to the computer you are connected with, and one command after, you try to perform another operation on the socket, chances are that the socket will return an error. The error is WSAEWOULDBLOCK (error number 10035). The good news is that this error is not a fatal error, but just means, "Try again later". The bad news is that in theory, you should be testing for this error specifically and trying to perform your action until it actually works and this error is no longer returned. Now this is annoying, since you can test for errors by just saying if (socketaction(s)==SOCKET_ERROR) (here, socketaction() doesn't mean anything. It is just an example). But WSAEWOULDBLOCK is an error also. That means you will have to specially test (call WSAGetLastError()) if WSAEWOULDBLOCK occurs and just repeatedly try again.

I have found a cheap way around this which is not 100% guaranteed to work. When you perform your action and there was an error, test if WSAEWOULDBLOCK was returned. If it was returned then just Sleep (750) and try again. What's so great about this? Well, you don't have to loop, instead you just delay and try once again. Chances are, that after 750 milliseconds, the socket will be ready to perform your action.

Next : Rock, Paper, Scissor, Shoot!