Archived

This topic is now archived and is closed to further replies.

sross

concerning UDP...

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
quote:
...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).

Most use UDP, even for reliable stuff. There are a few that use TCP (Anarchy Online is one) for everything, but most use UDP for everything going to/from the client. I believe Dark Age of Camelot uses both TCP and UDP depending on firewalls/secure transaction types etc. Everquest, EQoA, Planetside, Starwars Galaxies etc all use 100% UDP for game play. Their Patcher uses TCP (via http), and some backend services you would never know exist use TCP as well.

For the original poster:
On Pentium2 266 + 512Ram we used to support about 100 players with no game-induced lag. Modern CPUs could support much more provided that there is memory enough to keep track of them. I''d say start out using winsock with TCP to get the hang of network programming basics, then decide whether you need UDP later.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
For a MUD with 100-200 players you should be fine with directplay. I think that directplay 9 would work fine for a MMOG, provided that you don''t care about the underlying protocol that is being used AND you don''t mind using a windows box for your server.

Another thing is that I don''t see any reason why you would want to use IOCP for 100-200 players...seems like its using a bazooka on an anthill, so to speak.

I am also struggling to understand how you intend to turn a MUD into a MMO....isn''t a mud a MMOG to begin with??

Or are you saying you want to change from text-based to a graphics based game?

Share this post


Link to post
Share on other sites
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. 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



Amazingly, you don''t need IOCP to support 1000s of players on Windows or Unix. If you choose to use TCP, yes, you probably need IOCP. For UDP however, you don''t. Most likely your connection limit will be determined by available memory.

Also, to what exactly are you referring when you say ''cluster''. Are you talking about real clusters that share physical resources, or are you talking about a server farm, which is really just a bunch of server machines on a network. I only ask because the MMOGs I''ve worked with run in server farms, not actual clusters. To my knowledge Dark Age of Camelot runs on server farms as well. There is a marked difference between the two, particularly in price.

quote:
I am also struggling to understand how you intend to turn a MUD into a MMO....isn''t a mud a MMOG to begin with??


Yes and no. ''Massive'' implies something about scalability, which very few text-based MUDs claim. The ideas behind the game design are certainly similar though, with that I agree. Take current ''zone'' based MMOs... a ''zone'' basically runs like a MUD server, but only controls one zone typically. This spatial partitioning also provides availability, which means that although one zone is down, all others might still be available for play. One of the chief differences to overcome between MUD and MMO is the networking protocol. Most likely you will not want to use a text protocol for an MMO where the bandwidth requirements are likely to be enormous.

Share this post


Link to post
Share on other sites
I understand your point about the scalability of a MMO game. However, he used the term "mini-MMOG" that supports 100-200 players.

Isn''t that just a multiplayer online game then (minus the massive)?

To me, massive implies also having servers and implementing load balancing. Or at least, a game with 1000+ players who could play at once. 100-200 doesn''t seem to fall into that catagory.

Also, there is a huge difference between a text based nextworked game and any sort of real-time graphics intensive game. The networking code/messaging system would have to be rewritten.

Share this post


Link to post
Share on other sites
quote:
Original post by fingh
Amazingly, you don''t need IOCP to support 1000s of players on Windows or Unix. If you choose to use TCP, yes, you probably need IOCP. For UDP however, you don''t. Most likely your connection limit will be determined by available memory.


Well, I guess because you aren''t actually maintaining a connection, that makes some sense, I see your point. If you can be sure you won''t hit more than 64 pending buffer read/writes at any one time, you could use events. Or even use 2 threads to give you 128 events. Or whatever multiple of 64 you''re comfortable with. Still, for my own peace of mind, I''m glad I went with IOCP. I should never have to worry that the networking code is bottlenecking me

quote:

Also, to what exactly are you referring when you say ''cluster''.


Cluster, server farm, whatever Okay, fine, server farm. I don''t have my networking terminology down, hehe. I was unaware there was a defined difference between the two

quote:

Another thing is that I don''t see any reason why you would want to use IOCP for 100-200 players...seems like its using a bazooka on an anthill, so to speak.


I disagree with this statement for a couple of reasons. What happens if his MMOG is a big hit? Suddenly 500 players want to play at once and he can only support 200. You just lost 300 customers! Bad news, IMO. Also, even if you really only have 200 players on at once, I think its a good idea to have the power to talk to them all simultaneously (or nearly so) without stressing the network too much.

