Dropped stream connection #385

Closed
mmzeeman opened this Issue Aug 13, 2012 · 8 comments

Projects

None yet

4 participants

@mmzeeman
Member

If you have configured your site to use comet via sub-domain, browsers with websockets can experience a dropped stream connection.

The problem is this. Say you have a site called mysite.com and have setup the comet stream to connect to nnn.stream.mysite.com, the following can happen with a browser with websockets support. A lot of things happen in order to setup a stream connection. I hope the following will explain the failure scenario I found.

  1. The browser sets up a websocket to mysite.com

  2. Network glitch or something else which drops the websocket connection.

  3. Zotonic.js sees the dropped websocket connection and tries to re-connect to mysite.com once. (If there is a temporary network glitch this is highly likely to fail again)

  4. 3 failed. zotonic.js tries to setup a comet connection as a replacement for the failed websocket. This is configured via a subdomain.

  5. Browser tries to retrieve the page 123.stream.mysite.com/comet/subdomain.

6a) If 5 fails, due to the same network glitch, zotonic.js doesn't try again to reconnect. The stream is dropped and not retried.

How can we make the stream more robust?

Should we setup the websocket stream via the subdomain page? This would make it more robust because the browser can skip stage 5, and just switch over to comet, which will be retried.

@arjan
Member
arjan commented Aug 13, 2012

Are you sure this is related to subdomains?

In a mobile application I have experienced the same: sometimes the connection is not restored between a user putting the phone in standby and then after a while waking it up again.

@mworrell
Member

This sounds like a common problem in the retry strategy and how we added web socket support.

Maybe it is better to:

  1. Keep using web socket when it did succeed before (apparently browser is fine)
  2. Keep trying with some interval (maybe a small note/image on the screen that we are still trying?)

And (2) irrespective of the kind of connection.
We can use some fallback in the try frequency, after a while once a couple of seconds should be enough.

@mmzeeman
Member

That is another problem. That can happens when the page-session dies for some reason. Not only because of errors, but it could also be a server restart, or a regular timeout (suspended laptop is turned on after an hour). In that case you will silently get a new page-session, but if there are signals, they are not re-connected. If that happens there should be page-reload. This is more a problem with the stream js code itself.

@kaos
Member
kaos commented Aug 13, 2012

Perhaps add a check after a successful reconnect that it's the same page
session serving the connection... and reload if not.

2012/8/13 Maas-Maarten Zeeman notifications@github.com

That is another problem. That can happens when the page-session dies for
some reason. Not only because of errors, but it could also be a server
restart, or a regular timeout (suspended laptop is turned on after an
hour). In that case you will silently get a new page-session, but if there
are signals, they are not re-connected. If that happens there should be
page-reload. This is more a problem with the stream js code itself.


Reply to this email directly or view it on GitHubhttps://github.com/zotonic/zotonic/issues/385#issuecomment-7687633.

@mworrell
Member

Problem with the session restart is wiring the new session cookie. We use http only cookies, so the javascript can't set the cookie.

Maybe we have to find a secure way around that, then you don't need to reload the page.

Regarding the signals, maybe we can have a list in javascript on the page? Then you can re-wire them when the session changes. (Sounds like we need observers here... can.js / knockout.js? )

@mworrell
Member

Is #368 related?

@mmzeeman
Member

No it's different. This is a client side issue #368 a server side issue.

@mworrell
Member

The streams are redone with z_transport, closing this issue.

@mworrell mworrell closed this Feb 16, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment