That does not work over arbitrary connections, especially not mobile ones: in many cases, long-running connections are terminated (either because a moving phone moved in the network and received a new address, or because a middlebox threw away state about a connection it hasn't seen traffic for in x minutes). If you shut the modem down, you also can not receive messages, so you can only use polling patterns anyways (at which point the benefit of e.g. Websockets is largely lost).
So in practice, you have to regularly send traffic down the connection, fully powering up the modem, and ideally that shouldn't happen for each app individually. Now one could imagine a system where the OS coordinates this and signals to apps that the system is going to transmit now, and that they should trigger their own requests, bundling them in the process, but that's not how the platforms work. Instead, the choosen method is to have central push services, which the phone OS polls and then distributes the messages to the apps.
> Now one could imagine a system where the OS coordinates this and signals to apps that the system is going to transmit now, and that they should trigger their own requests, bundling them in the process
FWIW this would happen quite naturally if the system simply used flexible timers for these sorts of wakeups. It's an accepted, even trivial solution to the "need to power something up on an infrequent and perhaps unpredictable basis, and have it be used seamlessly by multiple apps" use case. Centralized services are nice but they shouldn't be the only way for a system to get notified about stuff.
> That does not work over arbitrary connections, especially not mobile ones: in many cases, long-running connections are terminated (either because a moving phone moved in the network and received a new address, or because a middlebox threw away state about a connection it hasn't seen traffic for in x minutes). If you shut the modem down, you also can not receive messages, so you can only use polling patterns anyways (at which point the benefit of e.g. Websockets is largely lost).
That's only true in so far as it is besides the point. Yes, suspending your phone for hours on end and expecting established TCP connections through some telco's IP connectivity to still work obviously won't work. But that wasn't my point. My point was that interrupting connectivity does not interrupt TCP connections, or other kinds of long-running connections. And that tearing down the connection does not in any way improve the situation with regards to not being able to receive messages.
The mere fact that polling doesn't make things worse in a particular use case is not an argument for designing a poll-based protocol. But also, saying that you can only use polling patterns anyway is a massive oversimplification. Even if you implement a poll-based "background delivery" mechanism, a push-based protocol still is advantageous for when the application is being actively used in the foreground. Mind you, you generally can still poll with a push-based protocol, but that does not really work the other way around. Even if you poll for new messages in the background, you have a better user experience when server-side state changes during active use of an application are reflected immediately in the user interface, so you should still have a push-based protocol, and only switch to polling when in the background.
Also, part of your argument only applies to TCP, which unfortunately uses the IP addresses as part of the connection identity, but that is not an argument against long-running connections per se, as you obviously can build connection protocols that don't do that, see QUIC for a real-world example. So, if that is an aspect you want to solve, you shouldn't invent a new poll-based protocol on top of a "transport" that doesn't fit the needs of the application and that also doesn't even solve the problem (when the IP address changes during an HTTP request, that connection will still fail, possibly using a long-ish timeout, and in any case necessitating a complete retransmit of anything that had already been transferred), but instead you should maybe write a specification for IMAP over QUIC, so you can actually seamlessly continue a data transfer over address changes and NAT remappings.
> but that's not how the platforms work. Instead, the choosen method is to have central push services, which the phone OS polls and then distributes the messages to the apps.
Well, yeah, but that's simply the manufacturers forcing a technically inferior solution on their users in order to gain power over their property. While designing a workaround for this situation certainly is a good idea, making this idiocy the basis for a protocol design, so that even software on sane platforms can not do better does not exactly seem like a bright idea.
So in practice, you have to regularly send traffic down the connection, fully powering up the modem, and ideally that shouldn't happen for each app individually. Now one could imagine a system where the OS coordinates this and signals to apps that the system is going to transmit now, and that they should trigger their own requests, bundling them in the process, but that's not how the platforms work. Instead, the choosen method is to have central push services, which the phone OS polls and then distributes the messages to the apps.