Hacker News Reader

Comment by saurik | Hacker News Reader

Do you know the answer to "Why not just use WebRTC?"? I am used to documents like this having an explanation of the "why", but I am not seeing it here (or an extra stupid today).

View on HN

I use WebRTC and WebSockets in a side project of mine [0]. WebRTC requires coordination of multiple services and fallbacks (relay servers) when peers can't establish a direct connection due to firewalls among other things.

STUN, TURN, and ICE are a few technologies you need to understand to get started with WebRTC. I'd guess most folks aren't familiar when first looking into it.

The complexity is worth it if you're determined to push most bandwidth costs to clients like I am.

If you want near 100% connectivity at a lower complexity, WebSockets are almost always preferred.

[0] https://github.com/samuelmaddock/metastream

Additionally, during the 3 years I've had experience with WebRTC, I've come across at least 2-3 browser bugs causing compatibility issues when connecting peers cross-browser.

This is just not something you run into with WebSockets.

I'd recommend simple-peer for anyone who does choose to use WebRTC. The maintainers are usually able to smooth these issues out in a reasonable timeframe. <3

https://github.com/feross/simple-peer

I don't think the issues with WebRTC is the protocol, but the tooling. The community did a really good job of creating tooling for Websockets with stuff like https://github.com/crossbario/autobahn-testsuite. There is nothing like that for WebRTC.

We tried to do it, but the IETF event was cancelled https://twitter.com/steely_glint/status/1230447935307026432. I am hoping that in the next 6 months we can have something like that so that all the WebRTC implementations will work together a lot better.

I guess my question wasn't clear; why would they create a new seemingly unrelated spec to try to try to bring WebSockets up to where WebRTC is rather than just add the little tiny signalling bit to WebRTC? (Particularly since people are also simultaneously trying to bring QUIC transports to WebRTC data channels?) We shouldn't be maintaining so many separate protocol stacks and APIs in the browser. (Context: I use WebRTC in my day job, not as a side project, and have been working with it for years now ;P.)

The effort to bring QUIC to WebRTC is the kind of the same effort. The WebTransport is an outgrowth of that effort. They are not unrelated.

As for "too many protocols": QUIC is already in the browser. This is just giving you an API to it. Think of it like WebSockets for the HTTP3 world.

WebRTC is known complicated to set up and quite unstable. Many companies have made a business of configuring WebRTC.

You can create a WebRTC datachannel in any modern browser with just one line of javascript:

     channel = new RTCPeerConnection().createDataChannel("foo", {ordered: false})

Then you can read from it with:

     channel.onopen = () => { ... }
     channel.onmessage = (event) => { ... }

This is widely supported in every modern browser.

What about the STUN, ICE etc stuff? Saying “you just open a connection” is only part of the story.

If you are talking to a websocket like server endpoint, hopefully it won't be behind NAT?

Exactly. If WebSockets were an option, then WebRTC will be pretty trivial and absolutely doesn't require any STUN/TURN.

(The main issue, and this has nothing to do with the client API, is that WebRTC implementations tend to end up assuming unique ports for each user--which would be needed to help with NAT--but if you aren't behind NAT then the ICE layer already has a connection ID so you should be able to multiplex them all over a single open port.)

One big issue was also being able to demux DTLS traffic. You could do it off the 3-tuple of the remote host, but that would fall down sometimes.

I am really excited for DTLS connection ids[0] to land. Then you will have everything you need to run ICE+DTLS (and SCTP over that) and be able to demux/load balance it easier.

[0] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connect...

Actually, I'm currently working on an app using WebRTC, and from everything I've read you actually still need a STUN and in some cases a TURN server, even if you have a public IP:

https://bloggeek.me/turn-public-ip-address/

To be perfectly honest, I'm still fuzzy on the why, but numerous blog posts, stack overflow questions, and the Kurento forums agree. This being Hacker News maybe someone with chime in with the technical reasoning.

You are probably right. But sounds like this would still be better solved by this light tweak to webrtc than by a new protocol.

This article is essentially claiming that for WebRTC to use TCP you have to be using TURN. While I am willing to believe I am wrong here (our product feels a bit crippled over TCP to the point where I just recommend you not use it, so if it isn't working I might not even notice), I am nearly certain this is not true.

You are right, ICE does support TCP. Not all ICE implementations support it though, probably where the incorrect anecdote comes from.

ICE TCP did get a little more limited recently in Chromium though [0] because of the TCP port scanning issue [1]

I have also heard that some gateways/firewalls/$x don't allow any non-TLS traffic, so you can't even establish ICE. In those cases the DTLS/TLS transport of TURN is nice.

[0] https://lists.w3.org/Archives/Public/public-webrtc/2020Feb/0...

[1] https://medium.com/tenable-techblog/using-webrtc-ice-servers...

WebRTC negotiates a peer-to-peer protocol which operates like client/server but has issues with NAT/PAT and firewall traversal. Each peer will realistically only know about its local network and there will also likely be limitations on the peers even being able to communicate with one another directly.

STUN and TURN allow the negotiation to include services outside the local network so that you can relay signaling and stream data to a set of endpoints that both peers can use to communicate with one another. This could be the peers directly or it could be a set of 3rd party servers run by Google or someone open to the public and you can't assume any particular network topology.

There pain point is running ICE, DTLS, and SCTP on the server.

That sounds like you need better software then :) Realistically what do you think the timelines are for QUIC?

When Bernard published the QuicTransport stuff I tried a few different versions and it only worked aioquic[0] (which is a really fantastic implementation)! But with 29 drafts and most servers not supporting them all feels like we still have some time to go.

So QUIC as a server is much less likely to happen then ICE/DTLS/SCTP which have implementations that work everywhere.

[0] https://github.com/aiortc/aioquic

> That sounds like you need better software then :)

No, it rather sounds like you have a hammer called WebRTC and you're attempting to use it on a nail called "bidirectional server/client communication".

Why deal with the complex protocol stack of WebRTC which solves, among other things, NAT traversal, mutual authentication and encryption independently of server certificates, multiplexing of data and A/V content on a single port and much more. And I say that as someone who absolutely loves WebRTC for A/V and secure P2P use cases.

There is a true gap of "UDP for the web", which this fills.

"WebSockets over UDP" don't need to be built on QUIC, but I'm assuming by the time you have added all the security features needed to make this as secure as WebSockets for web apps, you'll effectively end up with something equivalent.

This is simply not true. Unless things changed widely since I used WebRTC, this connects to nothing.

Leaving out the ICE will of course make WebRTC look palatable.

WebRTC is pretty hard to get right for client/server (it is designed for P2P), and may exhibit P2P downsides even when used for client/server (obnoxious NATs). If "dumb" client/server UDP doesn't work, your internet likely has bigger problems. Then there's the RFCs you have to implement to build it, which are more niche than you'd think. You can't do the entirety of WebRTC in Rust right now, without implementing multiple massive RFCs yourself.

It's a simpler spec to solve a simpler problem. WebRTC is necessarily complex, but still overkill for a bunch of scenarios.

I have a hard time understanding what metastream is... I saw a demo of being able to play a YT video and chat at the same time, invite ppl, etc... Does it support sharing any video stream playing on a browser? (say, netflix). How does it work?

EDIT: bizarrely, I found this article on The Verge more descriptive of what metastream does than the website, WIKI and source code :-) [1].

1: https://www.theverge.com/2020/3/25/21191604/watch-movies-fri...

I did a presentation last year that sort of answers that from a gaming perspective (gaming was the topic of the workshop):

https://vimeo.com/350908362

Reply on news.ycombinator.com