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
79 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:

 Setting Up

 Shaking Hands
 Sending and

 Printable version
 Discuss this article
 in the forums


Hello again. Itís been a while - Iíve been keeping myself quite busy with studies, work, school, and more. Ugh. But I saw a post on the boards asking for a DirectPlay or WinSock tutorial so here I am. I had to speed learn (is that even a term?) WinSock for work so we could develop a (big word here) multiplexing program for DSL modems. Blah - that got canceled. So here I am with all this knowledge and nothing to do with it - except share it, of course.

This article is written about a topic I only recently came to fully understand. Itís kinda confusing at first, but I had to rely on these stinking textbook-like books that gave no explanations whatsoever. Hopefully I can help save you from having to learn this way and then reduce yourself to begging for help and understanding from the boards. Anyway enough friggin talk - I have work to do after this. Now I have to learn (well, understand) Java in three days. Good grief. What do these people think I am, Superman? Hey I kinda like that...

This article assumes you have prior experience in WinSock programming - this article does not cover the basic WinSock conventions used within.

Asynchronous != Non-Blocking

Since you are just learning this, I will assume that up till now you have been using blocking sockets. With that in mind, I will assume that you may have toyed around with non-blocking sockets. Whatís the difference? A socket that is blocked sends out a call and then waits for an answer. A non-blocking socket sends out a call and the program execution continues. This is exactly what asynchronous sockets do. However, there is a major difference.

When using non-blocking sockets, you have to continually poll the socket to see whether or not you have any actions that need to be performed. These actions can include sending and receiving data, establishing a connection, sending back a response to a connection request, etc. Non-blocking sockets have the advantage in that they allow normal program execution to continue - meaning you can process data while waiting for more to come in. This immediately makes them superior to blocking sockets in many cases (but not all).

However, asynchronous sockets take polling to a new level - they do it for you. This means that you can focus on other things while WinSock keeps watch over your sockets. (Sounds better than non-blocking sockets eh? Not always, as youíll soon see.) So how does it do this? Well, um - I kinda like donít really know, sorry. I do know it calls a library and that creates a thread or something and, and - well I can tell you how you are notified, even if I canít tell you how it knows to notify you. J Had ya going there, didnít I?

Windows Socket Messages

Thatís right - read it and weep. Hope you werenít planning on a nice simple console app there, bucko. This requires a nice spiffy Win32 app, and nothing less. If you donít know how to create a Win32 app (namely, a window, a message handler, and a main loop) then I can suggest the first part of Game Programming Genesis, by that cool dude Ironblayde, which explains all you need to know that will get you started. Once youíre done reading that, get yourself back in here and keep going!

For those of you in the know, this is the one major advantage asynchronous has over non-blocking sockets. Of course, this can also give non-blocking sockets an advantage when you want to design a simple console app. Non-blocking sockets can be used in console apps, asynchronous sockets cannot.

But I still havenít gotten to the topic of this section yet! Socket Messages - right. WinSock makes use of the Windows message queue in order to notify you when socket events take place. These are the events that WinSock can generate for you:

  • FD_READ: This message indicates that you have just received data, and you must use the recv() function to get it.
  • FD_WRITE: This means that there is room in the buffer to send, and we must send using the send() function.
  • FD_CONNECT: Used only by the client program. This message indicates that the server has received the connection request and has accepted.
  • FD_ACCEPT: Used only by the server program. This message indicates the receipt of the connect() request and you must send back an accept().
  • FD_CLOSE: This message indicates that the other sideís socket has shut down. This can be for several reasons.

These five events (which are piggybacked on a message, as weíll soon see) are all you need to manage your connections. I say connections, plural, because the beauty of this setup is that each message has the socket instance that called it stored in its wParam field. This means you can manage multiple connections with only one FD_READ or FD_WRITE message! Iíll point this out a little later.

Next : Setting Up the Asynchronous Sockets