诊断从 Azure 通知中心到 APNS 的丢失通知 [英] Diagnosing dropped notifications from Azure Notification Hub to APNS

问题描述

我们通过 Azure 通知中心成功地实现了向 iOS 和 Android 设备推送通知.

We have a (mostly) successful implementation of push notifications to iOS and Android devices through Azure Notification Hubs.

问题是某些 iOS 设备显然从未收到 Azure 通知中心发送的通知.

The problem is that some of the iOS devices are apparently never receiving notifications that are sent by Azure Notification Hubs.

我们使用模板和标签将消息定向到适当的设备.标签是兴趣主题，从不针对特定用户，因此我们希望将一个标签通知推送到订阅该标签的所有设备.

We use templates and tags to direct the messages to the appropriate devices. The tags are interest topics, and never user-specific, so we're expecting one notification for a tag to be pushed to all devices subscribed to that tag.

Android 设备似乎可以完美接收通知，但 iOS 设备并不一致.他们中的大多数工作.一对夫妇没有.

The Android devices seem to receive their notifications flawlessly, but the iOS devices are not consistent. Most of them work. A couple do not.

我们很清楚推送通知是尽最大努力提供的，无法保证可靠性，但我们有限的测试表明，始终无法接收推送通知的设备多于看似不合理的设备(大约有十几个设备有两次以上的失败)).

We are well aware that push notifications are delivered with best effort and have no guarantee of reliability, but our limited testing has revealed more devices which consistently fail to receive push notifications than seems unreasonable (more than two failures from about a dozen devices).

设置如下:

我们在后端有一个简单的 C# 例程，它连接到 Azure 通知中心并向 Azure 发送通知:

We have a simple C# routine in the back end which connects to Azure Notification Hubs and sends notifications to Azure:

var outcome = await hub.SendTemplateNotificationAsync(properties, tag);

我们使用了 GetAllRegistrationsAsync 方法来确保我们正在检查的每个设备都已成功注册并使用正确的模板.每个设备都注册了，所有的模板都是正确的.

We have used the GetAllRegistrationsAsync method to make sure that every device we are checking has successfully registered and is using the correct template. Every device is registered, all the templates are correct.

我们不是在测试模式"；NotificationHubClient.CreateClientFromConnectionString 的 enableTestSend 参数设置为 False.

We are not in "test mode"; the enableTestSend parameter of NotificationHubClient.CreateClientFromConnectionString is set to False.

疑难解答:

当我们发出通知时，大多数设备都会收到通知，并且在我们正在测试的特定情况下，使用正确的数字更新徽章计数器.

When we send the notification out, most devices receive the notification and, in the specific case we're testing, update the badge counter with the correct number.

但是，一些设备似乎没有收到通知.在我们重新启动设备后，其中一台设备确实收到了通知，但之后它停止了.

However, a couple of devices do not seem to get the notification. One of the devices did get the notification after we rebooted the device, but after that it stopped.

使用上述 GetAllRegistrationsAsync 方法，我们已验证问题设备已在 Azure 上正确注册并具有正确的标签和模板.

Using the above mentioned GetAllRegistrationsAsync method, we have verified that the problem devices are correctly registered on Azure and have the correct tags and templates.

我们能够从 Azure 注册中确定问题设备的设备令牌.我们使用了一个直接与 APNS 通信的 PHP 脚本，使用他们的设备令牌向有问题的设备发送通知.每次，设备都会收到此直接发送的通知.只有来自 Azure 的通知不可靠.

We were able to determine the device tokens of the problem devices from the Azure registrations. We used a PHP script which communicates directly with APNS to send a notification just to the problem devices using their device tokens. Every time, the device receives this direct-send notification. It's only the notifications from Azure which are unreliable.

当我们检查 Azure 通知中心监视器页面时，我们会看到过去 24 小时的这些指标:

When we examine the Azure Notification Hub Monitor page, we see these metrics for the past 24 hours:

• 967 个 APNS 成功通知
• 3 个 APNS 错误频道错误
• 2 个 APNS 过期频道错误
• 4 个 APNS 错误

... 并且一般没有针对 APNS 或 Azure 报告其他错误.我们看到的失败率应该产生超过 20 的错误计数.

... and no other errors reported for APNS or for Azure in general. The failure rate we're seeing should have produced an error count over 20.

我们无法确定哪些设备令牌对错误负责；有没有办法从 Azure 获取这些信息?

We have not been able to determine which device tokens were responsible for the errors; is there a way to get this information from Azure?

我们无法解释为什么我们可以通过 APNS 本身直接向这些设备发送通知，而不是通过 Azure，以及为什么 Azure 报告的错误没有比它更多.

We're at a loss to explain why we can send notifications directly to these devices over APNS itself, but not through Azure, and why it is that Azure doesn't report more errors than it does.

有什么建议或见解吗?

推荐答案

您的数据库中很可能有一些沙盒设备令牌(我不确定这些设备令牌是存储在您的服务器中还是存储在 Azure 通知中心).尝试向生产推送环境发送带有沙盒设备令牌的通知时，Apple 返回 InvalidToken 错误，并关闭连接.

It's quite possible that you have some sandbox device tokens in your database (I'm not sure if the device tokens are stored in your server or in Azure Notification Hub). When trying to send a notification with a sandbox device token to the production push environment, an InvalidToken error is returned by Apple, and the connection is closed.

很多时候，当向 Apple 的 APN 服务器发送推送通知的服务器收到错误响应时，它已经发送了更多的通知(可能带有有效令牌)，而所有这些通知都被 Apple 丢弃了.此时，只有在与 APNS 建立新连接后，Apple 才会接受新通知，因此需要重新发送在无效令牌后发送到旧连接的消息.Azure 可能无法正确处理这种重新发送.

Very often, by the time the server that sends push notifications to Apple's APN server gets the error response, it has already sent many more notifications (possibly with valid tokens), and all of which are discarded by Apple. At this point, new notifications are accepted by Apple only after a new connection with APNS is established, so messages that were sent after the invalid token to the old connection need to be resent. It is possible Azure don't handle this resending correctly.

如您所说，Azure 通知中心监视器页面显示了一些错误.我怀疑 3 APNS Bad Channel Errors 意味着无效的设备令牌.我不知道您在数据库中实际有多少无效的设备令牌，但即使是一个也会导致许多带有有效令牌的通知不被 Apple 接受.

As you said, the Azure Notification Hub Monitor page shows a few errors. I suspect that 3 APNS Bad Channel Errors means invalid device tokens. I don't know how many invalid device tokens you actually have in the DB, but even one can cause many notifications with valid tokens not to be accepted by Apple.

最好的解决方案是测试数据库中的所有设备令牌，找出无效的并删除它们.

The best solution is to test all the device tokens in the DB and figure out the ones that are invalid and delete them.

这篇关于诊断从 Azure 通知中心到 APNS 的丢失通知的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！