Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Mobile Daily Check-in as register of device liveliness #788

Open
data-sync-user opened this issue Oct 21, 2024 · 0 comments
Open

Use Mobile Daily Check-in as register of device liveliness #788

data-sync-user opened this issue Oct 21, 2024 · 0 comments

Comments

@data-sync-user
Copy link
Collaborator

There is some reason to believe that mobile proprietary bridges (such as FCM and APNs) are not as reliable as we are lead to believe. This can be partly due to the fact that it is not certain that any of these systems have full awareness of the clients that they serve.

The bridges operate very similarly to the way that Autopush does. A device may register to receive messages and establish their connection, but then disappear, never to be heard from again. The bridges will accept a message for eventual delivery, which Autopush will record as a “successful handoff” but then fail to deliver the message for any number of reasons, and may never report back this failure to deliver. Eventually, the bridge may mark a given device or connection as “Unavailable” but that would still impact our internal delivery success rate, since we would also consider the device “legitimate” and would continue to accept delivery of messages to that device, for the delivery to fail during the bridge handling.

This means that relying on the bridge for any indication that the remote client is present may not be the best idea.

Mobile devices currently do a “daily check-in”, where they compare their list of channels with our server. If there’s a discrepancy, the UA discards it’s current set of subscriptions and requests that the associated webapps preform a re-subscription. Autopush could use that as an indicator of the ‘liveliness’ of a device. If a mobile device hasn’t performed this check in, say, a week, then we consider that device “lost” and drop it from service. If that device later reconnects, it would discover that the server has no record of it, and it would resubscribe any existing subscriptions. ( This does mean that any pending messages would be lost. )

#jr_dumb_ideas

┆Issue is synchronized with this Jira Task

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant