Einige Geräte, die nicht empfangen Apple-Push-Benachrichtigungen

Question

Ich bin mit Apples iOS erweitern Benachrichtigungs Format Push-Benachrichtigung in der Masse zu schicken, und mit Hilfe der PHP-Lösung in diesem Beitrag beschrieben: https://stackoverflow.com/a/10059000/300129

Die Erfahrung an dieser Stelle ist, dass, wenn ich sende eine Push-Benachrichtigung, einige Geräte empfangen die Nachricht und manche Geräte nicht. Die Ergebnisse sind inkonsistent. Manchmal empfängt Gerät X eine Benachrichtigung und manchmal Gerät X nicht. Ich protokolliere alles und bekomme keine Fehlerreaktionen.

Alle Gedanken über das, was passiert, wären sehr hilfreich.

Answer 1

Die Lösung in der Antwort, die Sie verknüpft haben, hat ein Problem. Es versucht, die Fehlerantwort zu lesen, nachdem jede Nachricht gesendet wurde, aber der Lesevorgang kehrt sofort zurück und wartet nicht darauf, dass eine Antwort verfügbar wird. Dies ist zwar effizienter als das Warten auf eine mögliche Fehlerantwort für X Millisekunden nach jeder Nachricht, aber Sie können die Fehlerantwort verpassen, und die Verbindung kann von Apple unterbrochen werden, ohne dass Sie einen Fehler bemerken.

Während ich Ihnen Code zur Lösung Ihres Problems nicht geben kann, gebe ich Ihnen einen Rat.

Hier ist die Logik, die Sie (laut Apple) verwenden sollte, aber ich habe es nicht geschafft, um es zuverlässig funktioniert (zumindest nicht in meinem Java-Implementierung):

Push Notification Durchsatz und Fehlerprüfung

Wenn der Durchsatz weniger als 9.000 Benachrichtigungen pro Sekunde beträgt, könnte Ihr Server von einer verbesserten Fehlerbehandlungslogik profitieren.

So prüfen Sie bei Verwendung der erweiterten Binärschnittstelle auf Fehler. Schreiben Sie weiter, bis ein Schreibvorgang fehlschlägt. Wenn der Stream wieder zum Schreiben bereit ist, senden Sie die Benachrichtigung erneut und fahren Sie fort. Wenn der Stream nicht schreibbereit ist, prüfen Sie, ob der Stream zum Lesen verfügbar ist.

Wenn dies der Fall ist, lesen Sie alles, was im Stream verfügbar ist. Wenn Sie null Bytes zurück erhalten, wurde die Verbindung wegen eines Fehlers wie einem ungültigen Befehlsbyte oder einem anderen Analysefehler geschlossen.Wenn Sie sechs Byte zurück erhalten, ist dies eine Fehlerantwort, die Sie nach dem Antwortcode und der ID der Benachrichtigung suchen können, die den Fehler verursacht hat. Sie müssen jede nachfolgende Benachrichtigung erneut senden.

Sobald alles gesendet wurde, suchen Sie noch einmal nach einer Fehlerreaktion.

Es kann eine Weile dauern, bis die unterbrochene Verbindung von den APNs zurück zum Server gelangt, nur weil die Latenz normal ist. Es ist möglich, über 500 Benachrichtigungen zu senden, bevor ein Schreibvorgang fehlschlägt, weil die Verbindung unterbrochen wurde. Rund 1.700 Benachrichtigungen können nur fehlschlagen, weil die Pipe voll ist. Versuchen Sie es einfach erneut, sobald der Stream wieder zum Schreiben bereit ist.

Jetzt, hier ist, wo die Kompromisse interessant werden. Sie können nach jedem Schreibvorgang nach einer Fehlerreaktion suchen, und Sie werden den Fehler sofort bemerken. Dadurch erhöht sich jedoch die Zeit, die zum Senden einer Gruppe von Benachrichtigungen benötigt wird.

Geräte-Token sollten fast alle gültig sein, wenn Sie sie korrekt erfasst und an die richtige Umgebung gesendet haben. Daher ist es sinnvoll zu optimieren, vorausgesetzt, dass Fehler selten auftreten. Sie erhalten eine deutlich bessere Leistung, wenn Sie warten, bis der Schreibvorgang fehlschlägt oder der Stapel abgeschlossen ist, bevor Sie nach einer Fehlerreaktion suchen, und sogar die Zeit für das erneute Senden der gelöschten Benachrichtigungen zählen.

Nichts davon ist wirklich spezifisch für APNs, es gilt für die meisten Socket-Level-Programmierung.

Wenn Ihr Entwicklungstool der Wahl mehrere Threads oder Interprozesskommunikation unterstützt, könnten Sie einen Thread oder Prozess ständig auf eine Fehlerreaktion warten lassen und den Haupt-Thread oder -Prozess darüber informieren, wann er aufgibt und es erneut versucht.

Dies ist aus Apples Tech Note: Troubleshooting Push Notifications entnommen.

Ich weiß nicht, wie Sie in PHP feststellen, dass der Schreibvorgang fehlgeschlagen ist, aber wenn dies der Fall ist, sollten Sie versuchen, die fehlgeschlagene Benachrichtigung erneut zu schreiben, und wenn es erneut fehlschlägt, versuchen Sie die Fehlerantwort zu lesen Verbindung.

