Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How and why Daily is using Rust for our WebRTC APIs

daily.co

Post reply on HN
Print view View original

11–20 of 30 posts

Re: How and why Daily is using Rust for our WebRTC APIs

#11

Post by dgunay »

yolo3000 wrote: post #4
kwindla wrote: post #3

Earlier quoted context omitted.

We're fans of webrtc-rs, but interop considerations pretty much mean that building on top of libwebrtc is necessary for our client libraries for now. `daily-core` is signaling, the (always evolving) low-level trickery needed to scale calls to 10,000+ participants, state management, and an opinionated internal API that lets us efficiently maintain public-facing API features like track management, and device selection.

Are there use cases for calls with so many participants?

WebRTC is some of the lowest latency streaming you can get, so I would imagine any realtime event with a large broadcasting audience would benefit. Interactive/2-way though, that's another story.

Re: How and why Daily is using Rust for our WebRTC APIs

#12

Post by jpgneves »

Sean-Der wrote: post #2

What is `daily-core` actually doing? It is signaling code? Have you evaluated webrtc-rs yet? I haven't keep up to date with mediasoup, but I saw they have a rust effort. Have you evaluated that yet? Seems possible to drop lots of C++ dependencies :)

Hi, I'm João, one of the co-authors of this post!

Regarding mediasoup, their Rust effort so far has focused mostly on the server side of things, whereas for this particular project we would be looking more towards the client side.

That would definitely be something we are considering contributing to, as it would, as you say, drop quite a significant amount of C++ (with additional benefits on the web side, too).

Re: How and why Daily is using Rust for our WebRTC APIs

#13

Post by VWWHFSfQ »

yolo3000 wrote: post #4
kwindla wrote: post #3

Earlier quoted context omitted.

We're fans of webrtc-rs, but interop considerations pretty much mean that building on top of libwebrtc is necessary for our client libraries for now. `daily-core` is signaling, the (always evolving) low-level trickery needed to scale calls to 10,000+ participants, state management, and an opinionated internal API that lets us efficiently maintain public-facing API features like track management, and device selection.

Are there use cases for calls with so many participants?

People have started turning to webrtc for broadcast streaming (1->many) instead of hls/dash because of the lower glass-to-glass latency. But it has scalability problems which makes it enormously expensive comparatively. There are low-latency variants of HLS and DASH emerging now though

Re: How and why Daily is using Rust for our WebRTC APIs

#14

Post by monocasa »

rictic wrote: post #9

> This means that whenever we decide to throw the switch to multi-threaded WebAssembly, essentially no code needs to change as all of our logic is already written in a concurrent-friendly manner. We simply reap the benefits of a multi-threaded runtime on the Web. In a multithreaded wasm app, do all threads have equal access to the DOM, or is it more like JS where there is a UI thread which can access all APIs and a b…

Last I checked, no WASM has direct DOM access, but instead it all has to go through a bridge to JS.

Re: How and why Daily is using Rust for our WebRTC APIs

#15

Post by kjsthree »

monocasa wrote: post #14
rictic wrote: post #9

> This means that whenever we decide to throw the switch to multi-threaded WebAssembly, essentially no code needs to change as all of our logic is already written in a concurrent-friendly manner. We simply reap the benefits of a multi-threaded runtime on the Web. In a multithreaded wasm app, do all threads have equal access to the DOM, or is it more like JS where there is a UI thread which can access all APIs and a b…

Last I checked, no WASM has direct DOM access, but instead it all has to go through a bridge to JS.

The question still stands though. Does each individual worker have its own bridge to JS? If so it’s just a constant race condition between them.

Re: How and why Daily is using Rust for our WebRTC APIs

#16

Post by monocasa »

kjsthree wrote: post #15
monocasa wrote: post #14

Earlier quoted context omitted.

Last I checked, no WASM has direct DOM access, but instead it all has to go through a bridge to JS.

The question still stands though. Does each individual worker have its own bridge to JS? If so it’s just a constant race condition between them.

Yes, sort of. They can all call into JS, but that JS context is single threaded and serializes access. There can be races depending on what assumptions you make, but those races can't cause memory unsafety of the type usages of Sync and Send are trying to prevent.

Re: How and why Daily is using Rust for our WebRTC APIs

#17

Post by vr000m »

yolo3000 wrote: post #4
kwindla wrote: post #3

Earlier quoted context omitted.

