You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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. )
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
The text was updated successfully, but these errors were encountered: