Apple Dropping Connection

[mikeytrw]

We should look at tracking if/when a connection is severed by Apple's server.

If it after a specific message it may be an invalid token (debug send to production gateway or vice versa)
If it's unable to connect initially then it's likely the PEM file is screwed.

[jawj]

And/or it might be nice to upgrade to using Apple's new, enhanced protocol, which returns error codes in situations like this.

[mikeytrw]

yes. I think that is esential

[mikeytrw]

Right, I'm in no way experienced enough with Python to take the lead on the new struct packing format for new notification types. However I'm interested to know people's thoughts on implementation of the alert identifier.

I suggest the following:

Adding an 'identifier' param to the notify method that takes an identifier or array of identifiers that correspond to the array of tokens/alerts. On error the server returns an array of identifiers and array of corresponding error codes.

[samuraisam]

If you guys would like to test... I just pushed a branch called 'disconnection-log' which, when sending a message that doesn't complete, will add some data to APNSService.log which is retrievable via log you enable it by passing log_disconnections=True to provision or calling the new config method and setting 'log_disconnections' to True. Check out the docs:

http://github.com/samuraisam/pyapns/tree/disconnection-log

I will look into upgrading to use the newer protocol (I was unaware one had been released).

[n8gray]

I haven't tested the disconnection-log branch, but I like the idea a lot. The newer protocol is a simple extension of the old one and should make it much easier to identify the reason for failures.

[samuraisam]

The newer protocol looks easy enough to implement and may help with the reliability of disconnection-log. Currently it doesn't work great, given the asynchronous nature of twisted servers, it is tough to tell exactly which message and token it had failed on.

[samuraisam]

So @n8gray I have implemented the enhanced protocol (the easy part) and now disconnection log can tell exactly which token it had failed on. However, in production environments it is impossible to tell which message were /not/ sent due to a disconnection.

The problem is, these subsequent messages have already gone out over the wire, and Apple disconnects while those packets are in transmission. Apple offers NO acknowledgement of sent messages, so it is impossible to recover those that were not sent.

[ssutch]

I have an idea with how to deal with this. The new protocol does not really give you any benefit when considering the disconnections. Any message that are already on the wire are lost.

The solution seems obvious to me now. To ensure that message are not lost due to disconnections:

• maintain a pool of connections to apple's gateway
  • for each message send operation, check the connection out from the pool, removing it from general availability
  • if there are no available connections start a new one up to a certain threshold
  • after the time has passed without a disconnection, recycle the connection back to the pool
  • if a disconnection occurs expire the connection and log the offending token
• your application periodically reads from a log of offending tokens or app ids.
  • this will be stored in memory so the frequency of reads should be some function of the total notifications sent