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

51–60 of 198 posts

Re: UDP vs TCP

#51

Post by mullen »

scurvy wrote: post #44
lobster_johnson wrote: post #23

Earlier quoted context omitted.

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…

NFS on Linux defaulted to UDP for what seems like a really long time. There were perf issues with TCP (can't remember what they were).

NFS used to default to UDP for the same reasons that games still would use UDP, it just needed the data as quickly as possible since it was blocking IO. Now a days, we don't need UDP for NFS because networks are a lot faster and the advantages of TCP start to over rule UDP.

Re: UDP vs TCP

#52

Post by gregschlom »

justin66 wrote: post #46
lobster_johnson wrote: post #23

Earlier quoted context omitted.

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…

> I always wondered why nobody used UDP for bulk data transfer That would be odd. It's not true. There's TFTP all the way up to UDT.

Although to be fair, given that with TFTP each packet must be acknowledged before the next one is sent, you're actually achieving a way worse throughput than TCP. Not a very good example on how to use UDP efficiently IMO.

Re: UDP vs TCP

#53

Post by wtallis »

blackflame7000 wrote: post #39
wtallis wrote: post #29

Earlier quoted context omitted.

That's not an explanation. That's just pointing in the general direction of where to look for an explanation.

Do you have a better explanation to offer because I'd love to learn? Not sure why I deserve a downvote for offering a potential solution when you with 6000 karma offer nothing.

I think the claim was far too broad to actually be entirely true, and the evidence was both narrow and weak.

The 1997 paper only shows that certain simulation parameters can produce bad packet loss for UDP traffic. But those parameters are almost all irrelevant to today's Internet: MTU is now 1500B not 512B, TCP congestion control is usually something like CUBIC rather than RENO, buffers are never a mere 16 packets long, and TCP traffic is more often relatively short-lived HTTP connections, not long-running FTP.

The paper is just another piece of evidence that TCP synchronization sucks. You are very unlikely to encounter such perfect TCP synchronization on today's Internet, and even if you did, the dynamics of introducing some UDP flows to that situation would be different.

Re: UDP vs TCP

#54

Post by wtallis »

macintux wrote: post #48
wtallis wrote: post #28

Earlier quoted context omitted.

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?)

DNS strikes me as something relatively painless to deprioritize. Small packets, not all that latency-sensitive for most use cases.

DNS isn't VoIP, but most DNS traffic is very much latency sensitive. When you click a link to a typical modern web page, you trigger multiple HTTP connections to load the page and its many resources hosted on dozens of domains. The DNS lookups are on the critical path for all of those requests.

Re: UDP vs TCP

#55

Post by tedunangst »

scurvy wrote: post #44
lobster_johnson wrote: post #23

Earlier quoted context omitted.

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…

NFS on Linux defaulted to UDP for what seems like a really long time. There were perf issues with TCP (can't remember what they were).

NFS (was) stateless and idempotent. Lose a packet? Send it again! Which is mostly what you want, since there can be dozens of processes performing IO and they're all independent. Last thing you want is head of line blocking.

Re: UDP vs TCP

#56

Post by macintux »

wtallis wrote: post #54
macintux wrote: post #48

Earlier quoted context omitted.

DNS strikes me as something relatively painless to deprioritize. Small packets, not all that latency-sensitive for most use cases.

DNS isn't VoIP, but most DNS traffic is very much latency sensitive. When you click a link to a typical modern web page, you trigger multiple HTTP connections to load the page and its many resources hosted on dozens of domains. The DNS lookups are on the critical path for all of those requests.

Yes, but the HTTP requests themselves dominate the overall load time, even if DNS takes a bit longer. Plus there's caching to reduce somewhat the need for the DNS requests.

(Of course, I'm pulling all of this out of my nether regions without a lot of thought, and you may well be right, the sheer volume of such requests might lead to problems.)

Re: UDP vs TCP

#58

Post by wtallis »

macintux wrote: post #56
wtallis wrote: post #54

Earlier quoted context omitted.

DNS isn't VoIP, but most DNS traffic is very much latency sensitive. When you click a link to a typical modern web page, you trigger multiple HTTP connections to load the page and its many resources hosted on dozens of domains. The DNS lookups are on the critical path for all of those requests.

Yes, but the HTTP requests themselves dominate the overall load time, even if DNS takes a bit longer. Plus there's caching to reduce somewhat the need for the DNS requests. (Of course, I'm pulling all of this out of my nether regions without a lot of thought, and you may well be right, the sheer volume of such requests might lead to problems.)

It looks like on Windows a typical DNS retry timout is 1 second, with backoff if multiple retries are needed. If a DNS packet needed for loading a web page gets dropped, it's very likely to increase the overall page loading time. Re-ordering DNS to be delivered only when there's a lull in the large TCP packets would almost serialize the loading of resources from different domains.

DNS caching is a good thing, but it certainly doesn't eliminate this problem. Web browsing still produces a lot of DNS requests, and any cache upstream of the bottleneck (ie. any cache operated by your ISP rather than in your own router) doesn't help against loss during congestion.

Re: UDP vs TCP

#59

Post by goodells »

sydd wrote: post #32

Ah I love Glen's articles. Ive learned so much from them: game physics, integrators, game loops, game networking,..

Yes! His writeups on networked physics were extremely lucid and easy to follow. The way that he focuses on minimizing the bandwidth with bitpacking and goes from something absurdly large to equally absurdly small was a mesmerizing read for me as a programmer just getting started because of an interest in games.
Post reply on HN