9 ms·

WebTransport API

113 points by Jarred 6y ago

smaddock 6y ago
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.
      - 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.
Fr33maan 6y ago
finally a specification for datagrams, unordered and unreliable ! This was one of the big struggles of bringing mmo to the browser. DatagramTransport seems really promising as it provides encryption and congestion control which are the most complicated parts of any netcode. Good luck !
- toomim 6y ago
  SCTP already provides that in WebRTC.
  - seangrogg 6y ago
    But requires a lot of mucking around with STUN/TURN/ICE, which is far less desirable than just "send UDP packets to a browser".
    - pthatcherg 6y ago
      You don't need to use STUN and TURN for client->server use cases, but you do need ICE, DTLS, and SCTP.
- k__ 6y ago
  This was one of the big struggles to bring anything remotely time critical to the browser. WebSockets only works for the mere basics.
jand 6y ago
To my understanding, the ability to perform browser-to-browser communication with WebTransport API is not touched by the document. Is my reading right?
- pthatcherg 6y ago
  That's in a separate doc. Search for "RTCQuicTransport".
fulafel 6y ago
I think this is harmful for the internet because we need webrtc to become more ubiquitous, to keep it from being blocked at firewalls. Also webrtc functionality is a superset of this so it's not a technically necessary protocol.
- pthatcherg 6y ago
  If anything, an increase in the use of QUIC will reduce the amount of UDP blocking, which would be good for WebRTC.
  - fulafel 6y ago
    I think UDP is often whitelisted by port in these cases and rarely blanket blocked, as dns, VPN protocols etc are still needed. So quic, webrtc, and webtransport all have their own battles.
dfabulich 6y ago
Folks who are interested in the WebTransport API may find it easier to read the "explainer" document. https://github.com/wicg/web-transport/blob/master/explainer.md https://github.com/wicg/web-transport/blob/master/explainer.... It addresses a number of the top comments here, e.g. why not just use WebRTC data channels: "While WebRTC data channel has been used for client/server communications (e.g. for cloud gaming applications), this requires that the server endpoint implement several protocols uncommonly found on servers (ICE, DTLS, and SCTP) and that the application use a complex API (RTCPeerConnection) designed for a very different use case."
josephg 6y ago
A lot of people here seem confused why this is needed or wanted with WebRTC. I sat in the BOF session at IETF 106 in Singapore last year when we talked about this. Happy to answer any questions as I understand them. (Though I'm no expert.) I can't find the video link, but the slides from that session are here: https://datatracker.ietf.org/meeting/106/materials/slides-106-webtrans-webtrans-bof-slides-03 https://datatracker.ietf.org/meeting/106/materials/slides-10... Webtransport is designed as a 'QUIC-native' client-server communication protocol to replace websockets. You can think of it like websockets but better (faster handshake, it reuses the http2 / QUIC connection, and you can relax websocket's reliability & ordering constraints). Or you can think of it as WebRTC, except way simpler for the 95% case where you want to communicate server/client. I'm excited about it for browser based video games. It looks complicated, but there's very little thats new here for browsers and web servers to implement. Remember QUIC is already built on top of UDP, and internally, QUIC supports basically all of webtransport's features natively. Webtransport mostly just re-exposes many of QUIC's features to applications. Browsers and HTTP servers are adding all that functionality anyway - so we may as well take advantage of it in our web applications. My favorite criticism voiced at the IETF was the name - webtransport has nothing to do with the web, and its not a transport. Its mostly just an application API around some of QUIC's features, with fallbacks for HTTP 1.1 and HTTP2.
- fractalb 6y ago
  > Webtransport is designed as a 'QUIC-native' client-server communication protocol to replace websockets. Is there anything wrong with websockets? I thought websockets were cool.
  - vertex-four 6y ago
    Websockets work on HTTP/1.1 (not later versions) and turns the TCP connection into a packet-based transport, unrelated to HTTP. WebTransport works on HTTP/3 and exposes a part of the underlying UDP QUIC connection (while still allowing HTTP/3 messages to travel across the same underlying connection), allowing for stream-based or packet-based subconnections, reliable or unreliable. Basically, it’s a lot more flexible and doesn’t require setting up an entire new connection to work.
vasilvv 6y ago
Really glad to see people excited about this! If anyone is wondering if this is already implemented anywhere, we're currently experimenting with it in Chrome: https://web.dev/quictransport/ https://web.dev/quictransport/ -- I'd be curious to hear what people think about it.
bullen 6y ago
If you need real-time both-ways communication in the browser you could look at Comet-Stream (since IE7 is now in all practical senses gone). It's simpler, consistent and scales like a monster on the server: https://github.com/tinspin/rupy/wiki/Comet-Stream https://github.com/tinspin/rupy/wiki/Comet-Stream The only thing that is annoying in the browser is that Chrome does not allow you to remove or change the User-Agent header which wastes a little bandwidth.
- lxgr 6y ago
  What is the benefit of this over WebSockets? More generally, what is it even, and what problems does it solve?
  - bullen 6y ago
    It uses HTTP/1.1 so it goes through all firewalls and the server implementation is simple enough for it to be rock solid and it scales with "joint parallelism" which only Java can do because of the complex memory-model and VM. Rupy is a complete beast in terms of multi-core power, as long as the selector thread is not saturated it can scale linearly on all cores on shared memory = no memory copying or locks like all other solutions! But the real upside is you get one process for async. HTTP (client and server), including database; which means you can use micro services the way they should be used by hosting all services on all machines and call them locally = more robust and less complex (no discovery after the initial client -> server DNS) completely without IO-wait! WebSockets are completely over-engineered, as is HTTP/2 and 3... So to answer your question: rupy is the final solution to internet servers. ;) Now I'm working on the final solution for internet clients: http://talk.binarytask.com/task?id=5959519327505901449 http://talk.binarytask.com/task?id=5959519327505901449 And internet 2.0: http://radiomesh.org http://radiomesh.org And the final computer: http://talk.binarytask.com/task?id=8015986770003767235 http://talk.binarytask.com/task?id=8015986770003767235
    - fulafel 6y ago
      What do you mean by joint parallelism?
