3 ms·
True. But it’s also true that trying to shoehorn every use case into TCP streams is counter productive. A stream API can layer over UDP as well (reading in ord
by mlhpdx 8mo ago
True. But it’s also true that trying to shoehorn every use case into TCP streams is counter productive.
A stream API can layer over UDP as well (reading in order of arrival with packet level framing), but such a stream would a bit weird and incompatible with many stream consumers (e.g. [de]compression). A UDP API is simpler and more naturally event (packet) oriented. The concepts don’t mix well.
Still, it would be nice if they browser supported a UDP API instead of the weird and heavy DTLS and QUIC immitations.
- drysart 8mo agoThe browser does have a UDP data stream available for applications to send arbitrary bytes over UDP; it's part of WebRTC.
- mlhpdx 8mo agoWhile Web RTC is built on UDP, it does not allow sending arbitrary UDP. It's DTLS, perhaps encapsulating SCTP, and DCEP.
- kaoD 8mo agoTCP or UDP are orthogonal to this, so the original comment feels like a non sequitur. These streams are not network streams and could be a file, chunks of procedural audio, or whatever.
- mlhpdx 8mo agoI agree, the stream concept should be (and is) very general and ideally cover all these cases - any “bytes producing” source. I was trying to be open minded about that and conceive a stream API over a UDP socket. It’d work IMHO, but be a little odd compared to an event-like API.