Mobile IM Development Guide 1: How to choose a technology

The Mobile IM Development Guide Series article will cover all aspects of an IM app, including technology selection, landing optimization, and more. In addition, the author will combine his experience in the development of iOS IM SDK in netease Cloud For many years, in-depth analysis of various common problems in real development.

Recommended Reading

Mobile IM Development Guide 2: Heart rate Instructions

Mobile IM Development Guide 3: How to optimize login modules

Choice of communication mode

Im communication is no more than two options: Device Direct Connect (peer-to) and through the server relay.

(1) peer

Multi-peer in the LAN chat tools, typical applications are: flying Pigeon biography. This kind of software usually does two things after startup:

L UDP Broadcast: Send your own information and accept other information in the LAN

L Turn on TCP listening: wait for the other side to connect

Detailed process can refer to the source of flying Pigeon biography. But this way there are limitations and inconveniences: On the one hand it is only suitable for online point-to-point message transmission, offline, group and other business support is not enough. On the other hand, because of the existence of NAT, it makes the interconnection of the machines in different LANs much more difficult, and the connection cannot be established under some network types (symmetric NAT).

(2) Server Relay

Almost all Internet IM products use server relay in this way for message transmission, compared to peer-to the way, it has the following advantages:

L can support more and more peers can't support or support bad business, such as offline messaging, group, chat room service

• Facilitates the expansion of business logic and compatibility with old and new versions

Of course, it also has its own problems: The server architecture is complex and the concurrency requirements are high.

Network connection mode

There are two ways to connect to the main network of IM:

L TCP-based long connections

L HTTP Short-Link Pull method

The latter is common in the Web Im system (of course, now many web im are based on websocket implementation), its advantages are simple, convenient development, the problem is large traffic, server load, message timeliness can not be well guaranteed, large-scale user support is not enough, more suitable for small IM system , such as a small website of the customer system.

Long-based TCP connections are better able to support large-volume users, the problem is that the client and server implementations are more complex. There are also variants, such as the downstream use of MQTT for server notification/message issuance, upstream use of HTTP short connection for instruction and message upload. This method can guarantee the timeliness of downlink message/instruction, but the problem of upstream slow in weak network is still quite serious. The early intercourse was based on this approach.

Protocol Selection

The principle of IM protocol selection is generally: easy to expand, easy to cover a variety of business logic, but also a more efficient flow. The latter point of demand is particularly important on the mobile side of IM.

Common protocols are: XMPP;SIP;MQTT; private protocol.

The advantages of the XMPP protocol are: open-source protocol, scalability, and the implementation of various languages at each end (including the server), the developer access is convenient.

But there are many drawbacks : XML is weak, there is too much redundant information, traffic is large, the actual use of a large number of sinkholes.

The SIP protocol is used for VoIP-related modules, is a text protocol, because I have not actually used, so do not comment, but from it is the text protocol can almost conclude that its traffic is not small.

The advantage of MQTT is that the protocol is simple and the flow is low, but it is not a protocol specifically designed for IM and is used for push.

L almost all major IM apps on the market use private protocol, a well-designed private protocol generally has the following advantages: efficient, save traffic (generally using binary protocol), security is high, difficult to crack. The disadvantage is that at the beginning of the development of no existing samples can be consulted, the requirements of designers are relatively high.

A good protocol needs to meet the following conditions: efficient, concise, readable, save traffic, easy to expand, but also able to match the current team's technology stack. Based on the above principles, we can launch: If the team is small, team technology is not accumulating on im enough to consider the implementation of XMPP or mqtt+http short connections. Instead, consider your own design and implementation of private protocols.

Design of Private protocol

L Serialization Selection

The most important features of mobile Internet are: Low bandwidth, high delay, high packet loss rate and poor stability, high traffic cost. Therefore, the binary protocol is generally used instead of the text protocol on the serialization of the private protocol. Common binary serialization libraries have PROTOBUF and messagepack, and of course you can implement your own binary protocol serialization and deserialization process, such as Mushroom Street teamtalk. But before both the scalability and readability of both teamtalk (TEAMtalk even variant is not supported, an int is transferred with a fixed occupancy of 4 bytes), it is not recommended to implement the binary protocol serialization and deserialization process in most cases.

L Protocol Format design

TCP-based application layer protocol is generally divided into Baotou and inclusion (such as HTTP), IM protocol is no exception. Baotou is generally used to represent the public part of each request/feedback, such as packet length, request type, return code, etc. The Baotou is filled with different request/feedback corresponding information.

One of the simplest headers can be defined as

Take the heartbeat packet as an example, assuming that the current serial is 1, Heartbeat packet command is 10, then use Messagepack to do serialization: length=4,serial=1,command=10,code=0, each field is a byte, the package body is empty, Only 4 bytes are required.

Of course this is the simplest example, in the face of real business logic, the package body will need to plug in more information, this need to develop according to their business logic to summarize the public part, such as in order to be compatible with the protocol version number, in order to load balanced module ID added.

The above is the general selection process of IM system, including the mode of communication, connection, protocol selection, protocol design. But there are still a lot of problems to be dealt with in the actual development process. The second article of the Mobile IM Development Guide series will answer common questions in real-world development.

Mobile IM Development Guide 1: How to choose a technology