[xir78]

Would be great for TCP to better address the reliable transmission of messages for games, these “reliable UDP” code bases in game engines don’t address all of the other issues such as bandwidth sharing fairness and avoiding saturation of networking links, which ultimately will just make networks slower than faster and more reliable for everyone.

[kabdib]

If you changed TCP sufficiently to make it a real-time protocol suitable for gaming, it wouldn't be TCP any more. Reliable streaming and real-time packet delivery are two completely different animals.

I would argue that bandwidth-sharing fairness with stuff going over UDP is easy: Just start dropping packets when pipes get full.

Most updates are going to be pretty small. It's not like game developers want the user experience of their titles to be bad, after all.

[xir78]

It’s not easy to share the bandwidth fairly, it’s taken decades of research and it continues to be improved in TCP.

You’re not consindering a server, the bandwidth is very high on the backend and does saturate links. You run many servers per physical or virtual machine due to cost, so you can have 1000s if players connected over a single network path.

[kabdib]

... which is why you provision servers and design your software and network architecture to take the demand (latency, bandwidth, etc.) into account. Data rates for online games are pretty predictable. A 10 Gbit fiber connection to a racked server doesn't cost that much.

At the datacenter level you're making sure that the bandwidth you bought from providers is sufficient (and ideally, redundant), and that you can shift load from one area to another if necessary. You can buy this capability from AWS or Azure, or build it yourself in many different ways.

[camgunz]

The penalties in TCP for dropped packets are too great, and there's essentially nothing anyone can do about it. I'm editorializing a little, but to me it's always felt like TCP's main goal was "be a good Internet citizen" to the detriment of basically everything else.

In fairness that was probably a crucial component of the Internet's success, but you don't get the good w/o the bad.

But re: "this will result in bandwidth hogging", routers will just drop your packets if you oversaturate them, so that's not a worry in practice. Well, it is for developers but they use rate scaling algorithms in those cases.

[twic]

That's an interesting perspective. My personal folk mythology of TCP is that once upon a time, there were terminals connected to mainframes by serial lines, then someone wanted to connect to a mainframe from their minicomputer, so invented a remote login program, which sort of emulated a serial line over the network, then when the ARPAnet came about, someone invented TCP to do remote logins over that. Then, because TCP existed and worked well, people invented millions of other application protocols that worked on TCP's emulated serial line, and got into the habit of thinking about protocols as things which work on emulated serial lines, and so there has never been much demand for anything else.

[camgunz]

Hah yeah I can see that. I mean, don't mess w/ success right?

[jsnell]

This code implements RFC 5348-style TCP friendly rate limiting [0]. Is your concern about the implementation being wrong, or about the algorithm in 5348 somehow being insufficiently fair?

[0] https://tools.ietf.org/html/rfc5348