APNS Push Server with multiple Apps
I'm currently in the planning phase to implement push notification functionality in my PHP-based web service, which will support multiple applications. My current service structure includes non-persistent auto-scaling servers used to hand large traffic/request loads.
For using APNS, I am having troubling coming up with an architecture. I've read through APNS Getting Started.
Apple, states that connections need to be maintained for push with APNS, to avoid being seen as a DDOS attack:
Keep your connections with APNs open across multiple notifications; don’t repeatedly open and close connections. APNs treats rapid connection and disconnection as a denial-of-service attack. 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.
For large number of pushes, Apple states:
"You may establish multiple connections to the same gateway or to multiple gateway instances. If you need to send a large number of remote notifications, spread them out over connections to several different gateways. This improves performance compared to using a single connection: it lets you send the remote notifications faster, and it lets APNs deliver them faster."
I've found this post about Persistent APNS connections on the site, which states "...appears a rule of thumb is 15 connections max"
My questions are:
1.How should I handle these pushes to multiple apps, without risking being seen as DDOS?. I don't think I can use my non-persistent auto-scaling servers, because they would be connection/disconnection on boot/shutdown. Do I need to spread my connections out over multiple static servers?
2.If I spread my connection out over multiple servers, will that allow me to get around this pseudo-restriction of 15 connections? If I need multiple connections for each app to send large amounts of push notifications, I feel like I would go beyond 15 as my client base grows.
Have looked at a similar use case and TBH it seems easier to just use Amazon SNS Mobile Push. You can maintain multiple platformApplications using their service and just ping an endpoint when you want to send a notification. It also comes with out of the box support for
- Sending to Additional platforms (GCM/Android/Baidu Push, WNS/MPNS/Windows phone, ADM/Kindle, SMS, AWS Lambda Functions, SQS queue producers, HTTP/HTTPS endpoints, SMS, Email, MacOSX etc.)
- Handling of the APNS Feedback service to prevent APNS sanctions for spamming de-registered devices - you would have to implement this yourself if you were to use APNS
- Topics (A single endpoint for all of your users or subsets of your users allowing you to send thousands of notifications with a single call)
- Instrumentation with CloudWatch and logging with CloudTrail to track your delivery rates, failures etc. and provide alerts based on metric levels you can define
- A Service Mock for integration tests
- SDKs, documentation and examples for most major languages
Between keeping connections open indefinitely (for each app, on multiple gateways), resending failed notifications in a stream, and managing the feedback service APNS is just a massive PITA. Plus if you trigger any of their service limits they will revoke your cert or worse and you won't be sending any notifications until you update your system with a new one.
May as well let someone else handle all those headaches for you :D
My own solutions to the problem was:
-A series of dedicated servers with their own IP address
-Monitoring and adjusting the speed of outgoing request during times of high volume transmissions to avoid DDOS cut-off.
A secondary problem I found was that specific phone carriers limit the number of pushes you can send them, before they cut you off. So even if the APNS restriction was 15 connections or so, I couldn't even have that many running at full speed without hitting the limit for specific carriers and having their servers shut me out. This may be a problem specific to Japanese carriers though (docomo in particular was strict, I ended up with a dedicated server just for them with heavy transmission load adjustments).