Hacker News Reader

Comment by zxilly | Hacker News Reader

I wonder why this protocol needs an ack? a websocket wrapped in a tls should be perfectly capable of guaranteeing the integrity of the message

View on HN

That just means that the message hit the TLS terminator. It doesn't mean that the backend logic received the state change.

You can verify this with ten lines of code and clumsy (a tool for simulating packet loss).

I tried this and not all the messages I sent arrived.

What do you mean? If you open a web socket connection it should behave like a normal TCP connection. All sent data guaranteed to be delivered complete and in order, unless the connection fails.

Unless the connection fails, at which point you have no idea when it failed. You know that the other side received all stream offsets within [initial, X] with X ≥ last received ACK, but other than that you have no idea what X is. Even getting the last received ACK value out of whatever API or upper-level protocol you’re using could be nontrivial, because people rarely bother.

I think I had it set up to auto reconnect. So I suppose the packets sent between "failure occurs" and "socket disconnected" were lost.

At any rate my conclusion was disappointment that if I actually want reliability, I need to implement my own ACKs anyway, meaning I'm paying a pretty high overhead for no benefit.

At least now there's UDP in browser with WebTransport. I haven't tried it yet, but I hear it's a lot more pleasant than the previous option WebRTC, which was so convoluted (for the "I just want a UDP socket" usecase) that very few people used it.

Maybe authorization, illegal moves? Don't know the full protocol to know how they handle edge cases. They might just return a NACK

So that the client knows the message has been delivered and handled by the server, which can make the UI indicate the state of the connection.

Reply on news.ycombinator.com