Why does Apple close socket/TCP connection is case of error/invalid token while sending push notifications?

Question

I realized this problem today:

http://redth.codes/the-problem-with-apples-push-notification-ser/

Is there a technical explanation as to why it happens this way, or is it just that Apple is not developer friendly. They could have queued the notifications at their end, and have ignored invalid tokens on their server, allowing the batch of notifications to be successfully sent using the same connection. I could query for invalid tokens later, using the feedback service. An invalid token resulting in a closed connection, which in turn results in all the notifications after that not being sent, is somewhat a foolish implementation to me from a web developers perspective. Or may be since I am not into socket programming, therefore I am overlooking some obvious details. Can someone please help me understand this. If that's a limitation of sockets, then may be as suggested in the blog post, Apple should move over to HTTP.

Answer 1

I've wondered the same thing, since this behavior of the APNS server is very annoying, and makes the implementation of the server side much more challenging.

I believe the reason for this behavior is that the format of the notifications we send to Apple is binary.

Lets assume you are using the simple binary format to send two notifications (but the explanation can be easily expanded to the newer formats) :

0 0 32 device-token1 payload-length1 payload1 0 0 32 device-token2 payload-length2 payload2

Now, if device-token1 has a length of 32 bytes, and the only problem with it is that it's invalid (i.e. it doesn't match any device in the current push environment), Apple could skip to the next message as you would like.

However, if you are missing one of the constant bytes (command or payload length), or you pass a device token of incorrect length, or the length of your payload doesn't match the payload length you supplied, Apple will have no way of knowing where the next notification begins. Therefore they close the connection and expect you to re-send any valid messages that followed the invalid message.