I'm diving into using WebSockets for the first time and I'm curious about the best strategies to make sure messages are reliably sent and received between the client and server without getting lost due to connection hiccups. I've thought about tagging each message with a unique ID and temporarily storing them until I get a confirmation back. My plan involves creating a Messenger class that maintains a map of messages using their unique IDs as keys. Each message would include the socket, payload, and a timer. When a message is sent, it's stored in the map, and if I receive a confirmation from the client, the message gets removed. If not, I'll resend it a set number of times before the connection is cut. Is this approach effective, or are there alternative methods I should consider?
2 Answers
You're on the right track with your idea of using unique message IDs! The important part is ensuring that the client sends back an acknowledgment so you know the message was received. Just remember, since WebSockets run over TCP, they'll manage some level of delivery assurance for you, but it might not be enough for "exactly once" delivery needs. If you really need that guarantee, consider looking into messaging systems designed for it, like AMQP or Kafka. They’ve got strong protocols for reliable message delivery.
What you're talking about is pretty similar to AMQP or Kafka style message delivery. The flow is: Client sends a subscribe request, then the server sends the message followed by the client sending an acknowledgment. I'd suggest checking out how those frameworks guarantee message delivery; they can give you some solid insights. Redis Streams can also help with managing message delivery semantics.
Thanks for the tips! I'll dig into those systems for ideas. Always good to learn from existing solutions!
How do you handle situations where the acknowledgment might get lost? Wouldn't that still be an issue?