SCTP ? about gamenetworkingsockets HOT 14 CLOSED

SCTP has a few other problems. Firewalls and middleboxes like to filter or mangle traffic they don't understand. ICMP, UDP, and TCP are about the only traffic that tends to get handled mostly properly. There's also limited OS-level adoption for SCTP (e.g. no official Windows or Mac support, but there are probably third party implementations out there).

There's a good Hacker News thread about SCTP and why it didn't really gain traction:

https://news.ycombinator.com/item?id=9819363

from gamenetworkingsockets.

SCTP only provide reliable message.

In game project, commonly we use reliable message for RPC call and unreliable message for state sync.

Because state sync is more frequently and new state can replace old state.

from gamenetworkingsockets.

@bg5sbk SCTP does provide unreliable mode for messages.

from gamenetworkingsockets.

Quite frankly this seems very different from SCTP. SCTP operates on the transport layer, which brings many issues on its own. What I like here is that this is indeed overlay protocol working on application layer, combination of reliable/unreliable messages. And not only for games, we have a similar stack implemented within our software and it has been very successful so far. Looking forward to see the code! :-)

from gamenetworkingsockets.

Regarding what other stuff we looked at: We did look at Google QUIC quite a bit for this, and for a time were thinking we might be able to just use it directly, instead of rolling our own stuff. It only does reliable, so we knew we'd have to fork it. After looking at the work it would take, we didn't think it was any easier to use the code, than to just take the ideas that were applicable and re-implement them.

While we hope this library is a solid transport library for reliable and unreliable messages, we didn't really compare to any other libraries like raknet, and we're not really trying to compete with them. The main reason we want to opensource this, and the main reason we think people will want to use it, is so that that their game on Steam doesn't have to code to a different API on any other platform they are targeting.

The rudimentary reliable layer we have right now is a side effect of where our focus has been: on using our relay network to provide DoS mitigation. Now that this solution has been in place for our games for a year or so, we're trying to get broader adoption from other developers. So we're looking at the reliability layer, and we're trying to make it as easy as possible to use the Steamworks networking library directly, instead of wrapping that with yet another wrapper/interface layer. We want to make sure developers don't think there is any risk in coding directly to that API (e.g. the API exposed by this opensource project).

This project currently doesn't offer any sort of NAT piercing or STUN support. In the Steamworks version of this code, we never piece NAT, it always uses our relay network, thus hiding players IPs from each other. We think that basically, it is always bad to reveal somebody's IP.

If somebody adds STUN support we would definitely consider pulling it in. The correct approach would be to to make a new Connection class. But right now supporting NAT piercing or STUN/TURN is not a high priority for us. Let me know if you are interested in working on this, I can give you some ideas on how to fit it in with the code we have.

If there is a game on Steam that really needs that support, we would consider allowing them to either use our relay network (even for their non-Steam traffic), or allowing them to run their own relays (running our proprietary software).

from gamenetworkingsockets.

@VMatrix1900 @tycho has explained it pretty much in spades. In our case we have systems distributed across the globe and in a lot of cases their connection is a terrible/spotty 3G modem connection in the middle of nowhere. We need to be able to handle a wide variety of connection contexts while reducing overhead in order to deliver messages between nodes. We don't need a streaming protocol, we just need to propagate messages to connected nodes either reliably or not reliably depending on the context of the message.

There are loads and loads of networking libs out there, a lot of them 100% stable and great, but I'm very interested in this one purely based on the parallels between the gaming context and our context. We may not have the volume of message passing that a full-blown game has and our focus may not be to reduce game jitter/latency, but we do need to keep our overhead extremely low (which a library like this would need to keep a game fast) and have granular control over the reliability of any given message.

I'm not saying we'll adopt it the moment it drops, i'm just extremely interested in how it's been implemented, and if it trumps our code, then cherry-picking or adopting the lib could become a reality really quickly.

from gamenetworkingsockets.

@ondrasek WoW. So a transport protocol which handles both reliable and unreliable messages is useful in many kinds of application besides game, right? That is exciting. Can you give me more detail about this kind of application?

from gamenetworkingsockets.

@VMatrix1900 Well, I am not a game developer, but I guess that having a large scale system which requires user coordination of sorts is what we are looking at here, be it a game or an app.

Our product deals (among other things) with documents and printing. Let’s see an example (vastly oversimplified). Imagine you have a network of print servers where documents wait to be printed (on request). The document goes through the following states (received, printed, deleted). The state transitions are as follows (received -> printed, received -> deleted, printed -> printed, printed -> deleted). This gets complicated, when you enable users to print anything anywhere (in my world, this is called print roaming) and basically makes all the print servers being part of a single, eventually consistent distributed system: this means that a document lying on one print server can be printed by any other print server and even multiple print servers concurrently.

So the states of the document induce a join semi-lattice where the ‘deleted’ state is the supremum. The ‘deleted’ state means that the document has been deleted and is no longer available.

So when a document goes from received to printed, that is a state transition, which can be propagated using non-reliable message (we are using update protocol) because it does not matter to all the print servers, what matters is that the document is still available. But when the document goes to deleted (because the user deleted it or because it has been sitting there for too long without being touched), this has to be propagated using reliable message to prevent any print server to enable users to print documents which are no longer available.

Going back to the semi-lattice thing, the state transitions to states which are not upper bounds can be propagated using unreliable messages. States which are upper bounds (and are “terminal”) need to be handled using reliable messages as they have more significant impact on consistency. This helps to reduce overhead of the system as reliable delivery means distributed state (session, whatever you want to call it) which is always bad and we treated on a necessary evil basis ;).

from gamenetworkingsockets.

from gamenetworkingsockets.

@ondrasek @VMatrix1900 This is a similar concept to what we're dealing with but in a health/emergency context, so keeping an eye on this to see the code when it gets released. Loads of non-game applications for this kind of library.

from gamenetworkingsockets.

I agree that right not, pure SCTP is not really useable (And will probably never be).
There is an implementation of SCTP over UDP that should allow to avoid this "need to be implemented on all hops" issue : https://tools.ietf.org/html/rfc6951
I was not thinking about stopping everything and use SCTP but maybe there are thing that could be inspired from SCTP in your development as it looks like they already implement a lot of things and it's used in production in some case (In closed networks)

from gamenetworkingsockets.

@jdu @ondrasek Is there any other open source library which can handle both reliable and unreliable messages? Why don't just use UDP for unreliable message, and TCP for reliable one? After all, those are already implemented in the kernel and well-tested/tuned.

from gamenetworkingsockets.

@VMatrix1900 Some people actually do just that. TCP for reliable, UDP for unreliable.

But TCP has other weird overhead that's hard to tease apart (sliding windows and congestion control). If you have strong latency requirements as game developers do, then TCP Isn't an option unless you're completely certain of the quality of the network link between peers. And game developers can never have that level of certainty because of their diverse user base.

from gamenetworkingsockets.

Also TCP is a streaming protocol instead of a datagram protocol. This can be painful for games, as most of the network traffic is around small events rather than large data transfers.

from gamenetworkingsockets.