Уведомления Apple Push навалом

У меня есть приложение, которое периодически отправляет уведомления Apple Push пользователям ~ 1M. Настройка для этого была построена и протестирована для небольшого количества уведомлений. Поскольку я не могу проверить отправку в этом масштабе, мне интересно узнать, есть ли какие-либо ошибки при отправке массовых push-уведомлений. У меня есть сценарии, написанные на Python, которые открывают одно соединение с push-сервером и отправляют все уведомления по этому соединению. Apple рекомендует держать его открытым как можно дольше. Но я также видел, что соединение завершается, и вам нужно его восстановить.

В целом, это обескураживает, что успешные отправления не подтверждены, но только ошибочные отмечены. С точки зрения программиста вместо того, чтобы просто проверять одну вещь "если (успех)", вам теперь нужно следить за множеством вещей, которые могут пойти не так.

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

Ответ 1

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

Итак, вот что говорит Apple, что вы должны сделать (из Техническая заметка):

Проверка пропускной способности и проверка ошибок уведомления

Для использования APN нет ограничений на размер кеша или размера партии. IOS 6.1 пресс-релиз заявил, что APN отправил более 4 трлн push с момента его создания. Об этом было объявлено на WWDC 2012 что APN ежедневно отправляет 7 миллиардов уведомлений.

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

Здесь, как проверить ошибки при использовании расширенного двоичного кода интерфейс. Продолжайте писать, пока не сработает запись. Если поток готов для повторного письма, отправьте уведомление и продолжайте движение. Если поток не готов для записи, посмотрите, доступен ли поток для чтение.

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

Как только все отправлено, выполните последнюю проверку на наличие ошибки Ответ.

Потерянное соединение может занять некоторое время, чтобы APN возвращаются на ваш сервер только из-за нормальной латентности. Возможно отправлять более 500 уведомлений до того, как сбой записи из-за соединение отбрасывается. Около 1700 уведомлений могут быть выполнены с ошибкой просто потому, что труба заполнена, поэтому просто повторите попытку в этом случае после поток готов к записи снова.

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

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

Ничего из этого не имеет особого отношения к APN, это относится к большинству программирование на уровне сокетов.

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

Ответ 2

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

К ссылкам ссылки @Eran, к сожалению, относится лучший ресурс, который мы имеем для того, как Apple управляет сокетами APNS. Это отлично подходит для небольшого объема, но документация Apple в целом очень искажена для обычного разработчика с небольшим объемом. Когда вы получите масштаб, вы увидите много недокументированного поведения.

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

Часть этого сообщения, в котором я принимаю исключение, это:

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

Предполагать, что совет с таким огромным "IF" кажется очень обманчивым. Я почти гарантирую, что большинство разработчиков не захватывают токены и не обрабатывают службу обратной связи Apple на 100% "правильно". Даже если бы это было так, система по своей сути была потеряна, поэтому дрейф будет происходить.

Мы видим ненулевое число ответов об ошибках # 8 (недопустимый токен устройства), которые я отношу к корневым телефонам, клиентским ошибкам или пользователям, намеренно подменяющим их токены. В прошлом мы также видели ряд ошибок # 7 (недопустимый размер полезной нагрузки), которые мы отслеживали до неправильно закодированных сообщений, добавленных разработчиком на нашем конце. Конечно, это была наша ошибка, но моя точка зрения: "Оптимизировать допущение неудач будет редкими" - это неправильное сообщение для отправки разработчикам обучения. Вместо этого я бы сказал:

Предположим, что ошибки произойдут.

Надеюсь, что они происходят нечасто, но защищайте код в случае, если они этого не делают.

Если вы оптимизируете допущение, что ошибки будут редкими, вы можете подвергать свою инфраструктуру риску, когда служба APNS снижается, а каждое отправленное сообщение возвращает ошибку № 10.

Проблема возникает при попытке выяснить, как правильно реагировать на ошибки. Документация неоднозначна или отсутствует в отношении того, как правильно обрабатывать и восстанавливать данные из разных ошибок. Это, по-видимому, остается как упражнение для читателя.