Is your feature request related to a problem? Please describe.
The current configurability of SocketLink reconnection is limited. In our case, the web socket can drift into an error state where no further connections would be possible (reconnection always fails), such as throwing the user out from the service altogether. While reconnecting is a good idea, we should be able to bail out from such cases (or at least prevent continuous bombardment of the API).
I was trying to extend the existing SocketClient implementation to add an 1) exponential backoff strategy and 2) a hard limit to connection attempts, but I simply could not do it without breaking the API.
Describe the solution you'd like
Could SocketClient expose a configurable RetryStrategy that could be consulted on whether a reconnect would be attempted? This strategy could e.g. store its own state and be informed about successful/failing connections. Encapsulating the implementation into a strategy would permit anybody to implement their way of handling reconnection.
A draft API could be something along the lines
abstract class RetryStrategy {
shouldReconnect(): bool;
onStateChange(SocketConnectionState state);
}
Describe alternatives you've considered
Tried extending the existing SocketClient, but failed as the required fields were private.
Is your feature request related to a problem? Please describe.
The current configurability of SocketLink reconnection is limited. In our case, the web socket can drift into an error state where no further connections would be possible (reconnection always fails), such as throwing the user out from the service altogether. While reconnecting is a good idea, we should be able to bail out from such cases (or at least prevent continuous bombardment of the API).
I was trying to extend the existing SocketClient implementation to add an 1) exponential backoff strategy and 2) a hard limit to connection attempts, but I simply could not do it without breaking the API.
Describe the solution you'd like
Could SocketClient expose a configurable RetryStrategy that could be consulted on whether a reconnect would be attempted? This strategy could e.g. store its own state and be informed about successful/failing connections. Encapsulating the implementation into a strategy would permit anybody to implement their way of handling reconnection.
A draft API could be something along the lines
Describe alternatives you've considered
Tried extending the existing SocketClient, but failed as the required fields were private.
Additional context