Can server-to-client messaging rely on 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?

回答1:

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.

1. Apple itself disclaims the reliability read the Programming Guide
2. 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.

3. 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

1. 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)
2. The Polling System You talked about in question, which can be utilised when your app is invoked for background fetch/location updates etc.
3. 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

回答2:

I have worked in this area for a while and from my modest experience I think your approach to solve your problems will reach you nowhere. Allow me first to highlight some important facts on the APN characteristics:

1. APNs are not reliable, they are not 100% guaranteed to reach the client.
2. As of Apple's documentation, APNs are best effort, so many times they might not reach.
3. APNs don't hold data inside them, so even if they reach your client app they hold nothing inside them for the app.
4. APNs are just notifications for the user that something related to your app has occurred, while there message (the text that appears in the Alert Box of the APN) is handled by the iOS and not your app. This is why devices with iOS 4 will display the APN in a different way than devices with iOS 5, it is OS job not your app.
5. The badge value that appears on your app icon when notifications come is the responsibility of your server, and not the device OS. Put differently, when an APN reaches the device it should come having the new notification count value for your app. The OS won't do anything for this.

Having said that I would like to explain a bit how usually such applications are designed. First, it is not done by URL Connections and the clients don't check the server every period of time. Usually you have a client/server architecture where your client is the app on the device and the server is a real server program that resides on a server machine. The server could be Microsoft (using C# for example) or MAC (using Objective C). The server has a database that it stores information inside it. Some important information (related to your question) is the APN Count Value, the Message that you want to deliver, the state of the client if online or offline.

When a client likes to send something to another client, or when the server wants to send something to a client (or all the client), a check is made to the recipient client to see if he is online or offline. If he is online the message is sent directly, and usually the communications are done on TCP Sockets. If the user is offline then the server will store the message that needs to be sent to the client, increase the APN Count value, send an APN to that recipient. When that recipient becomes online, the server will notice that (because there is establish connection and handshaking) and therefore will fetch all undelivered messages from the database and send them to him...

It is a long process, I hope I was able to explain things a bit to you. In all cases I don't think your way is practical or enables you to reach real work.