3 ms·

WebRTC's best days are ahead of it still IMO! I think the thing holding it back the most is the perception that it is a browser technology only. I just spent so

WebRTC's best days are ahead of it still IMO! I think the thing holding it back the most is the perception that it is a browser technology only. I just spent some time talking to a developer that was using it to control robots in a warehouse via DataChannels (ICE is fantastic technology to get around frustrating/complicated networks). If you aren't familiar with what WebRTC can do check out WebRTC for the Curious[0] I really tried to capture why WebRTC is exciting/what it can do. After that go build something cool with WebRTC in your favorite language. We have lots of implementations these days :) [0] https://webrtcforthecurious.com/ https://webrtcforthecurious.com/

graderjs 5y ago
I use peerjs from Node to run a WebRTC channel between clients and server to do UDP streaming of browser viewports in the pro version of ViewFinder: basically a co-browsing enabled remote isolated browser. I think WebRTC is great! It was also easy to set up. So far I have not had to run a STUN or TURN server myself, but I'm interested in exploring this in future. I think mainly this is because I use Websockets as an alternative channel so even if WebRTC won't go through (I've never encountered that, tho), I always have wss. My initial reason for doing this was not just to provide an alternative to UDP, it was in my experience UDP is not always faster than Websocket for streaming the screencast frames, but it can be, and seems to especially be a good option when Websocket is slow for some reason. Because of this my strategy is to measure the roundtrip time (via frame acks) for each channel, and switch to the faster channel (UDP via WebRTC or TCP via Websocket) when the real-life bandwidth conditions tell me to. Obviously, I'm not sitting there switching this over, the logic is built into the app itself, but it was just really cool how easy WebRTC was to set up and how much of a performance boost it gave. Overall, have the TCP/UDP dual-channel option smooths out a lot of real-world bandwidth irregularities, and is how I achieve optimal streaming right now. A source available version of the above that does not include the advanced streaming I described is here: https://github.com/i5ik/ViewFinder https://github.com/i5ik/ViewFinder
avaer 5y ago
Thanks for that site, bookmarked. However, I'd counter this. As someone whose company has been using WebRTC for years, WebRTC is just too complicated, trying to do everything, and as a result bad for its main use case: a comms interface that works. In practice it inevitably doesn't work for some subset of users/platforms, and fixing it is an exercise in yak shaving because there are so many combinations of networks, codecs and signals, and JS makes it easy to bug out with race conditions. Weird problems under load are common on exotic hardware like VR headsets. If you don't have UDP support, like many typical web deployments these days, then you are also signing yourself up for maintaining a separate server. The most technically appealing aspect of WebRTC is that it can be P2P, but even then, projects quickly realize that n^2 independent connections is not actually performant, which is why most run star topologies through a central server, neutering this most appealing aspect. Companies like Discord have implemented great products on WebRTC with custom hacks/subsets, but for the average developer it's a beast of complexity you probably didn't ask for or want. WebRTC frameworks (like mediasoup) help a lot but they are leaky abstractions in a production project. Doing WebRTC comms (IMO) means mostly throwing away WebRTC networking and leveraging the only parts that provide enormous value, which is the codecs! Thankfully that is being broken out into the WebCodecs standard: https://www.w3.org/TR/webcodecs/ https://www.w3.org/TR/webcodecs/ With WebCodecs, you can use your own sane transport like a websocket while still getting acceleration and efficiency.

graderjs 5y ago

I use peerjs from Node to run a WebRTC channel between clients and server to do UDP streaming of browser viewports in the pro version of ViewFinder: basically a co-browsing enabled remote isolated browser. I think WebRTC is great! It was also easy to set up. So far I have not had to run a STUN or TURN server myself, but I'm interested in exploring this in future. I think mainly this is because I use Websockets as an alternative channel so even if WebRTC won't go through (I've never encountered that, tho), I always have wss. My initial reason for doing this was not just to provide an alternative to UDP, it was in my experience UDP is not always faster than Websocket for streaming the screencast frames, but it can be, and seems to especially be a good option when Websocket is slow for some reason. Because of this my strategy is to measure the roundtrip time (via frame acks) for each channel, and switch to the faster channel (UDP via WebRTC or TCP via Websocket) when the real-life bandwidth conditions tell me to. Obviously, I'm not sitting there switching this over, the logic is built into the app itself, but it was just really cool how easy WebRTC was to set up and how much of a performance boost it gave. Overall, have the TCP/UDP dual-channel option smooths out a lot of real-world bandwidth irregularities, and is how I achieve optimal streaming right now. A source available version of the above that does not include the advanced streaming I described is here: https://github.com/i5ik/ViewFinder https://github.com/i5ik/ViewFinder

avaer 5y ago

Thanks for that site, bookmarked. However, I'd counter this. As someone whose company has been using WebRTC for years, WebRTC is just too complicated, trying to do everything, and as a result bad for its main use case: a comms interface that works. In practice it inevitably doesn't work for some subset of users/platforms, and fixing it is an exercise in yak shaving because there are so many combinations of networks, codecs and signals, and JS makes it easy to bug out with race conditions. Weird problems under load are common on exotic hardware like VR headsets. If you don't have UDP support, like many typical web deployments these days, then you are also signing yourself up for maintaining a separate server. The most technically appealing aspect of WebRTC is that it can be P2P, but even then, projects quickly realize that n^2 independent connections is not actually performant, which is why most run star topologies through a central server, neutering this most appealing aspect. Companies like Discord have implemented great products on WebRTC with custom hacks/subsets, but for the average developer it's a beast of complexity you probably didn't ask for or want. WebRTC frameworks (like mediasoup) help a lot but they are leaky abstractions in a production project. Doing WebRTC comms (IMO) means mostly throwing away WebRTC networking and leveraging the only parts that provide enormous value, which is the codecs! Thankfully that is being broken out into the WebCodecs standard: https://www.w3.org/TR/webcodecs/ https://www.w3.org/TR/webcodecs/ With WebCodecs, you can use your own sane transport like a websocket while still getting acceleration and efficiency.