Development status

[nxrighthere]

Lennart, I wonder, does this data channel implementation is mature enough for networking applications which are a few months away from production? The primary goals are reliability with low-latency/minimized head-of-line blocking, and fluent ordered/unordered delivery across multiple channels.

[lgrahl]

There may be a couple of people using it in production but I haven't gotten any negative or positive feedback, yet. I guess there's only one way to find out if it's mature enough and it also depends on a few factors:

• Do you use RAWRTC with its ICE stack? If yes, there are a couple of bugs that have been addressed already but not yet merged (such as Split the stack (and many improvements) rawrtc#109).
• Be aware of stream monopolisation when sending large messages, see Support interleaving of stream data #14. (I don't believe there are any implementations so far which don't suffer from this.) It's possible to work around it by sending large messages in chunks which needs to be done anyway if you want to talk to Chromium-based browsers.
• There is an unbounded outgoing message queue which may fill up if the receiving end is too slow. I'm open for proposals to change this.

[nxrighthere]

While I like the RAWRTC it's a bit overkill for the application that I'm working on, so I about to integrate only this data channels with SCTP, then handle stuff like connection sessions between clients and server by myself.

The messages are relatively small (on average 128-256 bytes and 1024 bytes in worst case scenario).

Thanks for the quick response. I'm going to start work on the integration. I'll come back here with results.

Cheers.

[lgrahl]

I'm going to start work on the integration. I'll come back here with results.

Sounds good. I'm looking forward to your feedback! 👍

[nxrighthere]

@lgrahl I finally finished data channels integration with a custom layer on top of SCTP into the application, and after some slight changes, everything works great! Latency and throughput are very satisfying I couldn't ask for more, thank you for your work. 😺

The code is understandable and convenient to work with (I'm also looked at Mozilla's implementation to understand how things work under the hood. If you don't mind, I'll take some parts from your implementation for my next project that aims for multiplayer games using SCTP, would love to hear your review when I finish doing this and publish a code. Cheers!

[nxrighthere]

Ah, forgot to ask one question. I saw that SCTP_PEER_ADDR_CHANGE is commented out in your code, in what circumstances this notification is triggered?

[lgrahl]

That's great news! 🎉

If you've encountered areas where you think it could use a bit of polishing, I'm open for suggestions.

If you don't mind, I'll take some parts from your implementation for my next project [...]

Sure, it's BSD-2 licensed after all.

[...] would love to hear your review when I finish doing this and publish a code.

Feel free to ping me.

I saw that SCTP_PEER_ADDR_CHANGE is commented out in your code, in what circumstances this notification is triggered?

In our case, never. This would be triggered if you had multiple IP addresses associated to an SCTP assocation (multi-homed). I guess I should remove that line. See also RFC 6458 for this and other events.