dont get me started on the lack of multicast out there. imagine game servers running multicast. one day.
The fact is that TCP was the MVP for reliable streams of data on the 1970s internet, and is woefully inadequate for modern usage, but we're stuck with it (including its oft-disabled parts like Nagle's Algorithm) because it's what's available everywhere.
Game network protocols are pretty easy in comparison with some of the protocols I've encountered in my day job, especially once you've learned the lessons of people like the author of that article.
The meaning of "custom" in this context was to distinguish it from a full TCP or raw UDP. Not to imply that there's no standard definitions for VOIP protocols. Quite the contrary in fact. The point being made is that UDP is just a substrate to create other protocols that also need to be designed for a purpose. And just calling all these protocols "UDP" is a mistake.
Btw, not to be argue from authority, but to back my words with some context, I'm responsible for at least one such "custom" protocol myself. https://packetzoom.com/blog/
Not necessarily. One of the largest live video streaming services, Twitch.tv, uses TCP for streaming.
UDP is used when low latency and low jitter is more important than complete information.
For telefony it's better to lose a few packets than to wait a second or two for a retransmit. Some for game state, I believe.
And I do believe that TCP was also designed by network engineers :-)
Rather, you'd want to use a protocol built on UDP whenever you want something faster, better, more reliable than TCP.
I don't think it's going to happen. Our current networks can't even do unicast well (eg. bufferbloat, general ISP randomness).
But I'd be keen to read the OP's rants if someone tried ...
When online gaming started, it was fairly common to send the entire world state to all clients. Multicast helps when you are sending the same data to everyone. but online gaming started, worlds were small (think Quake I level). However, this type of model does not scale as the world size increases, and eventually the world is too big to send everything to every client.
Plus, cheating. Sending the entire world state to every client, opens up cheating vectors. The trend has been for the game server to send only state that the particular client can actually see or needs. This limits the damage of what a compromised client can do. Plus, it allows the world size to scale up.
For each event, the server would find (or create) a multicast-socket channel that has only the correct subscribers, and push the message once over that multicast socket. The network would then do the job of making that message arrive on every client.
And, of course, you can separately encrypt each multicast channel[1], handing out keys over a regular 1:1 TCP+TLS "control" socket to the clients. (This would usually be merged with the client's unicast "send" socket.)
Guess what design I have just coincidentally described? Cable set-top-box pay-per-view! (The original kind, not the "over-the-top" access-on-demand kind which is effectively equivalent to Netflix.)
In legacy STB PPV, each movie stream chunk is an "event" as described above; each stream is separately encrypted; and each set-top-box gets a low-bandwidth TCP-like duplex control channel to the head office to request and receive keys for streams. People requesting the same movie at the same time get put into a queue and then bucketed on ~15min intervals; each bucket gets temporarily allocated a UHF band; and then a stream is broadcast over that band to everywhere that head-office reaches, injected on the line similarly to a local public-access cable TV channel, but only existing for two hours.
---
[1] If your clients are okay with their bandwidth being wasted, you can be a bit sloppier and get away with fewer (or even just one) multicast socket(s). Imagine a multiplayer game like Starcraft: you could push every player's update events to all players... encrypted with keys in a keybag whose owners are the people the event should be visible to. Clearing fog-of-war would literally involve the client performing an action that the server responds to by sending a key to decrypt previously-received opaque event data.
This matches the model of how, say, collaboration software treats group ACLs: being granted access to a new group means being given the key to decrypt the object-change-events within the global event stream that were relevant to that group.
Also, map-hack-style cheating will always be common because of games that take the efficient rout, sending only inputs.
Here is an example of what a custom protocol built over UDP taking in consideration the very specific use case of mobile devices accessing wireless networks, could do to achieve better throughputs than TCP, details here:
https://packetzoom.com/blog/lessons-learned-tcp-slow-start-d...
This. This "TCP already does it best in every situation" is a common trope usually spouted by people who know nothing about what TCP does and why. The easiest way to get over this misconception is to ask yourself, can you think of a protocol that not only works well over all sorts of networks, all the way from two boxes connected by a 10Gig switch (with 10us ping latency) vs two hosts talking to each other via a satellite link (with perhaps, 2 second ping latency) but is the best option across all those situations?
The truth is that TCP is the common denominator that's available in pretty much every device you would want to use. But in almost every individual use case, you could come up with a far better protocol if you took the time and effort to treat the problem seriously.