Sign in to follow this  

UDP or TCP for MMOG

This topic is 2056 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

If I were to program a massively multiplayer player vs player based game with 300 clients connected to one server at once, what protocol would you use then?

Would this be a good idea...

- Program a UDP messaging system with a "reliability layer" involved so that important messages such as sending account information and trading gold ingame have a reliable connection?
- Program another UDP messaging system (although this one is just as is, any packets lost are gone and nothing can be done about it) and only messages such as player movements, player casting spells/using abilites and health/mana updates are located here.

Now these two messaging system can easily be combined into one and only the reliable UDP messages would be blocked waiting for confirmation of a reply.

What do you think about this?

Also if I were to do the same with a TCP server wouldnt there be over 1000 async calls for stream writing to the 300 clients on TCP? making 1000 threads which is uhh... yeah... lol. I'm self taught and probably have bad habits but ive tried this before and updating constantly with async calls on TCP seemed laggy too...

Also is there any good books/resources/articles on this sort of stuff? I would really love to learn it.

Share this post


Link to post
Share on other sites
The form FAQ has some resources. It kind-of depends on what "this stuff" really means.

I'd recommend a good, basic, networking book. Stevens is good for the fundamentals, even if the specific examples/numbers are a bit old. Singh et all (Networked Virtual Environments) is another good book to get a feeling for the flavor of the problems. Then there's all the different games, where some have been written up in detail, and others are just scraping the surface.

Note that a typical, game-ready, UDP protocol will separate "messages" into "reliability classes" and often "channels," and the reliablity and blocking/waiting would be per-channel. All of the data to a particular node will be gathered into a single UDP packet per network tick, and even if one channel is blocked waiting for acknowledge, all the other channels would still be able to contribute data to the next packet.

Finally, asynchronous calls do not spawn a thread per call. Typically, there's a pool of worker threads, and one of those threads will pick up any of the asynchronous completion notifications. It's the most efficient way of doing heavy I/O on most systems. In the traditional UNIX model, the "pool" might even just be a single thread.

Share this post


Link to post
Share on other sites
Thanks, I did look for some books in my pefered langauge (C#) but they were published in the year 2002 etc...(does it matter if the books are dated, has anything changed drematically since then? also im guessing any book programming language is fine just to understand the logic of it?). And sorry I should have clarified. By "this stuff" I mean methods/ways to implement proper and stable game networks or any network that involves sending many packets in short intervals.

Also about what you said if you were to call a reliable packet write wouldnt all following writes be blocked to and then only unblocked/sent (when the acknowledge has been received) depending on the latency of the connection? so a latency of 333ms means only 3 packets a second? Or am I just miss interpretating what your saying?

Thanks for the reply again! :)

Share this post


Link to post
Share on other sites
I wouldn't look for books talking about "network programming in <language X>" because those tend to be API focused, and APIs change.
The fundamentals of networking (at the systems programming level) do not change at all as quickly, which is why I recommend a more textbook-like approach (such as TCP/IP Illustrated by Stevens -- it's 20 years old, and still great! But it uses C for its code illustration.)

I am explicitly saying that with a system that packs multiple separate "channels" on traffic into a single UDP packet, only traffic on a particular reliable channel needs to be blocked when you're waiting for acknowledgement; traffic on all the other channels can still flow, so you can send as many UDP packets as you want. Also, there will typically be a "window" of allowed outstanding packets, so you don't stop sending from the source until you've sent X messages without hearing any acknowledge back. If you read a textbook on TCP, it will explain how sliding windows work in great detail; this is the same idea.

Share this post


Link to post
Share on other sites

This topic is 2056 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this