Apple Notifications Push en Vrac

J'ai une appli qui implique l'envoi de Notifications Push d'Apple à ~1M utilisateurs périodiquement. Le programme d'installation pour le faire a été construit et testé pour un petit nombre de notifications. Depuis il n'y a aucun moyen que je peux tester l'envoi à cette échelle, je suis intéressée de savoir si il ya des erreurs dans l'envoi groupé de notifications push. J'ai des scripts écrits en Python qui s'ouvrent d'une seule connexion à la push serveur et envoyer toutes les notifications sur la connexion. Apple recommande de le garder ouvert pour aussi longtemps que possible. Mais j'ai également vu que la connexion se termine et vous avez besoin de rétablir cela.

Dans l'ensemble, il est déconcertant de constater que le succès de l'envoie ne sont pas reconnus, seulement erronée ceux qui sont marqués. À partir d'un point de vue du programmeur, au lieu de simplement vérifier une chose "si (succès)" maintenant, vous avez besoin de regarder pour de nombreuses choses qui pourraient aller mal.

Ma question est: Quelle est la configuration typique d'erreurs que vous avez besoin pour regarder dehors pour s'assurer que vos messages ne sont pas en silence disparaissent dans l'oubli? La connexion de la fermeture est facile. Il y a d'autres?

  • avez-vous trouver un moyen pour envoyer en masse des notification push pour les iphone? parce que je ne suis pas le trouver :/
  • Si vous êtes commencer juste dehors, puis envisager de commencer avec Urban Airship, qui vous donne ~1M gratuit de pousse par mois, mais sinon incroyablement cher. Si vous avez plus de volume que cela, alors vous pouvez utiliser Amazon SNS service (qui est à quelques ordres de grandeur moins cher qu'en milieu Urbain, Dirigeable, et c'est ce que j'utilise).
  • mais je suis de l'envoi de mon push gratuit donc il doit y avoir un moyen pour envoyer en masse des push aussi gratuit
InformationsquelleAutor er0 | 2013-05-03
  1. 12

    Je suis complètement d'accord avec vous que cette API est très frustrant, et si ils ont envoyé une réponse pour chaque notification, il aurait été beaucoup plus facile à mettre en œuvre.

    Cela dit, voici ce qu'Apple a dire que vous devriez faire (à partir de Note Technique) :

    De Notification Push de Débit et de contrôle d'Erreur

    Il n'y a pas de casquettes ou de la taille des lots de limiter l'utilisation de l'Apn. L'iOS 6.1
    communiqué de presse a déclaré que l'Apn a envoyé plus de 4 billions de pousser
    les notifications depuis qu'il a été établi. Il a été annoncé lors de la WWDC 2012
    que l'Apn est l'envoi de 7 milliards de notifications quotidiennes.

    Si vous voyez un débit inférieur à 9 000 notifications par seconde,
    votre serveur peut bénéficier de l'amélioration de la gestion des erreurs de logique.

    Voici comment vérifier pour les erreurs lors de l'utilisation de l'renforcée binaire
    de l'interface. Continuer à écrire jusqu'à ce qu'une écriture échoue. Si le flux est prêt
    pour écrire à nouveau, renvoyer la notification et de continuer. Si l'
    stream n'est pas prêt pour l'écriture, voir si le flux est disponible pour
    à la lecture.

    Si elle l'est, de lire tout ce qui est disponible à partir du flux. Si vous obtenez zéro
    octets de retour, la connexion a été fermée en raison d'une erreur telle qu'une
    commande non valide octet ou autre erreur d'analyse. Si vous obtenez six octets
    de retour, c'est une réponse d'erreur, vous pouvez vérifier pour la réponse
    le code et l'IDENTIFIANT de la notification qui a provoqué l'erreur. Vous aurez besoin
    pour envoyer chaque notification à la suite encore une fois.

    Une fois que tout a été envoyé, le faire une dernière vérification pour une erreur
    réponse.

    Il peut prendre un certain temps pour que la connexion a été interrompue à faire son chemin à partir de
    Apn arrière de votre serveur juste à cause de la latence normale. Il est possible
    pour envoyer plus de 500 notifications avant une écriture échoue à cause de la
    connexion d'être supprimé. Environ 1 700 notifications écrit peut échouer
    tout simplement parce que le tuyau est plein, il suffit donc de réessayer dans ce cas, une fois la
    flux est prêt pour écrire à nouveau.

    Maintenant, voici où le compromis intéressant. Vous pouvez vérifier un
    réponse d'erreur après chaque écriture, et vous allez prendre, l'erreur de droit
    loin. Mais cela provoque une énorme augmentation dans le temps qu'il faut pour envoyer un
    lot de notifications.

    Appareil jetons devraient presque tous être valable que si vous avez capturés
    correctement et que vous leur envoyez de l'environnement approprié. De sorte qu'il
    a de sens pour optimiser en supposant que les échecs sont rares. Vous aurez à obtenir de façon
    de meilleures performances si vous attendez pour écrire à l'échec ou le lot
    complet avant de vérifier qu'une réponse d'erreur, même en comptant les temps
    pour envoyer le tombé des notifications de nouveau.

    Rien de cela n'est vraiment spécifique à l'Apn, il s'applique à la plupart des
    prise au niveau de la programmation.

    Si votre outil de développement de choix prend en charge plusieurs threads ou
    communication interprocessus, vous pourriez avoir un thread ou processus en attente
    pour une réponse d'erreur de tous les temps et laisser le principal de l'envoi de fil ou
    processus de savoir quand il doit abandonner et de recommencer.

    • Wow. Pas mon premier temps de trouver une mine d'informations et de réponses dans un Apple Note technique que je ne connaissais pas. Merci pour le pointeur!
    • Vous êtes les bienvenus. Cette note technique a été autour depuis un certain temps, mais ils ont ajouté l'article que j'ai cité récemment.
    • Je me suis cassé la pipe d'erreur lors de l'envoi de la notification push en vrac, je suis en utilisant django python pour l'envoi de la notification, comment puis-je éviter le bris de tuyau d'erreur? Je suis en train de travailler première fois sur ce type de projet, donc je ne suis pas au courant de tellement de choses, s'il vous plaît suggérer la manière appropriée pour éviter ces erreurs.
    InformationsquelleAutor Eran
  2. 7

    Voulais juste carillon avec un point de vue première personne, comme nous l'envoient des millions de APNS les notifications de tous les jours.

    La référence @Eran devis est malheureusement la meilleure ressource que nous avons pour la façon dont Apple gère les APNS sockets. C'est bien pour un faible volume, mais la documentation d'Apple est globalement très biaisée vers le casual, le faible volume de développeur. Vous verrez beaucoup de sans-papiers comportement une fois que vous obtenez à l'échelle.

    La partie de ce document à propos de faire la détection de l'erreur asynchrone est essentiel pour le haut débit. Si vous insistez sur le blocage des erreurs sur tous les envoyer, alors vous aurez besoin d'fortement paralléliser vos travailleurs pour maintenir le débit. La méthode recommandée, cependant, est simplement d'envoyer aussi vite que vous pouvez les envoyer, et à chaque fois que vous obtenez et de l'erreur: la réparation et de relecture.

    La partie de ce post, je prends exception est:

    Appareil jetons devraient presque tous être valide si vous avez capturés
    correctement     et que vous leur envoyez de l'environnement approprié. De sorte qu'il
    a de sens pour optimiser en supposant que les échecs sont rares    .

    À prédicat que des conseils comme un grand "SI" semble extrêmement trompeuse. Je peux presque garantir que la plupart des développeurs ne sont pas capturer les pions et le traitement d'Apple service de réponse de 100% "correctement". Même si elles l'étaient, le système est intrinsèquement à perte, donc la dérive va arriver.

    Nous voyons un nombre différent de zéro de l'erreur #8 les réponses (non valide dispositif de jeton) que j'ai attribut pour les téléphones rootés, client bogues, ou des utilisateurs intentionnellement l'usurpation de leurs jetons pour nous. Nous avons également vu un certain nombre d'erreur #7 (invalides taille de la charge utile) dans le passé, nous avons traqué à mal des messages codés qu'un développeur a ajouté sur notre fin. C'était de notre faute, bien sûr, mais c'est mon point--disant "optimiser en supposant que les défectuosités seront rares" est le mauvais message à envoyer aux développeurs de l'apprentissage. Ce que je dirais serait plutôt:

    Assumer les erreurs vont se produire.

    De l'espoir qu'ils se produisent rarement, mais
    code de la défense dans le cas où ils ne le font pas.

    Si vous optimiser en supposant que les erreurs sont rares, vous pouvez peut-être mettre votre infrastructure à risque lors de l'APN service va vers le bas et de chaque message que vous envoyez renvoie une erreur #10.

    Le problème arrive lorsque vous essayez de comprendre comment répondre correctement à des erreurs. La Documentation est ambigu ou absent sur la façon de gérer correctement et de le récupérer à partir de différentes erreurs. Ce qui est laissé comme exercice pour le lecteur, apparemment.

    InformationsquelleAutor DougW