| > there always is a way to silently lose messages 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. |