Research on Android Push Technology

Objective

Recent research on the implementation of Android push, studied for two days a night, with a little harvest, write down both for sharing, but also to spit groove. What needs to be explained is that some things are biased to the bottom of the hardware and communications industry, I am ignorant of these, can only speak their own understanding.

Why study Android Push technology?

Main or graduation design to do a real-time communication app, I do not like to do social apps, also on the ivory tower in the people want to come out, to tell the truth there is this kung fu is not as good as delving into a small technical point, a point of study thoroughly, than to engage in a chatty, but also useless things much better, just who call us

Several ways to implement Android push service

In real life, push service is like a magazine, just to leave your address, the magazine can be sent to your hands, can feel that everyone has a unique address, but in the current network, this is impossible, because not everyone has a unique address, the server wants to send us a message, We have to know our address, but the server doesn't know where we are.

When it comes to push services, the implementation scenarios I know are as follows:

Polling

The client periodically asks the server if there are any new messages, so that the server does not have to take care of the client's address, and the client asks, just tell it.

Such a scheme is the simplest, for some do not pursue real-time client, it is very suitable, just need to set the time interval of several hours to take once, it can be very convenient to solve the problem.

But for instant messaging products, such a solution is completely useless. Assuming that the Instant messaging software in the case of network traffic to send the message requires the other 10s can be received, assuming that with polling, then the client to every 5s server, assuming that on the mobile side, the phone's power and traffic will be exhausted.

SMS Notifications

Such a solution is possible on the mobile side, let the client intercept SMS, the server in the new message to the user's mobile phone number to send a special text message, the client intercepted text messages found to be normal text message release, assuming that a special text message on the connection to the server to take messages.

Operators will not cooperate, users will not be assured that this program ordinary companies can not afford to play.

Long connections

This is probably the best scenario in the present situation, after the client actively and the server to establish a TCP long connection, the client periodically sends a heartbeat packet to the server, when there is a message, the server directly through the established TCP connection to notify the client.

XMPP, MQTT, etc. do not count as push technology

When searching for information on the Internet, we often see the implementation of the XMPP protocol Android Push and the MQTT protocol implementation of Android push, I personally think these two statements are very strange, both XMPP and mqtt are agreements, although I do not know strictly speaking the two agreements on which level of work, But definitely in the transmission layer above, I think they two in the TCP/IP five layer model of the application layer bar, not to mention the implementation of the transmission layer, but the application of the layer, this is really confusing, so I personally think XMPP, MQTT and so does not count push technology.

About this xmpp, I think very many people are involved in openfire and smack that set of things, I tried to use Asmack and openfire a year ago to do IM, just that time do not understand anything, do something very rotten, the only thing to know is openfire this stuff is quite old, I think there are some open-source push solutions are based on this set of things to change, think of this workload, very scary.

On TCP long Connection and Heartbeat

Long connection solution at first blush, what is a long connection? What is the difference between sending a heartbeat at timed intervals and polling?

What does a heartbeat do? The same is the regular communication with the server, why the long connection is better than polling? Is the TCP connection not broken when the phone is dormant?

This is my problem when I started to study push technology, although some of them are not very accurate answers, but the understanding of probably can share, what wrong welcome to point out.

What is a long connection

First of all, the short connection, the short connection is the communication between two parties have data interaction when the establishment of a connection, after the data is sent. This connection is disconnected.

Persistent connection

A long connection is when you establish a connection, do not actively disconnect. The two parties send data to each other, do not actively disconnect the connection, after the need to send the data will continue to send through this connection.

The TCP connection is the so-called long connection by default, which means that the connection is not actively closed, and the connection should always exist.

However, the situation in the network is complex and the connection may be cut off. For example, the link of the client to server is broken, or the server is down, or your network cable is cut, these are some inexplicable causes the connection is cut off factors, there are several special:

Nat Timeout

Because the IPV4 address is insufficient, or we want to surf the internet via a wireless router, our device may be behind a NAT device, and the most common NAT device in life is the home router.

The NAT device changes the source/destination IP address when the IP packet passes through the device. For home routers, the use of the network address port conversion (NAPT), it not only changed the IP, but also changed the TCP and UDP port number, so that the intranet device can share the same external network IP. For example, NAPT maintains a NAT table similar to the following table

