Principles of server and client message pushing

Principles of server and client message pushing

In fact, there are several ways to push messages between the server and the client:

1. The client constantly queries the server and checks new content, that is, the so-called pull or polling method;

2. Maintain a persistent TCP/IP connection between the client and the server (in HTTP1.1, all requests are considered persistent connections), and the server pushes the connection to the client;

3. When the server has new content, send a message similar to the SMS to the client. The client receives the goods and downloads the new content from the server, that is, the SMS push method;

 

The first method has the following Disadvantages:

1. Mobile phones consume a lot of power because they need to be polling constantly;

2. Easy to be killed by the system;

For the second method:

First, let's take a look at the knowledge of HTTP persistent connections:

In HTTP1.1, all links are considered persistent connections. An HTTP persistent connection sends multiple HTTP requests and receives multiple HTTP responses based on a TCP connection, this is to avoid opening a new connection for each request.

In the message push system, HTTP persistent connection is used to send requests to the server and wait until the server returns data. This is equivalent to the client's "listening" server, you can receive messages from the server at any time.

It also involves synchronization and Asynchronization, blocking, non-blocking, and other related knowledge:

Synchronization: IO operations will cause the request process to be congested and the IO operation is completed. That is to say, after the client sends the request, it must send the next request only after the server responds;

Asynchronous: IO operations do not cause request process blocking. That is to say, after the client sends a request, it can send the next request without waiting for the response from the server;

Blocking: when the server thread or process does not process data, it will not return. The thread or process will be suspended and no other requests will be sent;

Non-blocking: the server will return immediately when the processing is not completed, and the thread or process will not be suspended. You can continue to respond to other requests;

Blocking and non-blocking are the server-side request processing methods. In the message push system, clients and servers use Asynchronous non-blocking.

1. The client sends an http persistent connection request and waits for the response from the server. The request is asynchronous, so the client can continue other work, such as initiating other ajax requests.

2. After receiving the request, the server does not send data immediately, but holds the connection. This process is non-blocking, so the server can process other requests;

3. At a certain time point, the server has new data, and the server actively pushes the message, that is, the data is pushed to the client through the connection established previously;

4. When the client receives a response, it can process the data and initiate a new persistent connection.

For mobile terminals:

First, let's talk about android:

Ordinary socket connections consume too much on the server, so there is a lightweight and low-consumption protocol like MQTT to maintain persistent connections. To maintain persistent connections in android, a heartbeat mechanism is required, the client sends a heartbeat packet to the server, and the server sends a heartbeat response to the client, forming a complete handshake. This handshake allows both parties to know that the connection between them is not broken, and the client is online. If the threshold is more than one time, the client does not receive a response from the server or the server does not receive the heartbeat from the client, then the client disconnects from the server and creates a new connection, for the server, you only need to disconnect the connection.

The persistent connection of android is maintained by each application. Therefore, if every application is online 24 hours a day, each application must maintain a persistent connection. This kind of power consumption can be imagined.

Next for IOS:

IOS persistent connections are maintained by the system. That is to say, Apple's ios system maintains a persistent connection between the client and the Apple server at the system level, push on all ios apps pushes messages to Apple's servers first, and then Apple's servers push messages to the mobile phone through this system-level persistent connection. This has several advantages:

   
1. You only need to maintain a persistent connection on the mobile phone terminal. Because the persistent connection is system-level, it will not be killed and cannot be pushed;
    
2. power-saving. Each application does not maintain its own persistent connection;
    
3. Security: Only developers registered with Apple can push data;
 

Here we will explain the MQTT protocol:

   
Lightweight machine-to-machine communication protocol;
    
Publish/subscribe mode (publish/subscribe Mode)
    
Based on TCP/IP
    
Support Qos
    
Suitable for low-bandwidth, unreliable connections, embedded devices, and insufficient cpu memory resources;
    
Is a good android message push solution.
    
FacebookMessager uses MQTT