Upcoming Events
Unite 2010
11/10 - 11/12 @ Montréal, Canada

GDC China
12/5 - 12/7 @ Shanghai, China

Asia Game Show 2010
12/24 - 12/27  

GDC 2011
2/28 - 3/4 @ San Francisco, CA

More events...
Quick Stats
88 people currently visiting GDNet.
2406 articles in the reference section.

Help us fight cancer!
Join SETI Team GDNet!
Link to us Events 4 Gamers
Intel sponsors gamedev.net search:

  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!