W dniu 28.09.2016, śro o godzinie 15∶15 +0200, użytkownik Deweloper
> 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

[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." 

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to