1

我正在研究 Java 中 Apple 推送通知的服务器端开发。我正在使用增强格式，以检测失败的消息并重新发送错误消息之后的消息。我知道 Apple 不保证推送通知的传递，但我希望能够知道 Apple 是否收到我的消息以及是否包含任何错误。

我注意到，当我尝试向 Apple 发送无效消息（无效的设备令牌、过大的有效负载等）时，我可以在套接字关闭之前再发送几条消息。当套接字关闭时，从Apple读取错误代码为时已晚，所以我不知道哪条消息是错误的（或者即使有错误消息，因为Apple表示即使没有连接也可能偶尔关闭错误）。

我在 JavaPN 的源代码中看到的处理此问题的方法是在发送每条消息（或一组消息）后立即读取来自 Apple 的响应。从套接字读取是否频繁执行，并等待超时以防没有可读取的内容。如果您不经常发送推送通知，这是可以接受的。

如果您尝试以高频率发送大量通知（比如说每秒数百条），您无法在每条消息后停下来等待 Apple 的响应（即使您只等待 20 毫秒的响应，那也会将您限制为每秒 50 条消息，并且您无法知道 Apple 编写错误响应需要多长时间，因此短暂的等待可能还不够）。如果您在每条消息后不停地阅读可能出现的错误，则在向 Apple 发送消息期间您的连接可能会被关闭，在这种情况下，您将无法获得导致连接关闭的消息的 Id .

我正在考虑的另一种方法是在单独的线程中执行读取和写入。这样，我就有更好的机会从 Apple 获取错误消息（在连接关闭之前），而不会影响我向 Apple 发送消息的速度。这种方法在编程上更加复杂，并且由于我的服务器预计将 APNs 发送到多个 iOS 应用程序，每个应用程序都需要自己的套接字和读取器/写入器线程，这将使我需要的线程数增加两倍。

APN 服务器的上述所有行为都是在尝试向 Apple 的沙盒服务器发送推送通知时学习的。我不确定 Apple 生产服务器的行为是否更好，我不确定在生产服务器上执行测试是否是个好主意。

我的问题 - 有没有办法在 Alpha 关闭连接之前可靠地读取错误响应，而不会牺牲性能？是否有可能在服务器关闭套接字后以某种方式从套接字读取输入？

4

1 回答 1

0

我遇到了和你一样的问题。而且我尝试了两种方法，但它们都不能在关闭连接之前可靠地读取 Apple 的错误响应：

  1. 对于每个套接字，我启动了两个线程，一个用于连续写入，另一个用于阻塞读取。在大多数情况下，当写遇到“Socket Broken”异常时，读线程可以读到错误响应，但并不完全可靠。
  2. 对于每个socket，我只启动了一个线程连续写入，遇到异常时，在try缓存块中，尝试读取错误响应。在大多数情况下，套接字是关闭的，所以我只看到一个异常。
于 2013-06-17T02:58:18.997 回答