W dniu 28.09.2016, śro o godzinie 15∶15 +0200, użytkownik Deweloper napisał: > IMHO in step 2 server should notice an error sending message to Bob > (detect stale connection), change it's state to "offline" and store > the message for further delivery.
By design how TCP works, it is possible to detect a broken connection only by writing to that connection. And one write is not enough, because it will succeed even on half- closed connections, as the bytes are passed to network buffers and sent over the wire successfully. > If that's impossible due to very long timeout, then the messages > should still be kept in storage unless client acknowledges their > receipt, Unfortunately, there is no such feature built into XMPP. If the message gets lost in transit, it is just gone. With no feedback. You need to do active, client side acking as in XEP-0184 [1]. And then it is the client responsibility to resend unacked messages. > Or, at least, Alice should get "undelivered message" errors in step 4 Also, no such feature in XMPP. The server has no way of knowing whether the message reached the destination, without active recipient's application level cooperation. > > Sadly, with the current approach the communication is simply > unreliable. Unfortunately, this is how it is. TCP does not guarantee delivery [2] and so does not XMPP binding to TCP. [1] http://xmpp.org/extensions/xep-0184.html [2] http://lkml.iu.edu/hypermail/linux/kernel/0106.1/1154.html -- /o__ "Zaphod grinned two manic grins, sauntered over to the bar (_<^' and bought most of it."
signature.asc
Description: This is a digitally signed message part
