Turn: Mobile Instant messaging System Practice

Mobile real-time communication system practice2016-04-19 Liaojin iOS development exploration

With information highly developed today, IM has basically become the standard for a social application. This paper will discuss the technology selection and key points of mobile instant communication system from the perspective of a mobile developer.

1 demand for Instant messaging systems

Any technical system is derived from the needs of the real business and should be set before the architecture design. As an Instant messaging application, you can refer to the experience of using, you need to ensure the following features:

1, real-time. The receiving end of the message should be able to receive and process the message in a timely manner.

2, do not lose. You need to ensure that all messages are delivered smoothly.

3, not heavy. Duplicate messages are a bad experience for the user.

4, guaranteed order. The news didn't look at all as long as the order was a mess.

5, energy saving. The traffic is valuable, the electricity is valuable, can save the province.

6, safe. If sensitive data is involved, security must be taken seriously.

7, Smooth. The application of the lag is not accepted by the user.

2 Key technology points

In order to guarantee the real-time of the message, there are two kinds of ideas:

1, long polling mode, high frequency from the server to pull new messages. This approach is in fact the traditional request-response model, and now many sports text live software also take this way. This method is simple, but has many drawbacks. One is a lot of requests, which is a waste of both the pressure on the server and the user's traffic. Second, the message is still not timely enough, regardless of transmission time, the longest delay is the polling interval.

2, the producer of the message actively pushes the message. This should be a better choice to solve the shortcomings of long polling. Our Instant Messaging system also uses this approach. Long connections are used, and the connection must be stable and reliable in order to ensure the real-time nature of the message.

2.1 Data Communication Protocol

The data format needs to be negotiated between the server and the client, which is the basis of data transmission and data processing. The design of the protocol needs to focus on several requirements mentioned in the first section.

XMPP and Mqtt are two types of message protocols that are now more mature. If you are better able to handle your business needs, there is no need to reinvent the wheel. There are many businesses have special needs, you can consider the actual situation to customize the agreement, from scratch is obviously unrealistic, you can refer to the mature protocol to do design and development. The details of the agreement are not discussed in detail, only compare the pros and cons.

2.1.1 XMPP

XMPP is an open, XML-based, instant Messaging protocol.

The advantages of XMPP are safety, reliable security of SASL and TL technologies, and are built into the core XMPP technical specifications.

The most important point of the XMPP protocol is the open, whether it is a protocol, client, or Server side, there are mature implementation scenarios.

Based on XML, it is inherently highly flexible and can be easily customized on top of the core protocols. Google talk is the kind of protocol that is used.

But the disadvantage of XMPP is also obvious. First, the XMPP protocol is encoded as a single long XML file, so it is not possible to provide modifications to binary data. Second, XML has a large number of label redundancy information, 70% of network traffic is consumed in the XMPP protocol layer, which in the mobile internet era, traffic and power is a negligible consumption.

2.1.2 MQTT

The MQTT protocol is an IBM-based publish/subscribe model of the message Transfer Protocol, compared to XMPP, it is very lightweight and compact, the protocol includes fixed head + variable head + message body, the bottom of the case the head only need two bytes, the transmission overhead has a huge advantage, can save traffic and power.

MQTT guarantees the reliability of the message, which includes three different quality of service (one at a time, at least once, once and only once), and if the client unexpectedly falls off, a message can be published using "will", while supporting persistent subscriptions.

XMPP uses XML, which is a historical choice, and in the now mobile app scenario, the individual is more recommended for MQTT. It is understood that many enterprises, including the manufacturer of IM SDK, are also customized extensions and modifications on the basis of MQTT.

2.2 Stability of the connection

In the context of mobile Internet, the network environment is constantly changing and needs to ensure that the connection is stable.

2.2.1 Heartbeat

The most classic approach is to use heartbeat to detect connection status in real time. Usually the client sends a packet to the server every other time, notifying the server that it is still online and transmitting some data that may be necessary. If the server does not respond within a certain amount of time, it is considered that the connection may have been disconnected and the connection will be tried again.

The pseudo code is as follows:

The heartbeat interval for the above code is fixed. As the heartbeat packet also consumes traffic, you should find an ideal heartbeat cycle where you can increase the cycle interval as much as possible with a keen sense of connection changes. Therefore, an optimization can be made to increase the heartbeat interval dynamically.

2.2.2 Multiple connection attempts

(1) Multiple connection attempts

Considering the different network operators in different regions, users may not be able to connect to our services or be slow because of network restrictions. In practice, we found that some network operators blocked certain ports, causing some users to connect to the service. To solve this problem, you can provide multiple IPs and multiple ports, and the client can poll and switch to a faster IP when it is slow to connect to an IP.

(2) Long connection combined with short connection

This is just an escape route, not a conventional weapon.

In the case where the long connection is not connected, you can consider downgrading and replacing it with a short connection long polling.

2.3 Quality of Service

The system design often has the choice and the compromise. Just as TCP is more reliable than UDP, it is more load-efficient.

In the instant communication system There are also the question of choice, is the pursuit of fast delivery, or in the transmission of the guarantee of reliability, to ensure that not lose weight? Different business types may require different quality of service, and the MQTT protocol offers three quality of service, which can be used as a reference:

QoS 0: Send at most once, send is discarded. There is no confirmation message and I do not know if the other party received it. The message is not important, it doesn't matter if it's lost.

QoS 1: Sent at least once. After it is sent, it waits for the receiver ACK acknowledgement. Within a certain period of time, if no ACK is received, it will be sent again until received by the receiving party. Messages that are re-sent will have a DUP mark on the head. This QoS guarantees that the message will not be lost, but the receiver may have duplicate messages that need to be weighed. As shown in the following:

QoS 2: There is and only one time. can be guaranteed not to lose weight, but the communication pressure is high, need to shake hands many times. As shown in the following:

3, client implementation

3.1 Message Processing

Sending a message is simple, just publish it to a topic.

The process for receiving messages is as follows:

message : The client needs to maintain a long connection and ensure that the connection is stable, as shown in the previous section.

Message Filtering : If the sending side does not ensure that the message is not heavy (for example, QoS in Mqtt is 0 or 1), the client needs to be de-weighed, so the message needs to have a unique ID.

message merging and distribution : In a real-life scenario, there are often a variety of message types (such as chat messages, system notifications, and so on) that can be combined for messages of the same type to speed up subsequent message processing. Different types of messages are distributed to their respective processors, such as storing to a local database, notifying the page of updates, etc.)

UI Update : The client typically uses a list to display messages (in iOS is a ListView in Uitableview,android), and the list can have a large amount of data and the data source can be updated frequently, so you need to optimize the performance of the list. To ensure a user experience. For iOS, for example, use instruments to monitor performance bottlenecks and optimize memory usage and CPU usage. After determining the problem, the usual techniques are: caching the cell height, simplifying the UI hierarchy, avoiding a lot of off-screen rendering, reducing the blending layer, and so on. The remedy is conquer.

3.2 Other

Im applications, there are many common implementation requirements, such as the expression keyboard, image voice and other multimedia storage and download queue. But this is not in the system implementation of the scope of the future, the article will be elaborated in detail.

Reference:

Https://en.wikipedia.org/wiki/XMPP

Http://www.blogjava.net/yongboy/archive/2014/02/15/409893.html

Turn: Mobile Instant messaging System Practice