1 Milisecond Timer?

it sounds good in practice, but WM_TIMER messages were not designed for timing anything faster then about 10-15ms. Furthermore ANY message that your window recieves will be placed before a WM_TIMER. WM_TIMER is a low prioity message. It is placed on the back burner. This is true even if you use callbacks.

If your goal is to create an application that downloads data, look into asynchrosous sockets. They send your window messages when there is data to be read or when you can send data.

Check http://www.gamedev.net/reference/programming/features/asyncsock/

you should create a destroy timers, instead create a single timer that has a decent latency.

You can also look into using a worker thread for doing other things. Dont forget to use Sleep() to give time back to the cpu insteda of busy waiting. It may be best to explain better what you are trying to do.

[Edited by - qazlop on February 19, 2005 3:54:17 AM]

So I would bind/connect the socket after calling WSAAsyncSelect right?

[Edited by - jtmerchant on February 20, 2005 8:05:19 PM]

Thanks, but I have another problem. I've looked on some other articles about Winsock, but when using async sockets, everything goes through WinProc. This is all fine and dandy for the program I mentioned before, but now I need to know what to do in a game with a Direct3D rendering loop. Should I just use non-blocking sockets that require a loop anyway? It makes sense, it's just that a few articles said non-blocking sockets were inefficient. Are they wrong?

In my experience they're fine. Just be aware that there are NO asynchronous socket functions for reverse dns lookups or hostname lookups. you'll have to run those on a seperate thread (if it matters which it probally doesnt :P), or use the windows equiv: WSAAsyncGetHostByName which sends a little note in the wndproc when the event has been processed

For network programmig you often want to look into using multiple threads. I prefer to use blocking sockets with select() myself, but it really comes down to a matter of personal preference. Using multiple threads lets you use blocking sockets and make the most of the OS's context switching to handle the equivalent of select(), but you get the disadvantage of managing the synchronisation yourself.