Диагностика сброшенных уведомлений из Центра уведомлений Azure в APNS

У нас есть (в основном) успешная реализация push-уведомлений на устройства iOS и Android через Центры уведомлений Azure.

Проблема в том, что некоторые устройства iOS, по-видимому, никогда не получают уведомления, отправляемые центрами уведомлений Azure.

Мы используем шаблоны и теги, чтобы направлять сообщения на соответствующие устройства. Теги представляют собой темы интересов и никогда не относятся к конкретным пользователям, поэтому мы ожидаем, что одно уведомление о теге будет отправлено на все устройства, подписанные на этот тег.

Кажется, что устройства Android получают свои уведомления безупречно, но устройства iOS не соответствуют друг другу. Большинство из них работают. Пару нет.

Мы хорошо понимаем, что push-уведомления доставляются с максимальной эффективностью и не имеют гарантии надежности, но наше ограниченное тестирование выявило больше устройств, которые постоянно не получают push-уведомления, чем кажется необоснованным (более двух сбоев примерно с десятка устройств).

Вот установка:

У нас есть простая процедура C # в серверной части, которая подключается к центрам уведомлений Azure и отправляет уведомления в Azure:

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

Мы использовали метод GetAllRegistrationsAsync, чтобы убедиться, что каждое устройство, которое мы проверяем, успешно зарегистрировано и использует правильный шаблон. Каждое устройство зарегистрировано, все шаблоны правильные.

Мы не находимся в «тестовом режиме»; параметр enableTestSend NotificationHubClient.CreateClientFromConnectionString установлен в значение False.

Исправление проблем:

Когда мы отправляем уведомление, большинство устройств получают уведомление и, в конкретном случае, который мы тестируем, обновляют счетчик значков с правильным номером.

Однако на некоторых устройствах это уведомление не отображается. Одно из устройств получило уведомление после того, как мы перезагрузили устройство, но после этого оно остановилось.

Используя вышеупомянутый GetAllRegistrationsAsync метод, мы проверили, что проблемные устройства правильно зарегистрированы в Azure и имеют правильные теги и шаблоны.

Нам удалось определить токены проблемных устройств из регистраций в Azure. Мы использовали PHP-скрипт, который напрямую связывается с APNS, чтобы отправлять уведомления только проблемным устройствам, используя их токены устройств. Каждый раз устройство получает это уведомление о прямой отправке. Ненадежны только уведомления от Azure.

Когда мы изучаем страницу монитора концентратора уведомлений Azure, мы видим следующие показатели за последние 24 часа:

  • 967 APNS Успешные уведомления
  • 3 ошибки плохого канала APNS
  • 2 ошибки истекшего канала APNS
  • 4 ошибки APNS

... и никаких других ошибок для APNS или для Azure в целом не сообщалось. Уровень отказов, который мы наблюдаем, должен был привести к количеству ошибок более 20.

Нам не удалось определить, какие токены устройств были причиной ошибок; есть ли способ получить эту информацию из Azure?

Мы не можем объяснить, почему мы можем отправлять уведомления непосредственно на эти устройства через APNS, но не через Azure, и почему Azure не сообщает о большем количестве ошибок, чем сообщает.

Есть предложения или идеи?


person Alan McBee    schedule 03.07.2014    source источник


Ответы (1)


Вполне возможно, что в вашей базе данных есть токены устройств песочницы (я не уверен, хранятся ли токены устройств на вашем сервере или в Центре уведомлений Azure). При попытке отправить уведомление с маркером устройства песочницы в рабочую среду push-уведомлений Apple возвращает ошибку InvalidToken и соединение закрывается.

Очень часто к тому времени, когда сервер, который отправляет push-уведомления на сервер APN Apple, получает ответ об ошибке, он уже отправил еще много уведомлений (возможно, с действительными токенами), и все они отклоняются Apple. На этом этапе новые уведомления принимаются Apple только после того, как установлено новое соединение с APNS, поэтому сообщения, которые были отправлены после недопустимого токена на старое соединение, необходимо отправить повторно. Возможно, Azure неправильно обрабатывает эту повторную отправку.

Как вы сказали, на странице монитора концентратора уведомлений Azure отображается несколько ошибок. Я подозреваю, что 3 APNS Bad Channel Errors означает недействительные токены устройства. Я не знаю, сколько недействительных токенов устройств у вас на самом деле есть в БД, но даже одно может привести к тому, что многие уведомления с действительными токенами не будут приняты Apple.

Лучшее решение - протестировать все токены устройств в БД, выяснить, какие из них недействительны, и удалить их.

person Eran    schedule 03.07.2014
comment
Это кажется довольно разумным объяснением, но разве ваше объяснение не означает, что мы не должны иметь возможность отправлять прямое сообщение через APNS, используя тот же токен устройства, который использует Azure? Или Apple выборочно отклоняет входящие сообщения на основе IP-адреса отправителя (или чего-то подобного)? Кроме того, знаете ли вы, как получить эти недействительные токены устройств из Azure? (Мы не выполняем регистрацию; устройства напрямую взаимодействуют с Azure.) - person Alan McBee; 03.07.2014
comment
@AlanMcBee. Токены устройства, которые вы пытались отправить напрямую, вероятно, действительны, иначе они бы никогда не сработали. Проблема, вероятно, вызвана другими токенами устройств, о которых вы не знаете. Я не знаю, как удалить недопустимые токены из Azure. Я никогда не работал с Azure. Регистрировали ли вы устройства в Azure при тестировании сборки для разработки (с принудительной средой песочницы)? Это наиболее вероятные проблемные токены устройства. - person Eran; 03.07.2014
comment
Вероятно, нам следовало отменить регистрацию всех предпроизводственных регистраций, которые мы создали во время тестирования, чтобы не было никаких проблем. Но все проблемные устройства успешно зарегистрировали свои токены в Azure после установки производственного приложения с производственным сертификатом. Я ожидал, что отдельные недействительные токены устройств в конечном итоге будут удалены из регистрации. На самом деле у нас есть открытая заявка в службу поддержки Microsoft, чтобы помочь отследить ошибки отдельных устройств. Я буду держать эту ветку в курсе. - person Alan McBee; 04.07.2014
comment
Постскриптум. Проблема действительно заключалась в недействительных токенах устройства. Не существует (или не было в то время) эффективного способа обнаружения этих токенов песочницы и их удаления; нам пришлось отменить регистрацию всех токенов и начать заново. Двигаясь вперед, мы постараемся никогда не использовать ту же служебную шину + концентратор уведомлений для предварительной регистрации (песочницы), как мы это делаем для prod. Менеджеры по работе с Microsoft рассматривают / рассматривали способы улучшить ситуацию, но я не знаю, что из этого вышло. - person Alan McBee; 30.12.2014