13 ms·

> It needs coordination, but the coordination doesn't have to be done inside a service daemon as it is now, and It more-or-less does need to go through a singl

> It needs coordination, but the coordination doesn't have to be done inside a service daemon as it is now, and It more-or-less does need to go through a single daemon, or it would be nearly impossible to coordinate the requests. > it doesn't have to go through one shared cloud service provider as it is now. This is more true, for example you could have an open protocol and an app could register with the push daemon. It would be impossible to consolidate push notifications or throttle them for bad actors though.

jlokier 6y ago
> It more-or-less does need to go through a single daemon, or it would be nearly impossible to coordinate the requests. A single daemon, or a single kernel, it doesn't really matter which. I'm thinking a few socket() options. The kernel already coordinates coarse-grained timer wakeups between processes; it's not that outrageous to think it could nudge multiple pinging sockets towards each other then coalesce timings. The underlying mobile network registration for notifications is already quite low level. > It would be impossible to consolidate push notifications or throttle them for bad actors though At least at the moment, I don't think there's a need to consolidate push notifications into the same packet for different apps. The rate of notifications isn't high enough to matter. For keepalive pings (if the underlying radio network can't provide events to piggyback on), and consolidating pushes (if that is needed), voluntary cooperation on timings among good actors would allow incoming packets to arrive around the same time, and the mobile base station could, if a protocol was agreed, queue and coordinate the transmission time of those packets as a group, or coalesce them into a specially-addressed packet representing the group. For throttling bad actor pushers, the device itself (kernel or daemon) could block sockets and source IPs that are sending too fast. Presumably there's already some mechanism in place for things like SYN attacks. If there isn't, bad actors already have a way to drain your battery.

jlokier 6y ago

> It more-or-less does need to go through a single daemon, or it would be nearly impossible to coordinate the requests. A single daemon, or a single kernel, it doesn't really matter which. I'm thinking a few socket() options. The kernel already coordinates coarse-grained timer wakeups between processes; it's not that outrageous to think it could nudge multiple pinging sockets towards each other then coalesce timings. The underlying mobile network registration for notifications is already quite low level. > It would be impossible to consolidate push notifications or throttle them for bad actors though At least at the moment, I don't think there's a need to consolidate push notifications into the same packet for different apps. The rate of notifications isn't high enough to matter. For keepalive pings (if the underlying radio network can't provide events to piggyback on), and consolidating pushes (if that is needed), voluntary cooperation on timings among good actors would allow incoming packets to arrive around the same time, and the mobile base station could, if a protocol was agreed, queue and coordinate the transmission time of those packets as a group, or coalesce them into a specially-addressed packet representing the group. For throttling bad actor pushers, the device itself (kernel or daemon) could block sockets and source IPs that are sending too fast. Presumably there's already some mechanism in place for things like SYN attacks. If there isn't, bad actors already have a way to drain your battery.