While reading IceDragon2000''s post (which I wish I could answer, but I really know very little about the whole WSA set of functions ), I started thinking about whether blocking/non-blocking sockets are appropriate in certain circumstances. As I''ve said in my few posts to this board a couple months ago, I am interested (along with so many others) in the creation of an online RPG, and I''m getting curious if anyone out there has a suggestion on if blocking/non blocking sockets are more appropriate. I would think that, at least in the client software, non-blocking would be the best, since the game could go on handling the mouse, playing music, redrawing the screen, etc. while waiting for the data to finally get in. But what about on the server end? I''m sort of torn there...the only MMORPG type software I have worked on is a server emulator for Ultima Online (UOX) which used blocking sockets. However, the code wasn''t the most sophisticated thing ever. Since a server (IMHO) needs no graphical front end or anything, and could probably exist fine as a console app (server software needs to be *fast*, why give it any extra overhead at all in the form of a nice windows GUI?). Would the speed boost of being able to process AI and things while waiting a couple milliseconds for a socket to finish be worth it? I think by the time you have received the message that the socket is ready again and responded to that, you''ve basically made up that time you lost by not blocking. Or (and my total ignornace of how Threads really work shows here, heh), could you maybe run your network code all in one thread and everything else (AI, etc) in another? Would they operate independantly, or does waiting for a socket to unblock halt the entire process, not just its thread? I''d love it if anyone could help me through this Anthracks

Both types of sockets have their own place. It''s not just enough to say that clients should use non blocking and servers should use blocking sockets.

It all depends on the amount of throughput and AI processing your server has to do. I prefer Winsock 2 and Overlapping I/O. It''s the Microsoft suggested method for high-volume servers, and isn''t really all that complicated once you get used to it.

With Win2k and the new thread pool management API, writing a high-end server application isn''t much work at all *relative to what it used to be*.

So for the Server, I''m going to suggest Winsock 2 w/ Overlapped I/O. For the client, use whatever works best for you. If you''re using Direct3D and already have a windows message handler, use non-blocking async. sockets and handle the messages with your window code. If you don''t want to do that, blocking sockets are fine, and will probably work just as well as non-blocking. It''s your call.

But as to your thread scheduling question, running your AI on one thread and your network code on another will probably end up being more trouble than it''s worth. You would also have to handle the case of when your network started getting congested and handling backlogged messages by dropping them as they expire etc...

-Jon

Do you think you could elaborate a little on Overlapped IO? I just started digging through the docs that came with Visual C++ 6 and it mentions various functions that involve overlapped IO, but not what it means really. What does it do, and what advantages does it provide?

Thanks for what you''ve already helped with

Anthracks

I think directplay8 was totally rewritten to handle precisely this.

Good Luck

-ddn

I hate to say this so early in DPlay 8''s life, but I think I''ve found a new favorite network API. The few things that winsock makes difficult, DirectPlay makes easy. Add to that the fact that DPlay8 has priority sending, and I''m sold.

If the server will be a Windows NT/2000 box, then I strongly suggest using IOCP (i/o completion ports). It is essentially overlapped i/o with a thread pool and callbacks, and is the most efficient way to handle high-volume traffic on an NT box. The big problem with overlapped i/o and WSAEventSelect is that it's limited to 64 outstanding socket calls... IOCP has no real limit. IOCP can be kind of a pain to learn, however, because there's basically no documentation and the only sample program is fairly old and is some kind of IPX server. You could use DirectPlay as well, of course. Asynch sockets are not very efficient and are most practical for a GUI-based client.

Edited by - Kensai on November 15, 2000 4:30:07 PM