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

31–40 of 198 posts

Re: UDP vs TCP

#31

Post by acomjean »

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…

UDP messages are limited to 64K. It can be a pain to reassemble. lots of ugly corner cases.

We had need to send one type of message split due to size with udp. We were on the same subnet sending and receiving so it worked almost always. We were also using multicast.

Its very very hard to figure out whats going on when things don't work ( You don't know if the control messages are getting through, when you ask again or if the message just isn't being sent). At some point you are reinventing tcp/ip.

I always liked the way udp messages are received though, all or nothing. Not the byte stream that is tcp which needs to be broken into messages manually.

Re: UDP vs TCP

#32

Post by sydd »

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

Re: UDP vs TCP

#33

Post by other_herbert »

sytelus wrote: post #27
milansuk wrote: post #12

> they may arrive out of order, be duplicated, or not arrive at all! This is first time what I read that datagram can be duplicated. Is it true? It's duplicated by network or does it mean that peer send it again?

A classic example is FPV video from drone. There may be reflections in surroundings and you may get packets multiple times!

Right or a problem in something that could retransmit your packet again.. I did that in my office in the early 00s and took down a 100mbps lan from a few boxes retransmitting packets that weren't meant for them

Re: UDP vs TCP

#34

Post by ra1n85 »

noway421 wrote: post #13
milansuk wrote: post #12

> they may arrive out of order, be duplicated, or not arrive at all! This is first time what I read that datagram can be duplicated. Is it true? It's duplicated by network or does it mean that peer send it again?

Packets can be duplicated by faulty routers and loops in the topology. Happens all the time to me when I'm lost with iptables.

Observed this recently with a bug in Cisco's VSS. Some packets were being duplicated, which destroyed TCP throughput.

Re: UDP vs TCP

#35

Post by blackflame7000 »

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…

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 so you can receive and verify in parallel, but at some point you have to checksum every block anyways which means the full file must be processed to figure out where corruption might be before sending retry requests for the missing packets.

I see what you're getting at by trying to avoid processing the packets in order if it wastes time, but ultimately I think its a micro-op that introduces other bottlenecks. That's why bit-torrent still typically uses TCP even though they could potentially receive file parts in any order.

Re: UDP vs TCP

#36

Post by ra1n85 »

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…

Bad for everyone else, and it's up to the implementation to handle flow-control. Congestion-control handles network related loss/latency/load. Flow-control helps with receiver related loss/latency/load.

Re: UDP vs TCP

#37

Post by cpncrunch »

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.

Re: UDP vs TCP

#38

Post by placebo »

exDM69 wrote: post #8
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…

Another article on this site addresses TCP plus UDP mix. The tl;dr is that they should not be used at the same time because TCP retransmission will interfere with UDP (and routers give TCP priority). As long as TCP happens outside of the "hot" loop, it's fine.

There are quite a few "reliable UDP" implementations out there - I wonder if the same considerations would hold. Guess it might depend on the implementation of reliability using UDP.

Re: UDP vs TCP

#39

Post by blackflame7000 »

wtallis wrote: post #29
blackflame7000 wrote: post #22

Earlier quoted context omitted.

I too was wondering how TCP and UDP can affect one another on the same interface and the explanation I read is that at the lowest level both UDP and TCP segment data into packets and place them onto the same network adapter's queue which can affect they way they are transmitted under congestion depending on the device/drivers.

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.

Re: UDP vs TCP

#40

Post by lobster_johnson »

acomjean wrote: post #31
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…

UDP messages are limited to 64K. It can be a pain to reassemble. lots of ugly corner cases. We had need to send one type of message split due to size with udp. We were on the same subnet sending and receiving so it worked almost always. We were also using multicast. Its very very hard to figure out whats going on when things don't work ( You don't know if the control messages are getting through, when you ask again o…

Picking a smallish, fixed chunk size should work, and it could even be made to self-regulate. Reassembly is trivial -- allocate the file first, write chunks to their right location. And for the control stuff (i.e. requesting chunks) you just use a TCP connection. UDP for the data only.
Post reply on HN