Is this lib better than libwebrtc?

[Laky-64]

I've been having several arguments with webrtc lately (libwebrtc), like the number of connections is really very limited, you just need to get to 70 active peerconnections to send it to toomanyfilesopen, and well, reading for the network can depend on the fact that it opens many webrtc filedescriptors of its own, and I've heard absurd things, that some say it opens 200 sockets for each peer connection, does this lib also suffer from these problems?

[paullouisageneau]

libdatachannel was designed to be lightweight, it is way easier to build and resource usage is significantly lower (for instance, each peer connection typically opens a single socket). Therefore, the library can scale to hundreds or even thousands of parallel connections.

[pfeatherstone]

If you use boost::beast, you can also remove all http and websocket code as well which would be neat. By using asio and beast you could probably remove a substantial amount of code in this library, and likely end up with less dependencies overall. I might give this a go at some point. Using a single runtime, i.e. asio::io_context, would be a big win for me. Then literally everything can run on the main thread which runs asio::io_context::run()

[pfeatherstone]

Sorry, I'm not trying to get you to rewrite your library. It's fantastic! I was just curious as to the design decisions. I can see in your BIO you're also an ASIO user so wondered why you didn't go down that route.

[paullouisageneau]

Yeah i was wondering why you need a library for sctp ? You can create sctp posix sockets, which can then be used with Asio again. So if you remove the usrsctp library and add Asio, you're quids in. Plus by using Asio, you can remove a sh** load of code in both libdatachannel and libjuice. Just a thought.

No you can't, please stop speculating about what you don't know. You can't create SCTP sockets. First, libdatachannel runs on Windows, where they don't exist. Then, WebRTC requires an userland SCTP stack anyway because you need to tunnel SCTP over DTLS, you can't use the kernel stack. Finally, libjuice is written in C, not C++, you can't port it to Asio.

If you use boost::beast, you can also remove all http and websocket code as well which would be neat. By using asio and beast you could probably remove a substantial amount of code in this library, and likely end up with less dependencies overall. I might give this a go at some point. Using a single runtime, i.e. asio::io_context, would be a big win for me. Then literally everything can run on the main thread which runs asio::io_context::run()

You could use beast, it's a good library. libdatachannel has a NO_WEBSOCKET flag to completely disable Websocket code. Just understand that not everybody has the same use case as you.

[pfeatherstone]

Yeah sorry. I didn't mean to upset anyone. Though you can do SCTP with posix. https://man7.org/linux/man-pages/man7/sctp.7.html

[paullouisageneau]

Sorry, I'm not trying to get you to rewrite your library. It's fantastic! I was just curious as to the design decisions. I can see in your BIO you're also an ASIO user so wondered why you didn't go down that route.

Indeed, I have used boost:asio on some projects, but for libdatachannel I decided to go without it as it seemed to me the cons outweighted the pros. Besides adding a dependency, the main issue was that integrating with other libraries like usrsctp, GnuTLS, or libnice seemed like a pain.

Yeah sorry. I didn't mean to upset anyone. Though you can do SCTP with posix. https://man7.org/linux/man-pages/man7/sctp.7.html

You can indeed do SCTP over IP (more recently SCTP over UDP) with Linux and *BSD (It is not POSIX, for instance there is no out-of-the box support on MacOS), but for WebRTC you need SCTP over DTLS with ICE, which requires an userland stack (SCTP traffic is not sent directly on the network but encapsulated in DTLS).