_tryReconnect for auth errors

[facundoolano]

Hi, I have a server to server setup where the client issues a login event right after connecting to the SCServer. The server depends on another service to perform authentication. If there's an error during the process, for example if the auth service is down, the server will respond with an error to the login event. In such case, I'd like for the client to wait for a period of time and retry the authentication, in the same way a reconnect is attempted when the connection to the server is lost.

I've found that the following code does what I expect:

socket.on('connect', function (status) {
  if (!status.isAuthenticated) {
    socket.emit('login', credentials, function (err) {
      if (err) {
        // auth failure, try to reconnect
        socket.disconnect();
        socket._tryReconnect();
      } else {
        // auth OK, setup other listeners
       // ...
      }
    });
  } else {
     // already authenticated, setup other listeners
     // ...
  }
});

But I feel a bit uneasy using the _tryReconnect method. I wonder if there's a recommended way to handle this scenario without having to rewrite the reconnect behaviour myself. If not maybe _tryReconnect could be exposed as a public method?

Thanks!

[jondubois]

@facundoolano You could just call socket.connect() instead of socket._tryReconnect().

[facundoolano]

But that would attempt reconnection right away wouldn't it? I want it to delay, then try to reconnect, then delay a bit longer, etc...

Now that I think of it, using socket._tryReconnect() after an auth error doesn't really work either; since the error is in the login event and not in the connection, it will always succeed on the first reconnection attempt, so it's effectively the same as wrapping a socket.connect in a setTimeout.

I was hoping to somehow reuse the logic of exponentially increasing delays to retry the login event, but I guess that's not possible.

[jondubois]

@facundoolano

If you want to leverage SC's autoreconnect, you could pass an error status code to the disconnect method - Some of the status codes are used by SC internally but codes between 4100 and 4500 are free for your own use. So you could go (example): socket.disconnect(4400, 'reason sring or object') - This will cause the client socket to emit an error event but you can handle the error.code (if it's 4400) or just ignore it.

Status codes between 4100 and 4500 basically tell SC that the connection was closed abnormally (due to reasons unknown to SC) and to try to reconnect using exponential backoff - They are 'recoverable' errors.

You can choose your own codes for various errors (Just make sure you stay within that safe range of 4100 to 4500).

[facundoolano]

Ok, I'm going to use that for now (it doesn't really do the exponential thing since the connection succeeds and the login fails again, but it's still better than doing a manual timeout).

Closing this.