0.7.2 was released with important memory and thread safety fixes as well as macOS support 
1 Like
I think next major step would be to move away from pipes and try to use uv_async_t and combine it with Rust futures. That would allow to simplify things, avoid unnecessary memory copying and even reduce number of syscalls. No ETA though, just an idea of something to work on.
Then maybe, just maybe, create mediasoupbin element (not sure what API could look like) for GStreamer to simplify use cases that need to push data into GStreamer pipeline or pull data out of GStreramer pipeline, while avoiding RTP and WebRTC network protocols (using Direct Transport, which I think needs to be more efficient on C++/Rust boundary for that to work nicely and uv_async_t should help there).
1 Like
Can you move this to a separate thread, please?
This is a very general thread and probably not worth filling with very specific and project-specific questions. I’ll be happy to answer the question in the other thread though.
1 Like
I have a branch with no file descriptors and uv_async_t here: GitHub - nazar-pc/mediasoup at rust-no-fds
The primary benefit is that message sending benchmark results improved over 2x, it is now possible to send message with DirectTransport and receive it back all in ~8.5us down from ~21us.
Memory from C++ worker is shared with Rust, so when you receive a callback with memory slice of RTP packet it is just a pointer to RTP packet in C++ worker, no memory copying. In the other direction there is unfortunately memory allocation due to the fact that libuv is single-threaded, so we allocate a message in Rust and send notification using uv_async_t for worker to read it as soon at it can.
There are still a few tweaks that can be applied around callbacks locking, but this should be a decent performance already and all without send/receive buffers on either side, extra memory copies and syscalls.
As a side effect Windows support should be trivial to add, just need to figure out how to link C++ standard library and it should be good to go.
1 Like
It’s wonderful @nazar-pc 
Some more good news.
Same benchmark with DirectTransport is now down to ~7.3us on my machine.
Also when combined with Meson branch everything builds and all tests pass on Windows.
5 Likes
Hi @Meeshbhoombah , Have you face any difficulty in building the WASM-based Rust client?
WASM is 100% irrelevant here, this is a server-side library.
I want to build my own WASM based client by using mediasoup javascript client SDK so that I don’t need to write my client code browser specific.
Once again this is a threead about server-side Rust library, it is 100% irrelevant to anything frontend-related.
I have though about this some times, does server side Rust Mediasoup library compiles to WASM? Node.js can load it, and maybe performance could be better since there would not be IPC, or at least it would something interesting to look about 
No, it does not
Hello Nazar,
Is the rust library supposed to build on Windows out of the box these days?
The npm version builds fine, but the crate ends up in an infinite loop of trying to generate build files for me
Assuming version from NPM builds and you have modern compiler - yes, it should just work. And it does work in CI.