UDP isn't unreliable, it's a convertible (2024)

I disagree. Raw UDP is about as useful as raw TCP if your application matches the protocol's features and weaknesses. Plenty of protocols work by spamming packets around the network where it doesn't matter if half of them go missing or arrive out of order.

TCP is also barely enough to be a real "protocol". It does a bunch of useful stuff but in the end raw text is pretty useless as a protocol. That's why everything from IRC to HTTP has its own protocol on top.

SCTP is a bit of a weird outlier to be placed at the level of TCP and UDP, but there's no need to go all QUIC and reinvent TCP if you want to use UDP. DNS, NTP, and plenty of other protocols don't need to rebuild reliability and streams to be useful.

I agree with you about the category error.

In all fairness, though, there are quite a few application protocols which are built directly on top of UDP with no explicit intermediate transport layer. DNS, RTP, and even sometimes SIP come immediately to mind.

There are legit use-cases for "fire-and-forget"-protocol. E.g. anything that is more about "hey, here is a new value, just like the past 100.000 I sent within the last second" than about "here is a critical command where it would really suck if we didn't know about it not arrive at its target system.

Not caring about whether every single transmission arrives is a totally legitimate technological choice and it can have some tangible benefits when it comes to throughput, latency etc.

As with every piece of technology UDP gets problematic when you are ignorant towards its limitations and misapply it.

I always use the mail analogy when talking about unreliable packet delivery with non-technical people. People seem to grok it very quickly.

(It makes spoofing and amplification attacks easy to communicate, too.)

It's written by someone trying to sell specialized cloud services targeted towards UDP based protocols.

Talking up UDP like it's something special is part of the business strategy.

And, to be fair, a lot of TCP-based or even HTTP-based application protocols could probably have been UDP without any trouble.

Even the title uses one of ChatGPT's signature lines "It's not X, it's Y."

It's deep in the uncanny valley. Even ignoring the writing style, the entire post is about the incredible insight of "you can build TCP on top of UDP" using a forced analogy. No further analysis, no real world example, just UDP and the convertible and the convertible and UDP...

I felt the same way, which is terrible news for me because I explicitly use double dashes in my (100% human) writing instead of em/en dashes -- explicitly because of the LLM association, but they're evolving

https://www.pangram.com/history/f119a8ee-7e60-442a-8d0c-3fa0...

I show this more of as a discussion point than as a definitive answer. There is more research on this tool than others: https://www.nature.com/articles/d41586-025-02936-6

And I think it's interesting that it flags it as confidently AI generated. I also got a whiff of AI and I'm never sure how to take confirmation bias from AI detectors - though that said, I've gotten a whiff of AI before and had this detector say it's confidently human.

Reading this I kept waiting for the... point? I feel like the whole thing was more like saying "UDP is like a convertible because you can strap a tarp on top when it rains". Like... sure? But that tarp is going to be crappy compared to a real roof. And the idea that that tiny layer is "the best of both worlds" is frankly ridiculous to me.

If you want your packages delivered in order, without duplication, whenever it is not impossible to get them to you -- don't use a fulfillment company that might send you multiple boxes, or get them out of order, or not deliver them at all, and is really no cheaper anyway.

I never really understood this complaint. UDP adds such a tiny and useful header on top of IP that it hardly seems meaningful to reinvent the wheel instead of just using it.

The point of the article is that calling a protocol reliable doesn't make sense. You can (and should) use UDP if you don't care about (or you have a special way of handling) packet loss, and instead need to receive the latest packet as soon as possible. In the context of multiplayer FPS games and remote controlling drones -- it is actually more reliable.

> A colleague is working on a kernel patch to bypass part of the UDP stack to restore proper ordering, which will probably need to be maintained in-house or at least hidden behind a kernel config knob upstream since this reordering is considered acceptable under the guarantees for UDP.

My understanding is that in Linux, TCP on localhost (including packets sent to a public address on a local interface) bypasses the stack; I don't see why it would be a problem for UDP to do the same.

This is contrast with FreeBSD, where TCP to localhost is actually packetized and queued on the loopback interface, and you can experience congestion collapse on loopback if you do things right(wrong).

Some of these things turn out to be death penalty depending on the kind of app you're doing, and it can be quite surprising when it happens too. For example, redelivery with ordering with bad internet can lead to unbounded backup.

UDP has a checksum for a reason, bitflips happen and packets get mandled or lost, even if you control both sides of the link.

Your chances are better but you can't assume packet loss or data errors can't happen just because the fiber is right in front of you.

I would argue with "only". Full queues are only one reason you get packet drops. For example, packets can be damaged in transmission. This isn't common but that's not the same as saying it doesn't happen.

Okay, but the important part of a protocol is what happens when things don't go perfectly to plan.