Multiple ApnsClients for a single app ?

[Nidhi Aggarwal]

Hi All, I am new to pushy and want to implement batch processing of notifications. I have one app/cert use case with multiple apps. Since ApnsClient just has one channel  per app, is it a good idea to have multiple ApnsClients per app ? If yes, how many would you recommend. Say I have a minimum of 1000 notifications in one go.

Thanks.

[j...@turo.com]

tl;dr: You can have multiple clients if you really want to, but you almost certainly don't need them.

There are two main factors that limit the rate at which you can send notifications: processing power and network throughput. Our benchmarks show that, on reasonably modern hardware, we can crank out somewhere on the order of 10k-20k notifications/second on a single thread/core if we're primarily limited by processing power. Assume an average size of 256 bytes per notification, and that works out to somewhere between 2.5 and 5 MB/sec (or 20 and 40 Mbit/sec, if you prefer those units).

If you find yourself in a situation where you're sending lots of notifications and you have more bandwidth than you can saturate with a single core, you may see some benefit from running multiple parallel clients. If you're already limited by bandwidth, though, using multiple clients will just cause a traffic jam at the network layer.

In your case, where we're talking about 10e3 notifications at a time, you're very, very unlikely to need more than one client. Even if multiple parallel clients could come closer to saturating your network connection, it sounds like it would be the difference between sending all of your notifications in 25ms instead of 50ms. If you're in that situation, it's up to you to decide whether the increased throughput is worth the added complexity.

Hope that helps!

-Jon

[Nidhi Aggarwal]

Thank you Jon, I'll stick to 1 ApnsClient/app for now :)

Also, we have notnoop library in use in our project right now, would you be able to compare pushy with notnoop ? I know pushy supports http/2 (new APNs). Not sure about notnoop though. We are planning to switch to pushy.

-Nidhi

[Justin Miranda]

We used notnoop for years and it works pretty well, but it does not give you any feedback on the acceptance status of notifications (however, you can query it for inactive device IDs). It doesn't look like notnoop is going to implement HTTP/2 any time soon (https://github.com/notnoop/java-apns/issues/282). In addition, we needed to build our own keep-alive mechanism to prevent Apple/Google (and/or overzealous routers) from closing our persistent connections to the APNs/GCM servers. 

We recently re-implemented our Push API using Pushy (using HTTP/2). I would highly recommend going that route unless you really don't care about whether and/or why a push notification wasn't accepted by APNs/GCM.  I guarantee that you will eventually run into an issue where a user does not receive a push notification -- tracking down why the notification was not accepted is much easier (err, possible) if you're using Pushy.

Hope that helps. 

Justin

--
Pushy is an open-source Java library for sending APNs (iOS and OS X) push notifications. Pushy is brought to you by the engineers at RelayRides.
---
You received this message because you are subscribed to the Google Groups "pushy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pushy-apns+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[j...@turo.com]

> however, you can query it for inactive device IDs

A clarification here: the "feedback service" was a part of the older, pre-HTTP/2 APNs protocol. It provided a delayed means to discover if notification delivery failed because the destination token had expired, but did not indicate which specific notifications had failed. Pushy dropped support for the feedback service because the HTTP/2-based APNs protocol tells us immediately if a notification could not be delivered because the token expired. The new protocol means we get more timely and more specific information than what the old feedback service provided.

As Justin points out, an advantage of the HTTP/2-based protocol is that we actually know what happens to each notification that we send to the APNs server, which simply wasn't possible with the old protocol. That problem actually runs much deeper than you might expect; some curious design decisions in the old protocol(s) meant that, at the most basic level, it was impossible for Pushy (or any other library) to distinguish between notifications that were accepted by the APNs server and notifications that were lost due to a closed connection, packet loss, or some other error.

Pushy distinguishes itself from other libraries with a focus on design for industrial-scale operation, thorough documentation, and rigorous testing. On a more mundane level, Pushy is (to my knowledge!) the only APNs library for Java that's actually still maintained.

-Jon

On Thursday, October 20, 2016 at 11:19:09 AM UTC-4, Justin Miranda wrote:

We used notnoop for years and it works pretty well, but it does not give you any feedback on the acceptance status of notifications (however, you can query it for inactive device IDs). It doesn't look like notnoop is going to implement HTTP/2 any time soon (https://github.com/notnoop/java-apns/issues/282). In addition, we needed to build our own keep-alive mechanism to prevent Apple/Google (and/or overzealous routers) from closing our persistent connections to the APNs/GCM servers. 

We recently re-implemented our Push API using Pushy (using HTTP/2). I would highly recommend going that route unless you really don't care about whether and/or why a push notification wasn't accepted by APNs/GCM.  I guarantee that you will eventually run into an issue where a user does not receive a push notification -- tracking down why the notification was not accepted is much easier (err, possible) if you're using Pushy.

Hope that helps. 

Justin