Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UDP vs TCP

gafferongames.com

Post reply on HN
Print view View original

151–160 of 198 posts

Re: UDP vs TCP

#151

Post by nrjdhsbsid »

Dylan16807 wrote: post #101
nrjdhsbsid wrote: post #99

Earlier quoted context omitted.

You're right in that UDP will let you send the most updated data without requiring everything to be sent. My main issue was that UDP does not give you lower latency. TCP algorithms are extremely aggressive to the point I doubt you could get more recent packets on the wire with UDP. The problem is, the OS throws everything into the same buffer, and unless you're clairvoyant you won't be able to skip sending old packet…

You're only considering the case when no packets are lost. Once TCP drops a packet, data sits in the receiving buffer getting older and older instead of being delivered to the program.

It's way more rediculous than you think. OS network stacks try to do the reasonable thing in most cases if possible. In the case of Linux TCP Vegas is very unlikely to drop any packet since the main algorithm is RTT based not drop.

Red and hopefully codel can combat buffer bloat to some point but in the end all packets go to the same place

Re: UDP vs TCP

#152

Post by the_mitsuhiko »

Negitivefrags wrote: post #137
mjevans wrote: post #6

The main difference between TCP and UDP, as this programmer discovered, relates to quality of realtime service. Times to use UDP over TCP * When you need the lowest latency * When LATE data is worse than GAPS (loss of) in data. * When you want to implement your own form of error correction to handle late/missing/mangled data. TCP is best when * You need all of the data to arrive, period. * You want to automatically m…

People talk like most games use UDP, but they don't. Pretty much the only genre that does is First Person Shooters. MMOs (like world or warcraft) MOBAs (like Dota) RTSs (like Starcraft) Action RPGs (like Diablo) All of these are action games and use TCP. In most genres people would rather have the simulation pause when there is packet loss, and then run fast to catch up rather than have unreliable data about player l…

> MMOs (like world or warcraft) MOBAs (like Dota) RTSs (like Starcraft) Action RPGs (like Diablo)

Dota 2 definitely does not use TCP. The Starcraft games I assume can also work with TCP but I doubt that they use it as a primary choice of communication. I would love a source for this.

Re: UDP vs TCP

#153

Post by the_mitsuhiko »

nrjdhsbsid wrote: post #99
banachtarski wrote: post #94

Earlier quoted context omitted.

I'm not sure I follow your argument. Say I want to communicate from player A the position of player A to player B. The position is really only relevant for a 200 ms time frame or so (the game might support teleports, jumping, dashing, etc). In a TCP setting, even if a packet is old (>200ms), I have no choice but to send it regardless, and all new packets must queue behind it. The whole point behind using UDP for game…

You're right in that UDP will let you send the most updated data without requiring everything to be sent. My main issue was that UDP does not give you lower latency. TCP algorithms are extremely aggressive to the point I doubt you could get more recent packets on the wire with UDP. The problem is, the OS throws everything into the same buffer, and unless you're clairvoyant you won't be able to skip sending old packet…

TCP does head of line blocking so your entire argument is just wrong. TCP by design cannot give you the latency guarantees that UDP can.

Re: UDP vs TCP

#154

Post by the_mitsuhiko »

user5994461 wrote: post #127
Dylan16807 wrote: post #116

Earlier quoted context omitted.

If you don't check for returns, TCP isn't going to help either. The requirements you listed don't make sense as written. Nobody would ever use UDP.

TCP establishes a connection when it starts and it has build-in timeouts (and various mechanisms) to detect dead connections. TCP will signal to the application if the destination is unavailable or lost. The requirements make sense and the common usages for UDP fit these requirements. It's correct that [almost] nobody ever uses UDP. It's a niche protocol for a very few specific use cases, one of which is real-time FP…

TCP by itself does not detect dead connections.

Re: UDP vs TCP

#155

Post by coffeeaddicted »

rstuart4133 wrote: post #102

The entire article makes me shudder in disbelief. It's aimed at people who don't know the difference between UDP and TCP (and possibly wet string). Yet he recommends they implement their own reliably protocol over UDP, and they avoid TCP because it's better to implement your own QoS? Why not add obtaining PhD in quantum mechanics just to round it out? It wouldn't alter the odds of pulling it off overly.

You don't have to invent a protocol when using UDP, you can still use a library like enet or raknet which already do that for you. And if it's the better choice it's the better choice and it's not something a programmer can't learn to do.

Re: UDP vs TCP

#156

Post by zurn »

nrjdhsbsid wrote: post #151
Dylan16807 wrote: post #101

Earlier quoted context omitted.

You're only considering the case when no packets are lost. Once TCP drops a packet, data sits in the receiving buffer getting older and older instead of being delivered to the program.

It's way more rediculous than you think. OS network stacks try to do the reasonable thing in most cases if possible. In the case of Linux TCP Vegas is very unlikely to drop any packet since the main algorithm is RTT based not drop. Red and hopefully codel can combat buffer bloat to some point but in the end all packets go to the same place