Consider if player 1 picks up an item off the ground. You now have to communicate that the item is gone (off the ground) to all the other players as fast as you can (or at the very least, all those close enough to see the item) before someone else tries to pick up the same item (and you have to send them a very annoying rejection notice). What happens when several players pick up a few items on the ground at once? This sort of thing will cause frequent bursts of heavy network traffic outbound from the server, and if you have to stress your server to handle it, it''s also bad news IOCP could do this without breaking a sweat, the other models would not be as able to handle it.

IMHO, you should give your server as much horsepower as you can. There is no reason not to use IOCP, except that it''s hard to program, and that''s no excuse, if you don''t want to do something because it''s hard, you''re in the wrong business

Just my opinion. It''s been known to happen that I''ve been wrong once or twice before, heh.

Share this post


Link to post
Share on other sites
quote:
Original post by RonHiler
quote:
Original post by fingh
quote:

Another thing is that I don't see any reason why you would want to use IOCP for 100-200 players...seems like its using a bazooka on an anthill, so to speak.


I disagree with this statement for a couple of reasons. What happens if his MMOG is a big hit? Suddenly 500 players want to play at once and he can only support 200. You just lost 300 customers! Bad news, IMO. Also, even if you really only have 200 players on at once, I think its a good idea to have the power to talk to them all simultaneously (or nearly so) without stressing the network too much.

Consider if player 1 picks up an item off the ground. You now have to communicate that the item is gone (off the ground) to all the other players as fast as you can (or at the very least, all those close enough to see the item) before someone else tries to pick up the same item (and you have to send them a very annoying rejection notice). What happens when several players pick up a few items on the ground at once? This sort of thing will cause frequent bursts of heavy network traffic outbound from the server, and if you have to stress your server to handle it, it's also bad news IOCP could do this without breaking a sweat, the other models would not be as able to handle it.

IMHO, you should give your server as much horsepower as you can. There is no reason not to use IOCP, except that it's hard to program, and that's no excuse, if you don't want to do something because it's hard, you're in the wrong business

Just my opinion. It's been known to happen that I've been wrong once or twice before, heh.




All I'm saying is that from the scale of game he is describing, IOCP will be overkill. It will only become an issue with 200+ connections, in which case he has a ton of other concerns to deal with. Most likely, IOCP will not be necessary, and it can always be implemented later. Why spend that time up front if, from the sounds of his project, its meant to be on a small scale?
Whatever, use whatever works, I just like keeping things simple.

I mean, he's talking about a text-based mud. And another thing, what makes TCP too slow to expand into a MMO? TCP is too slow for real-time, latency sensitive systems.

I guess I dont understand what "expand into a MMO" means. Does this mean just increasing the # of players in the mud, or changing the game into a real time system with graphics, coordinates...etc..






[edited by - Sikara on July 7, 2003 5:22:53 PM]

Share this post


Link to post
Share on other sites
quote:

I guess I dont understand what "expand into a MMO" means. Does this mean just increasing the # of players in the mud, or changing the game into a real time system with graphics, coordinates...etc..

That''s my take on it, yeah. To me, MUD means text based, one of those telnet thingys people used to play that were basically Zork with lots of people. MMOG, on the other hand, means graphics, ala Everquest, Anarchy Online, Asheron''s Call, etc.

The former could use TCP just fine (and do, AIUI), while the latter are more needing UDP (although Fingh mentioned AO uses TCP, which would explain their crappy lag problems, I always knew that game was badly programmed hehe).

Share this post


Link to post
Share on other sites
quote:

quote:
I guess I dont understand what "expand into a MMO" means. Does this mean just increasing the # of players in the mud, or changing the game into a real time system with graphics, coordinates...etc..



That's my take on it, yeah. To me, MUD means text based, one of those telnet thingys people used to play that were basically Zork with lots of people. MMOG, on the other hand, means graphics, ala Everquest, Anarchy Online, Asheron's Call, etc.



Yea exactly, what i mean is, we are going to build a MUD which is text based to test all our client/server code for when we expand it with 3d graphics. So what we want to do is actually put all the functionnality we will need for when its going to be in 3d, even if it is totally overkill for only a simple MUD. That way we dont have to rewrite the whole client/server code and only have to focus on the 3d engine. And it also permits us to test the capabalities of our server and see how stable it is.

