In winsock is there a difference between non-blocking mode and asynchronous mode? I just want to use non-blocking mode and I dont want to have to full with all the windows messages stuff. Is this possible or no? If it is possible whats the function to enable non-blocking mode? ( i think blocking is default mode?) Also on another subject are there any online tutorials for directplay or do you basically have to buy a book to learn it?

I think that yes you can have non-blocking sockets without all the windows crap.

To change your sockets to non-blocking use ioctlsocket(). The parameters are documented in the platform SDK.

If your sockets are non-blocking then you should get a return code of WSAERRWOULDBLOCK or something like that. Play around it should work.

--------------------------
I guess this is where most people put a famous quote...
"Everything is funnier with monkey''''s" - Unknown

There are a LOT of different ways to do IP networking with Winsock. Asynch and nonblocking are indeed separate solutions. Asynch integrates with the windows message-handler and is good for a clinet app using a GUI. Nonblocking sockets are a BSD-style thing and while they work they''re really not as efficient as other solutions. Basically, for nonblocking, you just specify that the socket be nonblocking and then all your send/recv calls will return immediately, whether or not they''ve actually finished.

I reccommend starting with standard blocking socket code to get the feel for things and work from there. If you''re interested in efficiency, use overlapped i/o. It''s like nonblocking socket programming but integrates better with windows and is more efficient (though not portable). If you''re coding a server (for NT/2k) and feel brave, look into iocp. It''s basically overlapped i/o in combination with a thread-pool, and is the reccommended way to handle high-volume socket server stuff, though there is basically zero documentation on it. I''d been meaning to write an iocp tutorial but never got around to it... I think there is a decent one online, however... I''ll check my links from home.

Winsock also supports the BSD async call ''select()''. This checks fd_sets(file descriptor sets) for available reads and writes, and is similar to WSAAsyncSelect(), but works in a console application, without any windows messaging stuff.

So to use non-blocking mode instead of blocking mode I leave everything the same with the Winsock except when declaring the sockets I declare them nonblocking somewhere somehow but leave all the send and receive calls the same?

Yes, that''s basically it. EXCEPT if your code has been designed to use blocking stuff, it probably doesn''t handle when the network buffers may be full, or if the data is actually sent, or rates. Things along those lines. Remember that recv and send functions will return immediately, whether or not your data has been sent. So you may need to put additional checking in to make sure things are ok.

But yes, you don''t need any other syntax to any other functions other than to declare the socket non-blocking before you start using it.

From what I''ve been reading, if you''re into getting the most performance out of things, you use this BSD style. Then with a little less control, you use ASYNC sockets and depend on the windows message loop.

Beyond that, Direct PLay may be an option, but noone can really say what the difference in performance and things are -- I''ve been looking. Although maybe that guy''s new book will give you a hint. I''m planning on testing some of this stuff soon to evaluate DirectPlay vs BSD vs ASYNC sockets. I''ll post an article here maybe when I do that. I won''t be doing any overlapped IO probably, just to keep things somewhat portable.

The overlapped IO would have the greatest performance, I suspect.
And just because you use some OS specific code doesn''t mean you can''t ever port it. It makes some more work, but if you OOD''ed it right it wouldn''t be much - so long as the X''s support some kind of async socket.

Magmai Kai Holmlor
- The disgruntled & disillusioned