4 ms·

ReconnectingWebSocket

47 points by joewalnes 13y ago

nawitus 13y ago
Socket.io is a decent WebSocket wrapper which also reconnects, and of course has lots of other features.
- joewalnes 13y ago
  Socket.IO is awesome, but my understanding is that Socket.IO also requires server side components as it adds a layered protocol on top of the WebSocket transport.
  - nawitus 13y ago
    That's true! It's another protocl.
- james33 13y ago
  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 13y ago
    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
patrickaljord 13y ago
That's what I use. Works as advertised. Should be part of the spec I think.
tantalor 13y ago
No tests?
DanWaterworth 13y ago
This seems a bit naive. No ping/pong, no mention of what happens to messages in transit when the connection drops.
- joewalnes 13y ago
  > 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 13y ago
    > 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.
tinco 13y ago
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?
- jmtulloss 13y ago
  I came to the comments to mention exactly this. A production solution needs to back off or you're going to DDOS yourself if your pubsub cluster falls over.
- joewalnes 13y ago
  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 13y ago
    Fair enough, thanks for publishing :)
pornel 13y ago
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.
jamespitts 13y ago
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-different-from-socket-io http://stackoverflow.com/questions/9610951/how-is-engine-io-...

47 points by joewalnes 13y ago

nawitus 13y ago

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

joewalnes 13y ago
Socket.IO is awesome, but my understanding is that Socket.IO also requires server side components as it adds a layered protocol on top of the WebSocket transport.
- nawitus 13y ago
  That's true! It's another protocl.
james33 13y ago
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 13y ago
  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

patrickaljord 13y ago

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

tantalor 13y ago

No tests?

DanWaterworth 13y ago

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

joewalnes 13y ago
> 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 13y ago
  > 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.

tinco 13y ago

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?

jmtulloss 13y ago
I came to the comments to mention exactly this. A production solution needs to back off or you're going to DDOS yourself if your pubsub cluster falls over.
joewalnes 13y ago
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 13y ago
  Fair enough, thanks for publishing :)

pornel 13y ago

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.

jamespitts 13y ago

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-different-from-socket-io http://stackoverflow.com/questions/9610951/how-is-engine-io-...