Synchronize data between browser tabs

Based on cookies, for sites with a common superdomain

I want to share how this was done for one project. The difficulty of using other well-known methods was that the project was not tied to a single domain name, but was localized on a grid of subdomains. That is, the project sites were located on the third level domains. This circumstance caused some inconvenience due to the Same Origin Police.

What is synchronization and what is it for?

Developers who have not yet encountered similar problems will probably be interesting. Imagine a web service (for example, a social network) that should inform the user online about various “new messages”, “new friends” and the like. Web service, tracking online index, any, Dow Jones, or God forbid, the most MICEX.

From the pages of such projects, constantly, with a certain periodicity, requests are sent to the server to obtain relevant information. Moreover, some services establish a permanent connection with the client in order to keep this client informed of their dark server business in real time.

The sore spot of such systems begins, oddly enough - with browsers. From browsers that support opening pages "in a new tab." And it is even more painful when in the project, for various kinds of information, there is a separate type of pages. (but this is a completely different story - the history of design).

In fact, it’s really inconvenient for a user to constantly click on links from the current page in order to see “well, what grade did I get there”.
And the user first opens one tab, for navigation, then the second tab, for tracking ratings, then the third - for tracking new messages. The number of simultaneously open tabs is directly dependent on the size of the user's desire to “control everything”.

How many servers do you need to quickly process a request from each client from each such open page? Especially, if the requests are asynchronous and with some periodicity.

Both growing projects and dinosaurs swallowing the web are faced with the need to solve such problems.

To solve this problem, apply at least two options:
- Increase server power, thereby reducing the processing time of the client's request. Few can afford it.
- Or “reason” requests from the client himself, which from any glance seems to be more optimal and more expedient.

Why Cookies?

Local Storage (and its modifications), which is gaining popularity, did not fit for the simple reason that it was also imposed on the rule of domain restriction (same origin policy). In addition, it was necessary to monitor the status of active (open) tabs, which requires an additional share of resources. And, everything else, it works, so far, not in all browsers. For the same reasons, Flash also did not have much hope, as well as other tasty features. A good algorithm, by the way, was described here .

In general, after many days of beating his head against the wall and gnawing the edges of office desks, I remembered an ancient and native browser-based mechanism - Cookies.

Scheme of work

1. Loading page
   The current page ID is determined, and its own cookie is set (checked).
   The interval is set, during the operation of which, the ability to make a request to the server is checked.
   
2. Interval trigger
   We get the minimum ID of the open page (from cookies).
   If the minimum ID is its own ID, then only in this case a request is made to the server to receive data.
   Otherwise, we check the readiness of the data, and collect them if required.
   Do not forget to update the self-identifier.
   
3. Request to server
   Nothing special happens here, except that the server response does not contain normal data, but only sets a cookie with the result. In my case it was enough.
   We bypass all cookies set for tabs, and we define their value as "ready".
   
4. Data retrieval
   In the case when the minimum ID does not match its own ID, the value of its own cookie is checked.
   If its value is “ready,” this means that the data has been safely received and it is necessary to collect it.
   We collect data and process it in the context of the current page.
   

Special features

• Cooks have an excellent property — a lifetime that doesn’t need to be tracked — the browser monitors this.
  
• When you open a tab, the tab "marked", setting a cookie with its ID, the lifetime of which is limited.
  
• Cookies are set with a lifespan of slightly longer than the self-refresh interval.
  
• The server response is also set to cookie. In my case, this is a small amount of data that serves only as an indication for action.
  
• If the tab is not the main tab, then during the interval triggering, the tab only takes data from the cookie storage and processes it.
  
• The closed tab stops supporting its cookie and the cookie dies safely. Management intercepts before any open tab.
  
• Cook with data is destroyed before the request to the server. By this time, all other tabs have time to process it.
  
• In order to ensure the safety of its own cookies, the main tab, when requesting the server, reinstalls the cookie with its own ID.
  

Now, after a lot of experiments, I think that there is a place where fantasies can roam to optimize this mechanism.

The method was developed for the messenger, so a cookie was also installed for the messenger itself, which indicated in which tab the messenger was opened. When the interval triggered, the tab checked, including which tab the messenger was open in and whether it was open at all. And she closed it in her house, in case she wasn’t the “mistress” of the messenger.

Synchronization of the state of the messenger was carried out using Local Storage. In case of its absence, there was nothing to do, how to make a request to the server to get the last state.

Lynching

I'll start with the shortcomings:

• The main disadvantage is that all the baggage of cookies is sent with each request to the server.
  
• The second and equally important drawback is the limitation of the amount of data in the server response. As you know, the maximum amount of one cookie is ~ 4 kB (in ancient IE, this is the total volume of all cookies for one domain). That is, “our communication” is limited to specifying actions and passing the necessary parameters.
  
• This mechanism is valid within only one browser.
  
• The method is not yet well established. The code is constantly updated, as many trifles are revealed, both negative and positive, but requiring optimization.
  

Advantages:

• Cross platform Perhaps this is quite a significant positive circumstance. The cookie mechanism is supported by all browsers without exceptions.
  
• The care of tracking the “on / off” tabs is assigned to the native browser function. This has eliminated problems with beforeUnload functions that work incorrectly in some browsers, along with other not fully standardized features.
  
• Minimum complexity. The method does not require any SharedObjects and other WebWorkers. As well as their add-ins, which make the use of these features cross-browser.
  

For more detailed acquaintance with the described method, you can download an archive copy .

PS: Archived draft version.

PPS: UPD 10/23/2014 version 2.0 with blackjack ...