Intranet Address	Extranet Address
192.168.0.2:5566	120.132.92.21:9200
192.168.0.3:7788	120.132.92.21:9201
192.168.0.3:8888	120.132.92.21:9202

The NAT device makes changes to the data that goes out and comes in according to the NAT table, such as changing the packets sent by 192.168.0.3:8888 to 120.132.92.21:9202, and the outside feeling that they are communicating with 120.132.92.21:9202. At the same time, the NAT device will 120.132.92.21:9202 the packet received by the IP and port to 192.168.0.3:8888, and then sent to the intranet host, so that the internal and external communication can be bidirectional, but assume that 192.168.0.3:8888 = = 120.132.92.21:9202 This mapping is eliminated for some reason by a NAT device, the external device cannot communicate directly with 192.168.0.3:8888.

Our equipment is often in the back of the NAT device, for example, in the university campus network, check the IP assigned to it, in fact, is the intranet IP, indicating that we are behind the NAT device, if we are in the bedroom to connect a router, then we send the packet will be more than once Nat.

When the domestic mobile wireless network operator has no data communication over a period of time on the link, the corresponding entry in the NAT table is eliminated, causing the link to break.

Network State switching

Mobile network and wifi network switch, network disconnection and even the best situation, also can make long connection disconnect. The reason may be more, but the result is that the IP has changed, or the system is notified that the connection is broken.

Lease period of DHCP

At the moment, the test found that the Android system has a bug in DHCP processing, the DHCP lease period will not be actively renewed and will continue to use expired IP, this problem will cause TCP long connection accidental disconnection.

From Android Smart Heartbeat solution

The function of the heartbeat package

A lot of articles on the Internet on the long connection when all said:

Because it is a long connection, it is necessary to send a heartbeat packet regularly.
The heartbeat packet is used to notify Serverclient of the current state.

Those who make these statements are in fact smattering themselves. These statements are in fact true, but they are not answered. It's like someone asked, "Why are you going to the cafeteria?"

The man replied, "Check if you can find the canteen." This answer is not wrong, but in fact this person is to eat in the cafeteria, prove that he knows the road is only a gift.

Understand a bit, TCP long connection essentially does not need heartbeat packet to maintain, we can try, let two computers connected to the same WiFi, and then let one of the server, and one with a normal not set keepalive socket connected to the server, Just two computers do not break the network, the router also do not power off, DHCP normal renewal rent, so put on, after a few hours and then use one of the computer through the previous TCP connection to the establishment of a message, there is a send messages, there is a sure to receive.

Then why do you have a heartbeat pack?

In fact, the main purpose is to prevent the NAT timeout mentioned above, since some NAT devices infer whether or not the NAT mapping is based on a certain amount of time without data, then the client actively sends a data.

Of course, assuming that the server can send a heartbeat packet to the client to prevent NAT timeouts, the disadvantage is that if the connection is broken, the server will no longer be able to contact the client. So the heartbeat packet must be sent by the client, the client discovers that the connection is broken, and can try to reconnect the server.

So the main function of the heartbeat packet is to prevent NAT timeout, followed by probing whether the connection is disconnected.

The link is disconnected, the TCP connection without the write operation is not perceptible, unless the data is sent to the server at this time, causing a write timeout, otherwise the TCP connection will not know the disconnection. Actively kill off one side of the process, and the other side will close the TCP connection, is the system generation process to the server fin. This is the case with a TCP connection, only to have a clear message that the other person has received a close connection (the RST will be closed and everyone knows it), or that it is aware that a write timeout has occurred, or that the connection still exists.

Time interval for heartbeat packets

Since the main function of the heartbeat packet is to prevent NAT timeouts, this interval is great article.

Sending a heartbeat packet is bound to wake up the device first, and then the ability to send, assuming that the wake-up device is too frequent, or directly causing the device to hibernate, will be a lot of power consumption, and mobile network network communication, more than the WiFi under the electricity. So the time interval of the heartbeat packet should be as long as possible, the ideal situation is that there is no NAT timeout, for example, just now I said two in the same WiFi computer, there is no need to heartbeat packet. This is often said on the Internet long connection, slow heartbeat.

