Read receipt
Last updated
Last updated
Using push is not appropriate due to the following:
If a group chat has over thousands of members (e.g. 2K), there will be 2K read receipts messages being sent. Sending 2K separate messages is high consumption for device battery and network bandwidth.
Sender only cares about read receipt when the sender is reading the message inside conversation. If the sender is doing other things on app, he does not care about read receipt.
Using pull is not appropriate due to the following:
If the pull interval is too big, update for read receipt will have high latency.
If the pull interval is too small, cost much bandwidth and power.
Combined approach
When a client opens a conversation and read the message with read receipt, it could start pulling read receipt from server.
At the same time, client subscribe to the message's read receipt.
Server receives the subscription request and start pushing.
Cons: Requires huge amount of resources on the server to support subscription.
Key observation: User only cares about read receipt
Approach
User1 send a message with read receipt. After other users (User2/3/.../N) read the messages, the read receipt is sent to and cached on the server.
When User1 reads the message with read receipt, client will proactively pull read receipt by:
When the user is reading the message with read receipt, within 20 seconds client pulls every two second.
If the user is no longer reading the message, then stop pulling.
References
