例如，我想使用 socket.io、longpolling 等通过多个选项卡刷新聊天消息......无论我有什么......为此，我只想对所有选项卡使用单个连接。我怎样才能做到这一点？我可以将公共数据存储在 localStore、cookie 等中......而且我需要某种信号量，它只为其中一个选项卡提供一个同步器资源，在该选项卡关闭后，它提供给另一个选项卡等。 ..这怎么可能？我想到的唯一解决方案是用 onbeforeunload 告诉 localStore 资源是免费的，但这并不适用于每个浏览器。还有其他选择吗？
问问题
3790 次
1 回答
8
The keywords in this problem is "inter-tab communication", "cross-window messaging", etc...
One solution is similar to long-polling: inter-tab-communication-using-local-storage/ Periodically ask the localStore/cookies for changes, and add a queue to allocate common resources (e.g. socket.io connection). You can use onbeforeunload or timeout to determine whether a tab/window is navigated away or closed. After that shortly the next tab in the queue will allocate the resource...
The second solution is to use "localStore storage events" for the same. In that case you don't have to periodically ask the localStore (if onbeforeunload event is available). According to this: localStorage eventHandler Doesn't Get Called storage events are designed to affect only other tabs, so they are a good choice for intertab communication. The only problem is onunload: local storage on window unload event . So because of the lack of onunload support the first solution could be better.
The third solution would be the usage of "shared webworkers", but they have not been implemented yet in several browsers (internet explorer), or they cannot open socket (firefox). So currently they are not an option, maybe 1-2 years later after bug fixes... Here is a demo - works chrome only - html5-shared-web-worker-examples.
The fourth solution would be window.postMessage, which has not complete browser support currently. I read about it in some sto questions, and they all wrote that postMessage is not capable for what we want. I did not check the exact details about that function, it does not worth the time I think... There is an example about cross domain cross iframe communication: Cross-Domain iframe communication but same domain cross window communication is not possible with that I think.
The fifth solution would be using cookies but in that case every tab should ping document.cookie because there in no cookie change event, like storage event in localstore. BNC Connector uses this approach.
The sixth solution would be using WebSQL. Its driver is async non blocking, so it would be better than localStorage, but currently it is not supported by firefox and msie.
Conclusion:
Nowadays - 2013.10.03 - the best option to periodically ping the localStore from the resource utilizer tabs. The other tabs should listen to the storage event of the timestamp updates. If that event does not come in time, than the resource utilizer tab has timeout, and the next tab in the queue should get the resource. Maybe later the onunload event or the shared workers will be reliable, but currently they are not good enough...
Solution:
I found an implementation of the approach described in the conclusion: intercom.js I added an issue about a general interface of resource sharing, but in my case the single socket.io resource is good enough...
于 2013-10-03T17:47:07.547 回答