The reality is cruel, according to some of the internet, mobile 2/3g, Nat timeout time is 5 minutes, China Telecom 3G is more than 28 minutes, ideally, the client should be slightly less than the NAT timeout interval to send heartbeat packets.

WiFi, Nat timeout time will be longer, it is said that broadband gateway generally does not have a spare release mechanism, GCM some time in the WiFi heartbeat than in the mobile network heartbeat faster, may be due to the WiFi under the network communication cost less than mobile networks.

about how to make the heartbeat interval close to the NAT timeout interval, and at the same time actively adapting to the NAT timeout interval changes, can see

__biz=mzawndy1ody2oq==&mid=207243549&idx=1&sn=4ebe4beb8123f1b5ab58810ac8bc5994&scene=4#wechat_ Redirect ">android Smart Heartbeat scheme.

Differences in heartbeat packs and polling

Heartbeat packs and polls look similar, with the client actively contacting the server, but the difference is very large.

• Polling is to get the data, and the heartbeat is to keep the TCP connection alive.

• The more frequent the poll, the more timely the data gets, and the frequency of the heartbeat is not directly related to whether the data is timely or not.

• Polling is much more energy-efficient than a heartbeat, because one poll requires a TCP three handshake, four waves, and a single heartbeat does not require a TCP connection to be established and removed.

TCP Wakeup Android

This part of the content I only know the conclusion, do not know the detailed knowledge
Have you ever thought that the SMS function and function of the mobile phone is almost the same, why would it consume so much more than a text message? Of course not because of the text message a 0.1 yuan. What is a mobile phone message to get pushed?
The following is an unknown source, perhaps to inspire you.

First Android phones have two processors, one called Application Processor (AP), one called Baseband Processor (BP). The AP is an arm-architected processor for performing Android systems; BP is used to execute a real-time operating system (RTOS), and the communication stack executes on the BP RTOs. Non-talk time, BP's energy consumption is basically around 5mA, and the AP only to be in non-dormant state, energy consumption at least 50mA, the execution of graphics will be higher. In addition, the LCD operating power consumption around 100mA, WiFi is also around 100mA. When the phone is in standby, the AP, LCD, and WiFi all go into hibernation, and the code for the app in Android will stop running.

Android provides the Wake lock API to ensure the correct operation of critical code in the application, allowing the application to block the AP from entering hibernation through code. But if you don't understand the Android designer's intentions and misuse the Wake Lock API, In order for the program to work in the background for a long time to prevent the AP into hibernation, it will become a standby battery killer.

It is not necessary to worry about AP hibernation at all. The communication protocol stack runs on BP and once the packet is received, BP wakes up the AP and wakes up enough time for the AP to run the code to complete the processing of the received packets. The AP will be awakened when the other is triggered as a connectivity event. The only problem is how the program runs the logic of sending a heartbeat packet to the server. You obviously can't rely on the AP to make a heartbeat. The alarm manager provided by Android is here to solve the problem. The alarm should be BP timing (or some other chip with a quartz clock. Not quite sure, but definitely not the AP), when the wake-up AP is triggered when the program code is run. So what's the use of the Wake Lock API? For example, the heartbeat packet from the request to the answer, for example, the disconnection is re-connected to the operation of these key logic, you need to wake lock to protect. Once a key logic runs successfully, you should release wake lock immediately. Two heartbeat request interval of 5-10 minutes, basic not how to consume electricity. Unless the network is unstable. Frequent disconnection, which is not a lot of ways.

The above mentioned communication protocol, I guess should be the Wireless Resource Control Protocol (Radio Resource control), RRC should work in the OSI Reference Model of the third layer of network layer, and TCP, UDP work in the fourth layer of transport, the above mentioned BP, should be the cell phone baseband, There are also called radio, I am a little confused radio how to translate. Google mentioned in optimizing Downloads for efficient Network access a thing called Radio state Machine, and I translated it into a radio-wave mode, and I don't know what the correct translation is.

In the mobile network, each TCP connection should have a RRC connection, and the RRC connection will wake the baseband, the baseband will wake up the CPU processing TCP data, which is my personal understanding.

As for how to work under WiFi, I did not find the information temporarily.

It says so much, it actually means that TCP packets can wake up the phone. As for UDP, I'm not sure.