Wenn Sie die Fehlerreaktion lesen, wissen Sie, welche Benachrichtigung fehlgeschlagen ist und Sie kennen den Fehlertyp (der wahrscheinlichste Fehler ist 8 - ungültiges Geräte-Token). Der Code in der Antwort, auf die Sie sich bezogen haben, führt nach dem Identifizieren dieses Fehlers nichts aus. Wenn Sie nach dem Schreiben von 100 Nachrichten eine Fehlermeldung für die 80. Nachricht erhalten, müssen Sie die Nachrichten 81 bis 100 erneut senden, da Apple sie nie erhalten hat. In meinem Fall (Java-Server) gelingt es mir nicht immer, die Fehlerreaktion zu lesen (manchmal bekomme ich einen Fehler, wenn ich versuche, die Antwort vom Socket zu lesen). In diesem Fall kann ich nur weitergehen und die nächsten Benachrichtigungen senden (und habe keine Möglichkeit zu wissen, welche Benachrichtigungen tatsächlich von Apple empfangen wurden). Aus diesem Grund ist es wichtig, Ihre Datenbank von ungültigen Tokens freizuhalten.

Wenn Sie Ihre Datenbank sauber halten (dh nur Gerätetokens speichern, die von Apple an Ihre App gesendet wurden und alle zur selben Push-Umgebung gehören - entweder Sandbox oder Produktion), sollten Sie keine finden ungültige Gerät Token.

Ich stieß auf ein ähnliches Problem bei der Implementierung der Push-Benachrichtigung Server-Seite in Java. Ich konnte nicht alle Fehlerreaktionen von Apple zuverlässig erhalten.

Ich habe festgestellt, dass es in Java gibt es eine Möglichkeit, den TCP Nagle-Algorithmus zu deaktivieren, der die Pufferung mehrerer Nachrichten vor dem Senden in einem Stapel an Apple verursacht.Obwohl Apple uns ermutigt, den Nagle-Algorithmus zu verwenden (aus Leistungsgründen), habe ich festgestellt, dass ich 100% der Fehlerantworten erhalte, wenn ich sie deaktiviere und dann versuche, die Antwort von Apple nach jeder Nachricht zu lesen (I verifizierte es, indem er einen Prozess schrieb, der den APNS-Server simulierte).

Indem Sie den Nagle-Algorithmus deaktivieren und die Benachrichtigungen langsam nacheinander senden und versuchen, die Fehlerantwort nach jeder Nachricht zu lesen, können Sie alle ungültigen Token in Ihrer Datenbank finden und entfernen. Sobald Sie wissen, dass Ihre Datenbank sauber ist, können Sie den Nagle-Algorithmus aktivieren und das Senden von Benachrichtigungen schnell wieder aufnehmen, ohne die Fehlerreaktionen von Apple zu lesen. Wenn Sie dann beim Schreiben einer Nachricht in den Socket einen Fehler erhalten, können Sie einfach einen neuen Socket erstellen und versuchen, nur die letzte Nachricht zu senden.

Answer 2

Es kann nicht garantiert werden, dass Push-Benachrichtigungen tatsächlich zugestellt werden, auch wenn der APNS-Server diese akzeptiert.

Soweit es Ihren Server betrifft, sind Push-Benachrichtigungen Feuer-und-vergessen; Es gibt keine Möglichkeit, den Status einer Benachrichtigung zu ermitteln, nachdem Sie sie an APNS gesendet haben. Die Lieferzeit kann auch variieren, von Sekunden bis zu einer halben Stunde.
Außerdem kann das iPhone des Benutzers möglicherweise nicht immer Push-Benachrichtigungen empfangen. Sie könnten auf einem WiFi-Netzwerk sein, das keine Verbindungen zu APNS ermöglicht, da die erforderlichen Ports blockiert sind. Oder das Telefon könnte ausgeschaltet werden.

APNS wird versuchen, die letzte Mitteilung es für das Gerät erhalten zu liefern, wenn es zurück Online kommt, aber es wird nur für eine begrenzte Zeit versuchen. Sobald es ausläuft, wird die Push-Benachrichtigung für immer verloren gehen!

Answer 3

Ich habe dieses Problem auch in meinen verschiedenen Anwendungen erfahren. Der Grund für einige Geräte, die die Push-Benachrichtigungen nicht erhalten, kann sein:

Verwenden von Sandbox APNS-Server mit Produktion APNS-Zertifikat. -> Bitte überprüfen Sie es

Sowohl Entwicklung und Produktion provisorische Profile auf dem Gerät installiert. -> Entfernen Sie beide vorläufigen und dann müssen Sie mindestens 24 Stunden warten, damit apple auch das Gerät Token von seinem Server entfernt.

Answer 4

In meinem Fall wurden während der Entwicklung einige APNs nicht in einem Gerät empfangen (ich habe mit PushMeBaby getestet).

Ich löschte alle vorherigen Provisioning-Profile meines Projekts aus meinem Gerät, und von diesem Moment an ging alles gut. Gehe dazu auf Einstellungen> Profile.

Vielleicht hatte ich irgendeine Art von Konflikt mit Profilen, da das Projekt, an dem ich arbeite, die Bundle-ID und die Bereitstellungsprofile seither verändert hat.