服务器到客户端的消息传递可以依赖 APNS 吗? [英] Can server-to-client messaging rely on APNS?
问题描述
我正在开发一个消息传递应用程序，但我在如何将数据从服务器发送到客户端方面遇到了两难选择.
我正在使用集中式服务器设计，其中客户端使用 NSURLConnection 向服务器发送消息，服务器不保留和管理打开的套接字，并且无法为其中之一发送消息客户.所以客户端使用一个定时器，每 2 秒查询一次服务器，看看是否有新数据在等待它们.
这种方法的问题是每 2 秒轮询一次服务器似乎会很快耗尽电池电量，所以我想也许不是客户端轮询服务器，而是 使用 APNS*，这样当服务器有一些新信息 **给客户端，服务器会发送一个推送通知 ***给客户端，然后客户端会获取来自服务器的数据.
* use APNS - 如果客户端允许，客户端当然可以禁用此选项.因此，每次应用进入前台时，我都会检查是否允许推送，如果不允许，我将返回轮询方法.
** 新信息可以是从短信到服务器管理消息的任何内容.(并且有很多管理消息...)
例如，在我的应用程序中用户可以看到他们的好友状态(在线/离线)，所以如果用户 1 和用户 2 是好友，用户 2 只是将他的状态从在线更改为离线，那么服务器需要发送这个新信息(管理消息 = user2_offline) 到用户 1.
*** 推送通知服务器发送的是空的(没有数据/声音)，这只是客户端的触发器获取新信息，因此如果向客户端发送推送并且客户端应用程序已关闭，他将不会注意到任何内容.(如果应用程序正在运行，那么它将从服务器获取新信息)
这种方法是否适用于需要大量推送通知的大型消息传递应用程序?
更清楚地说，我的主要关注点是:
1. APNS 是否足够可靠，我可以将其用作我的核心服务器到客户端消息传递机制?
2. 苹果每天会批准来自我的服务器的数千或数十万推送通知吗?
APNS 是否足够可靠，以至于我可以将其用作我的核心服务器到客户端消息传递机制?
否.为了完整起见，让我重复一下原因.
- Apple 本身否认阅读 编程指南
- 此外，APNS 有一个 QoS 组件，它可能会以牺牲实时性为代价提高可靠性(例如，我可以要求 APNS 在 4 周内随时发送通知，如果设备无法访问，则重试)这是没有用的就你而言.
根据您的要求，如果您发送静默推送(没有用户可见消息的推送)，则无法将其作为高优先级推送发送，这会进一步降低可靠性.这是一个相关的报价
<块引用>无提示通知并不是让您的应用保持清醒的一种方式背景，它们也不是用于高优先级更新.接入点将静默通知视为低优先级，并可能会限制其如果总数过多，则完全交付.实际上限制是动态的，可以根据条件改变，但尽量不要每小时发送多次通知."
<块引用>
苹果每天会批准来自我的服务器的数千或数十万条推送通知吗?
通常，APNS 在负载方面不会有任何问题，但它有限制，它们可能会限制您的通知，请参阅上面的第 3 点
恕我直言，你应该看看 XMPP，因为这个协议只是为像你这样的用例设计的，它们在所有平台上都有广泛的社区支持.我建议您查看类似 https://github.com/robbiehanson/XMPPFramework 的内容并设置一个后端的 XMPP 服务器将处理消息和在线消息以及管理消息.
如果你已经评估过XMPP并且不想使用它，我建议你需要在iOS App中组合一个智能系统，根据App State采用不同的策略，例如以下，你可以有以下策略
- 基于实时套接字的方法 -> 建立永久套接字连接并尽可能保持数据同步(这是当您的应用程序运行到前台或后台时)
- 您在问题中谈到的轮询系统，可在您的应用被调用以进行后台提取/位置更新等时使用.
- 使用带有用户可见消息 + 自定义数据的 APNS，当您的服务器检测到设备没有活动套接字并且很长时间没有轮询时
I'm working on a messaging app and I have a dilemma about how to send data from server to client.
I'm using a centralized server design, where clients uses NSURLConnection to send messages to the server, the server doesn't keep and manage open sockets and can't send a message for one of the clients. So clients use a timer and query the server every 2 seconds to see if new data is waiting for them.
The problem with this approach is that polling the server every 2 second seem to kill the battery very fast, so I thought maybe instead of clients polling the server, to use APNS* so when the server has some new information ** for the client, the server will send a push notification *** to the client, then the client will fetch the data from the server.
* use APNS - if client allows it, client can of course disable this option. So I will check if push allowed every time the app enter foreground and if not I'll return to the polling approach.
** New information can be anything from text messages to server admin messages. (and there are a lot of admin messages...)
For example, in my app users can see their friends status (online/offline), so if user1 and user2 are friends, and user2 just change his status from online to offline, then server needs to send this new info (admin message = user2_offline) to user1.
*** The push notifications server sends are empty (with no data/sound), it's just a trigger for the client to fetch the new info, so if a push was sent to the client and the client app was close, he will not notice anything. (if the app is running, then it will fetched the new info from server)
Will this approach work with a massive messaging app requiring massive push notification uses?
To be clearer my main concerns are:
1. Is APNS reliable enough that I can use it as my core server-to-client messaging mechanism?
2. Will apple approve potentially thousands or hundreds of thousands push notifications a day from my server?
Is APNS reliable enough that I can use it as my core server-to-client messaging mechanism?
NO. Just for the sake of being complete let me iterate over the reasons.
- Apple itself disclaims the reliability read the Programming Guide
- Also, APNS, has a QoS component which may increase the reliability at the cost of being realtime (For Eg. I can ask APNS to deliver the notification anytime within 4 weeks and retry if devices are not reachable) which is not useful in your case.
As per your requirement, if you send a silent push (a push with no user visible message), it can not be sent as a HIGH priority push which decreases the reliability even further. Here is a relevant quote
"Silent notifications are not meant as a way to keep your app awake in the background, nor are they meant for high priority updates. APNs treats silent notifications as low priority and may throttle their delivery altogether if the total number becomes excessive. The actual limits are dynamic and can change based on conditions, but try not to send more than a few notifications per hour."
Will apple approve potentially thousands or hundreds of thousands push notifications a day from my server?
Generally, APNS will not have any issues with this in terms of load, but it has throttling in place and they might throttle your notifications, see point 3 above
IMHO, you should look at XMPP as this protocol is designed just use-cases like yours and they have wide community support on all platforms. I will suggest you look at something like https://github.com/robbiehanson/XMPPFramework and setup an XMPP server at your backend which will handle the messaging and presence messages as well as admin messages.
If you have already evaluated XMPP and do not want to go with it, I would suggest you need to put together an intelligent system in iOS App which employs different strategies based on App State, something like following, you can have following strategies
- A Realtime Socket based approach -> Establish a permanant socket connection and keep the data in sync as much as possible (This is when your app is running into foreground or background)
- The Polling System You talked about in question, which can be utilised when your app is invoked for background fetch/location updates etc.
- Use APNS with user visible messaging + custom data, when your server detects that the device does not have active socket and also have not polled for a very long time
这篇关于服务器到客户端的消息传递可以依赖 APNS 吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
