Consider supporting userland SCTP-stack (libusrsctp)

[qrlpx]

As noted in sctp-sys's Readme, support of SCTP is across the board quite spotty.
Linux & BSD-distros take their sweet time to support the newest SCTP-features and on Windows, SctpDrv is also supposed to be quite wonky, I hear?

libusrsctp is feature complete, supports all major OS and is used by both Firefox and Chromium.

It might be a good idea to allow the users of rust-sctp to choose between which stack/implementation to use.
This might entail:

• Create a usrsctp-sys crate, maybe provide a module with wrapper-fns to act as drop-in replacement for sctp-sys.
• Add the necessary cfg-attribs and features to rust-sctp.
• Maybe add a bunch of config-dependent freestanding functions to rust-sctp (usrsctp_[init|finish] and usrsctp_sysctl_[set|get]).

[phsym]

I haven't heard about usrsctp. It sounds really interresting.
I'll start exploring this very quickly. Thanks for your suggestion.

What is the stability of usrsctp if you know ? I see that it has not reached 1.0 yet !

Also, would it not worth it to drop linux kernel sctp support and only keep usrsctp, even if I like the idea to let the users choose the underlying implementation to use? Probably there is some different performances between kernel and user space implementations ?

SctpDrv is absolutely unstable, and I only succeeded in getting blue screens in Windows 7. I'll probably remove SctpDrv from sctp-sys in favor to usrsctp.

[qrlpx]

I've just looked into it again and the sight in the land of SCTP is quite a grim one:

• Windows and MacOS don't support it at all.
• Linux supports some of it but is missing vital features (1 2 3)... and I daresay, if you want to develop for anything other than the intranet, SCTP without udp-encapsulation is fairly useless.
• FreeBSD is just using usrsctp again.
• OpenBSD and NetBSD don't support it.

What is the stability of usrsctp if you know ? I see that it has not reached 1.0 yet !

I've took a diff of usrsctp.h* from three years ago (r8000) and the current master: https://gist.github.com/qrlpx/dcda562f20e5cef47268
So yea looks fairly stable. I doubt it'll ever formally reach 1.0.

Probably there is some different performances between kernel and user space implementations ?

I'm no expert in this, but I doubt it. I thought more of: 1. make use of system configurations; 2. don't bundle more than you need. But considering the above points, that'd actually only be the case for FreeBSD.

So, summarizing: It seems like it would only make sense to make use of the systems implementation if:

1. You're using Linux and only require the basics of the basics.
2. You're using FreeBSD (and who does that anyways?).

So yea,

Also, would it not worth it to drop linux kernel sctp support and only keep usrsctp, [...]

seems like a reasonable decision. Albeit I would keep the sctp-sys crate just for the sake of it.

*edit: forgot to mention what I took the diff of.

[phsym]

Just to give a update, I've been playing a bit with libusrsctp and made a draft rust binding to it. It was working on linux (but need sctp to be disabled in kernel), but I never succeeded in making it work in windows.
I should try again later but I miss time for now.
I can share with you my draft code if you want to give it a try

[iqualfragile]

i, too think that libusrsctp is the way to go, even dropping the native/kernel support is not a big price.
for the next ~10 years nobody will actually be able to use sctp directly on top of ip due to strange nat boxes, so udp encapsulation is needed.

[jeregrine]

@phsym would it be possible to share your branch of libusrsctp? Thanks!

[iqualfragile]

@phsym any updates?

[phsym]

@iqualfragile Nope sorry

[iqualfragile]

you said you had some draft code, can you share that so people can build on top of it?