|
|
|
|
|
|
by wusspuss
1524 days ago
|
|
|
>So with that said, I'm very interested in hearing any details you can provide about how to silently lose messages in modern XMPP. Clients involved, steps to reproduce, etc. Then we can produce actionable bug reports. Conversations, draugr.de, can't really say much on steps to reproduce - it worked reliably and then it didn't just yesterday, ironically just as I tried to send the article to a friend to check out. If I understand the two generals' problem correctly, there always is a way to silently lose messages, with any protocol, it's just that some approaches to not doing that are more reliable than others |
|
|
That's a bit overgeneralized.
A simple protocol for message delivery that will not silently fail: resend it (presumably with a unique identifier of some sort to avoid duplication), pessimisticly and loudly pointing out "failure" (really: ambiguity of delivery), until you get a reciept of delivery.
What the two generals problem points out for this protocol is:
1. the sender of the reciept won't be certain that said reciept was recieved
2. the message may be successfully sent before the sender realizes it
3. if communication is permanently severed, the sender may forever be uncertain if the message ever got through or not (but this can be messaged loudly and pessimistically to the end user)
This creates design problems for coordination of consensus for things like database transactions, but a chat client failing to alert to potentially undelivered messages is just bad, not merely running afoul of some fundamental law of information science.
Of course, it's always possible to successfully send and recieve reciept of a message, only for the recipient's server to suddenly catch on fire and explode before backups are made, thus permanently losing any record of said message, but that's more of a "two generals and an assassin" problem, outside the scope of the original thought experiment. It is also, hopefully, a rarer scenario than packet loss.