Is it even a push notification if you have to fetch them from a server?
I was under the impression it was all polling if you go down far enough, but at least because of central registration the phone only needs to poll one single pubsub service instead of a separate server per subscription.
Could be wrong though?
As far as I know, this is still what push notifications are built upon for an idle/sleeping device.
Carrier infrastructure knows which tower you last connected to, instructs that specific tower to broadcast a message telling your phone to wake up and fetch the remaining 80% of the notification content (the sms bit is usually just enough for your device to learn the UUIDs of the notifications)
I thought so too, but can't find any evidence for it anymore, all I can find is mentions of the phone keeping a TCP connection alive and then some device driver level tweaks to make that power efficient. I think the older GSM-specific wakeup mechanism might have died when iPhones stopped being carrier-specific.
(Said differently, the radio firmware got good enough that it doesn't need a special "wake up" packet anymore, it can recognize a packet to itself in a low power state.)
The TCP/IP and protocol-specific handshake is started by the phone, but then the phone just waits to receive data. That counts as fundamentally push, all the way down to the transport layer.
That’s the end-to-end principle. Each host on the Internet is fully capable of listening on a socket and doing whatever its owner wants it to do.
The issue is when firewalls prevent incoming traffic, and when NAT prevents a host from even being on the internet. There’s not really a good reason for NAT with IPv6, but there are some good reasons for firewalls. They mostly boil down to human imperfection. The developers of one’s OS and software are imperfect, so the fact that a laptop sitting in Dallas can be probed by other computers in Frankfurt or Maseru thousands of times a second is an issue: a single bug will make one’s computer, and all its data, vulnerable. And users are imperfect, too. One might misconfigure one’s computer, and accidentally expose a service to the world.
There could be some approaches to mitigate these issues, but we’re probably stuck with firewalls forever. Which is really kind of sad.
Any push service works this way. The client contacts the server to be updated. The server gives a no data or a data response. The server cannot magically contact the client.
The majority of end user devices are run from within private networks protected from the Internet. If you have connected to your cell provider, then in the majority the cell providers are running their own private networks. For one reason the IPv4 address space is limited as such, that there are no other possibilities. IPv4 is still the important protocol compared to IPv6. Second, it is that those providers, want to protect you. Some don't even allow cross communication.
If you devices are connected with Wifi, then there is the very same situation. There is almost no campus, commercial, and home network, that gives you public route-able IP addresses. I only know a view deployments were you get public route-able IP addresses at conferences like C3, EMF, and alike.
tl/dr: No, the end user devices is not easily to reach without additional infrastructure.
For better or worse, a lot of things on the Internet now assume that only "servers" can accept incoming connections, and therefore anything that needs to be "sent" to clients needs to be done by making the client poll a server over and over. True P2P apps (with no intermediary server) are pretty rare now, for a variety of reasons: some good reasons, some stupid reasons.