简体繁体 English

苹果推送通知-服务器部分的设计

[英]apple push notification - design of the server part

原文 2014-04-05 17:59:03 1 2 ios/ notifications/ push-notification/ apple-push-notifications

I have seen many tutorials and opinions on that - I have developed a simple script that will send batches of notifications to Apple servers, and I crontask it every 5 seconds. 我已经看到了许多教程和意见-我开发了一个简单的脚本，该脚本将向Apple服务器发送一批通知，并且每5秒钟执行一次crontask。 (it's php so far, should be improved soon). （到目前为止是php，应该尽快进行改进）。

This way, the code is simple, and if 1 batch is larger, it will not delay the next batch. 这样，代码很简单，如果一个批处理较大，则不会延迟下一个批处理。 It also allows to run on multiple servers to dispatch faster and solves any concurrency issues 它还允许在多台服务器上运行以更快地调度并解决任何并发问题

However, I am not clear about Apple tolerance to the fact that I open/close a socket with them every 5 seconds... In sandbox mode, it works perfectly. 但是，我不清楚Apple是否容忍我每隔5秒钟打开/关闭一个插座这一事实。在沙盒模式下，它工作得很好。

Thanks for the advice 谢谢你的建议

2 个解决方案

How about this approach: - batch all in some data-structure (I don't know about PHP, but in Objective-C this would be a NSArray containing instances of some custom NotificationClass or NSDictionaries). 这种方法怎么样：-在某些数据结构中全部批处理（我不了解PHP，但是在Objective-C中，这将是一个包含一些自定义NotificationClass或NSDictionaries实例的NSArray）。 - if you have either A) batched up more then X notifications you send them through, or B) waited a certain time (eg 5 seconds). -如果您要么A）进行了更多的批处理，然后通过它们发送了X条通知，或者B）等待了一段时间（例如5秒）。

Depending on what you use the push notifications for you can adjust these variables. 根据您使用推送通知的方式，您可以调整这些变量。 A chat app for example want them to be sent immediately, while some daily messaging app would probably be OK with sending them all at once each hour or so. 例如，一个聊天应用程序希望立即发送它们，而某些日常消息传递应用程序则可以每小时大约一次将它们全部发送出去。

Also, Apple's words on opening connections: 另外，苹果公司关于开放联系的话：

You may establish multiple connections to the same gateway or to multiple gateway instances. 您可以建立到同一网关或多个网关实例的多个连接。 If you need to send a large number of push notifications, spread them out over connections to several different gateways. 如果您需要发送大量的推送通知，请通过与多个不同网关的连接来分发它们。 This improves performance compared to using a single connection: it lets you send the push notifications faster, and it lets APNs deliver them faster. 与使用单个连接相比，这提高了性能：它使您可以更快地发送推送通知，并且使APN可以更快地传递它们。

Keep your connections with APNs open across multiple notifications; 在多个通知中保持与APN的连接打开； don't repeatedly open and close connections. 不要反复打开和关闭连接。 APNs treats rapid connection and disconnection as a denial-of-service attack. APNs将快速连接和断开视为拒绝服务攻击。 You should leave a connection open unless you know it will be idle for an extended period of time—for example, if you only send notifications to your users once a day it is ok to use a new connection each day. 除非知道连接将长时间闲置，否则应保持连接打开状态；例如，如果您每天仅向用户发送一次通知，则可以每天使用新连接。

See here for official docs ( Best practies for Managing Connections ). 请参阅此处获取官方文档（管理连接的最佳实践）。

The idea is that you simply leave the connection open between the batches. 这个想法是，您只需在批次之间保持连接打开。 In fact, Apple recommends you create multiple connections, so you can divide the 1000 over maybe five or ten or so connections. 实际上，Apple建议您创建多个连接，因此可以将1000个连接划分为五个或十个左右的连接。 You could have some connection manager in your code that controls the lifetime of the connections: if no messages have been send trough for x amount of time, shut it down. 您的代码中可能有一些连接管理器，用于控制连接的生存期：如果在x时间内没有消息通过槽发送，请将其关闭。 If some piece of client-code requests a connection, this manager either creates a new one, or returns one that is not currently being used to send data through. 如果某些客户端代码请求连接，则该管理器要么创建一个新的连接，要么返回当前不用于通过其发送数据的连接。 The client of this manager should be prepared to not receive a connection, and the connection manager should in turn notify clients about the availability of connections. 该管理器的客户端应准备好不接收连接，并且连接管理器应进而通知客户端连接的可用性。

Lots of possibilities in terms of architecture, but the main point it is better to leave a connection open and idle for some time, then to open and close them many times. 在体系结构方面有很多可能性，但要点是最好让连接保持打开和空闲一段时间，然后多次打开和关闭它们。