UDP - Packet Loss in Real Life? 127
PacketStorm asks: "There's always an argument between TCP and UDP users. TCP users complain that UDP is non-determinstic and lossy, while UDP users complain that TCP is slower and nobody needs all the features anyway. So the question is - has anyone actually seen/experienced UDP loss in high-traffic environments? Is the degeneration of UDP any better or worse than TCP in a congested environment? TCP also craps out in times of congestion, but at least you know - or do you? Experiences?"
Why UDP in games, TCP for bulk tranfer (Score:5, Informative)
TCP is designed to make unreliable networks (like the internet, which only gives "best effort delivery") reliable by ensuring that a stream can be reassembled, in order, with no missing pieces. Read the RFC for more info here. This reliability makes it good for things that need zero corruption (file transfers for example), and aren't time criticial.
Hope this helps.
--MonMotha
Re:UDP packet loss (Score:3, Informative)
With TCP, you have a listening socket and then a socket for each client. Each socket has a file descriptor, and you have to select() on all of them to check for activity. There is a lot of housekeeping to do - though it is a solved problem - all webservers solve it. Timeouts are harder to determine from the application's perspective because there can be retransmits and stuff going on that you have no idea about.
However, with UDP, it's laughably easy. You just do one recvfrom() and you get a packet and it also fills in a data structure to tell you where it came from. No filling in fd_set structures and no running out of file descriptors. When you got the packet, you got it.
Most online games and stuff would really like to know when packets were sent, when they were received and if packets are being dropped. With UDP you can usually find out these values directly. With TCP I think it would be more like an educated guess.
One drawback is that UDP is quite easy to spoof. I can send a packet and it is up to the application to figure out it has been spoofed.
If I were downloading a patch to a game I think TCP would be the better choice. It already has the smarts to pace the connection, transmit the data reliably and prevent spoofing.
Comment removed (Score:5, Informative)
Re:UDP Experience (Score:1, Informative)
#2. Within your LAN is something, out in the big bad internet is something else.
Re:UDP packet loss (Score:3, Informative)
I would think SOME game data would need to be reliable, but most isn't. The problem with TCP for an online game is that you can never THROW AWAY data that's too old or unnecessary. It will be transmitted and retransmitted further delaying current data. At some point, things will become unusable.
I don't think you could play a multi-user game for over an hour and not run into this problem. I think on lower-bandwidth connections, you might never be able to catch up once you fall behind.
Of course, you could do what microsoft does with DirectPlay: open multiple connections, sometimes on multiple protocols, some of them asymmetrical, while ignoring silly details like firewalls and NAT.
I think the initial handshake for dungeon siege was something like:
first packet: udp my_ip:6073 to server_ip:6073
reply packet: udp server_ip:6073 to my_ip:2302 (what!?!?)
next packet: udp my_ip:2302 to server:6073
or some garbage like that. I think the dungeon siege guys just changed it.
Re:UDP packet loss (Score:3, Informative)
Some tasty articles from gamasutra (might require a login, you might also find these in Google's cache):
"TCP is evil. Don't use TCP for a game. [gamasutra.com] You would rather spend the rest of your life watching Titanic over and over in a theater full of 13 year old girls."
article [gamasutra.com] on WON's servers for Half-Life.
Dead Reckoning [gamasutra.com] Latency Hiding for Multiplayer Games.
Other software might need the benefits of TCP, but game development is one familiar illustration of where UDP often wins out.
In most cases using UDP is a loss (Score:4, Informative)
About the only reason for using UDP is if you deliberately want to circumvent the congestion avoidance protocols that are built into TCP. So, if you are playing a game, and you need the packets to get through at all costs, but you aren't sending many packets- by using UDP you can agressively defend the small amount of bandwidth you need- any TCP connections around will tend to back off and get out of your way; and that's reasonable if you code it carefully. But writing the protocol to do that is hard, you have to understand not only UDP but also TCP, as well as your game requirements.
And that's the real problem. In most cases people think that waving UDP at the problem will solve their problems- in fact it makes them worse; and TCP has solutions to problems only PhDs have even thought of, and the solutions are built in.
As an example, somebody I know implemented a tftp protocol using UDP. The guy is off the chart in his software abilities (trust me the guy is amazing, he's in the top 2 percent of software engineers according to the tests). Anyway in a back-back comparison against a standard ftp protocol- the tftp protocol loses by a factor of 10 or more (on a network with some congestion, I expect a quiescent network would have been much more level). Of course tftp isn't supposed to handle congestion. But that's the problem- UDP can't handle network congestion out of the box... indeed if anything it tends to create network congestion.
The main algorithms in tcp include 'slow start' and 'exponential backoff'. Both of these are missing in UDP, and both improve the network performance enormously. If your application doesn't affect network performance and doesn't worry about packet loss much, then UDP may be the way to go, otherwise stay away from UDP.
Interestin paper on Checksums, CRCs (Score:4, Informative)
Derek