The reality is that, being 52 years old and only having studied briefly in my distant past, my formal knowledge in Computing is actually lacking these days, and one subject which I know too little about, is how Push Notifications work. Back in my day, if a laptop was ‘asleep’ – i.e. In Standby – it was generally unable to be woken externally via WiFi, but did have hardware clocks that could wake it at scheduled times. Yet we know that mobile devices today, including Android and iOS devices, are able to receive push notifications from various servers, which do precisely that, and that this feature even works from behind a firewall. And so I can muse over how this might work.
I can think of two ways in which this can hypothetically work:
- The application framework can centralize the receipt of push notifications for the client device, to one UDP port number. If that port number receives a packet, the WiFi chip-set wakes up the main CPU.
- Each application that wants to receive them, can establish a client connection to a server in advance, which is to send them.
The problem with approach (1) is that, behind a firewall, by default, a device cannot be listening on a fixed port number, known to it. I.e., the same WAN IP Address could be associated with two devices, and a magic packet sent to one fixed port number, even if we know that IP Address, cannot be mapped to wake up the correct device. But this problem can be solved via UPnP, so that each device could open a listening port number for itself on the WAN, and know what its number is.
We do not always know that UPnP is available for every NAT implementation.
Approach (2) requires more from the device, in that a base-band CPU needs to keep a list, of which specific UDP ports on the client device will be allowed to wake up the main CPU, if that port receives a packet.
Presumably, this base-band CPU would also first verify, that the packet was received from the IP address, which the port in question is supposed to be connected to, on the other side, before waking the main CPU.
(Edit 12/19/2016 : Google can simply decide that after a certain Android API Number – i.e., Android version – the device needs to have specific features, that earlier Android APIs did not require.
Hence, starting from , or , Google could have decided that it was no longer a special app permission, for the user to acknowledge, to wake the device. Likewise, starting from some Android version, possessing a base-band CPU might have become mandatory for the hardware, so that the API can offer a certain type of push notification.)
Also, approach (1) would have as drawback, a lack of authentication. Any networked device could just send this magic packet to any other networked device, provided that both the IP address and the port number it is sensitive to are known.
Approach (2) would bring as an advantage, that only specific apps on the client device could be enabled to receive push notifications, and the O/S would be aware of which UDP ports those are sensitive on, so that the base-band CPU would only be waking up the main CPU, if push notifications were received and associated with an app authorized to wake the device.
Also, with approach (2), the mapping of WAN port numbers back to LAN port numbers would still take place passively, through port triggering, so that the WAN-based server does not need to know, what LAN-based port number the connected port is associated with on the client device.
But, approach (2) has as a real drawback, that a server would need to keep a socket open, for every client it might want to send a push notification to. This might sound unimportant but is really not, since many, many clients could be subscribed to one service, such as Facebook. Are we to assume then, that the Facebook server also keeps one connection open to every client device? And if that connection is ever dropped, should we assume that a sea of client devices reconnect continuously, as soon as their clocks periodically wake them?
There are ways in which information is publicly represented today, that leaves ambiguities to a reader like me. Specifically, public information sources will want to focus on how the most modern devices solve a problem, and to skip how earlier devices used to solve that problem.
In a way this is understandable, because as progress continues, we do not want to burden people unduly, to learn how outdated solutions once worked. But there are specific cases where the historical aspect should be explained. Push Notifications should be one of them.
I have recently read, that modern phones do not only have a main CPU, but also a base-band CPU. This is too vague for me.
I have a Samsung Galaxy S6 phone, which I know possesses a high-powered and a low-powered CPU – both of which are quad-cores – in a way Samsung is famous for, because Samsung has gotten this approach to save battery charge. If there was historically a base-band CPU, then logically, Samsung would have rolled its functions into the quad-core, low-powered CPU. This would mean that the high-powered CPU goes into standby, but that the low-powered CPU does not, and that therefore, the modern phone never really goes to sleep.
But what I really need to be told is related to the Galaxy S4 phone I used to have, and earlier phones. Those phones only had one powerful CPU that the customer was made aware of.
We need to know whether all those phones, including the earliest Android phones, required a base-band CPU as well, before we can really understand this subject.
It is possible to send push notifications to a Linux laptop via a client-socket, on the assumption that the laptop is neither asleep nor shut down.
(Edit 12/19/2016 : ) I suppose that another way in which Android push notifications could work, is through a single API function, but using a client socket. If that was the case however, this would also imply, that there exists a central server into which all active Android devices authenticate a connection, which will also route all push notifications to Android devices.
Such a server would need to accept an unusually enormous number of simultaneous connections, considering how many Android devices exist.
This would also seem to raise the question, of whether certain content-providers are paying Google for this service…