UDP vs TCP • Hacker News Board

Re: UDP vs TCP

#61

Post by ak217 » Thu, Dec 29, 2016, 2:59 AM UTC

lobster_johnson wrote: post #23

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…

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…

There are many protocols that use this approach, Aspera FASP is possibly the most advanced one. It uses a TCP control channel to manage the rate on the UDP data channel.

Re: UDP vs TCP

#62

Post by chii » Thu, Dec 29, 2016, 3:02 AM UTC

mikepurvis wrote: post #7

The recommendation to avoid TCP altogether is surprising to me. Having encountered a number of video-conferencing systems which are in a similar space, it seems pretty standard to have separate real-time and control sockets on UDP and TCP respectively. I skimmed the linked paper and didn't find it conclusive; can someone summarize how it is that having a TCP socket can affect UDP traffic on the same interface? All th…

the post also recommends that some http traffic is OK, but doesn't that directly contradict the advice to not mix tcp with udp (assuming that the http traffic sits on top of tcp)?

Re: UDP vs TCP

#63

Post by SomeStupidPoint » Thu, Dec 29, 2016, 3:03 AM UTC

blackflame7000 wrote: post #35

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…

What it really comes down to is file block size granularity. TCP is simply using a much finer block size (~1500 bytes) which means a higher likelihood of arriving than for a large UDP packet. Furthermore, you'd still have to implement your own checksumming algorithm to ensure data integrity as UDP doesn't require a packet checksum for IPv4. I suppose you could offload file-block integrity validation to another thread…

But bittorrent breaks the files in to chunks it can receive out of order and sends those over TCP, so TCP only preserves ordering within a chunk. It might even get chunks from several different people.

The real answer is that chunking over TCP is efficient enough that little is gained by chunking over UDP.

Re: UDP vs TCP

#64

Post by justin66 » Thu, Dec 29, 2016, 3:03 AM UTC

gregschlom wrote: post #52

justin66 wrote: post #46

Earlier quoted context omitted.

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

UDT is a better example.

http://udt.sourceforge.net/

Re: UDP vs TCP

#65

Post by morgante » Thu, Dec 29, 2016, 3:13 AM UTC

lobster_johnson wrote: post #23

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…

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…

In practice, I think you'd end up having to reimplement most of TCP on top of UDP anyways.

Re: UDP vs TCP

#66

Post by chaosphere2112 » Thu, Dec 29, 2016, 3:13 AM UTC

lobster_johnson wrote: post #23

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…

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…

On LAN, this is basically how Symantec Ghost works; it multicasts the image over UDP, and each client figures out what they missed. Those chunks get retransmitted at the end.

Re: UDP vs TCP

#67

Post by wtallis » Thu, Dec 29, 2016, 3:16 AM UTC

ra1n85 wrote: post #42

cpncrunch wrote: post #37

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.

>The reality is that these days there generally isn't any packet loss Do you have any sources/data on that? Genuinely interested where you drew that conclusion from. From my vantage point (anecdotal), ISPs and carriers routinely under-provision, congest peerings, and don't find a problem well until after a number of customers complain.

Bufferbloat means that at many potential bottlenecks, you don't get any packet loss until well after the point at which your latency-sensitive application (be it TCP or UDP) has given up hope. Major peering points are pretty much the only place where you won't see >1second queues when congested, simply because they can't afford buffers that deep for the rates they operate at. But for ordinary everyday occurrences, your congestion will be somewhere around the last mile, where you cannot expect packets to be dropped within a reasonable timeframe.

Re: UDP vs TCP

#68

Post by ajross » Thu, Dec 29, 2016, 3:18 AM UTC

kevhito wrote: post #50

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…

> ship all the chunks over with a sequential number Except that if you ship them too fast, they will at best simply build up in a buffer somewhere (e.g. near a bottleneck link), or more likely they will overflow causing many of your packets to be lost. So not only did the recipient not get them (and you have to figure this out and resend them later), but you also wasted a bunch of resources sending packets only to ha…

Exactly. The core feature provided by TCP is not reliability, that is trivially easy. What TCP gives us is robust flow control that can detect and adapt to current network capacity.

Re: UDP vs TCP

#69

Post by josephg » Thu, Dec 29, 2016, 3:19 AM UTC

Does anyone know if SCTP is suitable / in use by any games? It supports streams to work around the head-of-the-line blocking problem TCP runs into and it also supports opt-in unreliable delivery for game data. On the surface seems ideal for games, though I don't know if its getting much actual use.

Re: UDP vs TCP

#70

Post by z3t4 » Thu, Dec 29, 2016, 3:20 AM UTC

I think tcp have an unfair reputation. Our networks are better now then 30 years ago ... Worst case latency for tcp is like 3 seconds, compared to the packet never arriving. The trick is to hide the lag with animations. I think google, facebook, and world of warcraft use tcp for their real time apps !?