3 ms·

I've experimented with this on the pinephone. You can often just get away with leaving TCP connections open while the device is locked (on mine "locked" means s

by usrn 4y ago

I've experimented with this on the pinephone. You can often just get away with leaving TCP connections open while the device is locked (on mine "locked" means something like Android where the device suspends and periodically wakes up so apps can maintain their sockets) as long as you wake up before the keep alive message for the protocol you're using leaving sockets open is fine. That's effectively what the push notification receiver in the OS is doing anyway (although it does something special with the hardware so the incoming packets actually wake up the device for lower latency.) There's no reason not to allow this for open source apps (commercial ones would obviously abuse it and you would have battery life issues.) Unfortunately it doesn't matter what makes sense on mobile, you're not allowed to tinker with the OS in any way. EDIT: That's great! I did not know about it. You could probably get around the issue of teaching clients to use it by modifying the BSD socket library to open sockets that way after checking an environment variable. I might mess around with that later.

Arnavion 4y ago
For the Pinephone, the Quectel firmware supports AT commands for creating a TCP connection through the modem, after which the modem sends wakeups on the bus when it receives data on that socket. So that can be used to implement push notifications without any lag from having to periodically wake up to check. The problem is that: a) ... this requires teaching ModemManager about this API since MM is the only thing that talks to the modem. b) ... this requires teaching clients to talk to MM for a TCP connection, likely using some new dbus-based API to match MM's existing API, instead of just socket() + connect() + read() + write(). So existing TCP-socket using programs will not work without modification. (LD_PRELOAD trickery can work, though ideally only sockets used for push notifications would be routed through MM and the rest use socket(), which can be hard for an LD_PRELOAD'd library to do.) c) ... one should really be running the OSS firmware instead of Quectel's, and the OSS firmware does not implement those commands. This was discussed a few months ago in #pinephone. AFAIK no one is working on it.

by usrn 4y ago

Arnavion 4y ago

For the Pinephone, the Quectel firmware supports AT commands for creating a TCP connection through the modem, after which the modem sends wakeups on the bus when it receives data on that socket. So that can be used to implement push notifications without any lag from having to periodically wake up to check. The problem is that: a) ... this requires teaching ModemManager about this API since MM is the only thing that talks to the modem. b) ... this requires teaching clients to talk to MM for a TCP connection, likely using some new dbus-based API to match MM's existing API, instead of just socket() + connect() + read() + write(). So existing TCP-socket using programs will not work without modification. (LD_PRELOAD trickery can work, though ideally only sockets used for push notifications would be routed through MM and the rest use socket(), which can be hard for an LD_PRELOAD'd library to do.) c) ... one should really be running the OSS firmware instead of Quectel's, and the OSS firmware does not implement those commands. This was discussed a few months ago in #pinephone. AFAIK no one is working on it.