iphone - que - Notificaciones push de Apple a granel
ios push service (2)
Estoy completamente de acuerdo con usted en que esta API es muy frustrante, y si hubieran enviado una respuesta para cada notificación, habría sido mucho más fácil de implementar.
Dicho esto, esto es lo que Apple dice que debes hacer (de la Nota técnica ):
Rendimiento de notificaciones push y comprobación de errores
No hay límites o límites de tamaño de lote para usar APN. El comunicado de prensa de iOS 6.1 declaró que APN ha enviado más de 4 billones de notificaciones push desde que se estableció. En WWDC 2012 se anunció que APN enviará 7 mil millones de notificaciones diarias.
Si observa un rendimiento inferior a 9,000 notificaciones por segundo, su servidor podría beneficiarse de una mejor lógica de manejo de errores.
Aquí se explica cómo verificar errores al usar la interfaz binaria mejorada. Sigue escribiendo hasta que una escritura falle. Si la transmisión está lista para escribir nuevamente, reenvíe la notificación y continúe. Si el flujo no está listo para escribir, vea si el flujo está disponible para leer.
Si es así, lea todo lo disponible en la transmisión. Si obtiene cero bytes de vuelta, la conexión se cerró debido a un error, como un byte de comando no válido u otro error de análisis. Si obtiene seis bytes de vuelta, es una respuesta de error que puede verificar el código de respuesta y el ID de la notificación que causó el error. Tendrás que enviar todas las notificaciones después de esa otra vez.
Una vez que se haya enviado todo, realice una última comprobación para detectar una respuesta de error.
La conexión interrumpida puede tardar un tiempo en volver de los APN a su servidor solo debido a la latencia normal. Es posible enviar más de 500 notificaciones antes de que falle la escritura debido a que se interrumpió la conexión. Alrededor de 1,700 escrituras de notificaciones pueden fallar solo porque la canalización está llena, así que vuelva a intentarlo una vez que la secuencia esté lista para escribir nuevamente.
Ahora, aquí es donde las concesiones se ponen interesantes. Puede verificar una respuesta de error después de cada escritura, y detectará el error de inmediato. Pero esto provoca un gran aumento en el tiempo que lleva enviar un lote de notificaciones.
Los tokens del dispositivo deberían ser casi todos válidos si los ha capturado correctamente y los está enviando al entorno correcto. Así que tiene sentido optimizar asumiendo que las fallas serán raras. Obtendrá un rendimiento mucho mejor si espera que la escritura falle o el lote se complete antes de verificar una respuesta de error, incluso contando el tiempo para enviar las notificaciones eliminadas nuevamente.
Nada de esto es realmente específico para los APN, se aplica a la mayoría de la programación a nivel de socket.
Si su herramienta de desarrollo elegida es compatible con múltiples subprocesos o comunicación entre procesos, puede tener un subproceso o un proceso esperando una respuesta de error todo el tiempo y avisar al subproceso o proceso principal de envío cuándo debe darse por vencido y volver a intentarlo.
Tengo una aplicación que involucra el envío de notificaciones push de Apple a usuarios de ~ 1M periódicamente. La configuración para hacerlo se ha creado y probado para pequeñas cantidades de notificaciones. Dado que no hay forma de probar el envío a esa escala, estoy interesado en saber si existen errores en el envío de notificaciones de envío masivo. Tengo scripts escritos en Python que abren una sola conexión al servidor de inserción y envían todas las notificaciones a través de esa conexión. Apple recomienda mantenerlo abierto el mayor tiempo posible. Pero también he visto que la conexión termina y es necesario restablecerla.
En general, es desconcertante que los envíos exitosos no se confirmen, solo se marcan los erróneos. Desde el punto de vista de un programador, en lugar de simplemente marcar una cosa "si (éxito)" ahora necesita observar muchas cosas que podrían salir mal.
Mi pregunta es: ¿Cuáles son los errores típicos que debes vigilar para asegurarte de que tus mensajes no desaparezcan silenciosamente en el olvido? El cierre de la conexión es fácil. ¿Hay otros?
Solo quería participar con una perspectiva en primera persona, ya que enviamos millones de notificaciones APNS todos los días.
Las citas de referencia de @Eran son, desafortunadamente, sobre el mejor recurso que tenemos sobre cómo Apple administra los sockets APNS. Está bien para un volumen bajo, pero la documentación general de Apple está muy sesgada hacia el desarrollador informal de bajo volumen. Verás un montón de comportamiento indocumentado una vez que llegues a la escala.
La parte de ese documento sobre cómo hacer la detección de errores de forma asíncrona es crítica para un alto rendimiento. Si insiste en bloquear los errores en cada envío, deberá paralelizar en gran medida a sus trabajadores para mantener el rendimiento. Sin embargo, la forma recomendada es simplemente enviar lo más rápido que pueda, y siempre que reciba un error: repare y repita.
La parte de esa publicación a la que hago excepción es:
Los tokens del dispositivo deberían ser casi todos válidos si los ha capturado correctamente y los está enviando al entorno correcto. Así que tiene sentido optimizar asumiendo que las fallas serán raras .
Predicar ese consejo con un "SI" tan enorme parece enormemente engañoso. Casi puedo garantizar que la mayoría de los desarrolladores no están capturando tokens y procesando el servicio de comentarios de Apple al 100% "correctamente". Incluso si lo fueran, el sistema tiene pérdidas inherentes, por lo que la deriva va a suceder.
Vemos un número no nulo de respuestas de error # 8 (token de dispositivo no válido) que atribuyo a teléfonos rooteados, errores de clientes o usuarios que nos falsifican intencionalmente sus tokens. También hemos visto un número de error # 7 (tamaño de carga útil no válido) en el pasado, que rastreamos a los mensajes codificados incorrectamente que un desarrollador agregó en nuestro extremo. Eso fue culpa nuestra, por supuesto, pero ese es mi punto: decir "optimizar asumiendo que las fallas serán poco frecuentes" es un mensaje equivocado para enviar a los desarrolladores de aprendizaje. Lo que yo diría en cambio sería:
Supongamos que los errores van a suceder.
Espero que ocurran con poca frecuencia, pero codifique defensivamente en caso de que no lo hagan.
Si optimiza, asumiendo que los errores serán raros, puede poner su infraestructura en riesgo cada vez que el servicio APNS se desactiva y cada mensaje que envíe devuelve un error # 10.
El problema viene cuando se trata de averiguar cómo responder adecuadamente a los errores. La documentación es ambigua o está ausente en cuanto a cómo manejar y recuperar adecuadamente los diferentes errores. Esto queda como un ejercicio para el lector al parecer.