我有一个包括发送苹果推送通知到〜100万用户定期的应用程序。 这样做的设置已建成并通知少量测试。 由于没有办法，我可以测试该尺度的发送，我想知道是否有发送大量推送通知任何陷阱。 我写的Python脚本打开给推送服务器的单一连接，并通过该连接发送的所有通知。 苹果建议保持它打开，只要可能的。 但我也看到，连接终止，你需要重新建立它。
总而言之，这是令人不安的，成功的将不被确认，只有那些错误被标记。 从程序员的角度来看，而不是简单地检查一两件事：“如果（成功）”你现在需要关注众多的事情可能出错。
我的问题是：什么是典型的集，你需要注意，以确保您的邮件没有声息被人遗忘的错误？ 在关闭连接是容易的。 是否有其他人呢？
我完全同意你的看法，这个API是非常令人沮丧，如果他们所要发送的每个通知这本来是很容易实现的响应。
这就是说，这里就是苹果公司说，你应该做的（从技术说明 ）：
推送通知吞吐量和错误检查
没有使用的APN帽或批量大小限制。 iOS的6.1新闻稿指出，APN的已派出超过4万亿推送通知，因为它成立。 它是在WWDC 2012是的APN每天发送7个十亿通知公布。
如果您看到吞吐量每秒下9000个多家通知，您的服务器可能会受益于改进的错误处理逻辑。
以下是如何使用增强的二进制接口时，检查错误。 继续写，直到写入失败。 如果流已经准备好再次写，重发通知，继续向前。 如果流是不是准备好写，看是否流可用于阅读。
如果是，请阅读可从流的一切。 如果你得到零个字节后面，连接被关闭，因为一个错误，如无效的命令字节或其他解析错误。 如果你得到六个字节回来，这是一个错误的反应，你可以检查响应代码，并导致错误通知的ID。 你需要重新发送下面是一个所有通知。
一旦一切都已经送到，做一个错误的响应最后检查。
它可能需要一段时间的下跌连接从APN的做它的方式返回到你的服务器仅仅因为正常的延迟。 它可以发送500通知之前，因为连接被丢弃写入失败。 大约1700个通知，因为满管的写入可以直接失败，所以只是在这种情况下，重试一次流准备好再次书写。
现在，这里的地方的权衡变得有趣。 您可以检查每一个写操作后错误响应，你会捕捉错误的时候了。 但是，这会导致它需要发送一批通知的时间大幅增加。
设备令牌应该几乎全部是有效的，如果你正确地捕捉它们，你将它们发送到正确的环境。 因此，它是有道理的优化假设的失败将是罕见的。 如果您等待写入失败或批量检查错误响应，即使只计算重新发送下降通知的时间之前完成，你会收获更好的性能。
这一切都不是真的特定的APN，它适用于大多数插座级编程。
如果你选择的开发工具支持多线程或进程间通信，你可以有一个线程或进程等待一个错误响应所有的时间，让主发送线程或进程知道什么时候应该放弃，然后重试。
只是想附和第一人称视角，因为我们每天发送数以百万计APNS通知。
@Eran报价参考不幸的是对我们有苹果如何管理APNS插座最好的资源。 这是罚款低量，但苹果的文档整体是非常偏向休闲，小批量开发。 你会看到大量的无证行为，一旦你按比例。
这样做的错误检测该文件的一部分异步是高通量的关键。 如果硬要阻止错误在每个发送，那么你就需要大量并行的工人跟上吞吐量。 推荐的方式，但是，是只需发送一样快，您可以发送，每当你得到和错误：维修和重播。
那个帖子我不同意是的一部分：
设备令牌应该几乎全部是有效的，如果你正确地捕捉它们 ，你将它们发送到正确的环境。 因此，它是有道理的优化假设的失败将是罕见的 。
与谓词建议如此巨大的“IF”，似乎巨大的误导。 我几乎可以保证，大多数开发商都没有捕捉标记和“正确”处理苹果的反馈服务100％。 即使他们的系统本质上是有损耗的，所以漂移的事情发生。
我们看到的错误＃8的响应（无效的设备令牌），我归因于根深蒂固的手机，客户端的错误，或用户故意欺骗自己的令牌给我们一个非零数字。 我们也看到了一些过去的错误＃7（无效的有效载荷大小），这是我们追查到不正确的编码，开发人员加入我们的最终消息。 这是我们事业的过错，但是这是我的观点 - 他说：“假设优化的故障将是罕见的”的错误信息发送给开发者学习。 我想说的，而不是将是：
假设错误会发生。
希望他们不常发生，但防守上的代码的情况下，他们不这样做。
如果您优化假设错误将是罕见的，你可能有危险把你的基础设施每当APNS服务下降和每封邮件发送返回错误＃10。
麻烦来试图找出如何正确响应错误时。 文档不明确或不存在关于如何妥善处理，并从不同的错误中恢复。 这是作为一个练习的读者明显。
