Hi,

I guess these issue (http://code.google.com/p/apns-php/issues/detail?id=8) isn't solved and gave me some headache. First i thought its related to ApnsPHP missing Errorcode 255 (error unknown) in Push.php, resulting in not being able to decifer the errormessage from apns, but adding the code didn't solve the connection losses.

The problem seems to be, that ApnsPHP is sending the messages to apns too fast, causing the apns-server-instance to die (IDK what happens), which results in the apns-server closing the connection without sending an errormessage. This results in a loss of messages, since without an errormessage containing the apropriate message-id ApnsPHP doesn't know which message was transfered successfully last and continues at the message which was SENT last, leaving the messages in between unsent (about 10 / 12 per error over here).

For me slowing down the transfer by adding some 50msecs sleep() in line 143 in Push.php solved the problem. Now it takes about 30 secs to send ~500 messages instead of ~5 secs, but at least all messages get sent. (it seems to work with 1msec, too, but since its important to ensure getting all messages transfered, i decided to stay with 50msec)

Uh guys, according to Apple's own docs you should be able to send at least 9000 messages per second unless you are checking for errors after every write.

https://developer.apple.com/library/mac/#technotes/tn2265/_index.html

As I know you can use 'setWriteInteval(0)' only if you haven't failed tokens. Otherwise you will lost part of your messages.

See here: https://github.com/duccio/ApnsPHP/issues/9

"Device tokens should almost all be valid if you've captured them correctly and you're sending them to the correct environment. So it makes sense to optimize assuming failures will be rare. You'll get way better performance if you wait for write to fail or the batch to complete before checking for an error response, even counting the time to send the dropped notifications again." From: https://developer.apple.com/library/mac/#technotes/tn2265/_index.html

My problem was, that there had been no response with information about the last message received if the transmission broke up, and thus there was no info available, from which message the transmission had to be picked up again. From my POV it's not really an option to try to boost performance if the result is that i'm not able to ensure all messages being sent (and every message getting sent only once).

Btw., the problem isn't related to invalid devicetokens. The interruption was random.