[Original] answers to frequently asked questions about the lightweight mobile instant messaging technology MobileIMSDK, mobileimsdk
Statement:Currently, the MobileIMSDK is a self-developed open-source project and has been released. I have summarized some common problems related to the MobileIMSDK. I hope it will be useful to those who need it. Thank you. To communicate with the author, see the personal signature at the bottom of the article to learn from each other.
For the code hosting address of the MobileIMSDK project, go to Git @ OSC:Click to enter
Learning and communication
- Discussion and materials area: Click here to go to recommendation
- Mobile instant messaging group:215891622Recommendation
- Bug/suggestion sent:Jb2011@163.com
- For Technical Support/cooperation/consultation, contact the author QQ:413980957
[Question 1]: What is the MobileIMSDK? What is the value? What problems have been solved?
① What is it?
From A purely technical perspective: it is A complete set of UDP-Based Client A, server, client B three-party instant messaging Algorithm Implementation, ultra-lightweight, highly refined.
From the application layer perspective: it is a set of Instant Messaging SDK frameworks that contain the Android client library, iOS client library, Java cross-platform client library, and server library.
More broadly speaking: it is a cross-device, cross-platform, and cross-network instant messaging development framework designed for mobile devices. It can be used (including but not limited) develop chat apps, enterprise OA, and message push applications.
② What is the value?
People who have experience in instant messaging application development can understand that the difficulty of instant messaging application development lies not only in the business logic implementation at the application layer, more importantly, it requires a stable, reliable, and application-friendly instant messaging core layer framework. Otherwise, the complex logic of the application layer is incorporated into the complexity of the instant messaging technology itself (in the era of wireless network popularization, problems are even more prominent), which will lead to confusion for experienced development teams. The value of MobileIMSDK is that developers can focus on application logic development, and the underlying complex instant messaging algorithms are handed over to SDK developers to solve the complexity of instant messaging application development.
③ What problems have been solved?
- The implementation of UDP protocol is more in line with today's complex mobile network communication environment;
- The complete QoS message delivery guarantee mechanism solves the message black hole problem during UDP communication;
- It solves the problems of reliability and stability of 2G, 3G, 4G, WiFi, and multi-network hybrid communication with traditional broadband in a high-latency network environment;
- With an automatic communication CURE algorithm, no matter how bad the wireless signal is, as long as the communication is restored, the connection will be automatically restored;
- Pre-define multiple power consumption modes to determine the power consumption and network traffic consumption in response to different communication scenarios;
- Protocol encapsulation that is easy to disassemble. You can select an appropriate protocol compression solution for different application scenarios;
- Through the tempering of multiple versions, the API is highly encapsulated and can adapt to more application scenarios while solving the code coupling between the application layer and the instant messaging layer.
[Question 2]: Is it difficult to develop a framework similar to the MobileIMSDK?
Honestly, it is not easy to develop a complete algorithm that is stable and reliable and can be used in the production environment (of course, this is just a personal opinion. If you do not think so, at least you are much better than the author of this article.) the obvious difficulties are as follows:
Difficulty ①: algorithms are highly integrated and difficult to integrate
The algorithm itself is not groundbreaking, but the complexity of the hybrid communication (such as the complexity of different standards and the high availability of interference), cross-device, cross-platform, and cross-network types, under these factors and conditions, the algorithms to be implemented are more integrated and more difficult to integrate.
Difficulty ②: algorithms require multi-platform, non-differentiated, accurate implementation, and insufficient staffing
Because it is necessary to support different platforms and multiple elements and conditions, the algorithms to be implemented are not too demanding, but obviously it is not easy to solve without some skills, therefore, staffing is a problem.
Difficulty ③: Refining and grasping the framework must be accurate and friendly to the upper layer.
The value of being able to implement the so-called "Framework" with higher quality has already exceeded the algorithm itself. Otherwise, anything that is awesome can only be enjoyed by itself. Therefore, it is critical to be friendly to the upper layer, simple code stacking is obviously impossible.
Difficulty 4: It is difficult to achieve it overnight
With the existence of many elements and conditions, without long-term testing and targeted optimization, it is difficult to meet the quality requirements of practical applications, and time cannot be saved.
[Question 3]: How can I get help when I use MobileIMSDK?
- Discussion and materials area: Click to enter;
- Mobile instant messaging group: 215891622 (Click here for more QQ groups );
- Send bugs and suggestions to: jack.jiang@openmob.net or jb2011@163.com;
- For technical support, technical cooperation, or consultation, contact the author QQ: 413980957.
[Question 4]: Does the MobileIMSDK define a specific chat APP protocol?
No. MobileIMSDK has a clear design goal: to achieve a highly reusable instant messaging framework that is specifically developed for mobile terminals and can be used in various scenarios such as cross-device chat apps, enterprise OA, and message push. ", So in order to improve the reusability and flexibility of MobileIMSDK, this was especially avoided at the beginning of the design.
The benefit of this design is that, for example, when MobileIMSDK is applied to enterprise OA, traditional enterprise application systems usually have their own user relationship management models and implementations, therefore, you only need to use MobileIMSDK as the instant messaging message routing sub-system. In such a scenario, things should be so simple.
Of course, you can customize the details of your chat APP protocol, which also means you have higher flexibility during development. A typical full-featured chat APP case based on MobileIMSDK: click here to view and try it out.
[Question 5]: Why is the MobileIMSDK implemented based on UDP? What are the benefits?
Due to the connectionless nature of the UDP protocol, the obvious advantages include the following:
Benefit ①: more efficient cost ratio under the same server hardware and software conditions
Compared with TCP, due to the connectionless nature of UDP, the instant messaging algorithm can be flexibly adjusted to support more concurrent online data under limited hardware and software conditions.
Benefit 2: Suitable for scenarios with high network latency and complex network environments
A MobileIMSDK-based application (Click here to view its non-sensitive operation data) operated in a high-latency, complex cross-country, cross-Intercontinental Network Environment (statistics show that, in a typical network environment of this application, the average one-way network latency for accessing an http application is as high as ms, and the latency for accessing mainstream portals in China is about 30 ms ), applications can still maintain a good user experience. This proves to some extent the stability and reliability of MobileIMSDK in this scenario. However, if the TCP protocol is used in this case, the packet loss and retransmission at the protocol layer will be very large. According to the retransmission algorithm Exponential Backoff principle of the TCP protocol, in some cases, therefore, the user experience disasters cannot be controlled.
[Question 6]: Does MobileIMSDK support clusters?
MobileIMSDK does not support clusters currently (later versions have plans to support clusters ). Theoretically, when using MobileIMSDK for chat apps, a single machine can load up to 100,000 online at the same time. It can be used in Push scenarios and up to 10 million levels. If your application can reach this load limit, the total number of users is at least one million or even tens of millions. I believe that all technical problems will no longer be a problem. In any case, the single-host capacity of any similar technology will have a neck. For higher load and better scalability, clusters in large applications are of course necessary choices. MobileIMSDK Pressure Test Report: click here to view.
[Question 7]: Does MobileIMSDK support the TCP protocol?
Not Supported currently. At the beginning of the design, the MobileIMSDK fully considered the Network Complexity and unreliable characteristics of the mobile Internet, and finally chose to implement it using the UDP protocol. At present, there is no special reason to support the TCP protocol, of course, if you have good suggestions and ideas, you are welcome to exchange and discuss them.
[Question 8]: Does the MobileIMSDK support logging on to multiple devices with the same user name?
Theoretically, the MobileIMSDK communication does not depend on the user name (the server will assign a unique ID for each login client). Therefore, the communication will not be affected when the same user name logs on to different clients, however, the specific implementation depends on the application layer for processing.
[Question 9]: Does the client have a heartbeat mechanism in the background? Why do we need a heartbeat mechanism?
The MobileIMSDK client has a strong heartbeat mechanism in the background. The main purposes of the heartbeat mechanism are as follows:
Objective ①: to refresh the UDP port aging time of a NAT route
In typical cases, the UDP port aging time in the NAT routing algorithm of the vendor is about 300 seconds (of course, the specific value is defined by the wireless ISP or your home router manufacturer, in many cases, this time may be shorter). If there is no heartbeat mechanism, your client will no longer receive messages due to the aging of the UDP port. This is obviously not a problem with MobileIMSDK. It is determined by the NAT routing algorithm of the gateway device.
Objective 2: To tell the server that your client is still "alive"
Because of the no-connection feature of UDP, the heartbeat mechanism is a direct and effective solution for refreshing the online list of the server.
Objective 3: To check whether the client is still in the "normal communication" status
There are many factors that make the client and the server unable to communicate with each other, and it is difficult to judge with limited and simple code. For example, when your mobile phone is connected to your home WiFi, the WiFi connection is normal, but at this time, your broadband connection cannot be accessed due to overdue payment or other reasons, if there is no heartbeat mechanism, your APP will think that the network is normal, but it will not be able to send and receive data, because it will not be able to access the network.