"Obviously, the right solution would be implement a new transport protocol directly on top of IP protocol, one that would provide desired functionality — failure detection and/or multiplexing — directly, without duplicating the features.
And, as a matter of fact, the above was already done. The protocol built directly on top of IP with both heartbeating and multiplexing is called SCTP and is available out of the box in most operating systems.
And here comes the problem: SCTP is not used, even for projects where those features are needed. Instead, they are lousily re-implemented on top of TCP over and over again."
(Not necessarily saying that SCTP would be the best fit for games, more the general point -- that there's room for more than just TCP and UDP on top of IP -- and also that that might not work, due to firewalls and routers refusing to route anything that's not TCP or UDP).
It's not that SCPT is less known by developers, I think most developers actively looking for a solution to the downsides of TCP will come across SCTP.
There are two real reasons, the first and most important is that Microsoft never implemented SCTP. Apparently there was not enough customer demand, but that's a lousy excuse, I'm not sure what the real reason is. Perhaps they just have no one thinking about networked applications besides the Web at the moment. Sadly lack of forward thinking is something that bugs the Windows team a lot I feel.
The second reason can be partly blamed on Microsoft as well, but most network devices operating at the transport layer have difficulty with SCTP. Why implement it when no one uses it right? just like IPv6 support. Anyway, apparently the difficulty lies with checksumming packets, which requires some more memory than is necessary for TCP/UDP.
It's a shame really. I think you can safely say that SCTP is the perfect gaming protocol. It supports almost all features gaming networking libraries usually implement on top of UDP just by configuring your streams.
> Perhaps they just have no one thinking about networked applications besides the Web at the moment. Sadly lack of forward thinking is something that bugs the Windows team a lot I feel.
If you found out about the wide range of networking protocols and services they provide in Windows, you wouldn't feel that way. For example, P2P. A few years ago, while working on P2P applications, we discovered Microsoft has a lot of technologies in that area. Things like Teredo (IPv6 transition and NAT traversal) and a complete P2P networking API -- which gives you encryption, self-organizing overlays and DHTs out of the box -- have been around since around 2001, and have been built into Windows since Vista. They also had lower level protocols for things like link-layer topology discovery and automated device (printers, etc) configuration.
Almost all proprietary stuff, of course - except Teredo, which has an RFC and an open source implementation - but quite interesting nonetheless. We talked to the team working on this, and they claimed it was even being used by some customers in 1000+ machine deployments.
For some reason, these things are not widely marketed. Maybe because it's a niche market. However, I wouldn't say they're not forward-thinking, at least when it comes to networking.
>And here comes the problem: SCTP is not used, even for projects where those features are needed.
sctp's achilles heel is its inability to work with NAT. It was designed to not work with NAT. NAT has since become widespread especially for connecting homes and sctp ended up not being so.
There is a school of thought that details of an internal network topology should not leak out [1] (ostensibly because obscuring that has security benefits), and so NATs should be used even if each machine can have a unique IP address. Even though I worked on P2P apps and NATs were the biggest pain point, I do kinda feel the same... Leaking internal details make me squeamish even if I can think of no obvious risks. I think there is a real chance that home routers will also NAT by default even when IPv6 is common.
And you can bet corporate networks will be NATted. Not to mention data centers.
Another concern is Carrier Grade NATs. These are already being deployed within ISP networks to alleviate the IPv4 address shortage. I worry that once this infrastructure is in place, not only will it delay IPv6 adoption, but the adoption will be uneven, as ISPs with CGNs may hold off transitioning much longer. So even if there is a part of the Internet that is all IPv6, the rest of it might still be behind CGNs, and to connect arbitrary peers we'd still have to deal with NATs.
SCTP is used in WebRTC DataChannels, so it will see use in web games hopefully. However I think Chrome and Firefox implement it on top of UDP at the moment (perhaps because not all OSs support it?)
If it is using native SCTP, I don't see how well it would work with firewalls and routers (both enterprise and home ones). It would have to fallback to user-space over UDP presumably.
We should probably accept that TCP and UDP are the only "natural" L4 protocols we get, build all new protocols on top of UDP, and then just abstract the difference at the OS level, such that those tunneled-over-UDP protocols appear as native L4 transports. Then when you say "I'm using SCTP", you really mean "I'm using SCTP-over-UDP" -- but since that's the only possible meaning, it's just taken as a given.
Heck, maybe we should even reimplement TCP on top of UDP (stripping out the redundancies, so UDP carries the ports and checksum), and then just consider UDP an L3 protocol--a bit of extra stuff you get with every IP packet, whether you want it or not.
If we can figure out a way to do implicit protocol negotiation, such that we can build both clients and servers that "prefer" TCPv2-over-UDP but will drop back to plain-TCP, this could really happen, and we might get to start writing new transport protocols again. (Heck, for that matter, DTLS might finally get used.)
> due to firewalls and routers refusing to route anything that's not TCP or UDP
If "The world is on fire because we're almost out of addresses" doesn't get residential ISP's to support another protocol for home users (IPv6), somehow I doubt "We can improve the performance of online games that work reasonably well right now" will convince them to support SCTP.
http://250bpm.com/blog:22
Especially:
"Obviously, the right solution would be implement a new transport protocol directly on top of IP protocol, one that would provide desired functionality — failure detection and/or multiplexing — directly, without duplicating the features.
And, as a matter of fact, the above was already done. The protocol built directly on top of IP with both heartbeating and multiplexing is called SCTP and is available out of the box in most operating systems.
And here comes the problem: SCTP is not used, even for projects where those features are needed. Instead, they are lousily re-implemented on top of TCP over and over again."
(Not necessarily saying that SCTP would be the best fit for games, more the general point -- that there's room for more than just TCP and UDP on top of IP -- and also that that might not work, due to firewalls and routers refusing to route anything that's not TCP or UDP).