Live data from Hacker News

UDP vs TCP

gafferongames.com

101–110 of 198 posts

Re: UDP vs TCP

#101

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…

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.

Re: UDP vs TCP

#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.

Re: UDP vs TCP

#103
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…

Damn. I disagree with all of your points.

Use UDP only if you satisfy all the following conditions:

  * Don't care about loosing data
  * Don't care about receiving data out of order
  * Not sending stream of data but individual messages ( 

Re: UDP vs TCP

#104
post #28

Earlier quoted context omitted.

You'd be shocked at the things home routers do. There's a reason most people don't try to implement NAT traversal and use common middleware. Since UDP isn't as common of a protocol I can certainly see some routers treating it a second class traffic when it comes to packet shaping.

I'm well aware of how dumb home routers can be, but a general de-prioritizing of the transport protocol that DNS uses is both really dumb and pretty easy to detect. Are you aware of any router vendors that have actually shipped such a configuration? (Or for that matter, any consumer router that has shipped with any prioritization rules enabled out of the box?)

Every home network I've seen ends up using the home router itself as a forwarding DNS server as configured through DHCP.

That said, I doubt home routers are de-pritoritising UDP to any extent, or it would be a big topic of discussion among gamers.

Re: UDP vs TCP

#105
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…

I always wondered why nobody used UDP for bulk data transfer: Ship all the chunks over with a sequential number identifying each, then when you've reached the end, have the client request any lost packets, then repeat the cycle until all are transferred. After all, the client doesn't need everything in sequential order if it knows the size, and it can deal with holes as long as they're eventually repaired. This gives…

[deleted]

Re: UDP vs TCP

#106

The reality is that these days there generally isn't any packet loss, so UDP vs TCP isn't such an issue as it might have been in the past. In fact TCP has a number of advantages these days such as easier firewall traversal, WebSockets, etc.

On the loopback port, sure.

I work on protocols that use sketchy wifi on mobile units that roam among access points. Sometimes they roam into RF black holes. TCP is all kinds b0rk3d for what I am doing.

Re: UDP vs TCP

#107
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…

Damn. I disagree with all of your points. Use UDP only if you satisfy all the following conditions: * Don't care about loosing data * Don't care about receiving data out of order * Not sending stream of data but individual messages (

UDP doesn't cause things like not knowing if the other end is gone. You're being kind of ridiculous.

Re: UDP vs TCP

#108
post #15

Earlier quoted context omitted.

> (and routers give TCP priority). What routers? Is this something that stupid routers did in the '90s and people are still worried about, or are modern routers actually behaving this way? (And if so, why?) TCP retransmission interfering with UDP sounds like something that shouldn't be a problem on any sane network, especially if the application authors are smart and use something like LEDBAT for their TCP traffic wh…

The internet is generally built on the implicit contract of "TCP-friendly flow control". If your homegrown protocol backs off slower than TCP, some router configurations will drop your packets first. There is no general policy against non-TCP packets of course, as lots of important internet services are non-TCP. Just flows that don't respond to congestion. It's not a vendor specific thing, all the major router vendor…

> If your homegrown protocol backs off slower than TCP, some router configurations will drop your packets first.

I think that's only if you're being less responsive to congestion signals (drops, ECN marks), and you're using more than a fair share of bandwidth or trying to use any available bandwidth. Fixed but low rate flows (eg. VoIP) shouldn't be penalized until the link is congested with so many flows that the VoIP is trying to use more than 1/N of the bandwidth.

Re: UDP vs TCP

#109
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…

This isn't really true, or at least not the main reasons to choose UDP or TCP . In modern days UDP is really only used in situations where you can afford packet loss and CPU is expensive, or when you need to bypass the built-in behavior of TCP on your OS. It's not as much about latency or data loss, usually UDP is used in places where processing power is expensive or load is too extreme to justify TCP. Sometimes, lik…

I'm getting the impression that you're mostly only taking the endpoints into account. There's tons of stuff happening in between the peers: having worked on specialty routing equipment, I can add that the prevailing philosophy was that generic UDP packets were lower quality-of-service than TCP. That is, if the router was under high load, UDP would be dropped before TCP.
Post reply on HN