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.
Related
The question is how to connect two local scripts (with no interner-connection at all). The whole task is controlling one opened local page from other opened page (same or different browser). That couldn't be bridged through web-server.
I have no idea who to make this except writing to localStorage on one page and constantly checking from another (or using a handler).
I have had a similar requirement, and localStorage is the only reasonable option I found. You could persist some info on the server, but if you need real-time update or frequent communication between pages, the server side methods begin to slow down the application.
I have no idea who to make this except writing to localStorage on one page and constantly checking from another (or using a handler)
With localStorage, you don't have to constantly check the state of storage. It does provide a storage event that you could bind to:
window.onstorage = function(data) {
console.log(data);
}
This event would be triggered when you modify the storage through another tab. Something like,
localStorage.setItem('key','value');
So localStorage can, in principle, serve as a basic communication channel between two tabs - running on the same domain.
Some libraries are also available that provide advanced features based on localStorage. I have used Crosstab, in past, and it works pretty fine for most purposes.
I have been searching for a way to communicate between 2 popups with JavaScript.
All I have found so far has been questions about how to communinate between Main and Popup, but I want Popup 1 to update Popup 2. Update it's URL or other stuff.
Any idea?
While you can't have each popup directly communicate with each other, you can use the localStorage storage event for each popup to set/get information from a single source:
One solution, assuming it is running on a server, would be to use web sockets. With web sockets you could instantly communicate between all open processes to the server. This avoids constantly polling your server for changes. You can also use something like Realm to get live updates.
This site does specifically what i want to do http://en.lichess.org/. Users join the chess game and after some seconds the lobby refreshes and there are new games added. Does anybody know how can i do that ? or at least give me a starting point?
In the traditional method (and for older clients) you would do 'long-polling' which would fire every few seconds asking for updates. The new way is through web sockets. The page you reference uses websockets.
So if you have a modern browser, then you can use Websockets and the server can push data to the browser (same with EventStream). Then that message is read on the browser and the proper view is updated.
There are some frameworks which do this stuff for you, biggest one I can think of is Meteor
See the dev console:
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 trying to understand how to work properly with IndexedDb and one thing I can't understand is how are we supposed to manage the connection.
When I started playing with IndexedDb, I created a connection once the page is loaded and let it open. So the same connection was used with every request to the database until the page was reloaded.
Letting a connection open seemed like a bad practice (which is what I want to confirm) so I changed my code to open the connection only when needed (when retrieving data for example) and close it immediately after.
It doesn't feel like the API was supposed to be used that way as I felt like fighting it when modifying my code (which might simply be because I have not yet fully understood how to work with it).
Can someone please explain to me the best practice when working with IndexedDb ?
I don't really have a best practice about it, but when you are working with databases on a server you mostly close the connection when the action is completed, and you open one for every action you want to do. In the library I builded to wrap the indexedDB I also choose to open and close the db connection for every action. That way I'm sure that no connections stay open, and it gives me the flexibility to change the db structure without having to worry about all the open connections.
What are the issues you are suffering with when opening and closing the db connection for every call?