Apple IOS Push notification protocol with egg pain

Brief introduction

The Apple push notification mechanism is simple: Apple's APNs server is an intermediary and pushes messages to the corresponding device.

A picture from an Apple document:

Of course, it looks simple, but there are some practical problems.

For example, how to distinguish provicer? How to differentiate the device?

In simple terms, this is the case:

• Each app has its own certificate (certificate) that developers can get from Apple;
• Applications can register on the APNS server, and then get a device_token that developers have to save themselves, and use this to differentiate between devices when pushing.
• Note that token is not a unique identification code for the device. Tokens can be changed, so APNs provides a feedback service where developers can get tokens that expire.
• For each device, only the last push is stored, so if a lot of push is sent and the device is not received in time, then the push will overwrite the previous one.
• Provider and APNS servers, communication between APNs servers and user devices are SSL/TLS protocols. This is better than the domestic push service providers to do, the domestic push services are HTTP interface, there is no encryption at all.
• Push is all about the device. So the sensitive information does not pass through push.
• Push is delivered as much as possible, and the push message may be lost, so do not use push to pass reliable data.

Apple Push protocol The place of the egg hurts

There are just a few small places to watch, and here's what really hurts: the Apple push protocol.

First, the obvious is the poor design:

the command in the agreement is now actually used to denote version.

For example, command = 0, 1, 2 represents the three versions of the sent message, respectively.

The more painful is the previous 0, 12 versions of the current document are not found. How does this make the maintenance of old code human? Want to debug the bug, the results found that the official documents have disappeared, it is a lot of egg pain.

Apple's documentation says only:

Field Name		Discussion
Command	1 byte	Populate with the number 2 .

Maybe when you read this article, it became "Populate with the number 3".

Normal people see here will only feel confused, why this command is 2? How to get this command is actually related to the version. I know there are three versions of it from some other implementation code.

Protocol Format Confusion

For example, this feedback format:

Devicetoken is fixed is 32 bytes, the front plus a token length.

One might say that this is considered after token greater than 32 bytes. That should simply add a version number to the feedback response package.

The sender can send the message in bulk, but only when an error occurs will the ID of the error message be returned.

At first glance, there's nothing wrong with it. But when you want to implement a push client, you know where the egg hurts:

The sender continued to 1,2,3,4 ... 100 messages, has been written into the socket, where the APNS server responded that the 57th message failed.

The sender has to start with the 58th and re-send it. The sender has to cache the messages that have been sent out before!

OK, it's okay to cache, so how many messages are cached? 1024 of them? 2048 of them? Goodness knows.

If the sender's speed is fast, all of a sudden 4,096 messages are sent out? So what?

Well, maybe you'll say 4,096. The size of the message body, Apple's server TCP socket buffer is full, you can not send so many messages.

I just want to send a push message, do I have to calculate the size of the APNS server's socket buffer? What if its network framework was buffered? What if the sender's network framework is also buffered?

Do you want to wait for the data to be written to the socket every time you send it?

the sandbox server for developer testing is a device

The document written in the development environment can be used with this domain name, gateway.sandbox.push.apple.com. But the pit daddy is, this domain name is actually a device, you can establish the SSL connection, also can send the message normally.

But your device is not receiving the message. If you implement your own client, use this to test, the egg hurts, check your code again and again to see if there is a problem, and finally found that the other side of the server has a problem.

Only the programmer can understand the feeling of the egg's pain.

Packet forwarding not supported

Now the domestic popular push service, such as Baidu Push, and so on, all support the configuration of the packet, so that greatly save the bandwidth, lift off the delivery efficiency.

There may be some place where the egg hurts, forget, next blog say some of the implementation of their own client to pay attention to the matter and a Java implementation zpush.

Reference:

Http://support.apple.com/kb/HT3576?viewlocale=zh_CN&locale=zh_CN

https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ Chapters/applepushservice.html#//apple_ref/doc/uid/tp40008194-ch100-sw12

https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ Chapters/communicatingwithaps.html

https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ CHAPTERS/COMMUNICATINGWITHAPS.HTML#//APPLE_REF/DOC/UID/TP40008194-CH101-SW1