Thoughts on Aurora push technology principles

Mobile Internet Application Status

Because of the limitations of mobile phone platforms, power, and network traffic, the design of mobile Internet applications is very different from that of traditional PC applications. Based on the characteristics of mobile phones, save power and traffic as much as possible, and ensure that data can arrive at the client in a timely manner.

To solve the problem of data synchronization, there are two common methods on the mobile phone platform. One is to regularly query data on the server, also known as polling. The other is to maintain a TCP persistent connection between the mobile phone and the server. When the server has data, it is pushed to the client in real time, that is, push.

In terms of the power consumption, traffic, and data delivery timeliness, push has obvious advantages, but the implementation and maintenance costs of push are relatively high. It is technically difficult to maintain persistent connections in mobile wireless networks. This article attempts to introduce how Aurora push maintains persistent connections on the Android platform.

Features of Mobile Wireless Networks

Because the IP address V4 has a limited number of IP addresses, the IP address assigned to the mobile terminal by the operator is the Intranet IP address of the carrier, and the mobile phone needs to connect to the Internet, you need to perform a Network Address Translation (NAT) through the carrier's gateway ). To put it simply, the carrier's gateway needs to maintain an Internet IP address, Port-to-Intranet IP address, and port correspondence to ensure that the Intranet mobile phone can communicate with the internet server.

Image Source: cisco.com.

The NAT Function is implemented by the ggsn module in the figure.

Most mobile wireless network operators will eliminate the corresponding items in the NAT table when there is no data communication over the link for a period of time, resulting in link interruption.

Implementation of persistent connections on the Android platform

In order not to invalidate the NAT table, we need to initiate a timed heartbeat to refresh the NAT table items to avoid elimination.

On Android, there are two commonly used methods for scheduled task running: timer and alarmmanager.

Timer

The timer class of android can be used to plan tasks that need to be executed cyclically. The problem with timer is that it needs to use wakelock to keep the CPU awake, which will consume a lot of cell phone power, greatly reduce the standby time of the mobile phone. This method cannot meet our needs.

Alarmmanager

Alarmmanager is a module encapsulated by the Android system for managing RTC. RTC (real time clock) is an independent hardware clock that can run normally during CPU sleep and when the preset time arrives, wake up the CPU by interrupting it.

This means that if we use alarmmanager to regularly execute tasks, the CPU can sleep normally, and only a short period of time can be woke up when the task needs to be run. The android SDK of Aurora push is implemented based on this technology.

Server Design

When a large number of mobile terminals need to maintain persistent connections with the server, the design of the server will be a great challenge.

Assume that one server maintains 0.1 million persistent connections. When there are 10 million users, up to 100 servers are required to maintain these users' persistent connections. This is not a backup server, this will be a huge cost issue. We need to increase the number of users connected to a single server as much as possible, that is, the c10k issue that has been discussed for a long time in the industry.

C2000k

To address this problem, we have set up a project named c2000k. As the name suggests, our goal is to maintain 2 million persistent connections on a single machine. In the end, we adopted a multi-message loop and asynchronous non-blocking model. On a dual-core, 24 GB memory server, we achieved a peak value of over 3 million persistent connections.

Postscript

Stable maintenance of persistent connections is a foundation of the push platform. The Aurora push team will invest in this field for a long time to ensure that users can effectively save power and traffic while delivering data in real time.

The above is an official Article of Aurora push, but I have a few questions after reading it.

1) They claim that the maximum peak value can reach persistent connections, but what is the highest processing rate of active connections?

2) What are the average message length and limits?

3) What is the message's timeliness and latency?

4) I don't know how many users are pushing Aurora now. So is the peak value in the production environment or the test environment?

5) Why does the client use alarmmanager to obtain push messages? Is this message timely? When you get to know Android, there are also N loads.

6) What I'm interested in is not how many million pieces of data are pushed by the Aurora solution each month, but how many seconds or minutes can be processed.