

ReconnectingWebSocket - joewalnes
https://github.com/joewalnes/reconnecting-websocket/

======
tinco
Does not even back off. I like the idea of offering libraries that provide
some abstraction over standard libraries, but what's the use if it's just the
most trivial solution that's unusable for any production situation?

~~~
joewalnes
Author here: That's a good feature request. I shall implement a truncating
exponential backoff algorithm tonight (maybe tomorrow).

I've been using this in production for over 2 years and my load levels have
not caused any usability issues (even without backoff). But no doubt for
heavier sites, this will be an excellent feature, so thanks for suggesting it.
If you have other feature requests, please add them to the issue tracker as
I'm more likely to notice them: [https://github.com/joewalnes/reconnecting-
websocket/issues](https://github.com/joewalnes/reconnecting-websocket/issues)

In answer to your question - the use of an abstraction is to allow new
features (like the one you suggested) to be added in one place so individual
users can easily make use of the additions.

~~~
tinco
Fair enough, thanks for publishing :)

------
jamespitts
Always important because our beloved websockets are fragile!

socket.io has it built in, but in various projects I had to hoist my own
reconnect functionality on top because reconnects kept failing.

engine.io aims to be more reliable than socket.io, mainly due to connecting
via the fallback methods first, then establishing a websocket connection. I
have not used e.io yet but intend to soon.

[http://stackoverflow.com/questions/9610951/how-is-engine-
io-...](http://stackoverflow.com/questions/9610951/how-is-engine-io-different-
from-socket-io)

------
nawitus
Socket.io is a decent WebSocket wrapper which also reconnects, and of course
has lots of other features.

~~~
james33
Socket.io used to be good, but it is littered with bugs and has been promising
1.0 for nearly 2 years without a single update. We switched to SockJS a few
months ago and haven't looked back.

~~~
atrilumen
Indeed. And Primus is nice if you want fallbacks and additional features (like
reconnects with randomized exponential back-off).

[https://github.com/primus/primus](https://github.com/primus/primus)

------
pornel
One of the nice things about EventSource (server-sent events) is that it
reconnects by default, and error recovery logic is handled by the browser.

------
DanWaterworth
This seems a bit naive. No ping/pong, no mention of what happens to messages
in transit when the connection drops.

~~~
joewalnes
> No ping/pong

Author here.

Are you referring to the ping/pong message frames in the WebSocket transport
protocol, or just a general heartbeating protocol layered on top of
WebSockets?

If it's the former, then there's nothing ReconnectingWebSocket can do here as
this is not exposed by through the standard JavaScript API. Even if it was
exposed, I'm not entirely sure what it would do.

The latter requires a custom protocol built on top of the user's WebSocket
messages. This would require additional code on the server to process the
messages. Libraries would have to be created for the various server side
WebSocket implementations. It's a much messier abstraction, and I'd prefer
this library to stick to one thing and do it well.

> no mention of what happens to messages in > transit when the connection
> drops

In this regard it behaves exactly like a regular WebSocket connection - the
message is lost. All this library care of is ensuring that a new connection is
opened.

~~~
DanWaterworth
> Are you referring to the ping/pong message frames in the WebSocket transport
> protocol, or just a general heartbeating protocol layered on top of
> WebSockets?

I'm talking about a protocol layered on top, for exactly the reason you state.

> In this regard it behaves exactly like a regular WebSocket connection - the
> message is lost.

But it doesn't, with a regular WebSocket connection, you know that if a
subsequent message is received and responded to, all previous messages were
also received.

> It's a much messier abstraction, and I'd prefer this library to stick to one
> thing and do it well.

It doesn't and can't. What you've created is completely trivial. If it was
indeed better, it would be the behaviour of WebSockets by default.

------
tantalor
No tests?

------
patrickaljord
That's what I use. Works as advertised. Should be part of the spec I think.

