Advantages of UDP vs TCP (programming question)

[Adrian Tung]

A lot of games, especially MMORPGs, use UDP as it is supposed to be faster than TCP. However, as I understand it, UDP is an unreliable transport that can result in packets either being lost or received out of order, while TCP is almost always guaranteed and in order.

So, if I were to write a multiplayer-based game using UDP, I will need to implement my own guaranteed transmission system (including all the networking stuff like re-sendings and sorting out-of-order packets and so on). However, through the internet, I would expect UDP packet loss to be reasonably high, thus severely affecting the performance of the system. In such a scenario, wouldn't TCP be more feasable rather than taking the *extra effort* to write a "guaranteed UDP transport" system? Or am I wrong?


Thanks in advance,
atwl

 

[DaveSimmons]

UDP arrives immediately (i.e. at ping speed) or not at all. TCP arrives, but could take awhile.

In many time-based apps (streaming, shooters, MMOGs) it's usually more important to have a steady stream of data with lost packets than reliable data that requires the extra confirmation steps for every packet and that arrives in fits and starts.

A good winsock programming book would go into more detail.

 

[Nothinman]

UDP is as close to RAW packets as you can get without writing all the IP headers yourself. There's no error checking, no setup handshake, etc.

The reason it's used is because if a TCP packet gets dropped, the TCP layer does it's own checking for this and will retransmit the packet, normally this is a good thing. In a game like quake if a packet is dropped it's probably too late and you don't want it, you just want the next one. In a real-time game (or as close to real as the Internet allows) you don't need high reliability, you need low latency.

 

[manly]

Like Nothinman said, a sensible application of UDP would not build error correction and guaranteed delivery on top of the protocol.

If you did need those characteristics, then you're right that TCP would be a better choice.

 

[Adrian Tung]

Thanks for the replies.

I play a lot of Dark Age of Camelot, and currently I am using it as a gauge. According to what you guys say, I would assume that DAoC, which uses both TCP and UDP, will use UDP to transmit movement data (which does not need to have guaranteed transmission), and TCP for everything else?

How would that work for a twitch game like Quake or Unreal Tournament? Do they also open both ports at the same time? From my understanding, the only application of UDP that I can think of is for movement; everything else needs to be guaranteed and therefore need a mechanism - either TCP or guaranteed UDP - otherwise things will look very bad with missing animations, lost mouse clicks, etc.

Or am I wrong in my assumptions?


atwl

 

[Strafe]

Now I'm just a newbie programmer, but would it make sense to use UDP for its speed/latency and implement error checking in your code?

 

[RSMemphis]

I think the IP header itself provides a checksum, which will verify data integrity.
if you need data fast, then it is better to just drop bad data and wait for good data.

If bandwidth is not an issue, sending two UDPs is a good choice, and give them the same identifier. If both arrive intact, just drop one.
If one is lost - no problem. If one has errors - no problem.
But it doubles the data sent, so a server that could host 8 people can only host 4 then.

 

[Nothinman]

From my understanding, the only application of UDP that I can think of is for movement; everything else needs to be guaranteed and therefore need a mechanism - either TCP or guaranteed UDP - otherwise things will look very bad with missing animations, lost mouse clicks, etc.

Or am I wrong in my assumptions?

First you have to realize most things you see in the game are local, the models, animations, textures, etc are all gotten from your PC, they just take orders from the server. Also all input is registered locally, just your position and actions are transmitted, so mouse clicks wouldn't be lost.

Well from a development standpoint you can do 1 of 2 things. Use TCP for the things that have to make it, even if they're late and UDP for the things that have to be quick even if they're lossy or you can use UDP for both and have your own error detection for the things that need it. I personally would think using UDP for both would be better, you would have 1 socket to manage and 1 send/recv loop to worry about, in that loop would be packet loss detection and the code to resend any packets that must be resent, all the rest you just go on sending the next update to try to get back in sync.

You also have to remember that even though UDP can be lossy, you don't normally lose a large number of packets, if you do there's nothing you can do to make it work well because something between you and the server is overloaded or broken in some way.

 

[Adrian Tung]

Thanks for the info, Nothinman, but I think I need to elaborate on what I was asking earlier.

When I meant missing animations or mouse clicks, I was actually referring to things such as using items or attacking, where the actual message being sent could be an attack or a use item message. If that message doesn't get through, the clients may not see the proper animations for the actions, but may see the result of the action later on. I don't know if this would be an issue in the design sense, but it's just something that came to the top of my head. Anyway, your explanation about using UDP for both guaranteed and unguaranteed transmissions clears up the issue, so thanks.

I have one more question: Someone told me when sending UDP it is better to pack up data and send them at regular intervals rather than sending small messages the moment the client program puts the message in the send queue. His reasoning was that some routers may drop packets that are too small, treating them as "rogue packets" or something like that. Is this true?

Thanks,


atwl

 

[Nothinman]

If you've ever played on a very lossy network you'll see exactly what you describe, it's unavoidable.

Any router that drops too small of packets (that have afull header and some data even if it's 2 bytes) are broken, too big is another story though.

 

[Mucman]

There was a good article on Gamasutra about this. The Network coder for X-Wing vs. Tie Fighter explains how they started off using TCP and it was a disaster! The did some clever coding with UDP to clear up the issues.

My memory may be fuzzy, but I believe every datagram that was transmitted contained data from the last datagram... so if some get dropped their is no data loss.

<edit>Here is the article, but with gamasutra you need to register with them to see the articles</edit>

 

[Jumpem]

UDP is faster since it's connectionless and doesn't keep state information about the connection. There is no three-way handshake between client and server. It can easily be made just as reliable as TCP. With TCP the application just needs to send data towards the server and the TCP protocol will handle the reliability factor. With UDP you can become much faster by negating the connection setup. The application developer will have to implement their own security at the application level, not the transport level, using a combination of packet sequence numbers, window sizes, timeout timers, acks(acknowledgements), or nacks(negative acknowledgements) .

 

[Adrian Tung]

I've just read the XvT article, and it's very interesting.

One last question though. The developers of XvT said its better to send large UDP packets since the header is uncompressed. The way I see it, the client can still send packets on-the-fly (even tiny ones with only 4-bytes) of data since the outgoing queue of a client is usually significantly less than the outgoing queue of the server.

So if I were to implement a server-client game of some sort, I'd have the client sending messages instantly as they are put into the message queue, while the server will pack data in its queue and send them in one lump sum at regular intervals. If I time the sending to the various clients properly, the outgoing throughput on the server-side should be a constant stream of data instead of bursts at regular intervals. I could also probably implement some sort of smart packing system that packs more data and/or sends at faster intervals for clients with fast connections, and less/slower data for slow-connecting clients. Will such an architecture do?


Thanks again,

atwl