Connect/Reconect in the Enhanced mode

[denisov]

Hi!

I have noticed many many 'connection establishing' and 'connection closed' events in Enhanced mode. After 30 seconds of idle it says me

2014-12-17 18:23:19,470 - DEBUG - apns - connection idle after 35 secs
2014-12-17 18:23:19,471 - INFO - apns -  GatewayConnection APNS connection closed
2014-12-17 18:23:19,471 - DEBUG - apns - error-response handler worker closed

And when I send one more message then it reconnects again:

2014-12-17 18:29:58,124 - DEBUG - apns - initialized error-response handler worker
2014-12-17 18:29:58,125 - DEBUG - apns - GatewayConnection APNS connection establishing...
2014-12-17 18:29:58,125 - DEBUG - apns - connection idle after 433 secs
2014-12-17 18:29:58,125 - DEBUG - apns - error-response handler worker closed
2014-12-17 18:29:59,196 - DEBUG - apns - GatewayConnection APNS connection established

The question is: does it may cause any penalty from Apple because of many connection/reconnection? So maybe it is better not to use Enhanced mode? I haven't seen many reconnection in 'normal' mode.

Thanks

[jimhorng]

Hi @denisov This had been addressed by #98 , please help owner @djacobs to review if possible, thanks :)

[denisov]

Thanks for quick response @jimhorng But I still don't understand enhanced mode logic

Please look at your log (after fix)

[11-17 16:01:34][20993][ErrorResponseHandlerWorker][/PyAPNs/apns.py:579][DEBUG] connection  idle after 30 secs
[11-17 16:01:34][20993][ErrorResponseHandlerWorker][/PyAPNs/apns.py:613][DEBUG] error-response handler worker closed
[11-17 16:01:45][20993][MainThread][/PyAPNs/apns.py:479][DEBUG] initialized error-response handler worker
[11-17 16:01:45][20993][MainThread][/PyAPNs/apns.py:543][DEBUG] error response handler worker is running
[11-17 16:01:45][20993][MainThread][/PyAPNs/apns.py:195][DEBUG] GatewayConnection APNS connection establishing...
[11-17 16:01:45][20993][MainThread][/PyAPNs/apns.py:241][DEBUG] GatewayConnection APNS connection established
[11-17 16:01:45][20993][MainThread][/py_test/apns/apns_test.py:80][INFO] client sent to: 2
[11-17 16:01:45][20993][MainThread][/py_test/apns/apns_test.py:82][DEBUG] getting msg from feedback server...
[11-17 16:01:46][20993][ErrorResponseHandlerWorker][/py_test/apns/apns_test.py:52][DEBUG] client get error-response: {'status': 8, 'identifier': 2}
[11-17 16:01:46][20993][ErrorResponseHandlerWorker][/PyAPNs/apns.py:598][INFO] got error-response from APNS:(8, 2)

Line 5 says "GatewayConnection APNS connection establishing..." Why there is need to re-connect to APNS after 30 seconds of idle?

Apple says

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.

https://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW1

I think rapid connect-disconnect cycles may cause a ban from Apple.

[jimhorng]

@denisov , good point, it's a trade-off between 1) frequency of re-connecting and 2) APNs randomly destroy connection.

Before implementation of disconnect after idle 30 secs, APNs might destroy connection without any informs after a long idle time, so that pyapns-side will not know the connection is destroyed and keep sending notification and vanished, there's no event to listen for triggering re-connect. Which is a very serious problem on our production site.

Disconnect after IDLE 30 secs might increase reconnection frequency in worse case, which is every notification are sent in a 31 secs interval. However, in normal distribution, notifications are sent continuously so it will not cause IDLE connection , or in off-peak, it will not send notification for a long time, therefore not causing reconnection.

That's my original thoughts, please kindly let me know if there's better solutions :)

[denisov]

ok, I see. Thanks for explanation, @jimhorng

[ExplodingCabbage]

I won't pretend to fully understand this at a glance, but it sounds like everyone involved was satisfied this was resolved, so I'm going to hit the close button. Please reopen if I've misunderstood and there's still something that needs addressing.