Hi! I'm presently involved in (heh, you know the next part) a garage-production MMO:) , currently in designdoc development. So, there was a proposition to use UDP instead of the original TCP as the underlaying protocol. We never wrote MMOs before, however, there were a couple of LAN multiplayer games. I'm aware that UDP doesn't have the TCP's colossal packet overhead. But it also doesn't handle packet loss, which I believe is an important factor in the Internet. The question is, is UDP seriously used in MMOs? Is it really so much more effective than good ol' TCP?

Real games sometimes use a mixture of UDP and TCP.

But TCP works, really quite well. TCP headers are also compressed by a lot of connections (something you failed to notice when stating that they're bigger), UDP ones may not be.

TCP is a big win for tidying up those awkward bits of networking; it provides useful security (not against client-hacking, against spoofing and some types of DoS) and resending. These are good.

Quite frankly, I think you'll have your work cut out trying to make a MMORPG, so you may as well make life as easy as possible for yourself by using TCP.

Mark

Just thought I'd mention this, not exactly MMO related, but still deals with interesting server issues, coming from p2p world.

http://lugdunum2k.free.fr/index.html#techn (the info is in french, but should be translatable or at least understandable)

When edonkey was launched, the server was more of a proof of princible. A bunch of enthusiasts took over server development, and during this time they improved it's scalability from several thousand concurrent users to over 1 million concurrent clients per single box.

Last hardware listing is this ("La version eserver 16.45 permet à Razorback2 (dual AMD Opterons 248, 6Go ram) d'accueillir 600000 clients."), with last record of razorback server with 16Gb ram reaching 1.15 mil concurrent! users on a single machine! ("Razorback 2.0 et 2.1 avec leur 16Go de ram accueillent plus de 1.150.000 clients chacun.")

The issues faced here go way beyond the usual encountered in gaming world (they need special socket and threading implementations), they do raise some interesting questions on scalability.

The edonkey protocol maintains persistent connection from each client to the server (maintained by keep-alive packets). Some updates are sent using UDP, but major operations, such as download status and requests, searching, and client updates are sent predominantly over TCP. Additionally, server must maintain freely searchable database of all files available on each and every client, as well as provide proxy services for clients behind firewalls.
On each download request, server is responsible for providing a list of clients that can provide upload, and keep an up-to-date list of files provided by clients.

Ironically, the controversy and negative publicity (not unjustified obviously) surrounding the p2p file sharing keeps such achievements away from wider recognition.

So statements like TCP is useless because of overhead or what is really effective are mostly pointless, it all comes down to individual needs and actual resources available for implementation.

The "big" problem with TCP isn't so much packet overhead. That's hardly an issue with today's internet speeds. Even on 56k, it's no biggie compared to how little bandwidth typical MMO's actually need.

Another issue is that latency might go up, as packets have to be ack'ed before they're made available to the receiving app. This essentially means you have to wait for one extra round trip. Sure, you'll probably need to do something like that with UDP as well, just to make sure you got the right packets, but if you're clever, you might be able to handle it in a more "game-friendly" way than TCP does.

That said, Guild Wars use TCP, and that game can be pretty damn fast-paced. If the latency wasn't a problem for them, I doubt it'll be a problem for you.

So I think I'll agree with the others and say, making a MMO is hard enough as it is. Use TCP for now. It's doubtful you'll ever reach a large enough userbase that scalability becomes an issue, and it takes a hell of a lot of work to bend UDP to your purposes. You could try to keep the networking code abstracted from the rest of the game, so that it can easily be switched out for another implementation later.

Quote:But it also doesn't handle packet loss, which I believe is an important factor in the Internet.

True, but packet loss can't be handled in online games. Sure, TCP claims to handle it, but only by making the game unplayable *anyway*.
With TCP, you'll get huge lag spikes making everything unplayable. With TCP, you'll have some missing packets making everything unplayable. It can't really be handled acceptably, so just pray it won't happen. [wink]

Quote:Original post by Spoonbender
That said, Guild Wars use TCP, and that game can be pretty damn fast-paced. If the latency wasn't a problem for them, I doubt it'll be a problem for you.
[wink]

GW does not use client-side prediction and interpolation. It does compensate for some movement, but to the minimal possible extent. If you lag, you're out.

This was a choice made due to combat mechanics. Due to highly positional combat, collision detection as a core element of gameplay, and interrupt elements, using any kind of dead-reckoning would do absolutely nothing to make gameplay more apealing.

Many of the TCP issues are unwarranted. It inevitably comes down to your gameplay. The common MMORPG combat model is completely and perfectly suitable for TCP. Attacks are on timers (1-5 seconds), there's few actions if any actions that require immediate response, and most events are timed at much higher than 1 second response time. And people that start experiencing high packet loss will usually have problems playing anyway.

TCP gives you one advantage over UDP, it makes it extremly easy to compress the data stream continuously. High-capacity compressors (LZO as simplest or even just adaptive huffman or arithmetic coding) make real-time compression viable, and compensate for the TCP overhead. UDP communication would only be able to use per-packet compression, unless you develop some sequence management, and end up with what TCP already offers.