How WeChat Guarantees No Lost Messages: The Secrets of Reliable IM Delivery
This article explains the three types of IM packets—Request, Acknowledge, and Notify—illustrates the basic message flow between client and server, identifies reliability gaps such as lost notifications, and proposes an application‑level solution using acknowledgments, timeout‑driven retransmission, and message deduplication to achieve dependable delivery.
Message Types in IM Systems
IM protocols typically define three packet categories:
Request (R) : client‑initiated message sent to the server.
Acknowledge (A) : server’s response confirming receipt of a Request; each A corresponds to one R.
Notify (N) : server‑initiated notification delivered to the client.
Basic Message Delivery Process
A simple flow for sending a text like “hello” works as follows:
client‑A sends msg:R to the IM server.
The server replies to client‑A with msg:A to acknowledge receipt.
If client‑B is online, the server forwards msg:N to client‑B.
If client‑B is offline, the server stores the message for later delivery.
Problems with the Simple Flow
When client‑A receives msg:A, it only knows that the server has accepted the message; it cannot confirm that client‑B actually received it. In real‑world scenarios, the msg:N packet may be lost due to server crashes, network jitter, or client‑B crashes, leaving client‑A unaware of the final delivery status.
Application‑Level Reliability Mechanism
To guarantee delivery, an explicit acknowledgment cycle is added:
client‑B sends ack:R to the server after processing the original message.
The server replies with ack:A to client‑B.
The server then sends ack:N back to client‑A, confirming that client‑B has successfully received the message.
Handling Lost Packets and Retransmission
If client‑A does not receive ack:N within a predefined timeout, it retransmits the original msg:R. To manage multiple in‑flight messages, client‑A maintains a "waiting‑ack queue" and a timer for each entry. When the timer expires without receiving the corresponding ack:N, the message is resent with the same msgid.
Deduplication at the Receiver
Client‑B must discard duplicate messages that may arrive because of retransmissions. It does so by generating a unique msgid for each logical message, storing this identifier in the waiting‑ack queue, and ignoring any subsequent msg:R with the same msgid.
Key Takeaways
The system ensures reliable delivery through timeout, retransmission, acknowledgment, and deduplication mechanisms.
A single "hello" transmission consists of six packets: three in the forward direction (msg:R/A/N) and three acknowledgments (ack:R/A/N).
The waiting‑ack queue is essential for tracking unacknowledged messages and coordinating retries.
Absolute loss‑free, duplicate‑free delivery can only be guaranteed at the application layer, not at the lower network or system layers.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
ITPUB
Official ITPUB account sharing technical insights, community news, and exciting events.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
