11

I experience a quite strange behavior using smack to build a small XMPP Client/Bot. I set up the connection as well as a ConnectionListener and a ChatManagerListener. This works quite fine and I can then chat with my application which is running on a portable device.

To test behavior on lost connection I plugged out the ethernet cable of the portable device. I expected the XMPP client to lose the connection and that the user will be set 'offline' in the roster of the users buddies. What happens is, that this user is still shown as 'online' and ConnectionListener of my client fires nothing, whether connectionClosed nor reconnectionFailed or else.

When I then plug the ethernet cable back in, sometimes it's like the connection has been alive all the time. The offline messages are handled and I can chat again like before. Other times my client is totally inaccessible and out of order, seems like all the listeners are gone... But no excpetions are thrown.

That's a quite strange and uncontrollable behavior that would make the whole client unusable for me, as I can't be sure that the client will come up again after connection has been arborted.

Has anybody else experienced such problems or has any hints what's (not) happening?

If needed I can provide my code, but it's actually just copy & paste from the Smack documentation.

Flow
  • 23,572
  • 15
  • 99
  • 156
signpainter
  • 720
  • 1
  • 7
  • 22

2 Answers2

8

You are actually describing two different effects here. Let's start with the one that's named in the title of your question: The user is assumed online by the server even if the connection is abruptly, and therefore unclean, aborted. The reason is simply that the server hasn't noticed the disconnect of the client yet, as there was no clean termination of the XMPP stanza stream. Most XMPP server check the clients with an ping every X minutes. If a client does not respond it's assumed disconnected and shown offline (if it was the last connected resource for that JID). That hasn't happened here and is not uncommon. Because sometimes you want to have long timeouts (half an hour or longer).

The same applies to the other side. Smack also sends XMPP pings every X minutes if PingManager or PingManagerWithAlarmManager (for Android) is used. If there is any problem with the used socket, an exception is thrown.

I hope that I could point you into the right direction. You have to debug for yourself why the connection is not terminated with an exception in your case.

One last thing: An TCP connection can easily survive some timeout even if the Ethernet cable is plugged out and then back in. There are many timeouts on various layers of the OSI model involved: NAT, TCP, XMPP, etc.

Flow
  • 23,572
  • 15
  • 99
  • 156
  • Thanks for the clarifications, they might help me. Perhaps I will be more patient and wait more than 1-2 minutes before plugging in the cable again. Anyhow the problem of the listeners sometimes staying tuned and sometimes not is still some mystery. But I think I will open another question for that. – signpainter May 31 '12 at 21:30
  • 2
    I would like to add that this behaviour of TCP is not a bug, but a great feature that few people seem to appreciate. Not needing to reconnect and do the quite expensive XMPP stream setup saves you a lot of roundtrips. What you probably want is for the OS to tell you about loss, and resumption, of connectivity so that you can then check if the connection survived. If it did, run along as if nothing happened, otherwise reconnect. XEP-0198 reconnection is also awesome. – Zash Jun 01 '12 at 14:37
0

You have too explicitly use the disconnect() method to terminate your connection, otherwise the server will have to periodically ping you and realize you have gone offline

Flow
  • 23,572
  • 15
  • 99
  • 156
Vedant Agarwala
  • 18,146
  • 4
  • 66
  • 89