You mean modifying glibc defaults?
Ah, got it, well it could well be a library which will open alternative transport for delivery. it just may make it a bit more complicated and eventually introducing multiple sockets… that’s exactly what comes to the area of review/comments of the concept. fully distributed concept is really a library (not bound to specific service)
Sorry, I don’t have any hard facts to support this, but couldn’t there be more reasons for Firebase (Google Cloud messaging) than just harvesting more of peoples’ personal data?
I mean, wake-up is is expensive - especially waking up radios - so a single push service could potentially let the device sleep more than having each and every app poll. (email, XMPP chat, Matrix chat, Mastodon, calendar sync, …)
Also, maybe also have a look at what Tutanota did to replace Firebase/Google Cloud Messaging, so they could have their app on F-Droid?
edit: added link to Tutanota blog post at F-Droid
1 Like
The rest of your message contains a potential answer:
Application polling is expensive, but also not the solution unless we consider HTTP to be the only acceptable network protocol.
Radio have to be on all the time anyway, listening for incoming packets before they get filtered and dispatched to the OS, so to me this sounds like the layer which should be used for accepting incoming communication.
1 Like
There might be another reason for Firebase, which has nothing to do with power use, but everything to do with application lifetime. Android applications can be killed by the OS at any time, transparently to the user. A persistent, direct connection to an application doesn’t work under the circumstances. And without a direct connection or a running program, there’s no destination for a server to send data to. So an intermediary becomes required.
1 Like
I wrote a post here some time ago:
It sound like you might be interested in taking a look at the decentralized nature of the Safe Network. There are some links in the above post. The Maidsafe Github repository can be found here:
That could be the case for WiFi, idk, but when it comes to cellular I think there is a lot of effort put into maximizing sleep and minimizing wake-ups. Entire clock domains in the SOCs are shut down, radios are just turned on briefly to stay in touch with base stations, etc.
That sounds like a likely reason, independent of how it affects power use.
Not quite true, look at BLE and other IoT. MMQT is also there for a reason. You sleep, you wake, you gather the data and react.
Okay, what I said is not strictly true. I should have said: for the purpose of handling incoming packets versus polling, there is no difference in radio usage.
The radio, regardless of which tech, will periodically wake up from low power mode, and ask the other end for updates. Say, in 10 seconds intervals. Without polling, that’s when it receives a data packet sent by the remote host, and passes it to the application.
With polling, it wakes up every 10 seconds, but never sees anything. Every 100 seconds or so, the application wakes up the radio in addition to the 10 sec cycle, to send and receive some data to/from the push server.
There’s not much difference between those 2 strategies.
1 Like
The difference starts when you have various application stacks. Some of them statefull (xmpp) some stateless (POP3) some mixed bag (IMAP4). All having different timeouts, back-off and retry timers, etc…
Then there are HW power states, frequency scaling, etc. so some apps have no time/desire to reconnect during wake period and skip it (eg due to growing backoff). If there’s a some sort of DBus signal which clearly indicates something is waiting - app may cancel backoff and force reconnection (as if user started interacting with it).
The push service on the other hand will be designed to quickly (re)connect on the wake and gather the events. So on one hand it won’t bash the CPU during wake allowing other apps to enjoy their sleep, on the other it won’t consider it needs to backoff - it must connect and poll.
I’m not sure I get it… don’t they all basically rely on the kernel’s TCP stack to handle timeouts, backoffs and retries?
No, not necessarily. See, despite TCP is reliable protocol there’s still SM in XMPP. And original SM was not even to do resumption, merely to guarantee stanza delivery (to protect from partial writes).
So an app may consider connection to be dead and give it up, and start reconnecting. Also if you put TLS on top it happens even more frequently due to the cipher block not always being aligned with MSS.
Some services introduce artificial delays to protect from abuse (eg SMTP hello delay) so f.i. smtp app which found connection closed, reconnected but went sleeping after it sent hello will most probably wake up with connection closed again by the server (bad example for push but just to illustrate that mere tcp flow control is frequently not sufficient).
To my knowledge, if a TCP socket waits for new data, the process (thread, rather) is sleeping until the timeout is reached. If this requires additional keep alive packages under the hood (does it?), the kernel handles it. This could possibly be optimized (in-kernel) by aligning such packets so that the kernel can sleep e.g. 15s and then send all keep-alive packages at once.
In a similar fashion, apps that are polling could be synced by (voluntarily) listening to some DBus events. This should be customizable. First I wanted to write I’m totally fine with having my mails polled only every 10 minutes, but then I realized I’m actually fine with “no polling at all” while the screen is off.
No need to poll my mails 50 or even 500 times every night when I won’t read them before turning on the screen anyway.
Yes, I know, we have a fancy LED to indicate incoming messages, but personally I’d poll emails only when the screen is on, and maybe disable messenger polling during night time.
Its an interesting case and I guess some standarized DBus events to notify applications about updates or even just the presence of an update would work.
But instead of just one solution id rather see a multitude of solutions which can hook into this… I don’t want all my apps consumed by one big external messaging system like GCM (decentralized or not) I have no control over.
I’d rather have a self-hosted solution where I can connect “all” my apps / services ( e.g. through polling ) and then specify that as the back-end for such a solution.
That’s not quite what I meant. Rather, DBus would only hint apps to do their polling in a synced fashion.
E.g., “Dear app, if you need fast polling, use this scheme: 10:10:15, 10:10:25, 10:10:35, … For medium, go 10:10:15, 10:11:15, 10:12:15, … and for slow polling, go 10:10:15, 10:20:15, 10:30:15”
Or, in other words, “Please sync on the timestamp 10:10:15, and then poll every 10 seconds, every minute or every 10 minutes”
Ok, let imagine following situation (again I’m at XMPP heavy case which is realtime and statefull).
So we have xmpp session setup (several dozens roundtips), we have SM, SI and TLS.
When phone goes sleeping and suspending apps - client detects that in pushes inactive SI message. Server treats that like stop spamming - increase keepalive timers, hold presense broadcast, maybe queue pep events. however since it can scarcely queue messages and IQs (those are interactive) it must fire them up even in SI inactive case. So server did writes to TCP socket.
Since client is still sleeping the packets don’t hit it. perhaps they are queued at operators gateway. Server sends retries, client still sleeps. Again - these retries are now server-side TCP stack (kernel) not application, so it’s not SI state aware. So again to avoid socket starving the stack most probably will be configured with shorter backoff and may eventually time out till client wakes up and resumes TCP conversation.
If there’s a push though - server may hold everything and rely on the fact that push should wake the client up, client will send active state and server would flush the buffer. That will allow socket to survive long silence periods and actually rely on client’s ineraction preserving the connection and resources.
It has nothing to do with notification led.
I think you’re going to have a more meaningful response if you expand your acronyms 
sorry - stream management and state indication. SM tracks xml-stream to enforce xml stanza framing integrity and SI allows mobile clients to indicate they are entering suspended state so do-not-disturb unless urgently needed.
SM was created as response to the fact that TCP reliable connection is still not reliable enough for higher level application framing. And SI was created exactly for mobile devices. However SI alone is still not sufficient as I described above, push service complements the gap.
Note: push service becomes required in mobile compliance suite 2020 for xmpp advanced server.
Do you mind posting or linking your dissertation?