4 ms·
Interesting idea I had: why not have many QUIC streams?
by daurnimator 10y ago
Interesting idea I had: why not have many QUIC streams?
- areed 10y agoAre you thinking one stream per packet?
- endianswap 10y agoYou could have a pool of them, right? Or would you have to actually tear it down after each packet
- daurnimator 10y agoMaybe. Why not?
- arkadiyt 10y agoThis would be the same as having a single QUIC stream, since QUIC already supports multiple data streams. The author addresses that with "Unfortunately, while head of line blocking is eliminated across unrelated data streams, it still exists within each stream."
- PeterisP 10y agoHowever, you could use a pool of x streams; when sending an update for the tick 't' then use the (t mod x)th stream, and thus if one stream becomes blocking for some time then you do receive the next update (since it's using a different stream) and you can treat it something as (1/x) rate of UDP packet loss.
- awqrre 10y agobut QUIC uses UDP?
- Matthias247 10y agoI think the only equivalent to UDP would be: 1 QUIC stream per packet, which avoids blocking inside a stream. I'm not into QUIC, but I guess creating and managing a (temporary) stream would have a lot more overhead than just sending an encrypted UDP packet. The other downside is that the browser (currently only chrome anyway) would present QUIC to the user only in form of QUIC streams with HTTP on top - which means the browser would reject any streams with non HTTP content and there's no API in Javascript for working with other content. The XHR and fetch APIs will utilize QUIC but only for HTTP on top of it. This means for transmitting unreliable and potentially unordered packets we would need a new browser API anyway. The webrtc data channel API allows to read/write this kind of data, but it's however bound to the webrtc protocol stack (SCTP/DTLS).