4 ms·
> The bytes within each stream are ordered, reliable, and can be any size; it’s nice and convenient. Each stream could be a video frame […] But you can tell the
by thomashabets2 2y ago
> The bytes within each stream are ordered, reliable, and can be any size; it’s nice and convenient. Each stream could be a video frame […] But you can tell the QUIC stack to focus on delivering important streams first. The low priority streams will be starved, and can be closed to avoid wasting bandwidth.
Is the author saying that with QUIC I can send a "score update" for my game (periodic update) on a short-lived stream, and prevent retransmissions? I'll send an updated "score update" in a few seconds, so if the first one got lost, then I don't want it to waste bandwidth retransmitting. Especially I don't want it retransmitted after I've sent a newer update.
- gnfargbl 2y agoI think you're looking for RFC 9221, "An Unreliable Datagram Extension to QUIC."
- swiftcoder 2y agoYou don't need datagrams for this. You can set the stream to discard itself as soon as packet loss is detected
- crote 2y agoThat doesn't quite provide the same experience, does it? For something like a scoreboard you don't want the message to be discarded once any packet loss is detected. As long as message N is the most recent one, message N should be retried until it succeeds. You just want to stop retrying N once N+1 becomes available - or ideally even successfully delivered.
- swiftcoder 2y agoIn a game context, where we're spewing state updates out 10-60x per second, there is always a newer packet in flight already, so discard-on-loss produces the same result. In your scoreboard example, you probably just want an actually reliable stream for that - it's not like scores are rolling in so fast that it's beneficial to deal with it as unreliable.