If usrsctp thread safe?

[ibc]

In other words: I've a multi-thread app which runs N threads (each one running a libuv events loop for UDP/TCP etc), and I want to add usrsctp on top of it.

Can I safely call usrsctp_init() on the main thread (which runs before all the others are created) and use this lib within the other threads?

To be clear: each thread manages its own UDP/TCP connections.

Thanks a lot.

[tuexen]

Yes. The stack runs already several threads for receiving packets, running timers, and so on.

[ibc]

Thanks. Anyhow I see a potential problem:

I need to use AF_CONN (my server is a WebRTC server to SCTP runs on top of DTLS on top of UDP/TCP). It seems that, in order to get outgoing SCTP messages to be send on top of DTLS, I need to pass a callback to usrsctp_init() (second argument), but obviously such a callback may be called from any thread.

This is: I call usrsctp_sendv() from thread A and the library will invoke the above callback from that thread, am I right?

[tuexen]

That is correct. The second argument can get called from the thread which calls usrsctp_sendv(), the timer thread, and even the input thread when incoming packets get processed. The locking within the SCTP implementation protects its data structures. But nor more. Does that makes things clearer?

[ibc]

Thanks a lot. I can deal with such a callback being called from the thread that calls usrsctp_sendv() and also from the thread that receives input via usrsctp_conninput() (because I assume the callback will also be called in the calling thread). I will figure out how to deal with the timer thread.

Thanks a lot :)

[tuexen]

OK. Closing.

[ccaughie]

If it helps, I've made some modifications to usrsctp that allow it to be used in an entirely single-threaded environment. In particular I've added an API to call the timer routine directly from an application thread; this thread can be the same thread that is processing events on the encapsulating socket(s).

My team have been using this modified version for some time with great success. I'm working on publishing them in my fork, along with an example program. I'll submit a pull request when I'm done.

[ibc]

@ccaughie that sounds good, just some questions:

• How do you (the app) know when it must call the timer routine? an interval timer perhaps?
• Can that work in a multi-thread application in which each server manages its own "instance" of usrsctp?

Regarding the second bullet, my server is based on libuv but runs several threads, having each one its own libuv event loop.

By using your fork, could I "initiate" usrsctp in each thread so each thread "instance" owns and manages its own and separate SCTP sessions and data without collision and without accessing to shared memory? (this is: no need for mutext).

[ccaughie]

Yes, the application calls the timer routine on an interval timer. I call it every 10 milliseconds just like the built in timer thread does.

Multiple instances of usrsctp in a single process is well beyond the scope of what I've done I'm afraid. Currently there is a lot of global state in the library; this would all have to be moved into a struct so that you could create multiple copies of it.

[tuexen]

When used in the FreeBSD kernel, almost all variables are in a struct. This is for supporting virtual networks. But this is not true for the glue code (socket stuff, mbufs and so on). It is a consequence that usrsctp is a port from the FreeBSD kernel to run in user land...

[ibc]

Thanks for the comments. Once I get some spare time I'll get deeper into the library with the aim of forking it to be multi-separate-threads :)

@ccaughie if finally you publish your fork please let me know (just comment here) so I can take a look to it. Thanks a lot.

[ccaughie]

I published it over the weekend: https://github.com/ccaughie/usrsctp.

Feedback welcome.

[ibc]

Thanks a lot.

[ibc]

@ccaughie I will come back to your fork soon. Just wondering if the code is actively maintained (I don't see the latest official commits merged in your fork).

[jmillan]

There's already a PR to have @ccaughie code into usrsctp: #38