การรับรองข้อความและการรับประกันการส่ง

A message can be lost if the socket drops mid-send, the server crashes, or the client reloads before processing. Without acknowledgements, neither side knows it happened.

Three common guarantees:

• At-most-once: may lose, never duplicate
• At-least-once: never lose, may duplicate
• Exactly-once: never lose, never duplicate (hardest)

WebSockets only confirm transport delivery, not processing. To know a message was handled, the receiver must send an explicit ack back.

Tag each message with a unique id so acks can reference it.

The receiver replies with an ack carrying the original id once it has safely processed the message.

The sender keeps a map of in-flight messages until their ack arrives.

If no ack arrives within a timeout, resend the message. This is how at-least-once delivery is achieved.

Retries can deliver the same message twice (e.g. the ack was lost, not the message). At-least-once therefore implies the receiver may see duplicates.

Make processing idempotent: handling the same id twice has the same effect as once. Track seen ids and ignore repeats.

True exactly-once is impossible to guarantee end-to-end, but at-least-once delivery plus idempotent handling gives the same practical result, which is what most systems use.

Build reliable delivery:

• Tag messages with unique ids
• Require application-level acks
• Retry unacked messages with a timeout
• Make processing idempotent to absorb duplicates

You added delivery guarantees to realtime messaging:

• Understand at-most/at-least/exactly-once
• Use message ids and application-level acks
• Retry unacked messages
• Combine at-least-once with idempotency

Your system no longer silently loses messages.