An updated version of Google Cloud Messaging was shown on Google IO. An API version for iOS was presented, a report on the number of notifications, applications, etc. was displayed. the audience was elated. Everything was good, until 2-3 days ago GCM in chrome did not completely fall off. More specifically, only about 2-10% of push messages arrive.

The problem affects both Google Chrome add-ons and sites that send Push via Push API using Service Workers. Our project hit right on two fronts in the end, receiving messages only works in Chrome on Android and through the application on Android. An implementation is being developed on WebSocket to work with an open tab.
More under the cut.

')

Identify the problem

At first, I turned one of the users. Notifications did not work for him either via Web Push or through the add-on in chrome. At the same time, the notifications in the supplement worked fine for me, but they did not work in Web Push after I turned them on. Here, the coverage of the problem on the service users was immediately clear - the old tokens worked fine, the new tokens simply refused to accept messages.

We thought it was a temporary problem and waited about half a day. On the network, few people even noticed this problem, but we came across a freshly created topic in the Android-GCM group and collectively dropped a problem report there. Next, one of the Chrome developers described the problem in the Chrome repository . The developers have promised to otdebazhit this problem with the team GCM.

This problem does not depend on the browser version, operating system, or other parameters, a problem in Google servers. The only exception is Android - it seems to use the client built into Google services GCM and everything works fine.



The above is a log from chrome: // gcm-internals (by the way, not many people knew about the possibility of debugging GCM in Chrome)
Google just stopped sending the FROM field for some messages.
Therefore, the messages could not find the application.

It is not entirely clear how in such a large company, such a project as GCM gave such a failure, and even for such a long period of time. The problem is still not fixed.

All sites with working with GCM are now inoperable, the same Roost or Pushover also cannot send notifications.

Limitations of current decisions

And here it is interesting that - at the moment, judging by the data from the network, it is impossible to use a third-party Push-service in Google Chrome or other browsers. Moreover, now each browser has its own protocol of Push-notifications and there is no unified API. Service Worker does not support working with sockets - it only responds to the push-service embedded in the browser.

I believe that it is not entirely correct in the age of open technologies to create closed solutions for such ordinary things as notifications. Sites should be cross-browser, and not depend on the protocols of individual decisions of the manufacturer.

This article has more informational character, because many are not aware of this problem so far. And also I would like to hear a discussion on the topic of open solutions and their development, is it possible now to send notifications to users cross-browser somehow? Is it possible to use our own server in this solution, and not browser development servers?

On the one hand, I support the general solution when a single process of obtaining new data is running in the browser. It saves energy. But on the PC it is not so important. Especially, if there are common alternatives that everyone can use - this will solve the problem.
It is important to understand. that in the browser, and so work a bunch of tabs with background processes, updates, etc. and even a dozen raised sockets in Service Worker will not make a large load for computers, especially since for most of the users, more than 10 are not needed.

Moreover, on mobile devices, Google could convert socket notifications to GCM or something similar.

PS Problem fixed