Backend Development 8 min read

Ensuring Reliable Message Delivery in Web IM Systems: The Six‑Message Ack Protocol

This article explains how web instant‑messaging systems achieve reliable, non‑lost and non‑duplicate message delivery by using a six‑message protocol (msg R/A/N and ack R/A/N), timeout‑based retransmission, and deduplication mechanisms.

Architect
Architect
Architect
Ensuring Reliable Message Delivery in Web IM Systems: The Six‑Message Ack Protocol

Message reliability—ensuring that messages are neither lost nor duplicated—is a core challenge in instant‑messaging (IM) systems. The article begins by noting that QQ’s success over ICQ stemmed from reliable message delivery and effective anti‑spam, and then focuses on the reliability aspect.

1. Message Types IM communication uses three packet types: request (R), acknowledge (A), and notify (N). R is sent from client to server, A is the server’s response to an R, and N is a server‑initiated packet to the client.

2. Normal Message Delivery Flow When user A sends “hello” to user B: (1) client‑A sends msg:R, (2) server replies with msg:A, (3) if client‑B is online, the server sends msg:N; otherwise the message is stored offline.

3. Problems with the Basic Flow The sender only knows that the server received the message (msg:A) but cannot confirm that client‑B received it (msg:N). Msg:N may be lost due to server crash, network jitter, or client‑B crash, leaving client‑A unaware of the delivery status.

4. Application‑Layer Ack and the Six‑Message Protocol To guarantee delivery, an application‑layer acknowledgment is added, mirroring TCP’s timeout, retransmission, and ack mechanisms. The full reliable delivery involves six packets: msg R/A/N and ack R/A/N. Only after receiving ack:N can client‑A be sure that client‑B got the message.

5. Issues with Reliable Delivery While msg:R/A loss can be reported as a send failure, loss of msg:N, ack:R, ack:A, or ack:N leaves client‑A without confirmation, requiring retransmission strategies.

6. Timeout and Retransmission If ack:N is not received within a timeout, client‑A retransmits msg:R and maintains a waiting‑ack queue with timers to track unacknowledged messages.

When ack:N arrives, the corresponding entry is removed from the queue.

7. Problems with Retransmission If msg:N is lost, retransmission works as intended. If ack:N is lost, client‑B may have already received the message, causing duplicate deliveries on the sender side.

8. Message Deduplication The sender generates a unique msgid for each message and stores it in the waiting‑ack queue; retransmissions reuse the same msgid so the receiver can discard duplicates.

9. Other Considerations - Client‑side retransmission keeps the server stateless. - For offline recipients, the server stores the message and fabricates an ack:N to the sender. - Offline pull also uses an ack mechanism (offline:R/A and offlineack:R).

10. Summary IM systems achieve reliable delivery through timeout, retransmission, acknowledgment, and deduplication, ensuring no loss or duplication. A single “hello” exchange consists of six packets: msg R/A/N and ack R/A/N.

Future topics may cover reliable delivery for group messages, which involve additional complexity.

backendIMMessage ReliabilityMessage DeliveryAck Protocol
Architect
Written by

Architect

Professional architect sharing high‑quality architecture insights. Topics include high‑availability, high‑performance, high‑stability architectures, big data, machine learning, Java, system and distributed architecture, AI, and practical large‑scale architecture case studies. Open to ideas‑driven architects who enjoy sharing and learning.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.