Handle multiple sets of credentials with a single ApnsClient instance

[jchambers]

Now that we've introduced connection pooling in #492, the next big step will be to get clients to choose connections from different sub-pools depending on the topic to which a notification should be sent (and therefore which credentials the client should use). To get there, we'll probably need to introduce some abstract notion of ApnsCredentials that has subclasses/implementations for X509 certificates and PKCS#8 signing keys, and then extend the existing connection pool infrastructure to add "keyed" pool functionality.

The end result will be that callers will only need to have a single ApnsClient instance for all of their destination apps, which will probably be a big win for high-volume users.

[justinpermar]

+1 from a user who would benefit from this enhancement!

[ChunBoL]

I also encountered the problem of handling multiple sets of documents, when can I support multiple sets of documents?

[jchambers]

I'm starting in on some initial design work for this feature, and we're going to have to work around a few obstacles. The main ones right now are:

1. We have two possible types of credentials: X509 certificates for TLS-based authentication and EC private keys for token-based authentication.
2. Based on an X509 certificate's metadata, we can identify the APNs topics for which it can be used. We can't tell which topics a signing key is good for, though, and have to rely on callers to tell us.

The general plan in my mind is to expand PooledObjectFactory (which creates connections to the APNs server) to be a KeyedPooledObjectFactory that would look something like this:

interface KeyedPooledObjectFactory <K, T> {
    Future<T> create(K key, Promise<T> promise);
    Future<Void> destroy(K key, T object, Promise<Void> promise);
}

Elsewhere, we'd have an ApnsCredentialProvider:

public interface ApnsCredentialProvider {
    Future<TlsApnsCredentials> getTlsCredentials(String topic);
    Future<ApnsSigningKey> getSigningKey(String topic);
}

I'm trying to decide what we should use for keys in the KeyedPooledObjectFactory. We could build everything around topics, which would be reasonably simple and straightforward, but maaaaay introduce some unnecessary overhead in cases where people are sending to lots of topics with the same credentials. If we keyed based on credentials instead, we'd have connections allocated per credential set rather than per topic.

In other words, it might be the difference between this:

• com.example.app
  • connection 1
  • connection 2
• com.example.app.voip
  • connection 3
  • connection 4
• com.example.app.complication
  • connection 5
  • connection 6

…and this:

• Signing key for com.example.app.*
  • connection 1
  • connection 2

My question to you folks: is the many-topics-with-one-set-of-credentials scenario a use case you actually have, or is the overhead of channels-per-topic tolerable?

Separately, what kinds of pool configuration are you folks hoping for? The simplest thing would be to just use a single limit like maxConnectionsPerTopic or maxConnectionsPerCredentialSet, but that might not be ideal in cases where some topics/credentials are much busier than others.

Cheers!

[jchambers]

Oh, right, and to close out this thought:

Based on an X509 certificate's metadata, we can identify the APNs topics for which it can be used. We can't tell which topics a signing key is good for, though, and have to rely on callers to tell us.

…right now, the situation is that the caller gives us a signing key and is free to at least try to send notifications to whichever topic they'd like, even if that topic isn't covered by the signing key. We rely on the APNs server to tell us if it's not the right key. In a world where we might have multiple credentials associated with a client, we couldn't get away with that any more because the client would need some mechanism to decide which credentials to use based on the topic.

The only real option I can think of in the general case is to make callers tell us which topics are associated with which keys. To be fair, we already do this for key IDs and team IDs, but at least those are clearly spelled out in the Apple Developer console. To my knowledge, there's no way to get a full list of all of the topics a key supports. Does anybody have other suggestions?

For a backward-compatibility hack, I'm thinking that we could have ApnsSigningKey implement ApnsCredentialProvider and have getSigningKey return the signing key itself unconditionally. That would allow callers who want to use a single key (I'm guessing that's a very common use case) to avoid listing out all of the topics to which they might ever want to send notifications.

[jacobwallace]

Any rough idea when this might be available @jchambers? Huge thank you for all your work on Pushy.

[jchambers]

It's the next major feature planned, but there's isn't a specific timeline for release.

[qiankunli]

+1 from a user who would benefit from this enhancement! I am looking forward to it.