So thats mainly why i'm going to use IOCP/UDP. Like RonHiler said, if it actually gets popular and we get tons of customer, well we will have a powerful server to handle it.

EDIT: btw i said earlier that our MMO would be for around 100-200 players cuz i dont think we will have lots of servers and a uber internet connection like commmercial MMOs have... (ie we plan to host our MUD on 2 computers and each have a cable/dsl connection... if it gets popular and we make money out of it, then we will pay for servers and a better connection) so anyway i guess that if we use whats the most powerful out there, we will be able to support more players even if we are limited on the server side...

thx for all your replies

[edited by - sross on July 7, 2003 7:32:04 PM]

Share this post


Link to post
Share on other sites
Good luck, sross! If you run into problems (and you will ), feel free to give me a holler if you want. Whilst I''m no networking expert, I do have some experience with coding IOCP. I''ll help where I can. Otherwise I''m sure the people here can help as well (I asked more than one stupid question here when I was learning it).

I tried to find you some IOCP tutorial links, but I must have thrown them all out (I can''t keep every printout I make, my desk would be awash in paper, heh). You should be able to find them though, there''s three or four out there. Just one thing, *every* single one I found used TCP rather than UDP (don''t ask me why, I have no idea). The conversion is semi-trivial, usually UDP is easier (or at least less WinSock calls).

Share this post


Link to post
Share on other sites
yea i looked on google for some code samples on IOCP, most were all using TCP, but i found one that used UDP, and i believe it is the only one out there hehe

heres the link if you want to check it http://www.codeproject.com/useritems/iocp-multicast-udp.asp

EDIT: other good links i found that used IOCP and TCP if anyone interested...
http://www.whiningdog.net/Articles/Programming/Windows/20021115-IOCP/
http://www.developerfusion.com/show/2498/1/

thx for your help RonHiler

[edited by - sross on July 8, 2003 12:10:40 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by sross
Yea exactly, what i mean is, we are going to build a MUD which is text based to test all our client/server code for when we expand it with 3d graphics. So what we want to do is actually put all the functionnality we will need for when its going to be in 3d, even if it is totally overkill for only a simple MUD. That way we dont have to rewrite the whole client/server code and only have to focus on the 3d engine. And it also permits us to test the capabalities of our server and see how stable it is.

So thats mainly why i''m going to use IOCP/UDP. Like RonHiler said, if it actually gets popular and we get tons of customer, well we will have a powerful server to handle it.

thx for all your replies

[edited by - sross on July 7, 2003 7:32:04 PM]



Implementing a MUD is a different ballgame then implementing a 3d multiplayer online game. First off, traditional muds use TCP whereas you will probably have to use UDP for a 3d game. And thats just to start. The entire way you handle messages will be different. With a 3d game, you will probably have to send world updates X times a second and use interpolation and dead reckoning. A mud requires none of these things. You can send simple commands in a mud, whereas with a 3d game, just sending commands will quickly de-synchronize the client from the server.

Just trying to point out that writing a server using IOCP will be useful, but implementing something beyond that in the form of a mud will be less so if your goal is to make a 3d online rpg. You might want to make a multiplayer action game instead. A latency sensitive real time game is not something that a mud would easily convert into...



Share this post


Link to post
Share on other sites
quote:

Implementing a MUD is a different ballgame then implementing a 3d multiplayer online game. First off, traditional muds use TCP whereas you will probably have to use UDP for a 3d game.



thats why we are going to use UDP in our MUD...

quote:

With a 3d game, you will probably have to send world updates X times a second and use interpolation and dead reckoning. A mud requires none of these things. You can send simple commands in a mud, whereas with a 3d game, just sending commands will quickly de-synchronize the client from the server.



I know that a MUD requieres much less packet sending than in a 3D game. Although in the design of our game for the MUD, update packets will still be needed to updates all sort of things that change over time... sure it will be like maybe 1 time per sec... not 10 times per sec as in normal 3d games... and yea there will be no interpolation/dead reckoning... but that will probly be the only thing we will have to add to our server, along with collision detections...

So i beleive that building our MUD is not that a bad idea overall... and it will gives us more experience in building massively multiplayer persistent worlds... and that is one of the thing that brings lot of different issue compared to regular non-persistent world games.

Share this post


Link to post
Share on other sites