如何可靠，高效地读取所有苹果的错误响应推送通知服务器在Java服务器？ [英] How to reliably and efficiently read all error responses from Apple Push Notifications Server in a Java Server?

问题描述

我研究苹果的服务器端开发推送通知在Java中。
我使用的是增强型的格式，以检测失败的消息，并重新发送后面坏消息的消息。我知道苹果不保证推送通知的交付，但我希望能够知道苹果是否收到了我的邮件，以及是否包含的任何错误。

我注意到，当我尝试发送一个无效消息（无效的设备令牌，过大的有效载荷，等...），以苹果，我可以关闭套接字之前发送几个消息。当关闭套接字为时已晚读取苹果错误codeS，所以我不知道这消息是坏的（或者即使是一个坏消息，因为苹果公司说，连接可能会偶尔关闭，即使没有错误）。

我在JavaPNs处理这种源看到的方法是（消息或组）每条消息后立即发送到读取苹果回应。如果频繁地执行从插座上阅读，如果等待超时没有什么阅读。如果您发送推送通知的很少，这是可以接受的。

如果您尝试发送在高频大数量的通知（可以说每秒数百个），你不能每封邮件后，停下来等待苹果的反应（即使你等待只为20ms的响应，这将限制你每秒50条消息，你有没有办法知道它需要多长时间苹果写错误响应的方法，所以短暂的等待可能是不够的）。如果不停止每个消息后读可能出现的错误，你的风险您的连接信息发送给苹果，在这种情况下，你将无法得到消息的ID导致连接关闭时被关闭

我考虑的另一种方法是执行读取和在单独的线程的写入。这样，我从苹果公司得到的错误消息的更好的机会（在连接关闭前）不影响中，我将消息发送到苹果的速度。这种方法是更复杂的编程，并且由于我的服务器预计发送的APN到多个iOS应用程序，每个都需要其自己的插座和读/写器线程，这将增加我需要由两个因素的线程数。

所有APN服务器的上述行为，同时试图发送推送通知到苹果的沙盒服务器的教训。我不知道，如果苹果的生产服务器的行为是更好的，我不知道这是一个好主意，在生产服务器上执行我的测试。

我的问题 - 有什么办法能够可靠地读取来自阿尔法的错误响应，它们将关闭连接之前，在不牺牲性能？是否有可能以某种方式从套接字读取输入它是由服务器关闭后？

解决方案

我也遇到同样的问题，因为你。而且我已经试过两种方法，但没有人能够可靠地读取来自苹果的错误响应，它们将关闭连接之前：

1. 对于每一个插座，我开始两个线程，一个连续写作和其他阻止读取。在大多数情况下，读线程可以读取错误响应时遇到写插座破的例外，但它不是完全可靠的。


2. 对于每一个插座，我一开始只有一个线程，不断写，遇到了异常时，在try缓存块，尝试读取错误响应。在大多数情况下，插座是封闭的，所以我看不过是个例外。

I am researching server side development of Apple Push Notifications in Java. I am using the enhanced format, in order to detect failed messages and resend messages that follow bad messages. I know that Apple to not guarantee the delivery of Push Notifications, but I wish to be able to know whether Apple received my messages and whether the contained any errors.

I noticed that when I try to send an invalid message (invalid device token, too large payload, etc...) to Apple, I can send several more messages before the socket is closed. When the socket is closed it's too late to read the error codes from Apple, so I have no idea which message was the bad one (or even if there was a bad message, since Apple say the connection may close occasionally even when there is no error).

The approach I've seen in the source of JavaPNs to handle this is to read responses from Apple immediately after each message (or group of messages) are sent. The reading from the socket if performed frequently, and waits for a timeout in case there is nothing to read. This is acceptable if you send push notifications infrequently.

If you try to send a large number of notifications in a high frequency (lets say hundreds per second), you can't stop after each message to wait for responses from Apple (even if you wait for a response only for 20ms, that would limit you to 50 messages per second, and you have no way of knowing how long it would take Apple to write the error response, so a short wait may not be enough). If you don't stop to read possible errors after each message, you risk your connection being closed during the sending of messages to Apple, in which case you won't be able to get the Id of the message that caused the connection to close.

Another approach I'm considering is to perform the reads and the writes in separate threads. This way I have a much better chance of getting the error messages from Apple (before the connection is closed) without compromising the speed in which I send messages to Apple. This approach is more complicated programmatically, and since my server is expected to send APNs to multiple iOS applications, each requiring its own socket and reader/writer threads, this will increase the number of threads I need by a factor of two.

All of the above described behavior of the APN Server was learned while attempting to send push notifications to Apple's sandbox server. I'm not sure if the behavior of Apple's production server is better, and I'm not sure it's a good idea to perform my tests on the production server.

My question - Is there a way to reliably read the error responses from Alpha before they close the connection, without sacrificing performance? Is it possible somehow to read input from the socket after it was closed by the server?

解决方案

I have encountered the same problem as you. And I have tried two approaches, but none of them can reliably read the error responses from Apple before they close the connection :

1. For each socket, I started two threads, one for writing continuously and the other for blocking read. In most cases, the read thread can read the error response when the write encounters "Socket Broken" exception, but it's not completely reliable.
2. For each socket , I started only one thread to write continuously, and when encountered the exception, in the try cache block, try to read the error responses. In most cases, the socket is closed, so I read nothing but an exception.

这篇关于如何可靠，高效地读取所有苹果的错误响应推送通知服务器在Java服务器？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！