Re: Stale c2s connection leads to loosing messages without any notice
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
Stale c2s connection leads to loosing messages without any notice
Hello everyone, Let me describe a behaviour of chrome.pl XMPP server which I believe to be erroneous. Observed with Psi and Pidgin. Let's start with 2 registered users, for example Alice and Bob; they are mutually authorized and both online so they see each other as "available" in their XMPP clients. 1. Now, Bob's XMPP client gets suspended - either because Bob suspended his computer running Linux, or because his machine just locked up. 2. Alice still sees Bob as "available" and sends him a message. 3. From Alice's point of view the message has been successfully delivered (no error message) and Bob is still online. She may continue sending messages. 4. After some long time (minutes) finally some timeout occurs and Bob's perceived state changes to "offline". 5. Bob logs in again. 6. Bob never receives the messages Alice sent him in steps 2&3. 7. Alice doesn't get any notification that server failed to deliver her messages to Bob. 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. If that's impossible due to very long timeout, then the messages should still be kept in storage unless client acknowledges their receipt, so Bob should be able to receive them after step 5. Or, at least, Alice should get "undelivered message" errors in step 4 - when server finally notices that Bob's connection is stale. What do you think? Sadly, with the current approach the communication is simply unreliable. --
