Re-connection Strategy

Awesome Library.

I was taking a look at the re-connection handler and noticed it just takes a static delay before attempting to reconnect.

I usually like to use some form of re-connection strategy to control how a re-connection occurs for example an Exponential Back-off.

Would this be a suitable feature addition?

To keep the module size down the constructor could take a function:

new Sockette(..., {
  reconnection: (attempts, maxAttempts) => Number
});

[ghost]

If your server can’t handle a couple of reconnects then you have serious problems server side. First off, even if you spam a server with tons and tons of SYN packets, the Linux kernel will just discard any such packet it cannot handle, fully according to TCP spec. The user space process will not even see those connection attempts, and the sender will just resend them in exponential backoff ways until the server can handle them. You don’t need to reinvent the wheel by implementing that same logic once again on top because it doesn’t make any difference. Latency + sender backoff is already achieving this for you. Also, any well-written server can handle millions of connections with no problem at all. Don’t let Socket.IO marketing buzz become what you call “source of truth” because those kind of projects rely on nothing but fancy words and marketing bullshit to make you think they actually achieve anything.

[ThisIsMissEm]

Hi! From someone who’s once built large scale websockets as a service infrastructure (many year ago), you’ll definitely want to introduce some jitter on reconnection, otherwise you’ll get a thundering herd problem, as described by other commenters.

Even if this is for 100-700ms, it’ll still give you time to process the connection attempt, and then try to handle it. The alternative is that you end up overload various aspects of your infrastructure, making it impossible to restart any single component. Additionally, a simple Math.random() * 500 can really make a difference. Sure, it might still be 1000-3000 clients reconnecting at once, but that’s far more manageable than 10,000 trying at once, even if those 3000 don’t all manage to successfully reconnect, it still cuts load on the subsequent reconnect attempt.

It’s great to make a small module, but with caching and service workers, that becomes practically irrelevant if an intermittent issue will make it really hard to recover availability due to a thundering herd. People will generally be reloading your page less than they will be reconnecting.