Tigase server doesn't know if TCP connection was failed
As I so, tigase-server doesn't know if a TCP connection through 3G or WiFi was failed. I have 2 connected users, one close his connection (move to airplane mode) and the second user still see him as online. In that time, if user1 sends IM to user2 (the one that is down), the IM lost - user2 doesn't get it ever if he re-connect.
Is there a way to save this IM? I mean - when user1 trying to send IM to user2, if Tigase is trying to write to the socket does he gets failure?
Added by Wojciech Kapcia about 5 years ago
This is quite old problem. Basically Tigase relies on underlying operating system to establish whether the socket is still available. As outlined in Linux settings for high load systems namely TCP_keepalive section, you can adjust Linux settings to increase reliability.
Another thing to look at is using
acks in XEP-0198: Stream Management
Added by Keren Meir about 5 years ago
I thought that by this alert I can get response for IM which can function as ack:
3.4.1 alert The "alert" action triggers a reply <message/> stanza to the sending entity. This <message/> stanza MUST contain the element <amp status='alert'/>, which itself contains the <rule/> that triggered this action. In all other respects, this action behaves as "drop". Example 7. Alert Response <message from='hamlet.lit' email@example.com/elsinore' id='chatty2'> <amp xmlns='http://jabber.org/protocol/amp' status='alert' firstname.lastname@example.org/elsinore' email@example.com'> <rule action='alert' condition='deliver' value='stored'/> </amp> </message>
Added by Artur Hefczyc about 5 years ago
This kind of ACK has only meaning that the message has been delivered and more or less when it was delivered. This is too little to ensure message delivery for a few reasons:
Lack of response does not mean that the message has not been delivered (the ACK itself could be lost, the user could be still offline)
If for any reason the message is not delivered, there is no negative ACK or any other feedback
There is no automated way to retry sending the message
Plus the AMP ACK comes from the server not from the other client software, which means the message could be lost on the network link between the server and other client and the original sender could still receive positive ACK because the server submitted the message for delivery.
Really the only way to have reliable communication is stream management extension plus packet receipts extension implemented.