7 ms·

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

by zxilly 2y ago

enneff 2y ago
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.
andai 2y ago
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 2y ago
  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 2y ago
    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.
    - deleted 2y ago
      [deleted]
  - andai 2y ago
    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 2y ago
Maybe authorization, illegal moves? Don't know the full protocol to know how they handle edge cases. They might just return a NACK
parl_match 2y ago
That just means that the message hit the TLS terminator. It doesn't mean that the backend logic received the state change.

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

by zxilly 2y ago

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

enneff 2y ago

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.

andai 2y ago

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 2y ago
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 2y ago
  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.
  - deleted 2y ago
    [deleted]
- andai 2y ago
  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 2y ago

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

parl_match 2y ago

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