Do you want to hear a joke about UDP? You might not get it, but I don't really care.
Do you a hear joke UDP? about
UDP vs TCP
41–50 of 198 posts
Re: UDP vs TCP
#42The 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.
Re: UDP vs TCP
#43That's a pretty obnoxious 'donate' button. They can't make it even larger?
Re: UDP vs TCP
#44The 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…
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).
Re: UDP vs TCP
#45Earlier quoted context omitted.
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.
If you do the obvious work to convert UDP to a reliable streaming mechanism, you will generally more-or-less reinvent TCP, only probably more poorly, and would probably be better off just using TCP. UDP is a good choice when you have options or requirements that TCP can't accommodate. For instance, the classic case of streaming audio has both; it both requires timely delivery and has some very sophisticated techniques for dealing with missing packets with a lot of local intelligence about human perception and such built into the codecs. If you can drop packets without issue, if future packets completely supercede past packets (FPS network gaming for instance), there's a lot of possibilities, but if you're just going to recreate reliable streaming you probably be net losing on account of the effort spent doing that instead of something useful, and bugs in the implementation.
Re: UDP vs TCP
#46The 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…
> 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.
Re: UDP vs TCP
#47> 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?
It's very common for netflow data to be mirrored and multiplexed. Syslog, too.
Re: UDP vs TCP
#48Earlier 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?)
DNS strikes me as something relatively painless to deprioritize. Small packets, not all that latency-sensitive for most use cases.
Re: UDP vs TCP
#49The 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.
I'm....skeptical.
Re: UDP vs TCP
#50The 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…
> 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 have them dropped.
And if you send them too slow, you are leaving some potential capacity on the table. So you need to send them fast, but not too fast.
So you add some additional logic to implement flow control and congestion control. And that's TCP, pretty much.