Notifications 发送到APNS套接字服务器的最大设备数

我们已经运行了将近一年的推送通知脚本突然停止工作。该脚本执行以下操作：

在DB中查询iPhone设备令牌列表

打开与Apple live APNS服务器的SSL套接字连接

$ctx = stream_context_create();
stream_context_set_option($ctx, 'ssl', 'local_cert', $apnsCert);
stream_context_set_option($ctx, 'ssl', 'passphrase', $pass);
$fp = stream_socket_client($apnsHost, $err, $errstr, 60, STREAM_CLIENT_CONNECT, $ctx);

使用255字节大小的消息创建有效负载

$payload = '{
  "aps": {
     "alert": "' . $message . '",
     "badge": 1,
     "sound": "default"
  }
}';

循环遍历每个设备并将有效负载写入打开的连接

$msg = chr(0) . pack("n",32) . pack('H*', str_replace(' ', '', $deviceToken)) . pack("n",strlen($payload)) . $payload;
fwrite($fp, $msg);

然后关闭连接

fclose($fp);

所以我的问题是——脚本中没有任何内容发生变化，但数据库的大小发生了变化。我创建了一个web界面，允许用户向所有iphone设备发送有效负载，当它运行时，发送/加载只需几秒钟。尽管DB中的设备数量（大约3500个）可能会造成问题吗

当我写入套接字时，我可以发送推送通知的最大设备数是多少？是否存在最大值或限制？

同样的问题。。 看起来最大限制是2000台设备。

---

因此，通过套接字打开2000个（或更少）令牌。试试看

事实上，根据经验，在一些通知被推送到APN之后，与APN的连接似乎会失败。在我们自己的APNS库中(http://code.google.com/p/javapns/)，库中包含的多线程传输引擎在推送200个通知后自动重新启动连接（经过反复试验后，这似乎是一个神奇的数字）。由于我们引入了该功能（以及其他一些次要的comlink恢复选项），大量通知的失败通知率变为零。

问题不在于发送到APN的设备数量。问题是苹果改变了他们的API。你现在需要检查每个设备，看看它是否仍然有效（例如，如果他们拒绝推送通知，如果设备删除了应用程序，等等）。如果该设备不再接受来自应用程序的推送通知，并且您以任何方式向其发送推送通知，苹果将立即断开与您的APNS套接字的连接。我现在有一个cronjob，每天运行一次程序，检查并删除数据库中不再接受推送通知的任何设备（苹果有这个列表）。但是要小心——一旦你从苹果公司提取了禁用设备ID列表，苹果公司就会从他们的服务器上删除它，你可以再也不提取它

---

您还需要更新推送通知代码，以检查连接是否曾经断开。当连接断开时，程序需要重新建立连接并再次尝试推送。

在开发模式下测试时，我创建了5个伪令牌UDID，并在最后放置了一个真实的UDID，然后执行OP所做的操作（设置循环），以测试如果前几个出现问题，会发生什么情况，但失败了（或者我有一些其他错误）在第一次尝试时，（从未在实际设备上收到通知）为了进一步测试，我先发送了真正的一个，然后在一个循环中发送了5个假的。这是成功的。这似乎是处理第一个发送的UDID的本质上不好的方法。这意味着如果有人擦拭他们的设备，令牌号在你的发送设备组的中间，你的通知就不被传送，你不知道他们是否曾经。通过..有人能确认这个“实验”吗？我也可能有某种长度的消息错误导致这种行为。如果知道这是苹果的意图，那就太好了。不确定2012年是怎么回事，但目前在设备无法接受通知时（例如，由于应用程序被删除），连接不会中断。我很难想象，这种行为甚至是可能的，因为它会使APN不可用-应用程序会不断从设备上删除。确定它是2000而不是200？值得一读：推送通知吞吐量和错误检查-我知道没有限制。它肯定不是200个通知。