Связь провайдера со службой уведомления нажатия Apple
В этой главе описываются интерфейсы, которые провайдеры используют для связи с Apple Push Notification service (APNs), и обсуждает некоторые функции, которые провайдеры, как ожидают, выполнят.
Общие требования провайдера
Как провайдер Вы связываетесь со службой Apple Push Notification по двоичному интерфейсу. Этот интерфейс является высокой скоростью, интерфейсом большой емкости для провайдеров; это использует проект сокета TCP потоковой передачи в сочетании с двоичным содержанием. Двоичный интерфейс является асинхронным.
Двоичный интерфейс продуктивной среды доступен через gateway.push.apple.com
, порт 2195; двоичный интерфейс среды разработки доступен через gateway.sandbox.push.apple.com
, порт 2195.
Для каждого интерфейса используйте TLS (или SSL) для установления канала защищенных связей. Сертификат SSL, требуемый для этих соединений, получен из Задействованного Центра. (См. Настройку и Разработку для подробных данных.) Для установления доверяемых идентификационных данных провайдера представьте этот сертификат APNs во время соединения с помощью одноранговой аутентификации.
Как провайдер, Вы ответственны за следующие аспекты удаленных уведомлений:
Необходимо составить полезную нагрузку уведомления (см. Полезную нагрузку Уведомления).
Вы ответственны за предоставление числа значка, которое будет выведено на экран на значке приложения.
Соединяйтесь регулярно со службой обратной связи и выбирайте текущий список тех устройств, неоднократно сообщавших о попытках неработающей поставки. Тогда прекратите отправлять уведомления устройствам, связанным с теми приложениями. Посмотрите Службу Обратной связи для получения дополнительной информации.
Если Вы намереваетесь поддерживать уведомления на нескольких языках, но не используете loc-key
и loc-args
свойства aps
словарь полезной нагрузки для выборки клиентской стороны локализованных предупредительных строк, необходимо локализовать текст предупредительных сообщений на серверной стороне. Чтобы сделать это, необходимо узнать текущее языковое предпочтение из клиентского приложения. Планирование, Регистрируясь и Обрабатывая Уведомления предлагает подход для получения этой информации. Посмотрите Полезную нагрузку Уведомления для получения информации о loc-key
и loc-args
свойства.
Методы наиболее успешной практики для управления соединениями
Можно установить многократные соединения с тем же шлюзом или с многократными экземплярами шлюза. Если необходимо отправить большое количество удаленных уведомлений, распространить их по соединениям с несколькими различными шлюзами. Это улучшает производительность по сравнению с использованием единственного соединения: это позволяет Вам отправить удаленные уведомления быстрее, и это позволяет APNs поставить им быстрее.
Сохраните свои соединения с APNs открытыми через многократные уведомления; неоднократно не открывайте и закрывайте соединения. APNs обрабатывает быстрое соединение и разъединение как атака «отказ в обслуживании». Необходимо оставить соединение открытым, если Вы не будете знать, что это будет неактивно в течение длительного периода времени — например, если Вы только отправите уведомления своим пользователям один раз в день, нормально использовать новое соединение каждый день.
Двоичный формат интерфейса и уведомления
Двоичный интерфейс использует простой сокет TCP для двоичного содержания, передающего потоком в природе. Для оптимальной производительности обработайте многократные уведомления в пакетном режиме в единственной передаче по интерфейсу, или явно или использование TCP/IP алгоритм Nagle. Формат уведомлений показан на рисунке 5-1.
Верхний уровень формата уведомления составлен из следующего в порядке:
Имя поля | Длина | Обсуждение |
---|---|---|
Команда | 1 байт | Заполните с числом |
Длина кадра | 4 байта | Размер данных кадра. |
Данные кадра | переменная длина | Кадр содержит организацию, структурированную как серия элементов. |
Данные кадра составлены из серии элементов. Каждый элемент составлен из следующего в порядке:
Имя поля | Длина | Обсуждение |
---|---|---|
Элемент ID | 1 байт | Идентификатор элемента. Например, номер изделия полезной нагрузки |
Длина данных элемента | 2 байта | Размер данных элемента. |
Данные элемента | переменная длина | Значение для элемента. |
Элементы и их идентификаторы, следующие:
Элемент ID | Название товара | Длина | Данные |
---|---|---|---|
1 | Маркер устройства | 32 байта | Маркер устройства в двоичной форме, как был зарегистрирован устройством. |
2 | Полезная нагрузка | переменная длина, меньше чем или равная 2 килобайтам | JSON-отформатированная полезная нагрузка. Полезная нагрузка не должна быть завершена нулем. |
3 | Идентификатор уведомления | 4 байта | Произвольное, непрозрачное значение, идентифицирующее это уведомление. Этот идентификатор используется для создания отчетов об ошибках к Вашему серверу. |
4 | Дата истечения срока | 4 байта | Опорная дата UNIX выразила в секундах (UTC), идентифицирующий, когда уведомление больше не действительно и может быть отброшено. Если это значение является ненулевым, APNs хранит попытки уведомления поставить уведомление, по крайней мере, один раз. Укажите нуль, чтобы указать, что уведомление сразу истекает и что APNs не должен хранить уведомление вообще. |
5 | Приоритет | 1 байт | Приоритет уведомления. Обеспечьте одно из следующих значений:
|
Если Вы отправляете уведомление, принятое APNs, ничто не возвращается.
Если Вы отправляете уведомление, которое уродливо или иначе непонятно, APNs возвращает ошибочный ответный пакет и закрывает соединение. Любые уведомления, которые Вы отправили после уродливого уведомления с помощью того же соединения, отбрасываются и должны быть снова посланы. Рисунок 5-2 показывает формат ошибочного ответного пакета.
Пакет имеет значение команды 8 сопровождаемых однобайтовым кодом состояния и идентификатором уведомления уродливого уведомления. Таблица 5-1 перечисляет возможные коды состояния и их значения.
Код состояния | Описание |
---|---|
0 | Никакие ошибки не встретились |
1 | Обработка ошибки |
2 | Недостающий маркер устройства |
3 | Недостающая тема |
4 | Недостающая полезная нагрузка |
5 | Недопустимый маркерный размер |
6 | Недопустимый размер темы |
7 | Недопустимый размер полезной нагрузки |
8 | Недопустимый маркер |
10 | Завершение работы |
255 | Ни одно (неизвестное) |
Код состояния 10 указывает, что сервер APNs закрыл соединение (например, для выполнения обслуживания). Идентификатор уведомления в ошибочном ответе указывает успешно отправленное последнее уведомление. Любые уведомления, которые Вы отправили после него, были отброшены и должны быть снова посланы. При получении этого кода состояния прекратите использовать это соединение и откройте новое соединение.
Обратите внимание, что маркер устройства в продуктивной среде и маркер устройства в среде разработки не являются тем же значением.
Служба обратной связи
Служба Apple Push Notification включает службу обратной связи, чтобы дать Вам информацию о неработающих удаленных уведомлениях. Когда удаленное уведомление не может быть поставлено, потому что намеченное приложение не существует на устройстве, служба обратной связи добавляет что маркер устройства к его списку. Удаленные уведомления, истекающие прежде чем быть поставленным, не считают неработающей поставкой и не влияют на службу обратной связи. При помощи этой информации, чтобы прекратить отправлять удаленные уведомления, которые не будут поставлены, Вы сокращаете ненужное сообщение наверху и улучшаете полную производительность системы.
Запросите службу обратной связи ежедневно для получения списка маркеров устройства. Используйте метку времени, чтобы проверить, что маркеры устройства не были повторно зарегистрированы, так как запись обратной связи была сгенерирована. Для каждого устройства, не повторно зарегистрированного, прекратите отправлять уведомления. APNs контролирует провайдеров для их усердия в проверке службы обратной связи и воздержании от отправки удаленных уведомлений несуществующим приложениям на устройствах.
Служба обратной связи имеет двоичный интерфейс, подобный интерфейсу, используемому для отправки удаленных уведомлений. Вы получаете доступ к производственной службе обратной связи через feedback.push.apple.com
на порту 2196 и служба обратной связи разработки через feedback.sandbox.push.apple.com
на порту 2196. Как с двоичным интерфейсом для удаленных уведомлений, используйте TLS (или SSL) для установления канала защищенных связей. Вы используете тот же сертификат SSL для соединения со службой обратной связи, как Вы используете для отправки уведомлений. Для установления доверяемых идентификационных данных провайдера представьте этот сертификат APNs во время соединения с помощью одноранговой аутентификации.
Как только Вы соединяетесь, передача сразу начинается; Вы не должны отправлять команду в APNs. Считайте поток из службы обратной связи, пока больше не будет данных для чтения. Полученные данные находятся в кортежах со следующим форматом:
Метка времени | Метка времени (как четыре байта |
Маркерная длина | Длина маркера устройства как двухбайтовое целочисленное значение в сетевом порядке. |
Маркер устройства | Маркер устройства в двоичном формате. |
Список службы обратной связи очищен после чтения его. Каждый раз, когда Вы соединяетесь со службой обратной связи, информация, это возвращает списки только отказы, произошедшие, так как Вы в последний раз соединились.