苹果手机和通知：最大通知数？
我有一个发送通知的 iPhone 应用程序，一切正常...除了有时:)
让我解释一下：我使用一个非常简单的 PHP 脚本来发送通知（使用 stream_context_create 方法），但是一些用户告诉我他们没有收到一些通知。显然，我可能会遇到一些情况，我需要在一分钟内发送多达 50,000 个通知，我认为这可能就是问题所在。我使用一个流来发送所有通知。
你们有人遇到过这样的问题吗？我需要分成几个流吗？是否有关于我可以在流中发送的最大通知数量的信息？
谢谢:)
编辑1
“速度”不是这里的问题：我能够在一分钟内将所有通知推送到Apple（如果我的用户数量增加，我将来可能会遇到一些问题，但是ATM机没问题）。我在这里看到的问题是，Apple 可能会认为我是垃圾邮件发送者或其他什么，并且不会发送我所有的 50,000 条通知：/你们知道我如何确定这一点吗？
I have an iPhone app sending notifications and everything is working fine... Except sometimes :)
Let me explain : I'm using a pretty simple PHP script to send the notifications (using the stream_context_create method) but some users told me they do not receive some notifications. Apparently, I may encounter some cases where I need to send up to 50,000 notifications within a minute and I think this might be the problem. I'm using one single stream to send all the notifications.
Did any of you guys encountered such an issue? Do I need to split in several streams? Is there any info about the max number of notifications I may send in a stream?
Thanks :)
Edit 1
"Speed" is not the issue here : I am able to push all my notifications to Apple within a minute (I may have some issues in the future if my number of users growns but it's OK ATM). The problem I see here is that Apple may consider me a spammer or something and does not deliver all my 50,000 notifications :/ Do you guys have any idea how I can get sure about that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我向一位苹果开发者代表询问了此事，并被告知没有速率限制，而且系统从未丢弃过通知。
（这是 12 个月前的事，当时 Push 还比较新，所以他们可能从那时起就改变了政策）
I asked an Apple developer representative about this and was told there were no rate limits and that the system had never dropped a notification.
(This was 12 months ago, when Push was still relatively new, so they may have changed policies since then)
我宁愿开发代码来用 C 发送通知。PHP 作为一种脚本语言，无法（可能）保证每分钟处理 50K 通知所需的速度。此外，您可能需要一台配备最新一代 CPU 和大量内存的配置量非常大的服务器。事实上，为了满足您所要求的 QOS，您必须能够每秒发送大约 14 个通知。我怀疑 PHP 是否真的能够应对这个速度。
过去我有自己的提供商，我的 QOS 比您要求的要低得多。然后我决定转向商业服务提供商Urban Airship。我发现这项服务很有魅力。没有任何用户报告丢失通知。你必须付费，但自己处理这些东西可能会非常麻烦。
I would rather develop the code to send the notifications in C. PHP, being a scripting language, can not (probably) guarantee the required speed to handle 50K notifications per minute. Moreover, you may need a very hugely provisioned server with latest generation CPUs and a lot of memory. Indeed, to meet the QOS you require, you must be able to send about 14 notification per second. I doubt PHP is actually able to cope with this rate.
In the past I had my own provider, and my QOS was much less than the one you require. Then I decided to switch to a commercial service provider, Urban Airship. I have found this service works like a charm. None of the users have - ever - reported a missing notification. You have to pay for it, but handling this stuff by yourself may prove to be an incredible hassle.
如果通知流中出现故障（即错误令牌），则会丢失一些继续处理的令牌。这是我的经验，所以我一次发送一个令牌。除了一个坏令牌之外，没有更多的失败。
If there is a failure in the notification stream (i.e. bad token), then a few tokens proceeding it are missed. This has been my experience, so I send one token at a time. No more failures, other than the one bad token.
我遇到了完全相同的问题，但每个流的推送要少得多。就我而言，我将所有消息（大约 250 条）推送到同一个流上，但没有一条消息被传递。看起来确实是一个错误的令牌导致了失败，但到目前为止我还不确定什么构成了错误的令牌。
我在其他地方读过，在沙箱环境中使用分发令牌推送消息以及在分发环境中使用沙箱令牌推送消息可能会导致流失败，但我在这两个环境中混合了令牌并且没有错过消息，但是当时我只在一个流中推送几条消息。
长话短说：我在每个流中推送一条消息，并且效果很好。推送 250 条消息需要几秒钟的时间，这看起来效率极低，但对我来说只是一个小麻烦。
I have run into exactly the same issue, but with far fewer pushes per stream. In my case, I pushed all my messages, about 250, on the same stream, and none would be delivered. It does appear that a bad token seems to cause the failure, but so far I'm not certain what constitutes a bad token.
I've read elsewhere that pushing messages using the distribution tokens in a sandbox environment and pushing messages using sandbox tokens in the distribution environment can cause a stream to fail, but I've mixed tokens in both environment and haven't missed messages, but I was only pushing a few messages in one stream at the time.
Long story short: I'm pushing one message per stream, and it works fine. It takes on the order of seconds to push 250 messages, which seems terribly inefficient, but its just a minor nuisance to me.