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

Do you think dplay8 can handle this sort of thing?

I think directplay8 was totally rewritten to handle precisely this.

Good Luck

-ddn

I agree that Async sockets should be used on servers. Why? The gem of them is that 1) they post windows messages, so they are easy to handle, and 2) the messages have the wParam variable assigned the name of the socket that the message is for. This means that you do not need to write code to handle all the different connections, just one message handler with the wParam variable in place of where the socket variable would go. Great for multiple connections.

==============================
"Need more eeenput..."

- #5, "Short Circuit"
==============================

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.

Yeah the priority & reliablity can be set on each packet and it has VoIP, c'es la pied!

The addressing seems overly complicated though...

uses a worker-threaded pool too, so mutli-processor servers will benefit.

...
portability goes out the window though... have to use 2000 for the server...

Edited by - magmai kai holmlor on November 14, 2000 10:44:11 PM

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