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

Question

最近苹果修改了他们的Technical Note TN2265 - Troubleshooting Push Notifications。他们添加了一个关于吞吐量和错误检查的部分。

这是取自该部分：

以下是使用增强型二进制文件时检查错误的方法 界面。 继续写入，直到写入失败。如果流准备好了 再次写作，重新发送通知并继续。如果 流尚未准备好写入，请查看流是否可用于 阅读。

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

所有内容发送完毕后，进行最后一次检查是否有错误 回应。

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

我的 APN 提供程序服务器是用 Java 编写的，使用阻塞套接字 (SSLSocket)。

是否可以使用SSLSocket 执行他们在粗体文本中建议的操作？ 写入失败后，我可以再次写入套接字吗？在这种情况下套接字不会关闭吗？我如何知道流是否准备好再次写入？我怎么知道它是否可供阅读？

我想避免使用 NIO，因为那需要使用 SSLEngine，这似乎很难实现。

Answer 1

查看 Unix/Linux/OS X write(2) 函数的手册页。如果由于操作系统的完整输出缓冲区而导致写入阻塞，您将返回 EAGAIN 或 EWOULDBLOCK 错误代码。我的猜测是，上面的“写入失败”可能是指除了“真正的”错误之外的这种情况。如果您再试一次（可能只是稍晚一点，甚至立即），如果缓冲区先前已满，则写入很有可能会成功。如果 TCP 连接本身没有了，当然除了建立一个新的连接之外，你没有什么可以恢复的。