Ok i would like to build a MUD which i plan to expand to a mini MMO later on ( that supports arround 100-200 players maybe... ) So i believe i should use UDP since TCP would be too slow to expand the MUD to a MMO... Now i'm wondering if i should code it with Socket or DirectPlay8... so heres my questions: - Is there a way to use UDP with DirectPlay8? - In my other post on this forum, someone said DirectPlay couldnt support more then 20-30 players... is that true? - and last question... do you know any MMO/MUD that was coded using DirectPlay??? Im asking so much questions about DirectPlay cuz i find that its architecture is much more eazy to use then normal UDP Sockets... so i would rather use DirectPlay if it can support around 100-200 players in a MUD/mini MMO

ouch speed/many users and dplay in one post eww

seriously you dont want to use dplay for more than a few (id guess ~16) clients as its not really designed for more

also as far as i know muds are 100% text based so it should be no problem to use tcp at all as there should not be that much traffic even with 1000 players at the same time (yea some people call me optimistic )

also every mud i know is tcp not udp (most can be used with telnet)...



mfg Phreak
--
"Input... need input!" - Johnny Five, Short Circuit.

While it's true MUDs are generally text, and thus TCP is probably fine for them, sross mentioned he wants to expand it to an MMOG later.

For that, you'd definately need UDP. You might consider a TCP/UDP hybrid, as that's what I think most MMOGs use (they use the TCP where ordering and reliability is important and speed of transmission is not). I have found, however, that adding a reliability and ordering layer to UDP is one of those things that sounds a lot harder than it actually is I added both things to my network code and I use pure UDP, with certain packets types getting order and/or reliable delivery, and it works pretty well.

I understand why you'd want to start with a MUD and expand to a MMOG, since MUDs are undeniably a much easier thing to do. But the differences between the two are pretty significant and may cause you a lot of extra programming effort. For instance, are you sure you want to spend all the time putting together a parser only to rip it all back out when you go graphic?

So, as to your questions, here's how I understand them. I make no claims about being an expert on any of this, but I have coded my own Server/Client systems with both DPlay and Winsock, so I feel okay about sharing what I found
1) Yes, there's a way to use UDP with DPlay. It involves simply setting a flag during initialization, very simple (and easy to go back and forth with a single line change and recompile). Sorry, I forget the exact flag, but I do remember doing it before You should be able to find it by browsing though to DX docs.
2) As I understand it, yes DPlay has a 20-30 person limit. I only know this second hand, however, I didn't see happen it in practice. But I believe it, since I *think* DPlay uses the asynchronous select Winsock model, and then dumps a bunch of overhead on top of that. My prototype client/server used to use DPlay, and it worked fine with up to 7 people on at once. That's as high as we got it before switching over to Winsock
3) No, I know of no MMOGs or MUDs that have used DPlay. I'm certainly no expert when it comes to MUDs out there, so possibly they exist. AFAIK, all MMOGs use Winsock (or the *nix equivalent if they're using a *nix for the server, which more or less amounts to the same thing). As to which Winsock model, I would *expect* them to use IOCP (for the server), as it's the only one that can handle 1000's of connections. However, commercial MMOGs use server clusters, so maybe they can keep the population/machine down enough to use one of the other models (such as overlapped events or possibly selects), I dunno. But if you want to handle 1000's of people on one machine, you're options are IOCP or IOCP

My in-development game uses Winsock, with IOCP for the server and event notification through the message pump for the clients. It seems to work very well. Of course, we haven't really stress tested it overly much yet. We still limit the server population to 50, and actually, I've not seen it get anywhere near that level yet. As soon as we finish our next milestone, I want to try to hit that level so we can raise it for the next testing cycle.

Hope that answers some of your questions. Maybe someone else can fill in more blanks where I'm not sure of my facts.

[edited by - RonHiler on July 6, 2003 1:00:31 AM]

thx for all your replies

quote:
I understand why you''d want to start with a MUD and expand to a MMOG, since MUDs are undeniably a much easier thing to do. But the differences between the two are pretty significant and may cause you a lot of extra programming effort. For instance, are you sure you want to spend all the time putting together a parser only to rip it all back out when you go graphic?

Yea thats true... but i''ll probly do only a few simple commands... only the bare minimum for it to work... since it is basicly only to test our client/server code...

quote:
As to which Winsock model, I would *expect* them to use IOCP (for the server), as it''s the only one that can handle 1000''s of connections

What is IOCP? I never heard of that before...

quote:
I''d say start out using winsock with TCP to get the hang of network programming basics, then decide whether you need UDP later.

Yea I already made a little card game that used TCP that you could play up to 4 players... But i find UDP a lot harder then TCP... theres more things to consider for it to work well... like if you want to implement reliable sends, etc...

But i guess i have no other choice hehe... going to use winsock and UDP

quote:
What is IOCP? I never heard of that before...

IOCP is one of the Winsock models. It stands for Input / Output with Completion Ports.

Winsock uses a variety of models of varying power. At the bottom of the list are blocking sockets, where you call Receive (or Send or whatever) and the program halts at that command waiting for something to come in (or go out). The blocking socket model is usually the first one people try, because it''s very easy to use. It is also the worst performing, for fairly obvious reasons

Up from that are other models that are all non-blocking, where you make the Receive call (et al) and continue on doing other things without waiting. The differences mainly lie in how you get notified that some packet has come in. You can use events or the windows message pump (the asynchronous select model) or a couple of different versions of overlapping.

IOCP is the most powerful of the bunch. It can handle, in theory, some 50,000 simultaneous active connections using a P4 1.7 GHz processor with 768 MB of memory. Of course, you won''t get that many if you''re spending time calculating all the stuff you need for a MMOG, heh. But certainly a couple of thousand connections is not out of the question.

Unfortunately, IOCP is also the most difficult of the bunch to get a grasp of and actually program. It is inherently multithreaded, and there are a lot of nasty pitfalls that will trap you I don''t mean to discourage, just be prepared to spend a good month just working on the basic networking code.

Now, as for the clients, they don''t need that sort of horsepower, because after all, they''re only dealing with a single connection to the server, not several thousand. Like I said, I use the asynchronous select model for our clients, which basically means I get a message in my windows pump like any other windows messsage. This model is pretty simple, if you can write an IOCP server, you can write a async select client in your sleep

The other models I''d pretty much stay away from. Blocking sockets are useless, and non-blocking (the specific model, not the general term) aren''t much better (too much constant dealing with FD_SET). The event select and overlapped event models are okay, but they have an inherent limitation of event waiting (and you can only wait on 64 events per thread, so you end up with lots of threads, which can bog down your server). Therefore I don''t see the use of them. They''re too powerful for clients and too underpowered for servers In my opinion, anyway.

Of course, which model(s) you use is dependent on what you are doing. If your client doesn''t have a message pump, then perhaps non-blocking or event select would be a better choice. It''s worth doing a bit of research before you decide on a particular model for either your client or server.

thx a lot for the info

I was currently going to use the method they showed in one of my book that used FD_SET and threads like you mentioned... but if IOCP is better than that i''m going to check it out

I''ll try to find some tutorials on it... if you have some good ones post the links here