I think he meant the situation where the network drops a TCP segment, leading to head-of-line blocking.

Re: UDP vs TCP

#157

Post by ozy »

"TCP has an option you can set that fixes this behavior called TCP_NODELAY"

That fixes nothing. Now you are sending too many small packets using too many syscalls. Just like UDP, buffer in user space, send in one go. If you do that, TCP_NODELAY makes no difference. (The exception is user input, if you want to send those as they happen, use TCP_NODELAY, but think about the why ... it has little to do with what this article is talking about.)

Games likely send data only around 25 times per second, and ping is likely The problem starts when the connection stalls for more than 100ms, especially in high bandwidth games. During the stall both behave the same. After the stall, TCP will be playing catchup and wasting more time receiving outdated data, and handing it to user space in order. UDP just passes on what is received, with a lot less catching up, and maybe some dropping of packets.

But gameplay has been degraded in both cases. UDP just has a higher chance of masking and shortening degradation more.

Anything more than that is basically cargo-culting, like this article.

Re: UDP vs TCP

#158

Post by luuse »

the_mitsuhiko wrote: post #152
Negitivefrags wrote: post #137

Earlier quoted context omitted.

People talk like most games use UDP, but they don't. Pretty much the only genre that does is First Person Shooters. MMOs (like world or warcraft) MOBAs (like Dota) RTSs (like Starcraft) Action RPGs (like Diablo) All of these are action games and use TCP. In most genres people would rather have the simulation pause when there is packet loss, and then run fast to catch up rather than have unreliable data about player l…

> MMOs (like world or warcraft) MOBAs (like Dota) RTSs (like Starcraft) Action RPGs (like Diablo) Dota 2 definitely does not use TCP. The Starcraft games I assume can also work with TCP but I doubt that they use it as a primary choice of communication. I would love a source for this.

Starcraft uses a mix of TCP and UDP[1]. I can't find the link now but I remember something about a late switch from TCP to UDP in the beta of the first StarCraft 2 game and some pretty unstable network gameplay while they were tweaking the error handling.

1. https://us.battle.net/support/en/article/300479

Re: UDP vs TCP

#159

Post by barrkel »

nrjdhsbsid wrote: post #151
Dylan16807 wrote: post #101

Earlier quoted context omitted.

You're only considering the case when no packets are lost. Once TCP drops a packet, data sits in the receiving buffer getting older and older instead of being delivered to the program.

It's way more rediculous than you think. OS network stacks try to do the reasonable thing in most cases if possible. In the case of Linux TCP Vegas is very unlikely to drop any packet since the main algorithm is RTT based not drop. Red and hopefully codel can combat buffer bloat to some point but in the end all packets go to the same place

I see packet loss and spurious resends (lost acks) all the time on WiFi in certain locales. You are massively underplaying packet loss imo.

Re: UDP vs TCP

#160

Post by drawkbox »

Negitivefrags wrote: post #137
mjevans wrote: post #6

The main difference between TCP and UDP, as this programmer discovered, relates to quality of realtime service. Times to use UDP over TCP * When you need the lowest latency * When LATE data is worse than GAPS (loss of) in data. * When you want to implement your own form of error correction to handle late/missing/mangled data. TCP is best when * You need all of the data to arrive, period. * You want to automatically m…

People talk like most games use UDP, but they don't. Pretty much the only genre that does is First Person Shooters. MMOs (like world or warcraft) MOBAs (like Dota) RTSs (like Starcraft) Action RPGs (like Diablo) All of these are action games and use TCP. In most genres people would rather have the simulation pause when there is packet loss, and then run fast to catch up rather than have unreliable data about player l…

True but you can create a reliable UDP implementation and get the same TCP features you need (resending/ordering/ACK). Many games use UDP and then some form of reliable UDP where important messages are ACK'd (game start, game end, global events etc).[1] Almost every multiplayer game I have worked on has a flavor of this, where there is a bit or flag on important messages that need reliable tracking over UDP. Everything else is just broadcast like player positions, local action and more where packets can be missed and extrapolated/interpolated, predictive methods and lag compensation.

There can also be some packet loss increase when using TCP mixed with UDP[2]. Most games built recently probably use more RUDP than TCP. But when you need to use any UDP at all you may as well just go reliable UDP. TCP definitely works for non-realtime games and turn based especially but if you ever want some non essential systems updating where packet loss is ok (maybe world physics, or events that are just decorative/fun) then reliable UDP is best in my opinion.

SCTP was supposed to fix much of this but really reliable UDP does almost everything you need for realtime and not, so if investing in a network lib/tech that is the best choice.

enet[3] is a popular reliable UDP framework that was the base or basis for many others. RakNet[4] also has some nice implementations of it. There are many others now but some larger common systems based their systems on these, Unity is one.

[1] https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protoco...

Characteristics of UDP Packet Loss: Effect of TCP Traffic

[2] http://www.isoc.org/INET97/proceedings/F3/F3_1.HTM

[3] http://enet.bespin.org/

[4] https://github.com/OculusVR/RakNet

Post reply on HN