2 ms·
> We can’t reliably say “the next message” received on the stream is the result of the previous command since the server could have sent any number of messages
by lxgr 2y ago
> We can’t reliably say “the next message” received on the stream is the result of the previous command since the server could have sent any number of messages in between now and then.
Doing so is a protocol decision though, isn't it?
If the protocol specifies that the server either clearly identifies responses as such, or only ever sends responses, and further doesn't send responses out of order, I don't see any difference to pipelined HTTP: The client just has to count, nothing more. (Then again, if that's the use case, long-lived HTTP connections would do the trick just as well.)
- scheme271 2y agoWhat happens if a message somehow gets lost? Dropped packets, error, etc? Or is that completely precluded by using http streaming?
- lxgr 2y agoTCP provides a lossless in-order stream, and errors are corrected at the layers even below that, so HTTP and WebSockets are equivalent in that regard.