8 ms·

The WebTransport API looks to bring WebSockets up to speed with similar features provided by WebRTC: reliable or unreliable connections and multiplexing. The ad

The WebTransport API looks to bring WebSockets up to speed with similar features provided by WebRTC: reliable or unreliable connections and multiplexing. The addition of a Stream interface means it will be efficient for uploads and downloads too. I can see this replacing most use cases of WebSockets once brought to ubiquity.

saurik 6y ago
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).
- Fr33maan 6y ago
  WebRTC is known complicated to set up and quite unstable. Many companies have made a business of configuring WebRTC.
  - toomim 6y ago
    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.
    - untog 6y ago
      What about the STUN, ICE etc stuff? Saying “you just open a connection” is only part of the story.
      - fulafel 6y ago
        If you are talking to a websocket like server endpoint, hopefully it won't be behind NAT?
        saurik 6y ago
        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.)
        Sean-Der 6y ago
        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-connection-id/ https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connect...
        Volundr 6y ago
        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/ 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.
        fulafel 6y ago
        You are probably right. But sounds like this would still be better solved by this light tweak to webrtc than by a new protocol.
        saurik 6y ago
        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.
    - pthatcherg 6y ago
      There pain point is running ICE, DTLS, and SCTP on the server.
      - Sean-Der 6y ago
        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 https://github.com/aiortc/aioquic
        lxgr 6y ago
        > 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.
    - kaoD 6y ago
      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.
- smaddock 6y ago
  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 https://github.com/samuelmaddock/metastream
  - smaddock 6y ago
    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 https://github.com/feross/simple-peer
    - Sean-Der 6y ago
      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 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 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.
  - saurik 6y ago
    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.)
- pthatcherg 6y ago
  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 https://vimeo.com/350908362
- emmanueloga_ 6y ago
  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-friends-online-netflix-hulu-youtube-party-twoseven-metastream-amazon-hbo-scener https://www.theverge.com/2020/3/25/21191604/watch-movies-fri...
- zamalek 6y ago
  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.

saurik 6y ago

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).

Fr33maan 6y ago
WebRTC is known complicated to set up and quite unstable. Many companies have made a business of configuring WebRTC.
- toomim 6y ago
  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.
  - untog 6y ago
    What about the STUN, ICE etc stuff? Saying “you just open a connection” is only part of the story.
    - fulafel 6y ago
      If you are talking to a websocket like server endpoint, hopefully it won't be behind NAT?
      - saurik 6y ago
        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.)
        Sean-Der 6y ago
        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-connection-id/ https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connect...
      - Volundr 6y ago
        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/ 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.
        fulafel 6y ago
        You are probably right. But sounds like this would still be better solved by this light tweak to webrtc than by a new protocol.
        saurik 6y ago
        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.
  - pthatcherg 6y ago
    There pain point is running ICE, DTLS, and SCTP on the server.
    - Sean-Der 6y ago
      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 https://github.com/aiortc/aioquic
      - lxgr 6y ago
        > 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.
  - kaoD 6y ago
    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.
smaddock 6y ago
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 https://github.com/samuelmaddock/metastream
- smaddock 6y ago
  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 https://github.com/feross/simple-peer
  - Sean-Der 6y ago
    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 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 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.
- saurik 6y ago
  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.)
pthatcherg 6y ago
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 https://vimeo.com/350908362
emmanueloga_ 6y ago
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-friends-online-netflix-hulu-youtube-party-twoseven-metastream-amazon-hbo-scener https://www.theverge.com/2020/3/25/21191604/watch-movies-fri...
zamalek 6y ago
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.