4 ms·
> Only the OS does not know the context, so it prioritises both streams equally. Of course there's prioritization options on socket APIs since forever (DSCP),
by toast0 19d ago
> Only the OS does not know the context, so it prioritises both streams equally.
Of course there's prioritization options on socket APIs since forever (DSCP), but usage is limited, because it requires coordination and coordination is hard.
Even with equal prioritization, when you overuse on the media connection and that results in packet loss and congestion window reduction, chat messages don't have to wait for all the dropped packets to be resent over multiple round trip times. If you're lucky the chat connection didn't see any of the loss, and even if you're not, you've likely got a smaller queue on your chat connection than your media connection.
This also doesn't prohibit client driven prioritization --- when connecting, get caught up on chat before processing media. Maybe pause media while sending chat messages or if server acks are slow. Server driven prioritization is hard, because probably your http media servers don't have information on the chat connection --- but if a client stops reading from the media connection, the server will get the message eventually.
- aboardRat4 19d ago>Even with equal prioritization, when you overuse on the media connection and that results in packet loss and congestion window reduction, chat messages don't have to wait for all the dropped packets to be resent over multiple round trip times. Well, again, it's merely an implementation detail. You could just open a second TCP connection using the in-band IM protocol, not some external HTTP. Or make your IM protocol UDP based. But really, that's what quic was designed for, which is also not new.