Because author of the article likes to be edgy and parrot the deep truth he learned yesterday - that TCP is "reliable" and UDP is not.

The reality, of course, is somewhat different and muddy. For example, if you have network outage following later by a software crash or a reboot, then all the TCP buffer worth of data (several kilobytes or upto some megabytes - depends on your tuning) is mercilessly dropped. And your application thinks that just because you used TCP the data must have been reliably delieved. To combat this you have to implement some kind of serializing and acking - but the article scoffs us that we are too dumb to implement anything besides basic stream /s

I'm not arguing that TCP is useless, just that UDP has its place and we - mere mortals - can use is too. Where appropriate.

> Because author of the article likes to be edgy and parrot the deep truth he learned yesterday

I will point out that "author of the article" is one of the core contributors in the IETF Media-over-QUIC working group (which is an effort to standardize how one might build these real-time applications over QUIC) and has been working in the real-time media protocols space for 10+ years.

The author recognizes that the title is clickbait, but the key point of the article is that you probably don't want to use raw UDP in most cases. Not that UDP is inherently bad (otherwise he wouldn't be working on improving QUIC).

The thing is, when you need that low latency, you don't want most of the features of more robust streams.

When you are using UDP the correct way to handle out of order delivery is to just ignore the older packet. It's old and consequently out of date.

Figuring out how to solve any mess caused by mistransmission necessarily has to be done at the application level because that's where the most up to date data is.

The author (disclaimer: former coworker) has likely learned about UDP before yesterday because he's been complaining about TCP for years.

You might want some form of encryption or message signing to prevent spoofed packet injection. Just because the data might not have value to a third party, knowing that the data is legitimate has value to you.

Arguments like this should have practical value for business. For my business the value is zilch. It is simply not worth it for the hacker to mess with my packet server. I've been running it for 10 years with 0 complaints. And the worst they can do is to temporarily annoy few people. And yes I implement simple proprietary form packet of signing. It took me whole few minutes to develop.

Many games are popular targets for griefers or DDOS attacks, not because the attacker gains anything of value from the attack (and many of them aren't actually hackers, they just download the tools written by others), but instead they do it solely for the perverse happiness they get from knowing that they ruined someone else's day / hour / minute.

Possibly you just haven't seen this problem yet because your game isn't high-profile enough for them to bother with and it doesn't provide enough amusement for them to get a kick out of it.

It is game like by tech used but is not really a game. Unlikely to be noticed. When IF it ever does I'll worry about it the, Not too difficult as there are libs just for that. For now my simple signing works like a charm.