I am currently building a WebSocket-based instant chat web application, it has more than one page. Every time users refresh or click a link to another page, WebSocket has to be reconnected. Is there a solution to avoid this?
If you refresh the page it will need to reconnect, i dont think there is a way around it.
I would recommend not using page-load to navigate between pages, but to build a single page application.
If you cannot do that in any way, maybe you can have your application in a frame, and the outer html will have the socket. that could work.
You might be interested in this blog post: WebSocket - persistent across page loads?
This discusses the issue and options in depth.
Disclosure: I work for Tavendo.
Related
According to this post https://code.google.com/p/chromium/issues/detail?id=429419 as well as some testing I did to verify the limit is real - I understand that number of WebSockets I can open is limited.
Problem is that I sometimes need more than 30 websockets, because a user might open 30 tabs.
I was wondering what would be the best possible way of maybe sharing a pool of webSockets between different tabs. Here are some ideas I had in mind, and I would love to hear other possible ideas:
Allocate a webSocket pool in one main window, as a globally reachable element and then make sure all other tabs are children of that main page. Then I can use an inter-tab communication:
window.parent...
Problem is that not all tabs are created as child windows of the main window, and that main window might be closed.
Allocate a webSocket pool somehow "in the local storage" - I am not too familiar with the local storage, but I think that at the very least it can hold somehow a reference to a master tab that is currently managing the webSockets. Every once in a while, other tabs try to set themselves as a master tab.
I know its sounds awful and cumbersome. But how possible is it to write a thread/proccess safe code when accessing the local storage? Any example will be appreciated.
Would love to hear any other suggestions you might have.
Number 2 won't work, because LocalStorage is limited to string types.
I would recommend looking at ServiceWorkers.
A single service worker can control many pages. Each time a page within your scope is loaded, the service worker is installed against that page and operates on it.
This sounds pretty close to what you want. Register a ServiceWorker that simply accepts messages and rebroadcasts them to clients - any page from your domain. So you can have one main page that creates the WebSocket connection, and every time it gets a push it will broadcast a message through the ServiceWorker messaging system. Other tabs can pick up on it as needed.
Alternatively, you could use a shared WebWorker on the same principle. Just install it as a messaging system that broadcasts the messages from your WebSocket.
These aren't exactly the intended uses for these technologies... but if it works it works.
I had a specific questin about angularjs with websocket. I currently have an application that utilizes a websocket to communicate with a server, this is all nice and dandy - and when I move around pages in angular the websocket persists throughout all of the routes which is neat. Unfortunately the problem is that if the user refreshes the page (for some dumb reason), the websocket disconnects. I was wondering what the best method of handling this is. Should I just have an alert when the user tries to refresh, can I somehow detect that the websocket is closed when the page is refreshed and start a new one? I'm just wondering what the best practice for something like this is.
Thanks
There is nothing you can do, if the user refreshes, it is like restarting an application, all the bootstrapping happens again and connections are created again.
You can use javascript:onbeforeunload to warn the user that if refreshes or leaves he will lose the connection. But your users will hate your for that, it is very annoying.
Consider as well, that the user may open several tabs.
Starting a new connection is the best way. Just make sure that the user can somehow recover his context. If there is a different context per tab, then you will have to put a connectionID parameter in the URL to persist it through refreshes, and if the context is per user session, then a cookie with the session ID will do.
I'm just getting started with Pusher and so far everything is great.
But I realize that as my user opens and closes, or clicks on an internal link in my site, the connection automatically disconnects as the page unloads.
This would make the user connect and disconnect every time he navigates to a new page.
Is there a way to keep the user's subscriptions and connections persistent as he travels through my site?
Edit: Just to clarify, I understand the behavior that Pusher disconnects the moment the user closes his browser or page. I was just wondering how do we keep a connection alive if the person visits another internal link within the same site. Or is disconnection the best practice? If so, why?
As #devnull69 says, for the moment you would need to create your application so that it didn't perform standard page navigations - you would build your app as a SPA (single-page-application). That way there are no page unloads and loads between page navigations.
It may be possible to persist a connection between page loads by using shared web workers. But as CanIUse demonstrates, browser support isn't perfect yet.
Pusher does have plans to offer message history which would mean that any messages missed during page loads can be fetched upon reconnection.
Also see:
How to maintain a WebSockets connection between pages?
Do Shared Web Workers persist across a single page reload, link navigation
The only workaround would be to switch from regular page refresh to Ajax. This would enable you to keep up the websocket connection while loading only the part(s) of the page that change using Ajax requests.
I have my NodeJS and Socket.IO server running perfectly, however I notice that a socket disconnect and reconnect occurs every time I refresh the browswer page or navigate to a different page.
How do I make it so sockets persist between pages?
Thanks, I thought of that but wanted to avoid it as it's quite a big change for the system I'm making and would be a fair bit of work.
The only thing the socket connects/disconnects will effect is a "users logged in" counter. But I think I can get around that with a setTimeout on the Node server, so if a socket disconnects and reconnects within 2 seconds, the counter won't change. Is that the best work around in terms of this counter?
You can't really do that: network connections do not survive page navigation or refreshes. If you really really care you'll basically need to build a single page application.
you could use AJAX to navigate between the pages, to avoid the page refresh/socket disconnect
We have a book reading application and I have been tasked with implementing basic chat functionality. We have chosen openfire as the chat server. My question is, while reading a book, when the user turns the page, this does a complete page refresh. How can I keep the chat going across those refreshes? I don't want to bump a user and make them rejoin. Any ideas of the path I should take to implement this? We would in theory like to drop in a client into the page and it works with minimal effort. Anyways, are their clients that persist across refreshes?
Web pages are stateless. They cannot by themselves propagate data from one load to another. For that, you need to use cookies, and/or server-side sessions. Once you've got a user logged in and a login cookie/session token established, you can SIMULATE the chat being unbroken.
Basically, you keep the state of the chat in the user's session file, and update as necessary. That way, whenever the page is reloaded or they navigate to another page, the chat's state "just follows along", making it appear it was never gone.
Use AJAX + postate/onhashchange effect for all of the pages on the website. This way the page itself (the view) can change, but the content wrapping around it (header + footer) won't change.