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:

Contents
 Introduction
 Setting Up
 Notification
 Messages
 Shaking Hands
 Sending and
 Receiving
 Printable version
 Discuss this article
 in the forums

Introduction

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