1, the introduction
I haven’t written technical articles for a long time. Today, this article is not the original rational article, but to share with you the whole process of upgrading and transformation of the IM instant messaging chat system developed and implemented by the author, which is aimed at the user experience problems caused by a large number of offline messages (including message roaming).
In this article, I will introduce it from the following aspects:
- 1) Main business and features of this IM product;
- 2) IM system business status and pain points;
- 3) Road of upgrading;
- 4) Optimization of message ACK logic.
The following content is based on my personal experience of developing IM summed up down the valuable experience, dry goods full, looking forward to your praise.
Learning and communication:
– Im/Push technology development communication group 5:215477170 [Recommended]
– Mobile IM Development primer article: Just one Primer: Developing Mobile IM from Scratch
This article has been simultaneously published in the “instant Messaging technology circle” public account, welcome to pay attention to:
Bring this article public links are: mp.weixin.qq.com/s/XHdt1IpCr… The original link is: www.52im.net/thread-3036…
2, IM development of dry goods series articles
This article is the 25th in a series of articles with the following table of contents:
Realization of IM Message Delivery Guarantee Mechanism (I) : Ensuring reliable Delivery of Online Real-time Messages
Realization of IM Message Delivery Guarantee Mechanism (II) : Ensuring reliable Delivery of offline Messages
How to Ensure “timing” and “consistency” of IM Real-time Messages?
Should I Use “Push” or “pull” to synchronize online status in IM Chat and Group chat?
IM group chat messages are so complex, how to ensure that not lost and not heavy?
Discussion on the design and Implementation of an Android IM Intelligent Heartbeat Algorithm (with sample code)
How to Save Traffic by Pulling Data during IM Login on mobile Terminal?
Easy to Understand: Load Balancing Solution Sharing based on Cluster for Mobile TERMINAL IM Access Layer
Brief Introduction to multi-point Login and Message Roaming principle of MOBILE TERMINAL IM
Understanding the Principles of the Pre-HTTP SSO Single Sign-on Interface
How to Design a server storage Architecture for a large number of image files?
Fundamentals of IM Development (iii) : Quick Understanding of server Database read/Write Separation principles and Practical Suggestions
Understanding cookies, Sessions, and Tokens in HTTP Short Connections
How to Implement the Read Receipt function of IM Group chat Messages?
Should IM group chat messages be saved in one copy (spread read) or in multiple copies (spread write)?
IM development basics tutorial (5) : Easy to understand, correctly understand and use MQ message queue
Discussion on a Low-cost Method to Ensure IM Message timing
IM development basic knowledge supplement lesson (six) : database use NoSQL or SQL? Read this article is enough!
What is the implementation principle of the “nearby people” function in IM? How to implement it efficiently?
Basic KNOWLEDGE of IM Development (7) : Principle and Design Idea of mainstream Mobile Terminal Account Login Method
“IM development basics tutorial (eight) : The most popular in history, thoroughly understand the nature of character garbled problem”
How to realize the scan code login function of IM? Understand the principle of scan code login technology of mainstream applications.
IM to do mobile phone scan code login? First look at the technical principle of wechat scan code login function
IM development basics tutorial (9) : Want to develop IM cluster? First understand what is RPC!
IM Development: How I Solved the problem of client Lag caused by a Large number of offline chat messages
In addition, if you are new to IM development, it is highly recommended that you first read just getting Started: Developing Mobile IM from Scratch.
3. Main business and features of this IM product
Different from the traditional Internet industry, the company I work for (whose name will not be revealed) is an entertainment social app company, including small games, chat, friends feed and so on.
We all have the experience that game business is fundamentally different from e-commerce, tourism and other industries in terms of technology and product form.
Most of my friends in back-end development are developing interfaces. The client or browser H5 sends HTTP requests to the Controller interface of our back-end, and the back-end searches the database and returns JSON to the client. As we all know, HTTP protocol has the characteristics of short connection, stateless, three handshake and four wave. Services such as games and real-time communications are not well suited to HTTP.
Here’s why:
- 1) HTTP cannot achieve the effect of real-time communication, so client polling can be used, but it is too wasteful of resources;
- 2) Three-time handshake and four-time wave have serious performance problems;
- 3) Stateless.
For example, when two users chat through an App, one side sends a message, and the other side senses its arrival in real time. When two or more people play a game, players need to see each other’s status in real time, which is impossible with HTTP! This is because HTTP can only pull, whereas chat and game businesses need to push.
4. IM system business status and pain points
4.1 Service Status
The author is in charge of the real-time chat system of the whole company, similar to wechat and QQ, with private chat, group chat, messaging, voice pictures, red envelopes and other functions.
Now LET me explain in detail how the whole chat system works.
First of all, in order to achieve the effect of real-time communication, we developed a set of long link gateway based on Netty. The protocol used is MQTT. App connects to gateway (NettyServer) through MQTT when the client logs in, and then pushes the chat messages to NettyServer through MQTT. NettyServer maintains a long link with NettyClient, which is used to process business logic (such as sensitive word interception, data verification, etc.). Finally, the message is pushed to NettyServer, and then pushed to the client by NettyServer through MQTT.
Secondly: if the client and server want to communicate normally, we need to develop a unified protocol. Take chat as an example. If we want to chat with each other, we need to locate each other’s Channel (equivalent to a socket in Netty) through uid and other information to send the message to the correct client. At the same time, the client must use the data in the protocol (UID, groupId, etc.). Display messages in private or group conversations.
The main fields in the protocol are as follows (we encode data intoprotobufFormat for transmission) :
{
“cmd”:”chat”,
“time”:1554964794220,
“uid”:”69212694″,
“clientInfo”:{
“deviceId”:”b3b1519c-89ec”,
“deviceInfo”:”MI 6X”
},
“body”:{
“v”:1,
“msgId”:”5ab2fe83-59ec-44f0-8adc-abf26c1e1029″,
“chatType”:1,
“ackFlg”:1,
“from”:”69212694″,
“to”:”872472068″,
“time”:1554964793813,
“msg”:{
“Message “:” chat message”
}
}
}
Note: if you are not sure what the Protobuf format is, please read the Protobuf communication protocol in detail: code demonstration, detailed principle introduction, etc.
The main fields of the protocol are as follows:
If the client is offline, the server needs to store the sent messages in the offline message table. When the other client goes online next time, the server NettyServer pushes the offline messages to the client through a long link.
4.2 Business Pain points
With the rapid development of business and the increasing number of users, the number of groups created by users, the number of groups they join, the number of friends, and the increase of chat activity, a large number of offline messages are generated during the offline period of some users (especially for group chat, there are a lot of offline messages).
When the client goes online next time, the server pushes all offline messages to the client, causing the client to be stuck on the home page after login. In addition, the product needs to expand the number of group members (from the previous hundred to thousands of people, ten thousand people, etc.).
As a result, some clients are bound to be jammed due to a large number of offline messages after login, resulting in poor user experience.
I analyzed the reasons with my colleagues on the client side:
- 1) After user login, the server sends all offline messages in batches in a circular manner, resulting in a large amount of data.
- 2) When the client logs in to the home page, it needs to load not only offline messages, but also other initialization data;
- 3) Clients with different prices have limited data processing ability. When processing chat messages, they need to store the messages in the local database, refresh the UI interface, and reply to the server ACK message. The whole process is very performance consuming.
(Thankfully, online messaging currently has no performance issues).
Therefore, in view of the above problems, combined with the broad planning of the product for IM system, we decided to optimize the offline message server (slightly joking, the client processing capacity is not enough, why should the server do optimization? Server performance is far from bottoming out…) .
5. Upgrading and transformation
Fortunately, the author participated 100% in the whole process of the system optimization, including the technology selection, scheme formulation and the final code writing. During this period, the author thought out a variety of solutions, and then discussed with the server and client colleagues, and finally decided on a stable solution.
5.1 Scheme 1 (One scheme that was passed)
The main cause of client login delay is that the server forces a large number of offline messages to the client. After receiving the offline messages, the client replies to the server ACK, saves the messages to the local database, and refreshes the UI. Client feedback, even if the client is asynchronous, there will be serious performance problems.
Why does the client reply to the server ACK after receiving the message without storing the data in the database? It’s very likely that the storage will fail, which is inherently irrational, for one thing. Second, the server is forced to push the client to a standstill, not caring about the processing capacity of the client, unreasonable.
int max = 100;
// Read from the new library
while(max > 0) {
List<OfflineMsgInfo> offlineMsgListNew = shardChatOfflineMsgDao.getByToUid(uid, 20);
if(CollectionUtils.isEmpty(offlineMsgListNew)) {
break;
}
handleOfflineMsg(uid, offlineMsgListNew, checkOnlineWhenSendingOfflineMsg);
max–;
}
Since it is unreasonable to push it forcefully, we can change it to another way. According to the processing capacity of different models of clients, the server uses different speeds to deliver.
We can think of the whole process as a producer-consumer model, where the server is the message producer and the client is the message consumer. After receiving the ACK message, the client stores the message in the local database, refreshes the UI, and then sends an ACK message to the server. After receiving the ACK message, the server pushes the next batch of messages.
In this way, the message delivery speed is based on the processing capability of the client and is delivered in batches. But this is still push.
However, the ideal is full, the reality is very skinny.
For this scenario, the client asks some questions:
- 1) In this scheme, the client will not be stuck, but if the current user has too many offline messages, it will take a long time to receive all offline messages;
- 2) The client will refresh the interface every time it receives a message. It is very likely that the interface will jump up and down.
So, the plan was rejected…
5.2 2
Since the amount of data being pushed is so large, can we load it on demand? The server delivers offline messages to the client when the client needs to read them. The server does not deliver offline messages when the client does not need to read them.
1) We added the concept of offline message counter: each session of each user, the metadata of unread messages (including the number of unread messages, the last unread message, timestamp, etc.), this counter is used for the client to display the red bubble of unread messages. This data is incremental and only the message metadata received during the offline period is retained.
The message format is as follows:
{
“sessionId1”:{
“count”:20,
“lastMsg”:[
“Last N messages.”
].
“timestamp”:1234567890
},
“sessionId2”:{
}
}
2) Every time the client logs in, the server does not push the full offline message, but only pushes the offline message counter (this part of data is stored in Redis and the data volume is very small). This number of users is displayed in the red dot of unread message list on the client.
3) The client takes the offline message counter data, iterates through the session list, increments the number of unread messages successively (note: it is not overwrite, the server saves the incremental data after the client goes offline), and then notifies the server to empty the incremental data of the offline message counter.
4) When the client enters a session, it sends the HTTP request to the server through the msgId and other information of the message during the pull-up loading, and the server returns the offline message to the client after paging.
5) After receiving the message and saving it in the local database, the client sends an ACK to the server, and then the server deletes the offline message in the offline message table.
The client and server technicians approve the solution. By combining push and pull, we solve the problem of client loading offline message lag. (Before the transformation is a strong push, after the transformation, the combination of push and pull)
The flow chart is as follows:
Although the scheme was passed, it caused a new problem: the client message connection problem.
The problem is described as follows: After the client logs in to the session page, the client itself saves historical messages. When the client drops down to load new messages, how do I determine whether to load local historical messages? Or do you want to ask the server to load an offline message?
After some consideration, the server and client finally agreed on a solution:
- 1) In the red dot logic of the unread message counter, the server will send the last N messages of each session to the client together;
- 2) When the client enters the session, it will display the home page data according to the latest N messages of the unread message counter;
- 3) Each time when the client pulls down the load, it requests the server, and the server reverts the offline message to the last offline message of the current session, until all the data in the offline message library is returned to the client;
- 4) When there is no offline message in the offline message library, an identifier is returned to the client. According to this identifier, the client does not request the offline message of the server in the next drop-down load of the session page, but directly requests the local database.
6. Optimization of message ACK logic
Finally, we also optimized the logic of the message ACK.
Before optimization: The server uses the push model to push messages to the client, whether online messages or offline messages, the LOGIC of ACK is the same, which also uses kafka, Redis and other middleware, the process is very complex (I will not expand the specific process of ACK here, anyway, not reasonable).
Offline messages differ from online messages in that we do not store online messages, whereas offline messages are stored in a separate library. It is not necessary to use the ack logic of online messages to process offline messages. It is not only a problem in the process, but also a waste of kafka, Redis and other middleware performance.
After optimization: We and the client decide to send the msgId or message offset of the last batch of offline messages to the server every time the offline message is loaded down. The server directly deletes the offline messages sent to the client from the offline library according to the msgId, and then returns the next batch of offline messages to the client.
In addition: We also added message roaming function, users can still check the history of the message after switching mobile phone login, this part of the content I will not expand to you in detail.
7. Document screenshots during the design of optimization scheme (for reference only)
The following is a screenshot of the optimized scheme document for your reference.
Appendix: Summary of more IM development related articles
[1] IM Development
Just one Beginner: Developing Mobile IM from Scratch
Mobile IM Developers must Read (1) : Easy to Understand the “weak” and “Slow” mobile Web
Mobile IM Developers must Read (ii) : Summary of the Most Complete Mobile Weak Network Optimization Methods ever
“Message Reliability and Delivery Mechanism of Mobile IM from client’s Perspective”
Summary of Optimization Methods for Short Connections in Modern Mobile Networks: Request Speed, Weak Network Adaptation, and Security Guarantee
Tencent Technology Sharing: The Evolution of Bandwidth Compression technology for Social Network Pictures
Session and Token in HTTP Short Connections
Fundamentals of IM Development: Understanding the Principles of the Pre-HTTP SSO Single Sign-on Interface
How to Ensure the Efficiency and real-time performance of Mass Group Message Push in MOBILE TERMINAL IM?
Technical Issues facing MOBILE IM Development
Is it better to design your own protocol using byte streams or character streams to develop IM?
Does anyone know the mainstream implementation of voice mail chat?
Realization of IM Message Delivery Guarantee Mechanism (I) : Ensuring reliable Delivery of Online Real-time Messages
Realization of IM Message Delivery Guarantee Mechanism (II) : Ensuring reliable Delivery of offline Messages
How to Ensure “timing” and “consistency” of IM Real-time Messages?
Discussion on a Low-cost Method to Ensure IM Message timing
Should I Use “Push” or “pull” to synchronize online status in IM Chat and Group chat?
IM group chat messages are so complex, how to ensure that not lost and not heavy?
Optimizing login Requests for Mobile IM Development
How to Save Traffic by Pulling Data during IM Login on mobile Terminal?
On the Principle of Multi-Point Login and Message Roaming in MOBILE IM
How to design a “Retry Failure” mechanism for a completely self-developed IM?
Easy to Understand: Load Balancing Solution Sharing based on Cluster for Mobile TERMINAL IM Access Layer
Technical Experiment and Analysis of wechat’s Influence on Network (Full paper)
“Principles, Technologies and Applications of Instant Messaging Systems” (Technical Paper)
The State of Open Source IM Project “Mogujie TeamTalk” : An Open Source Show that Never Ends
QQ Music Team share: Android image compression technology in detail (Part 1)
QQ Music Team share: Android image compression technology in detail (Part 2)
“Tencent original Sharing (I) : How to greatly improve the mobile QQ picture Transmission speed and success rate under the Mobile Network”
“Tencent original Sharing (II) : How to greatly reduce APP traffic Consumption in mobile Network (PART I)”
Tencent original Sharing (iii) : How to greatly reduce APP traffic Consumption under mobile Network (Part II)
As promised: Mars, a cross-platform component library of mobile IM Network layer for wechat’s own use, has officially opened source
How does Social Networking Yelp achieve lossless compression of massive user images?
Tencent technology Sharing: How Tencent dramatically reduced bandwidth and Network traffic (picture compression)
Tencent Technology Sharing: How Tencent dramatically reduced bandwidth and Network traffic (Audio and video technology)
The Character Coding Thing: A quick understanding of ASCII, Unicode, GBK, and UTF-8
Fully master the features, performance and tuning of mainstream picture formats on mobile terminals
Behind bullet SMS: The chief architect of netease Yunxin shares the technical practice of 100-million-level IM Platform
IM development basics tutorial (5) : Easy to understand, correctly understand and use MQ message queue
Wechat Technology Sharing: Practice of Generating Serial number of wechat’s Massive IM Chat Messages (Part of Algorithm Principle)
From the development of IM is so difficult? Hand to hand teach you from a Simple Andriod version OF IM (source)
Rongyun Technology Sharing: Decoding the Chat Message ID Generation Strategy of Rongyun IM Products
IM development basic knowledge supplement lesson (six) : database use NoSQL or SQL? Read this article is enough!
For beginners: Developing an IM Server from Scratch (Netty based, complete source code available)
Pick up the Keyboard and do it: Develop a Distributed IM System with my Hands
“Suitable for beginners: A Hands-on guide to Quickly Build high-performance, extensible IM Systems with Go (source code)”
What is the implementation principle of the “nearby people” function in IM? How to implement it efficiently?
Basic KNOWLEDGE of IM Development (7) : Principle and Design Idea of mainstream Mobile Terminal Account Login Method
“IM development basics tutorial (eight) : The most popular in history, thoroughly understand the nature of character garbled problem”
Is the IM “Scan” function easy to do? Look at the complete technical implementation of wechat “scan the content”
How to realize the SCANNING code Login function of IM? Understand the principle of scanning code Login technology of mainstream Applications.
IM to do mobile phone scan code login? First look at the technical principle of wechat scan code login function
IM Message ID Technical Topic (I) : Wechat’s Massive IM Chat Message Serial Number Generation Practice (Algorithm Principle)
IM Message ID Technical Topic (2) : Wechat’s Massive IM Chat Message Sequence Number Generation Practice (Disaster Recovery Solution)
IM Message ID Technical Topic (3) : Decoding the Chat Message ID Generation Strategy of Rongyun IM Products
“IM Message ID Technical Topic (4) : Deep Decryption of Meituan distributed ID Generation Algorithm”
IM Message ID Technical Topic (5) : Technical Implementation of Open Source Distributed ID Generator UidGenerator
IM Development Bible: The most complete collection of Wechat function parameters and logic Rules in history
IM Developer: How I Solved the problem of client lag caused by a Large number of offline chat messages
>> More similar articles……
[2] IM group chat
Fast Fission: Witness the Evolution of wechat’s Powerful Background Architecture from 0 to 1 (I)
How to Ensure “timing” and “consistency” of IM Real-time Messages?
Should I Use “Push” or “pull” to synchronize online status in IM Chat and Group chat?
IM group chat messages are so complex, how to ensure that not lost and not heavy?
Wechat Background Team: Practice Sharing on optimization and Upgrade of wechat Background Asynchronous Message Queue
How to Ensure the Efficiency and real-time performance of Mass Group Message Push in MOBILE TERMINAL IM?
Discussion on Synchronization and Storage of Chat Messages in Modern IM System
Discussion on the Disorder of GROUP Chat messages in IM Instant Messaging
How to Implement the Read Receipt function of IM Group chat Messages?
Should IM group chat messages be saved in one copy (spread read) or in multiple copies (spread write)?
Design practice of a set of highly available, Scalable and Concurrent IM Group chat and Single Chat Architecture
Is it technically possible to pull 1.4 billion Chinese into a wechat group?
IM group chat mechanism, besides circular to send messages, what other ways? How to optimize?
Netease Cloud Communication Technology Sharing: Practical Summary of The Technical Solution of 10,000 People Chat in IM
Ali Dingding Technology Sharing: The King of Enterprise-level IM — The Excellence of DingDing in back-end Architecture
>> More similar articles……
[3] Articles on IM Architecture design:
Brief Discussion on IM System Architecture Design
The Pits of Mobile IM Development: Architectural Design, Communication Protocols, and Clients
Sharing of mobile TERMINAL IM Architecture Design Practice of a Set of Massive Online Users (with detailed pictures and texts)
Theoretical Architecture Scheme of an Original Distributed Instant Messaging (IM) System
From Zero to Excellence: Evolution of The Technical Architecture of JINGdong Customer Service Instant Messaging System
Architecture Selection for Mogujie INSTANT Messaging /IM Server Development
Technical Challenges and Architecture Evolution PPT of Tencent QQ140 million Online Users
Design Practice of Massive Data Cold and Hot Classification Architecture Based on Time Order in wechat Background
“Wechat Technical Director on Architecture: The Way of wechat — Avenue to Simplicity (Full speech)”
How to Interpret wechat Technical Director’s Talk on Architecture: The Way of wechat — The Road to Simplicity
Fast Fission: Witness the Evolution of wechat’s Powerful Background Architecture from 0 to 1 (I)
17 Years of Practice: Technical Methodology of Tencent’s Massive Products
How to Ensure the Efficiency and real-time performance of Mass Group Message Push in MOBILE TERMINAL IM?
Discussion on Synchronization and Storage of Chat Messages in Modern IM System
How to Design a server storage Architecture for a large number of image files?
Fundamentals of IM Development (iii) : Quick Understanding of server Database read/Write Separation principles and Practical Suggestions
Understanding cookies, Sessions, and Tokens in HTTP Short Connections
WhatsApp Technology Practice: A Technology Myth Created by a 32-person Engineering Team
Summary of technical Challenges and Practices behind 100 billion visits to wechat Moments of Friends
Behind King of Glory’s 200 million users: Product Positioning, Technical Architecture, Network Solutions, etc.
Selection of MQ Messaging middleware for IM systems: Kafka or RabbitMQ?
Tencent Senior Architect Summary: Understanding the Design of large distributed Systems
Summary of architectural Design Steps of Massive Social System based on Microblog Application Scenarios
Quick Understanding of Load Balancing techniques for High-performance HTTP Servers
Behind bullet SMS: The chief architect of netease Yunxin shares the technical practice of 100-million-level IM Platform
Zhihu Technology Sharing: Redis High Performance Cache Practice Path from Single machine to 20 million QPS Concurrency
IM development basics tutorial (5) : Easy to understand, correctly understand and use MQ message queue
Wechat Technology Sharing: Practice of Generating Serial number of wechat’s Massive IM Chat Messages (Part of Algorithm Principle)
Wechat Technology Sharing: Practice of Generating serial Numbers of wechat’s Massive IM Chat Messages (Disaster Recovery Solution)
Getting Started: Understanding the Evolutionary History, Technical Principles, and Best Practices of Large Distributed Architectures with Zero Fundamentals
Design practice of a set of highly available, Scalable and Concurrent IM Group chat and Single Chat Architecture
Ali Technology Sharing: An in-depth insight into the 10-year History of Ali Database Technology Solutions
Ali Technology Sharing: The Arduous Growth of OceanBase, a financial database developed by Ali
“Social software red envelope technology decryption (I) : comprehensive decryption QQ red envelope technology scheme — architecture, technical implementation, etc.”
Decryption of Red Envelope Technology in Social Software (II) : The Technical evolution of Wechat Red Envelope Shaking from 0 to 1
Decryption of Red Envelope Technology in Social Software (3) : Technical details behind wechat’s Red Envelope Rain
Decryption of Social Software Red Envelope Technology (4) : How does wechat Red Envelope System cope with High Concurrency
Decryption of Social Software Red Envelope Technology (5) : How to Achieve high availability of wechat Red Envelope System
Decoding red Envelope Technology of Social Software (VI) : Evolution practice of Storage Layer Architecture of Wechat Red Envelope System
Decryption of Red Envelope Technology of Social Software (7) : Practice of Massive and High-concurrency Technology of Alipay Red Envelope
Decryption of Social Software Red Envelope Technology (8) : Comprehensive Decryption of Micro blog Red envelope Technology Scheme
Decryption of Red Envelope Technology in Social Software (9) : Talk about the functional logic, Disaster recovery, Operation and Maintenance, Architecture, etc.
Decryption of Red Envelope Technology in Social Software (10) : The Technical Practice of Hand-Q client for 2020 Spring Festival Red Envelope technology
Introduction to IM: What is Nginx and can it implement IM load balancing?
Getting Started with INSTANT Messaging: A Quick Understanding of RPC Technology — Basic Concepts, Principles, and Uses
Multi-dimensional comparison of 5 major Distributed MQ Message Queues: Mom no longer Worries about my Technology selection
From Guerrilla to Regular Army (1) : Evolution of IM System Architecture of Hornet’s Nest Tourism Network
From Guerrilla to Regular Army (II) : Summary of IM Client Architecture Evolution and Practice of Hornet’s Nest Tourism Network
IM development basic knowledge supplement lesson (six) : database use NoSQL or SQL? Read this article is enough!
Data Architecture Design of Guazi IM Intelligent Customer Service System (collated from the live speech, with accompanying PPT)
Ali Dingding Technology Sharing: The King of Enterprise-level IM — The Excellence of DingDing in back-end Architecture
From Guerrilla to Regular Army (III) : Technical Practice of Distributed IM System of Hornet’s Nest Tourism Network Based on Go
Design practice of a New generation of Massive Data Storage Architecture Based on Time Sequence in wechat Background
IM development basics tutorial (9) : Want to develop IM cluster? First understand what is RPC!
>> More similar articles……
(This article is simultaneously published at: www.52im.net/thread-3036…)