Two Hypothetical Ways, in which Push Notifications Could Work Over WiFi

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:

  1. 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.
  2. 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?

Dirk

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…

 

Print Friendly, PDF & Email

5 thoughts on “Two Hypothetical Ways, in which Push Notifications Could Work Over WiFi”

  1. I suppose yet another possibility could be, that each and every app is allowed to register a real push, without needing to be bound to a specific account, and that the app generates a token to do so. But this would have two drawbacks: (1) It would deplete the entropy pool of the device, constantly generating random keys, (2) any eventual base-band CPU would need to store a much larger number of keys, to compare the wake-up packet to.
    Also, rather than asking app designers to generate pseudo-random keys, it strikes me as more likely that the API will ask them to receive a token from one place, and to specify it someplace else – in object-oriented code of course, without explaining to the Dev why he needs to do so.
    Dirk

  2. Another possibility would be that under Android, there could be two tiers of apps with push: Ones with true push, and the others with only fake push, implemented in fact as polling of the server. The true push apps would be the ones associated with listed Accounts.
    The way this might work is, that the packet sent to the listening port contains a key, which needs to match the key of one account, in order actually to wake up the device. If the device wakes up, it makes a callback through that account. Then, it would also perform any actions whose time is up…
    Dirk

  3. There exists the very common methodology called “a callback”, which in the translated sense would mean, that an incoming packet to one listening port, would wake up the device, after which it could wake up a sleeping process, which in turn would make an outbound connection via a newly-opened port. I do not know if that is what you meant.
    But then this would still mean, that when asleep, the device is listening on one port number, and that whenever it receives any packet to that port, it must wake up, if only to determine that the request did not correspond to a registered callback.
    Dirk

  4. There is also a practice called “port knocking” which uses a sequence of port accesses to awaken a process and open a port for communication. It’s sometimes used for security as a way to hide ports but I don’t know where else it is used. Also, the Ethernet hardware has the ability to recognize a magic packet to activate the “wake on LAN” feature.

    1. IIRC, WoL was used to boot a computer which was completely shut down, and not sensitive to one specific port number. The critical question here remains, if the device is in standby, does it need to keep listening on more than one WiFi port number, to wake up? It would be much more expensive if this was so. But, traditional laptops also had the completely different standby behavior, that they would disappear from the WiFi network, while modern mobile devices remain networked.
      Dirk

Leave a Reply

Your email address will not be published. Required fields are marked *

Please Prove You Are Not A Robot *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>