Hacker News Reader

Comment by raggi | Hacker News Reader

I campaigned for this for years when working on fuchsia, to folks in fuchsia and android folks.

We lack a unixy API for “the radio is now on, do your reconnects or send your queues”

The platforms always hoist this stuff higher level and it rarely works that well.

Platform leads insist the platform will do it better, but it’s never true. They also insist that persistent connections are battery killers - which for sure they _can be_ but done properly (and with the aforementioned api) it can work just fine.

Establishing such an API in the Linux and BSD ecosystem would make a good step toward encouraging its exposure in the places we need it.

View on HN

The Play Services people would have a stronger case if FB Messenger hadn't outperformed them on so many metrics of this type for years. One of the shocks of Copperhead/Graphene is how the absence of the play service push mechanism radically improves your battery life.

It is definitely the case that doing such things efficiently, especially in the world of evolving radio technology, is beyond the absolutely overwhelming majority of mobile app developers, and apparently in many cases even very good ones. It also seems unlikely that having the platform poll a process to then do the push (as your API would, in response to something like a radio burst about to be made) is a good idea, as keeping the app process asleep if at all possible is distinctly preferable, and most devs struggle with what is a real time constraint. An API to achieve this is definitely buildable though, it does require offloading a certain amount to the platform.

The truth is centralized services are strategic for the platform owner these days, so any technical argument for them will really be on that basis.

I also had some experience in that space, and my conclusion was that what was really hard is handling keep-alive correctly. Some mobile networks will very aggressively flush their NAT entries while other will be fine with a packet every hour or so. And sometimes the NAT timeout changes depending on the server's IP range. Building a solution that is both battery-optimal and that will keep the connection alive is pretty hard.

QUIC (or HTTP/3 with enough low-level control) sounds like a good fit: there is no NAT connection that has to stay alive, but the server can remember the handshake for a quick restart. Doesn't matter if you switch between wifi and LTE. When ever the app is told radio is now available, send a single UDP packet to request new notifications, server sends one of more UDP packets back in response.

But how would google get all the metadata if the app just connects to its own server to know about notifications?

systemd-networkd and NetworkManager have something to that effect.

There’s however a big difference between an interface coming online, an interface getting its addresses, a particular address being resolvable and reachable, and the particular address being routed to the place you actually want to reach. In an ideal world, you want all four; NM kinda sorta has it. There are d-bus APIs, just maybe not easy to use in shell scripts CLI tools.

The routing table won't get flushed in between the slumber of the WiFi or 5G modem. You do not have to care about IPs or interfaces being up - we just need to synchronize network work so that most comms can be done in short bursts and then everything can go back to sleep. iOS does this, has done this for years.

Can't you hook into NM and provide the missing bits with scripts? Or do you need also to listen to "something else" to get the events like "the modem just went to sleep" which is not quite the same as deconfiguring it?

(I think no wonder those pieces are missing, it usually isn't happening on computer-shaped things, more on embedded- and phone-shaped things.)

This irked me recently. I think it’s very reasonable for networkd to delegate everything after the interface meets an “online criteria” to later services. However I was disappointed that you couldn’t then tell networkd an interface was “active” (vs. online) later down the line.

Would be interested to hear how you & others approach this. Perhaps I’m not thinking systemd-y enough hah.

Can you describe your use case in a bit more detail? (Also to make sure it’s not really a XY problem)

systemd-networkd sure keeps some state tracking. There are systems where it’s the only thing managing the network, so it doesn’t have anything to delegate to. You can see it by running networkctl before and after yanking the Ethernet cable.

Even if you had that on Android, they won't allow you to open a network connection in the background if the device is sleeping. You still need to send messages through FIrebase.

Reply on news.ycombinator.com