And the most important part of the push is to keep the phone as dormant as possible, only to wake it when the server needs it to process data, which is exactly what we need.

Power consumption under the mobile network

Google mentions a thing called Radio state machine in optimizing Downloads for efficient Network access.

Mobile Radio State Machine

Said should be the work of the baseband, in the radio standby almost no power, but once there is a need to deal with things, such as a mobile phone app to access the network (from the last section can guess: Received RRC instructions will also cause wake), will enter into radio full power, The wake-up process from standby to full power is very battery-intensive, with the full power baseband spare 5s into radio low Power, assuming spare 12s to enter standby. The basic meaning is not to frequently wake up the baseband to request the network, because only to wake up, at least let baseband in full power to work 5s, under low power 12s, and the wake-up process very power consumption. So in the mobile network, the heartbeat needs to be as slow as possible, just in the current situation, want to slow down almost impossible.

But this also brings another problem, if there are 10 applications in the mobile phone, each application sends a heartbeat packet, each application server may wake up the phone, the phone is not dormant?

The actual implementation of the problems encountered

I started to do the demo, the server uses Apache Mina, the client also uses this

Mina

This framework is very useful, is encountered some very strange things, I saw two days ago, so it may be my own problem.

One is the Android side sends a Chinese character to the server, ServerFilter crashes, sends more than one Chinese character, Clientfilter crashes, writes a iofilter to do the next decoding is good. There are also errors in the code in User Guide. The second is that the Iosessionconfig write timeout setting is completely ineffective.

A wonderful socket for Xiaomi phone

Later found that the client only in the background more than a certain time, the socket write operation will become very strange, performance as the socket to swallow the data, tell the application data has been received by the other side, but the server did not receive anything, and the server sent the message client also received . Just to get the app to the foreground, the previously disappearing data will be sent to the server, and the client will receive the server retransmission message.

I started thinking that it was the sleep mechanism of Android to break the WiFi, I put all kinds of wifilock, Wakelock are held, or out of this situation. Later inadvertently found that Xiaomi for each app has a background execution when agreed to the Internet switch, I opened it, really good for a while, and then began to repeat the situation before, I thought it was Mina IO thread was killed or how, with DDMS see thread information no problem. Do not rest assured, and with a pure socket to achieve the client, or there is a problem, and then on the basis of the previous plus 1 minutes of heartbeat, or there is a problem.

A fantastic bug in Xiaomi phone

This is really my luck, I looked at the background when the implementation of the switch agreed to the Internet, found that the demo app This switch has just been opened by me, which is closed again, I suspect that the function of millet is a bug, I remember there are millet employees mentioned this thing has the server under the white list, I think the server issued data to my changes to cover, I put a few apps in the background of the Internet off, restart the phone, they opened again.

Finally I changed a 10s heartbeat interval, in the heartbeat of the time, the background agreed to turn off the Internet, to reproduce the wonderful socket behavior, presumably determined to be MIUI bug.

After a nap, MIUI's project Master contacted me to confirm that it was a bug. By the way to remind the use of millet testing machine developers and users, the temporary solution of this bug is: With the implicit mode of their own definition of the configuration, you want to change the settings can be.

Think of a year ago, don't know anything to run to Millet interview is funny, I this level is completely deceptive, but did not expect this is millet pit.

The best push technology in my heart

RRC that set of things, you know, the baseband Standby mode also maintains the connection.

Reference website

Understanding the Android "Radio" for better battery life

__biz=mzawndy1ody2oq==&mid=207243549&idx=1&sn=4ebe4beb8123f1b5ab58810ac8bc5994&scene=4#wechat_ Redirect ">android Smart Heartbeat Solution

Q=cache:m9nwcz-0x1ij:blog.oasisfeng.com/2013/04/14/dirty-secret-behind-weixin-charge-gate/+&cd=1&hl= ZH-CN&CT=CLNK&GL=CN "> The technical details that are widely overlooked behind the charge event
Android device hibernation
Optimizing Downloads for Efficient Network Access
About the socket long connection heartbeat package
Network Address Translation
The TCP keepalive in the programming of C + + network
Tcp/ip,http,socket, long connection, short connection-summary.
Android Implementation Push Way Solution

Turn from "Http://www.jianshu.com/p/584707554ed7"

Research on Android Push Technology