Is there mobile push technology which is actually fundamentally push, all the way down to the transport layer? Like open socket, listening for incoming packets only, no notifications-> no traffic?
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.
Yes, sms is "actually push" all the way down to the transport layer.
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)
> As far as I know, this is still what push notifications are built upon for an idle/sleeping device.
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.
iOS or Android push notifications (can) use SMS for notifying the client that a new message is available ? That’s lovely. Do you have any links or any keywords to find more ? All I can find online is that iOS uses TCP (XMPP in fact :o TIL. )
It wasn't really SMS, it was another message type riding on top of the same lower-level protocol called SS7. But it seems that's no longer in use and it's all just TCP/IP now.
(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.)
No, Apple push cannot use SMS/Text. You need a cell modem to have working SMS/Text. Except the phone itself, most of the devices have no cell modem. Then Apple would need to keep a directory of all the cell phone numbers, because that is the way how the cell modem is addressed.
Both Apple and Google mobile notifications are long-lived TCP/IP sockets where the server writes bytes to the stream when it wants to wake up the phone.
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.
In theory you could do that, that's how I had push set up on my Pinephone. Often the ssh connection that was used for it was still live after rtcwake came back up. It's kind of a moot point since the WiFi radio couldn't wake the CPU up on its own though.
> Is there mobile push technology which is actually fundamentally push, all the way down to the transport layer? Like open socket, listening for incoming packets only, no notifications-> no traffic?
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.
Well, the server could contact the client. The client would just need to be listening on a port/address that the server knows. Which is completely infeasible for 99.99% of end user devices.
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.
I think this is one of those many cases where how the technology works doesn't match the actual meaning of the English word, but for whatever reason the word has stuck.
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.
