Apple Push Benachrichtigungen in Bulk

Question

Ich habe eine App, die das Senden von Apple Push-Benachrichtigungen an ~ 1M Benutzer in regelmäßigen Abständen beinhaltet. Das Setup dafür wurde für eine kleine Anzahl von Benachrichtigungen erstellt und getestet. Da es keinen Weg gibt, den Versand in dieser Größenordnung zu testen, möchte ich wissen, ob beim Senden von Massen-Push-Benachrichtigungen irgendwelche Probleme bestehen. Ich habe Skripte in Python geschrieben, die eine einzige Verbindung zum Push-Server öffnen und alle Benachrichtigungen über diese Verbindung senden. Apple empfiehlt, so lange wie möglich offen zu halten. Aber ich habe auch gesehen, dass die Verbindung beendet wird und du sie wieder aufbauen musst.

Alles in allem ist es beunruhigend, dass erfolgreiche Sends nicht bestätigt werden, nur fehlerhafte werden markiert. Vom Standpunkt eines Programmierers aus, anstatt einfach nur eine Sache zu überprüfen: "Wenn (Erfolg)", müssen Sie nun auf zahlreiche Dinge achten, die schief gehen könnten.

Meine Frage ist: Was sind die typischen Fehler, die Sie beachten müssen, um sicherzustellen, dass Ihre Nachrichten nicht still in Vergessenheit geraten? Das Schließen der Verbindung ist einfach. Gibt es andere?

Answer 1

Ich stimme Ihnen völlig zu, dass diese API sehr frustrierend ist, und wenn sie eine Antwort für jede Benachrichtigung gesendet hätten, wäre es viel einfacher zu implementieren gewesen.

Das heißt, hier ist, was Apple sagen Sie tun sollten (von Technical Note):

Push Notification Throughput and Error Checking

There are no caps or batch size limits for using APNs. The iOS 6.1 press release stated that APNs has sent over 4 trillion push notifications since it was established. It was announced at WWDC 2012 that APNs is sending 7 billion notifications daily.

If you're seeing throughput lower than 9,000 notifications per second, your server might benefit from improved error handling logic.

Here's how to check for errors when using the enhanced binary interface. Keep writing until a write fails. If the stream is ready for writing again, resend the notification and keep going. If the stream isn't ready for writing, see if the stream is available for reading.

If it is, read everything available from the stream. If you get zero bytes back, the connection was closed because of an error such as an invalid command byte or other parsing error. If you get six bytes back, that's an error response that you can check for the response code and the ID of the notification that caused the error. You'll need to send every notification following that one again.

Once everything has been sent, do one last check for an error response.

It can take a while for the dropped connection to make its way from APNs back to your server just because of normal latency. It's possible to send over 500 notifications before a write fails because of the connection being dropped. Around 1,700 notifications writes can fail just because the pipe is full, so just retry in that case once the stream is ready for writing again.

Now, here's where the tradeoffs get interesting. You can check for an error response after every write, and you'll catch the error right away. But this causes a huge increase in the time it takes to send a batch of notifications.

Device tokens should almost all be valid if you've captured them correctly and you're sending them to the correct environment. So it makes sense to optimize assuming failures will be rare. You'll get way better performance if you wait for write to fail or the batch to complete before checking for an error response, even counting the time to send the dropped notifications again.

None of this is really specific to APNs, it applies to most socket-level programming.

If your development tool of choice supports multiple threads or interprocess communication, you could have a thread or process waiting for an error response all the time and let the main sending thread or process know when it should give up and retry.

Answer 2

Ich wollte nur mit einer Perspektive der ersten Person läuten, wie wir Millionen von APNS Meldungen täglich senden.

Die Referenz @Eran Zitate ist leider über die beste Ressource, die wir für wie Apple APNS-Sockets verwaltet hat. Es ist in Ordnung für geringe Lautstärke, aber die gesamte Dokumentation von Apple ist sehr schief gegenüber dem gelegentlichen Entwickler mit geringem Volumen. Wenn Sie skalieren, werden Sie viel undokumentiertes Verhalten feststellen.

Der Teil dieses Dokuments über die asynchrone Fehlererkennung ist entscheidend für einen hohen Durchsatz. Wenn Sie darauf bestehen, bei jedem Sendevorgang Fehler zu blockieren, müssen Sie Ihre Mitarbeiter stark parallelisieren, um den Durchsatz aufrechtzuerhalten. Der empfohlene Weg ist jedoch, senden Sie so schnell wie Sie senden können, und wann immer Sie tun und Fehler: Reparatur und Wiederholung.

Der Teil dieser Beitrag habe ich Ausnahme zu nehmen ist:

Device tokens should almost all be valid if you've captured them correctly and you're sending them to the correct environment. So it makes sense to optimize assuming failures will be rare.

, dass die Beratung Prädikat mit einem so großen „IF“ äußerst irreführend sein scheint. Ich kann fast garantieren, dass die meisten Entwickler keine Token erfassen und den Feedback-Service von Apple zu 100% "richtig" verarbeiten. Selbst wenn sie es waren, ist das System von Natur aus verlustreich, also wird es zu Abweichungen kommen.

Wir sehen eine Anzahl von Fehler # 8 Antworten (ungültiges Geräte-Token) ungleich null, die ich gerooteten Telefonen, Client-Fehlern oder Benutzern zuschreibe, die ihre Token absichtlich gefälscht haben. Wir haben in der Vergangenheit auch eine Anzahl von Fehler # 7 (ungültige Nutzlastgröße) gesehen, die wir auf falsch codierte Nachrichten aufgespürt haben, die ein Entwickler an unserem Ende hinzugefügt hat. Das war natürlich unsere Schuld, aber das ist mein Punkt - zu sagen, "Optimiere Annahme von Fehlern wird selten sein" ist die falsche Botschaft, die an Lernentwickler geschickt wird. Was würde ich sagen, stattdessen wäre:

Assume errors will happen.

Hope that they happen infrequently, but code defensively in case they don't.

Wenn Sie Fehler optimieren vorausgesetzt wird selten, können Sie Ihre Infrastruktur in Gefahr setzen, wenn der APNS Service geht und jede Nachricht, die Sie kehrt senden einen Fehler # 10.

Das Problem tritt auf, wenn Sie herausfinden möchten, wie Sie auf Fehler richtig reagieren. Die Dokumentation ist mehrdeutig oder fehlt hinsichtlich der korrekten Handhabung und Behebung verschiedener Fehler. Dies ist offensichtlich eine Übung für den Leser.