That gets me to wondering why more streaming stuff isn't UDP with a little bit of ECC (sort of like CD audio vs. data CD). Maybe the ECC overhead is more than the TCP overhead.
https://www.rfc-editor.org/rfc/rfc9000.pdf
More stuff will be soon. Some already is.
...the speed benefits of UDP over TCP are based on the fact that you're NOT doing error-correction. A error-corrected UDP is much slower than raw UDP. QUIC, huh? We already have that - it is called Transmission Control Protocol (TCP).
https://docs.codavel.com/technology/
Reading over it, it's kind of like UDP+. Their info-graphics help explain it better than I could, so I won't.
Quality of service i'd imagine. Under heavy loads if your stream continues but your data loss exceeds 5-10% your going to complain.
You have bigger problems with those kind of losses. You probably would have trouble with TCP streams then, too.
Well I'm sorry faggot, I don't know correlations of % of packet loss verses stream quality. I just threw a percent out there. I trust that multi billion dollar multimedia companies know a bit more than you or I.
There are lots of protocols built on top of udp that add reliability as needed without taking on tcp entirely.
https://networkencyclopedia.com/real-time-transport-protocol-rtp/ one example
What I've never been able to figure out is why it isn't multicast
Wouldn't that only work for live streams? That won't work when you want your TV show to start streaming at 14:30 and the next guy wants to start watching at 14:37.
For sure. That's what I thought I was talking about. Even in the case of live streams, AFAIK, Multicast is rarely used.
(post is archived)