We're fans of webrtc-rs, but interop considerations pretty much mean that building on top of libwebrtc is necessary for our client libraries for now. `daily-core` is signaling, the (always evolving) low-level trickery needed to scale calls to 10,000+ participants, state management, and an opinionated internal API that lets us efficiently maintain public-facing API features like track management, and device selection.

Are there use cases for calls with so many participants?

One thing to consider is if you would have One API and a few knobs to control the experience and not have to worry about the underlying protocol-, reliability-, latency- aspects to build that experience. (particularly not worry about the shenanigans around tuning RTMP, RTP, HLS, or webrtc)

There are some use-cases in every industry. * Finance/Company: earnings calls as mentioned before, all-hands meetings at companies (with several people queuing for questions and answers) * Live Events (music or talkshows) * Tutoring or education in general. * Healthcare and education -- Surgeries which are broadcast to several schools and have active collaboration from some doctors. The large-scale interaction can begin much earlier before the surgery.

Re: How and why Daily is using Rust for our WebRTC APIs

#18

Post by 7sidedmarble »

jpgneves wrote: post #12
Sean-Der wrote: post #2

What is `daily-core` actually doing? It is signaling code? Have you evaluated webrtc-rs yet? I haven't keep up to date with mediasoup, but I saw they have a rust effort. Have you evaluated that yet? Seems possible to drop lots of C++ dependencies :)

Hi, I'm João, one of the co-authors of this post! Regarding mediasoup, their Rust effort so far has focused mostly on the server side of things, whereas for this particular project we would be looking more towards the client side. That would definitely be something we are considering contributing to, as it would, as you say, drop quite a significant amount of C++ (with additional benefits on the web side, too).

I'm curious about the approach you guys are taking here. The client side of doing WebRTC is by far the easiest part. Maintaining separate client side implementations for mobile and web is... no harder then maintaining a web and mobile app separately anyways.

The server side is the hard part to work on. Also, one of the downsides of wasm is that it can be a pain to communicate out to the JS APIs, especially for doing lots of DOM manipulation. I'm not sure how sound this approach is really. It seems like you're going to do a lot of extra work in order to solve a problem that isn't much of a problem in the first place.

Re: How and why Daily is using Rust for our WebRTC APIs

#19

Post by Sean-Der »

yolo69420 wrote: post #7

Even if it sounds like it makes sense, something tells me that these (not just this one, all of these kinds of 'why x and y is happening') are really after-the-fact rationalizations after some dev or devs decided to engage in a pet project that would have happened even if it had no sensible justifications at all.

I do that all the time. is anything wrong with that? Sometimes you go and build something to solve a specific problem, and realize it solves lots of different things.

I don't think it matters what the Daily team originally intended. It is exciting/inspiring to me that they are trying to solve things differently. I think security for RTC is really important, so seeing more memory safe language usage makes me hopeful for the future.

All this new code also means people are really learning what goes into these problems. A whole new generation of coders are getting into the space and rethinking things. It is great.

Re: How and why Daily is using Rust for our WebRTC APIs

#20

Post by kwindla »

7sidedmarble wrote: post #18
jpgneves wrote: post #12

Earlier quoted context omitted.

Hi, I'm João, one of the co-authors of this post! Regarding mediasoup, their Rust effort so far has focused mostly on the server side of things, whereas for this particular project we would be looking more towards the client side. That would definitely be something we are considering contributing to, as it would, as you say, drop quite a significant amount of C++ (with additional benefits on the web side, too).

I'm curious about the approach you guys are taking here. The client side of doing WebRTC is by far the easiest part. Maintaining separate client side implementations for mobile and web is... no harder then maintaining a web and mobile app separately anyways. The server side is the hard part to work on. Also, one of the downsides of wasm is that it can be a pain to communicate out to the JS APIs, especially for doing…

I would say that both the client and the media server (SFU) side of the work are challenging in their own ways, if you are trying to support a large variety of use cases, features, and sessions with large numbers of participants.

The client-side and server-side code end up being tightly coupled and you end up having a lot more client-side code than maybe is obvious if you're building an application that uses WebRTC in one specific way. For example, handling fast subscription to and un-subscription from batches of tracks is non-trivial, but important if you're implementing "grid mode" client views.

The goal of the approach we're taking here is to be able to support a bunch of different platforms at the same level of performance, stability, and feature parity. Web, iOS, and Android are the three most important platforms. But people are also using WebRTC on Flutter, native Linux, macOS, Windows, Unreal, Unity, and various embedded platforms.

Post reply on HN