How will websocket works when websocket client is too slow?
The above link is the problem I want to solve. My server will push a lot of data to client. So it is possible that client side consumes too slow.
I want to detect slow client in my springboot app by checking TCP buffer size. But I don't know how to check the size in Spring Websocket (Jetty 9.2.x). I can't find any interface related to TCP buffer in jetty websocket source code.
If I can't, is there any other way to detect slow client?
Sorry, you can't access the TCP buffer.
Jetty websocket is beholden to Java's networking.
What you want to know is the WebSocket write results in TCP congestion / backpressure.
To do this, you pay attention to the write calls.
With blocking WebSocket it just a simple matter of doing the write, it won't return until the write has completed. If it blocks then the write is likely TCP congested and you should back off from writing anything else.
With async WebSocket writes, you pay attention to the results of the write (either from the Future or the Callback) and don't write the next message until you have confirmed the current message has written successfully.
Failure to pay attention to the async write callbacks/futures results in message queuing (the queue has no upper limit and will grow to fit all available memory).
It's up to you, as a application using websocket, to decide what to do when you detect this slow write scenario.
Do you close the connection?
Do you drop some messages?
Do you queue messages at all?
If you do queue messages, do you have message priority or importance?
If a certain number of priority messages haven't been sent, do you then close the connection?
Do you hold onto those priority messages to resend when (if?) the client reconnects?
Do you have an expiration / timeout on the queued messages?
Removing messages that haven't been sent by X amount of time?