gioscarab 6y ago
Could PJON https://github.com/gioblu/PJON https://github.com/gioblu/PJON be used as one of the underlying pluggable protocols? It would be cool to be able to use the browser along with an open-hardware physical network infrastructure.
francislavoie 6y ago
How is this expected to work for apps that having a webserver fronting the app that terminates TLS/QUIC/HTTP3 and proxies over fastcgi/http1.1/h2c for example? Specifically, how would this work for say, a PHP app that wants to stream stuff? I use https://reactphp.org/ https://reactphp.org/ for websockets in PHP (so I can have a shared codebase with my main app, etc). I don't think I understand how this would look on the server-side. I'm interested to understand how it would look like to support this in Caddy (I'm one of the core contributors).

113 points by Jarred 6y ago

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

Fr33maan 6y ago

finally a specification for datagrams, unordered and unreliable ! This was one of the big struggles of bringing mmo to the browser. DatagramTransport seems really promising as it provides encryption and congestion control which are the most complicated parts of any netcode. Good luck !

toomim 6y ago
SCTP already provides that in WebRTC.
- seangrogg 6y ago
  But requires a lot of mucking around with STUN/TURN/ICE, which is far less desirable than just "send UDP packets to a browser".
  - pthatcherg 6y ago
    You don't need to use STUN and TURN for client->server use cases, but you do need ICE, DTLS, and SCTP.
k__ 6y ago
This was one of the big struggles to bring anything remotely time critical to the browser. WebSockets only works for the mere basics.

jand 6y ago

To my understanding, the ability to perform browser-to-browser communication with WebTransport API is not touched by the document. Is my reading right?

pthatcherg 6y ago
That's in a separate doc. Search for "RTCQuicTransport".

fulafel 6y ago

I think this is harmful for the internet because we need webrtc to become more ubiquitous, to keep it from being blocked at firewalls. Also webrtc functionality is a superset of this so it's not a technically necessary protocol.

pthatcherg 6y ago
If anything, an increase in the use of QUIC will reduce the amount of UDP blocking, which would be good for WebRTC.
- fulafel 6y ago
  I think UDP is often whitelisted by port in these cases and rarely blanket blocked, as dns, VPN protocols etc are still needed. So quic, webrtc, and webtransport all have their own battles.

dfabulich 6y ago

Folks who are interested in the WebTransport API may find it easier to read the "explainer" document. https://github.com/wicg/web-transport/blob/master/explainer.md https://github.com/wicg/web-transport/blob/master/explainer.... It addresses a number of the top comments here, e.g. why not just use WebRTC data channels: "While WebRTC data channel has been used for client/server communications (e.g. for cloud gaming applications), this requires that the server endpoint implement several protocols uncommonly found on servers (ICE, DTLS, and SCTP) and that the application use a complex API (RTCPeerConnection) designed for a very different use case."

josephg 6y ago

