[zxilly]

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

[parl_match]

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

[andai]

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.

[enneff]

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.

[mananaysiempre]

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.

[andai]

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.

[augusto-moura]

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

[enneff]

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.