Project

General

Profile

Tigase server doesn't know if TCP connection was failed

Keren Meir
Added about 5 years ago

Hi,

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?

Thanks


Replies (6)

Added by Wojciech Kapcia TigaseTeam 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

What about XEP-0079: Advanced Message Processing

Is this plugin will help to not losing IM ?

I Just take a look at the code of MessageAmp and it doesn't looks like it solves the problem (not losing IM) but as described in the link, I thought it does.

Added by Wojciech Kapcia TigaseTeam about 5 years ago

AMP is a bit different and doesn't involve client confirmation of delivering particular stanza. How exactly the specs support the notion that it could provide acknowledged of delivery of each stanza?

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam about 5 years ago

Indeed, AMP is for a bit different purpose and it does really not solve the message loss problem.

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'
           to='bernardo@hamlet.lit/elsinore'
           id='chatty2'>
    <amp xmlns='http://jabber.org/protocol/amp'
         status='alert'
         from='bernardo@hamlet.lit/elsinore'
         to='francisco@hamlet.lit'>
      <rule action='alert' condition='deliver' value='stored'/>
    </amp>
  </message>
Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam 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:

  1. 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)

  2. If for any reason the message is not delivered, there is no negative ACK or any other feedback

  3. There is no automated way to retry sending the message

  4. 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.

    (1-6/6)