UDP vs. TCP......round 2134

[jared888]

Hey,

If I want fast AND reliable, do I use UDP and write my own error/datagram tracking into my app?

[blahblahblahh]

No. But if you want reliable and out-of-order delivery, then yes.

Whether or not it's "faster" depends upon the exact traffic patterns of your game (in general, it will often be slower).

And don't bother writing your own unless you're trying to get a job in writing network protocols. There's too many free ones for it to be worth re-inventing the wheel (would you write your own software 3D renderer without OpenGL? Obviously a few would, but usually only those wanting to prove their abilities at 3D maths)

[jared888]

I don't actually want to re-write networking code. I would use the existing sockets classes to build my communications between game components (I have a 3 tier plan).

So, what you are sayting, is that if I want stuff to be reliably delivered in order, I want to use TCP, and it won't be significantly slower than UDP?

Thanks!

Games published by our own members! Check 'em out!

[Herkules]

For sure not slower than a protocol on top of UDP with these features.

[jared888]

Thanks all, y'all just made my life a heckuva lot easier!

[Matei]

It depends a lot on what kind of game you make. After wondering about TCP vs UDP myself, I was quite surprised to find out that virtually all MMORPG games, for example, use TCP. UDP is only for when you need very fast reactions, perhaps in a shooter game.

[blahblahblahh]

It depends a lot on what kind of game you make. After wondering about TCP vs UDP myself, I was quite surprised to find out that virtually all MMORPG games, for example, use TCP. UDP is only for when you need very fast reactions, perhaps in a shooter game.

If you're going to make a statement like that you should list the games you're citing.

[endolf]

Ultima online uses TCP, but Earth and Beyond uses both. UO of course is just point and click for movement, whilst Earth and Beyond isn't. Dark age of Camelot also uses UDP and again is not just point and click for movement.

It would *seem* that even some of the newer MMORPGs are using UDP for some parts of the game play.

Just for interests sake

Endolf

[aldacron]

Dark age of Camelot also uses UDP and again is not just point and click for movement.

Actually DAOC uses both TCP and UDP. UDP handles all of the positional updates, spawn notifications, etc...

[endolf]

The all use TCP for something, usually login/updates and a few other things, I was only mentioning the gameplay/movement aspects, as I assumed TCP for certain things was a given

Endolf

Games published by our own members! Check 'em out!

[blahblahblahh]

The all use TCP for something, usually login/updates and a few other things, I was only mentioning the gameplay/movement aspects, as I assumed TCP for certain things was a given

Endolf

Exactly. My guess on reading the "most use TCP" statement was that is what the poster was probably referring to, and that they hadn't checked their facts fully (e.g. had just seen "game X uses TCP" and assumed that meant it didn't use UDP and that it used TCP for something other than OOB data).

Hence the request for a list of games, so we can check their facts.

[crystalsquid]

For MMORPG in-game messages, the main performance issue with TCP is the socket-per-client overhead on the server, and can impact performance (using a thread per socket and 1000+ clients is a lot of thread switching).

Another aside is that each socket will perform its own throttling, which is good for clients, but means its trickier to throttle the whole server when the server output stream bandwidth is too large.

Building a TCP stack on UDP eliminates the thread overhead and socket management, but you really should implement a SACK-TCP per-client, and add some global throttling to this. Its a fair amount of work but will save you some significant proportion of server processing when you get it right. You should refer to the relevant RFC docs to get it right - there is a lot of freely available information there that would take you months to work out by yourself, + important algorythms to use so that you don't start knocking routers over when things start going wrong (which they will do).

My own implementation also uses a reduced header of around 8 bytes instead of the 20-ish of TCP. For 1000 clients and 4 msg's per second this can save you 100kbs!

To summarize - for (at a guess) 50 clients or less, the standard TCP is MUCH easier to implement, less prone to errors, and not too much overhead. If your client numbers is reaching over 500+, you should probably consider your own UDP stack  - or powerful (& expensive) multiprocessor servers / a server farm. You can beat TCP performance, but only in the realms that TCP wasn't originally intended for, and only with a lot of work.

- Dom

[endolf]

For MMORPG in-game messages, the main performance issue with TCP is the socket-per-client overhead on the server, and can impact performance (using a thread per socket and 1000+ clients is a lot of thread switching).

Thats what NIO is for, no more do you need a thread per socket. It *was* a problem with the old Java IO and TCP, under C you've always had the selectors like in NIO anyway.

Endolf

[Gambit]

Dom could you give more details or some links about building TCP like protocol on top of UDP?

Cheers,
Gambit

[crystalsquid]

Endolf:
You're right - Due to various reasons I always end up thinking of Java 1.1 as that is our target platform most of the time. I haven't looked into NIO myself  
On Windows (C++) you need to use IOCompletionPorts to handle all the sockets instead - which is a big pain that I couldn't be bothered to wade thorugh... Not sure what Linux is like for 1000+ TCP sockets, but now I have my UDP library I don't need toknow

Gambit:

Useful things to look at:
ENet: http://enet.cubik.org/
A good starting point (in C though). It doesn't do Selective ACKs (which is a must) but does include a few other essential TCP features such as exponential back-offs, and the receiver window system.

And some googled stuff:

RFC2581: Congestion Control
http://www.zvon.org/tmRFC/RFC2581/Output/chapter3.html
The basic algorithms you need to consider.

RFC 3517: A Conservative SACK based loss-recovery system
http://community.roxen.com/developers/idocs/rfc/rfc3517.html
A very good algorithmic description of using SACKs. It also has a few references to other useful RFC's

http://www.eventhelix.com/RealtimeMantra/Networking/TCP_Fast_Retransmit_and_Recovery.pdf
A nice descriptive 'flow' of communications using fast retransmits & SACKs.

These were pulled from my old favourites when I was writing my network layer, and I found them to be very useful.

Hope this helps,

- Dom

[Gambit]

THX Dom!

Cheers,
Gambit

[aldacron]

Endolf:
On Windows (C++) you need to use IOCompletionPorts to handle all the sockets instead - which is a big pain that I couldn't be bothered to wade thorugh...

Actually, you don't *need* to use IOC on Windows. There are several (at least 4) models available. Besides, IOC does not work on Win9x kernels. Aside from select, the simplest model to use is AsyncSelect, in which socket events are handled via Windows messages. It's also more efficient than select.

I've always wondered which model NIO uses under the hood on Windows.