Question

我遇到了APNS问题和一个无效的令牌，它“阻止”所有后续推送。这是PHP中的代码示例：

$ctx = stream_context_create();
stream_context_set_option($ctx, 'ssl', 'local_cert', $cert_path);
$fp = stream_socket_client($ssl_url, $error, $errorString, 2, STREAM_CLIENT_CONNECT, $ctx);
stream_set_blocking($fp, 0);
stream_set_write_buffer($fp, 0);

if (!$fp) {
    while ($message = nextMessage()) {
        $msg = chr(0) . pack("n", 32) . pack('H*', $token) . pack("n", strlen($message)) . $message;
        $fwrite = fwrite($fp, $msg);
    }
    fclose($fp);
}

此代码完美无缺

使用一个有效令牌（设备收到消息）
有许多有效令牌（所有设备都收到了消息）

此外，我不想为每条消息打开/关闭流套接字：它太慢了。

但是如果使用了无效的令牌，则所有关注无效令牌的设备都不会收到该消息。反馈服务现在没有告诉我任何事情（我可能已收到此令牌无效的信息）。做“while（！feof（$ fp））fread（$ fp）;”不给我信息。

你能帮我解决这个问题吗？

谢谢。

Answer 1

这就是Apple实施推送通知的方式（非常烦人）。如果发送无效令牌，则会返回错误响应并关闭套接字。在您发现套接字已关闭之前，您可能已经发送了更多消息，所有这些消息都已丢弃，需要在创建新套接字后重新发送。

反馈服务对您没有帮助。它返回不再安装应用程序的设备的有效设备令牌。它不会返回无效令牌。

Here's what Apple have to say about it：

推送通知吞吐量和错误检查

使用APN没有上限或批量大小限制。 iOS 6.1   新闻稿称，APN已经发送超过4万亿次推送   自成立以来的通知。它是在2012年WWDC上宣布的   APN每天发送70亿条通知。

如果您发现吞吐量低于每秒9,000次通知，   您的服务器可能会受益于改进的错误处理逻辑。

以下是使用增强型二进制文件时如何检查错误   接口。继续写入，直到写入失败。如果流准备就绪   再次写入，重新发送通知并继续。如果   stream尚未准备好写入，请查看该流是否可用   读数。

如果是，请阅读流中的所有内容。如果你得到零   返回字节，因为一个错误，连接被关闭了   无效的命令字节或其他解析错误。如果你得到六个字节   回来，这是一个错误响应，您可以检查响应   代码和导致错误的通知的ID。你需要   再次发送该通知后的每个通知。

一旦发送完所有内容，请最后一次检查是否有错误   响应。

删除连接可能需要一段时间才能完成   APN仅因正常延迟而返回您的服务器。这是可能的   在写入失败之前发送超过500个通知因为   连接被丢弃。大约1,700个通知写入可能会失败   只是因为管道已满，所以只需在那种情况下重试一次   流已准备好再次写作。

现在，这里的权衡变得有趣。你可以检查一下   每次写入后都会出现错误响应，并且您将正确捕获错误   远。但是这会导致发送时间的大幅增加   一批通知。

如果您捕获了设备令牌，那么设备令牌几乎都应该有效   正确而且您将它们发送到正确的环境。所以   有意义的优化假设失败将是罕见的。你会得到的   如果等待写入失败或批处理，则性能会更好   在检查错误响应之前完成，甚至计算时间   再次发送已删除的通知。

这些都不是APN特有的，它适用于大多数   套接字级编程。

如果您选择的开发工具支持多个线程或   进程间通信，你可以让一个线程或进程等待   为了一直错误响应，让主发送线程或   过程知道何时应该放弃并重试。

PHP APNS一个令牌失败

1 个答案: