How do I automatically retry when there is a connection error?

[Container-Zero]

Describe your issue
How to observe the link status after creating the first new WebSocket\Client. Automatically try to reconnect after a delay of a few seconds when there is a link error, and stop the connection when a certain threshold is exceeded? (Similar to curl's CURLOPT_RETRY)

[sirn-se]

The client will automatically (re)connect when used to send or receive messages, or when connect() method is explicitly called. So it would be fairly easy to implement a retry strategy when setting up the client interaction.

I will consider an internal retry strategy for future version.

[Container-Zero]

The client will automatically (re)connect when used to send or receive messages, or when connect() method is explicitly called. So it would be fairly easy to implement a retry strategy when setting up the client interaction.

I will consider an internal retry strategy for future version.

Oops, is there a good case for this?

It seems to be all I can do right now:

$count = 0;
do{
    try {
        $client = new WebSocket\Client($url,$header);
        $message = $client->receive();
        $count = 10;
    } catch (Exception $e) {
        $count++;
    }
}
while($count<10);

This doesn't seem very convenient.

[sirn-se]

An exception thrown by the constructor indicates setup error. This can never be restored by retry attempt, so keep the constructor outside the try/catch block.

On the other hand, exceptions thrown by the send/receive methods might be fully recoverable and should probably not count towards a max limit. The WebSocket\Exception\ClientException indicates failed connection, and could be eligible for retry attempt.

[Container-Zero]

internal retry strategy

I get it, but that doesn't seem convenient either, and I'm very much looking forward to the internal retry strategy.

[Container-Zero]

An exception thrown by the constructor indicates setup error. This can never be restored by retry attempt, so keep the constructor outside the try/catch block.

On the other hand, exceptions thrown by the send/receive methods might be fully recoverable and should probably not count towards a max limit. The WebSocket\Exception\ClientException indicates failed connection, and could be eligible for retry attempt.

For now I'm going to
$client->receive();
Replace it with the use of:

function receive_auto_retry($client){
    $count = 0;
    do{
        try {
            $message = $client->receive();
            return $message;
        } catch (Exception $e) {
            if (!$client->isConnected()) {
                $client->connect();
            }
            $count++;
            $error = $e;
        }
    }
    while($count<10);
    return $error;
}

Is this a better way to use it?

[sirn-se]

Given above snippet, I'm not sure what issue you're trying to solve. So instead I can give you an explanation what's going on and what errors might occur.

1

$client = new Client($url);

Initializes the client but does not connect to server

• If provided URI is invalid, a BadUriException will be thrown (not resolvable)

2

$client->connect()

Attempts to connect to server and perform handshake

• If it can't establish a connection with server, a ClientException will be thrown (possibly resolvable)
• If handshake fails, a HandshakeException is thrown (possibly resolvable)

3

$client->receive();

Attempts to read message sent by server, will call connect() if not already connected and possibly throw exception accordingly

• If message is invalid, a BadOpcodeException will be thrown (resolvable)
• If read attempt times out, a ConnectionTimeoutException will be thrown (resolvable)
• If connections has closed, a ConnectionClosedException will be thrown (resolvable)
• If any other connection failure occur, a ConnectionFailureException will be thrown (possibly resolvable)

What to retry

• The not resolvable will never succeed a retry attempt
• The resolvable can be retried, but using a counter would do more damage than good
• The possibly resolvable could be retried, but might never succeed so a counter could be beneficial

[Container-Zero]

I keep forgetting to add that my production environment is php 7.4, so I can only use version 1.7.0.
Thanks for the explanation, but I would like to follow up:

1. why might counters present drawbacks? What exactly are the drawbacks?
2. does not using $client->receive(); before using $client->connect() make the probability of reporting an error increase? If it does, why does this happen?
3. My wss server is capable of doing all interactions in one session, if I use the 'persistent'=>true configuration item, can I enable persistent connections to avoid doing a handshake connection to the server every time $client->receive(); and instead use a previously existing link as a way of enhancing the stability of the link?
4. Since I'm on version 1.7.0, does this mean I won't get future internal retry updates? I'll just have to fulfill those requirements myself?

[sirn-se]

Reading your 3) I think there is a misunderstanding how websockets work. Unlike HTTP, which always perform a connect/send/receive/disconnect series of operation (that could easily be retried on failure), a websocket connection will be kept open until the client or server explicitly close it. Once connected, you may perform any number of send and receive operations independently.

1. Some failures are non-disruptive. For instance, the receive() operation may timeout. This mean a message could not be read, but the connection would still be available for additional send/receive operations. Breaking your application after 10 timeout errors is unnecessary.
2. receive() will internally call connect() if not already connected.
3. The persistent setting means that your OS will attempt to keep the connection even if your application closes. But as mentioned above, even without it the connection will remain open until explicitly closed. Don't use this option unless you have good reason to do so.
4. The 1.7 will only have maintenance patches from now on.

[Container-Zero]

Reading your 3) I think there is a misunderstanding how websockets work. Unlike HTTP, which always perform a connect/send/receive/disconnect series of operation (that could easily be retried on failure), a websocket connection will be kept open until the client or server explicitly close it. Once connected, you may perform any number of send and receive operations independently.

1. Some failures are non-disruptive. For instance, the receive() operation may timeout. This mean a message could not be read, but the connection would still be available for additional send/receive operations. Breaking your application after 10 timeout errors is unnecessary.
2. receive() will internally call connect() if not already connected.
3. The persistent setting means that your OS will attempt to keep the connection even if your application closes. But as mentioned above, even without it the connection will remain open until explicitly closed. Don't use this option unless you have good reason to do so.
4. The 1.7 will only have maintenance patches from now on.

I understand it in general, thanks for the answer.

[UksusoFF]

In my case:
Create CLI command with Laravel.
It's keep long live connection till not failed.
Run command with supervisor.
Configure for autorestart when it fail.

Read more: https://beyondco.de/docs/laravel-websockets/basic-usage/starting#keeping-the-socket-server-running-with-supervisord

[indigoram89]

Thank you for great package! We are waiting for automatic reconnection functionality.

[indigoram89]

I did it like this way:

And reconnection:

[sirn-se]

Hi @indigoram89

This library will automatically connect/reconnect when sending, receiving or starting the listener.

However, subscribing to a websocket server typically means that the client send some initial messages for identification and/or configuration. So we can't provide a generic restart of a listening session - a client application need to handle the communication logic for the current service itself.

So if above code works for your application, you should stick with it. Some notes though;

• Instead of catching Handshake and ConnectionFailure, you could catch ConnectionLevelInterface. Both mentioned, and other connection-level errors, implement that interface.
• You probably want to put the client->start part in a while(true) or it will only attempt to reconnect once