A lot of people here seem confused why this is needed or wanted with WebRTC. I sat in the BOF session at IETF 106 in Singapore last year when we talked about this. Happy to answer any questions as I understand them. (Though I'm no expert.) I can't find the video link, but the slides from that session are here: https://datatracker.ietf.org/meeting/106/materials/slides-106-webtrans-webtrans-bof-slides-03 https://datatracker.ietf.org/meeting/106/materials/slides-10... Webtransport is designed as a 'QUIC-native' client-server communication protocol to replace websockets. You can think of it like websockets but better (faster handshake, it reuses the http2 / QUIC connection, and you can relax websocket's reliability & ordering constraints). Or you can think of it as WebRTC, except way simpler for the 95% case where you want to communicate server/client. I'm excited about it for browser based video games. It looks complicated, but there's very little thats new here for browsers and web servers to implement. Remember QUIC is already built on top of UDP, and internally, QUIC supports basically all of webtransport's features natively. Webtransport mostly just re-exposes many of QUIC's features to applications. Browsers and HTTP servers are adding all that functionality anyway - so we may as well take advantage of it in our web applications. My favorite criticism voiced at the IETF was the name - webtransport has nothing to do with the web, and its not a transport. Its mostly just an application API around some of QUIC's features, with fallbacks for HTTP 1.1 and HTTP2.

fractalb 6y ago
> Webtransport is designed as a 'QUIC-native' client-server communication protocol to replace websockets. Is there anything wrong with websockets? I thought websockets were cool.
- vertex-four 6y ago
  Websockets work on HTTP/1.1 (not later versions) and turns the TCP connection into a packet-based transport, unrelated to HTTP. WebTransport works on HTTP/3 and exposes a part of the underlying UDP QUIC connection (while still allowing HTTP/3 messages to travel across the same underlying connection), allowing for stream-based or packet-based subconnections, reliable or unreliable. Basically, it’s a lot more flexible and doesn’t require setting up an entire new connection to work.

vasilvv 6y ago

Really glad to see people excited about this! If anyone is wondering if this is already implemented anywhere, we're currently experimenting with it in Chrome: https://web.dev/quictransport/ https://web.dev/quictransport/ -- I'd be curious to hear what people think about it.

bullen 6y ago

If you need real-time both-ways communication in the browser you could look at Comet-Stream (since IE7 is now in all practical senses gone). It's simpler, consistent and scales like a monster on the server: https://github.com/tinspin/rupy/wiki/Comet-Stream https://github.com/tinspin/rupy/wiki/Comet-Stream The only thing that is annoying in the browser is that Chrome does not allow you to remove or change the User-Agent header which wastes a little bandwidth.

lxgr 6y ago
What is the benefit of this over WebSockets? More generally, what is it even, and what problems does it solve?
- bullen 6y ago
  It uses HTTP/1.1 so it goes through all firewalls and the server implementation is simple enough for it to be rock solid and it scales with "joint parallelism" which only Java can do because of the complex memory-model and VM. Rupy is a complete beast in terms of multi-core power, as long as the selector thread is not saturated it can scale linearly on all cores on shared memory = no memory copying or locks like all other solutions! But the real upside is you get one process for async. HTTP (client and server), including database; which means you can use micro services the way they should be used by hosting all services on all machines and call them locally = more robust and less complex (no discovery after the initial client -> server DNS) completely without IO-wait! WebSockets are completely over-engineered, as is HTTP/2 and 3... So to answer your question: rupy is the final solution to internet servers. ;) Now I'm working on the final solution for internet clients: http://talk.binarytask.com/task?id=5959519327505901449 http://talk.binarytask.com/task?id=5959519327505901449 And internet 2.0: http://radiomesh.org http://radiomesh.org And the final computer: http://talk.binarytask.com/task?id=8015986770003767235 http://talk.binarytask.com/task?id=8015986770003767235
  - fulafel 6y ago
    What do you mean by joint parallelism?

gioscarab 6y ago

Could PJON https://github.com/gioblu/PJON https://github.com/gioblu/PJON be used as one of the underlying pluggable protocols? It would be cool to be able to use the browser along with an open-hardware physical network infrastructure.

francislavoie 6y ago

How is this expected to work for apps that having a webserver fronting the app that terminates TLS/QUIC/HTTP3 and proxies over fastcgi/http1.1/h2c for example? Specifically, how would this work for say, a PHP app that wants to stream stuff? I use https://reactphp.org/ https://reactphp.org/ for websockets in PHP (so I can have a shared codebase with my main app, etc). I don't think I understand how this would look on the server-side. I'm interested to understand how it would look like to support this in Caddy (I'm one of the core contributors).