4 ms·
The problem is that sometimes your application intends to send messages[0] multiple times. If your "log-and-discard" system was implemented naively then each no
by kmeisthax 2y ago
The problem is that sometimes your application intends to send messages[0] multiple times. If your "log-and-discard" system was implemented naively then each node could only ever send each possible message once and only once. Ever.
That would be like:
Alice: "Honey, where did you put the keys?"
Bob: "They're up on the counter."
(The next day...)
Alice: "Honey, where did you put the keys?"
Bob: (nothing, I already received this message, it could have echoed off the walls from yesterday)
What you need is for all sent messages to have unique IDs that will never repeat, and then log those. That's known as an idempotency token.
But even then, logging all those UUIDs forever is probably not a good idea for disk usage. At some point you'll have to trash old message logs and hope you don't have a rogue network router retransmitting six month old messages or something.
[0] Or the moral equivalent of messages, e.g. HTTP POST requests
- lisper 2y ago> What you need is for all sent messages to have unique IDs that will never repeat, and then log those. That's known as an idempotency token. So your problem is not really a problem because you yourself present the solution. The real problem is: > But even then, logging all those UUIDs forever But you don't need to log them all forever. Just make the UUIDs sequential, and all you need then is to keep track of the smallest id that has not yet been received. (You can be more efficient by storing more state, but it's not necessary. Remember, we're assuming at-least-once deliver here, so you can always force retransmission by not acknowledging receipt.)