Shared Websocket connections over multiple tabs #628

Open
khugin opened this Issue Feb 24, 2014 · 7 comments

Projects

None yet

3 participants

@khugin

I'm trying to find a solution to avoid multiple connections over multiple open tabs. Instead, I'ld like to share the connection between them (especially since users tend to have up to 30 tabs open sometimes). Now, I'm apparently not the only one with the Issue, and after searching around for informations for a while, I found this 2 year old entry: https://groups.google.com/forum/#!topic/socket_io/FbHU7HvxK6U

Here, Guillermo Rauch writes:

24/06/2011
I have a solution outlined which will probably land in 0.9.

Now, I'm wondering: is it implemented? Does it work? I couldnt find any informations about it, and I'ld really like to solve the problem over socket.io instead of creating a strange localStorage hack to share a connection.

Thanks in advance, I hope there are some good news - would save me a lot of work ;)

@rauchg

Can you describe your proposed solution? I'm very interested in making this happen.

@khugin

Oh, if I'ld have one, that would already be great. Sadly, it seems to be quite difficult (especially when regarding IE). I hoped / thought this was already solved.

As far as my researches / tests went, there are 3 Solutions:

  1. Using SharedWorker's, but that only seems to work on Chrome and Opera, maybe on FF, but not on <=IE9. But still, as far as I could tell, this is probably the best approach. I didnt have the time to dig into it enough tough, to see how it could be used with socket.io.
    http://www.sitepoint.com/javascript-shared-web-workers-html5/

  2. The common solution (according to many SO threads) a while ago, was to use LocalStorage (basically having one connection, that saves all events while other tabs listen from them). But I'm quite sceptic about that one - especially performance-wise. I'm still reading about Issues with LocalStorage that causes the browser to freeze - and in my case it'ld be used for a chat (so, a high event-frequency) so I guess it'ld be too slow at some point.

  3. The third "solution", and the one I'll be probably be forced to use at the end, is to simply disconnect multiple connections, after the first one. Would be a shame tough, since that's not really a solution but just a workaround to avoid multiple connections.

As far as I can tell, simply re-using the already established websocket connections over different Tab's doesnt seem to be possible - so it always has to go over a master connection in the first tab.

Sorry, I had the impression that this was already solved somehow by that post 2 years ago, that's why I was asking ;) I wish I'ld already have found a solution, but it really seems quite difficult.

@kapouer

Bump !
https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
the idea is to check there isn't already a socket.io instance connected on same domain using postMessage. If there is, a "simple" relay must be done between new socket.io instances and the existing one.
Being bitten currently by a stupid limitation in webkitgtk (6 xhr per host, cumulated on all tabs !) i might try to test that idea.

@kapouer

Also when a "host" instance has its window closed, other instances must receive a signal to decide which one is going to serve as master.

@kapouer

For shared web workers, i came across https://github.com/gonzalo123/wsww

@kapouer

The two ideas combined could be great: use a shared web worker when available, fallback to sharing first window connection if postMessage is available between windows - that's everyone but IE<=9.

@kapouer

Hey checkout this sweet Cross-tab message bus for browsers !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment