Project

General

Profile

Client timeout?

Steffen Larsen
Added almost 5 years ago

Hi Guys,

I have scenario where I need to know the presence of clients of different users. I've made a groovy script which works fine, delivering me the presence of a bare JID (see code snippet):

@List conns = session.getActiveResources()

for (XMPPResourceConnection con: conns) {

        conns_str += "" + con.getJID() + " : " + con.getPresence() + " "

}@

I only have one small problem. When a client disconnects (by network error or something else faulty), I still see this resource as being available, because its waiting for a timeout.

So my question is:

  • Can I actively test if any of my active resrouces is really active and not disconnected (waiting for a timeout) - maybe do it by an XMPP ping?

  • Can I set the timeout? . I can see the property: c2s/max-inactivity-time[L]=86400 . But the timeout seems longer (like 10 minutes).

-Cheers!

/Steffen


Replies (31)

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 5 years ago

Tigase tests all the users' connections to detect a broken one. Usually it is able to detect client's disconnection very quickly. Could you please provide us with more details on the use case when you see disconnected user as online for a longer time?

Added by Wojciech Kapcia TigaseTeam almost 5 years ago

Steffen Larsen wrote:

  • Can I set the timeout? . I can see the property: c2s/max-inactivity-time[L]=86400 . But the timeout seems longer (like 10 minutes).

Steffen,

To add to what Artur has said - those broken connection can be detected either by adjusting os level settings (keepalive, etc.) because by default they can report broken connection after even a few hours (v. Linux settings for high load systems) or you can rely on Tigase build in watchdog mechnism (which seems that is currently involved in discovery of broken connections): --watchdog_delay

Added by Steffen Larsen almost 5 years ago

Hi Guys,

Sure.

My scenario:

User connects and gets avaialable with two clients:

user@mydomain/aaaa

user@mydomain/bbbb

I use my script, and I the two available presence, which is fine.

Then one of the clients (e.g. the bbbb resource) gets disconnects due to some network error or other disconnect..

Then when I use my script again I still get two available presence where I actually expected one (aaaa). The bbbb client timeout in about 5-10 minutes, which is far too long than expected and what I have ever seen earlier.

I haven't touched anything on the given linux system (only set the ulimit in the startup script and thats it). I am running on the latest stable (5.2.1).

-Cheers

/Steffen

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 5 years ago

The most important thing is in what case you experience such a long time 5-10 minutes before the server discovers disconnection? Could you provide us steps on how to replicate the situation so we could simulate it?

Added by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 5 years ago

You may want to try using Tigase XMPP Server 5.3.0-SNAPSHOT version as this daily released version contains improvements in disconnection detection algorithm.

Added by Steffen Larsen almost 5 years ago

Hi.

Artur: What more description do you want?..

A user (e.g. user1@mydomain.com/aaaa) connects with PSI on one computer. The same user connects with another client on another computer (with another resource of course, bbbb). Everyhting is fine and when I check the presence from the aaaa client I can see bbbb, which is fine. Then the client with resource bbbb disconnects due to network failure (wifi online for example), then user with resource aaaa is still able to see bbbb client, even though he is disconnected. And the bbbb client seems to be present for 5-10 minutes even though that client have no network.

Wojcick: Just skimmed the repository and can't really see any changes regarding that, can you point me to a revision?. Just want to see whats changed.

Something must have changed either to the watchdog or something around there, because before running version 5.2.x, my server seemed to pick up the disconnect very quickly.

-Cheers and have a nice sunday!

/Steffen

Added by Steffen Larsen almost 5 years ago

I can see some changes to the connectionManager here: https://projects.tigase.org/projects/tigase-server/repository/revisions/a5019c042eb3b5d5f5e65d42941270d81bbeaf32/diff/src/main/java/tigase/server/ConnectionManager.java . Thats what you are talking about Andrzej?

-Cheers!

/Steffen

Added by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 5 years ago

Most of changes leading to improvement are in following commit https://projects.tigase.org/projects/tigase-server/repository/revisions/f12d7d05527687398baa6301ff37e7c20f32c0f9 and they are on IO level rather than on ClientConnectionManager level.

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 5 years ago

Artur: What more description do you want?..

I am interested in how to break user's connection so the Tigase needs 5-10 minutes to discover the broken connection. I have run several different tests and usually Tigase disconnects broken connection right now. There are cases however, when Tigase cannot but, unfortunately there is almost nothing Tigase can do in such case.

As an example. When I use a Linux machine and connect it with ethernet cable, then run any XMPP client and connect over the network to Tigase XMPP Server, then if I unplug the ethernet cable, both the Tigase server and the XMPP client still think the connection is OK. Moreover, ALL network applications on the Linux machine think the network and their connections are OK. Apparently Linux does not report unplugged cable as network outage for an extended period of time. When I plug in the cable after a few minutes, all software (and the XMPP client) continue to send data on old connections.

This is one of the case, Tigase cannot discover broken connection for a prolonged period of time and there is really little we can do about it. However, I do not think this is a real problem because cases like are extremely rare.

Added by Steffen Larsen almost 5 years ago

Hi Artur,

I break the users connection by turning off the wifi of a tablet which I am using as one of the clients. Then on my other client (a laptop) I still can see its presence.

So it looks like your example by disconnecting the cable.. It should be the same at least. :-)

Cant I do an active XMPP ping from within my groovy script to see if the client is still there or anything else?

/Steffen

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 5 years ago

You can send a ping to a user from groovy script but you cannot get a response. This is generally not a good idea to ping users from a groovy script. It is not designed for that. Please consider a system with 200k online users connected to the server. Tigase has a built-in mechanisms to ping and monitor user connections, discover broken and react.

The default time of 10 minutes is scaled for large installations, otherwise, if the checking is more frequent you would get a server overloaded just by the connection checking task. And as I said, broken connections like this, in reality are very rare.

Added by Steffen Larsen almost 5 years ago

Hi Artur,

I do understand your points (I had the same thoughts). I just haven't noticed this long time out before now.

And you are right, it is not something that seems like a big problem, but it actually is when you are developing and using clients on a mobile set or tablets, where the wifi connection drops quite often, or people turn the wifi off.

BTW: is XEP-0198 (stream management) implemented on the server? and how do you enable it on the session manager?

-Cheers and thanks for the replies guys!

/Steffen

Added by Wojciech Kapcia TigaseTeam almost 5 years ago

Steffen Larsen wrote:

BTW: is XEP-0198 (stream management) implemented on the server? and how do you enable it on the session manager?

Yes, it is :

To enable Stream Management you need to add following line to etc/init.properties file to enable Stream Management processor in c2s component: c2s/processors[s]=urn:xmpp:sm:3

Added by Matthew M almost 5 years ago

I've also noticed the same issue. I tested this a while ago with the official tigase.im site. Two registered xmpp users connected to tigase.im via PSI or iChat (TCP connection). Then I unplug the network cable from one of the user's desktop. The other user will see the unplugged user green (online) for about another 10 to 15 minutes...

Added by Steffen Larsen almost 5 years ago

Yes so for my client its a problem, because I use presence as a part of a business logic.

So I am trying to lower the timeout from the server to the client.

So Andrzej, I was taking a look at the watchdog parameters:

--watchdog_delay

In the doc actually I can't see what unit it is. Is it milisecs, nano sec or just secs? :-)

Let us update that page.

Other than that Ive been trying to set it in a different ways:

cl-comp/watchdog_delay[L]=30000

cl-comp/watchdog_timeout[L]=60000

is the cl-comp defining the timeout between the cluster only then?

And like so:

c2s/watchdog_delay[L]=10000

c2s/watchdog_timeout[L]=10000

c2s/max-inactivity-time[L]=100

I assume that c2s is the correct way to do it. If I want to have a maximum of 1minute timout from the server to the client, before the server notices, what should the value be and which parameter should be set?

PS: Sorry for all the questions, but setting the TCP/IP stack (keep alive) is a no go because other stuff is running on the servers as well. :-)

/Steffen

Added by Wojciech Kapcia TigaseTeam almost 5 years ago

Steffen Larsen wrote:

In the doc actually I can't see what unit it is. Is it milisecs, nano sec or just secs? :-)

Miliseconds, I've updated the docs to include that bit :-)

Let us update that page.

What would you like to add there that is currently unclear?

c2s/watchdog_delay[L]=10000

c2s/watchdog_timeout[L]=10000

c2s/max-inactivity-time[L]=100

I assume that c2s is the correct way to do it.

Yes, this follows general configuration guidelines in Tigase - options prefixed with double dash are considered 'global' and per component configuration starts with /= where could be any component like c (please take a look at etc/config-dump.properties for full set of options).

If I want to have a maximum of 1minute timout from the server to the client, before the server notices, what should the value be and which parameter should be set?

Watchdogs are in milliseconds, max-inactivity is in seconds, hence if we want to run check (watchdog) every minute and verify that the client has been idle for more than a minute:

c2s/watchdog_delay[L]=60000
c2s/watchdog_timeout[L]=60000
c2s/max-inactivity-time[L]=60

Added by Steffen Larsen almost 5 years ago

Hi,

Perfect with the doc update. No the rest is pretty clear.. Also if you know about the TCP/IP keep alive params, they are pretty mappable. :-)

I'll try out the settings for the timeout, thanks so much for the help!

/Steffen

Added by Natale Vinto almost 5 years ago

Hi guys,

I found this information very useful about discovering broken connections, I got the unavailability of the disconnected user in the timeout set by watchdog settings. But trying to use xmpp instead of whitespace, I had a strange behaviour, all connected clients were disconnected.

Those are additional settings I put in default init.properties of the 5.3.0-SNAPSHOT-b3526 on linux 3.2

c2s/processors[s]=urn:xmpp:sm:3
c2s/watchdog_delay[L]=60000
c2s/watchdog_timeout[L]=60000
c2s/max-inactivity-time[L]=60
c2s/watchdog_ping_type=xmpp

The only which is different to linux high load settings suggested is

net.ipv4.tcp_retries2 = 3

Added by Natale Vinto almost 5 years ago

Hi,

sorry for previous posts, the first one was probably due system tcp params modified (clients were disconnected before 60 s) and the second one is a mistake while modify comment, is possible to delete it?

Anyway, I tried this configuration:

c2s/watchdog_delay[L]=60000
c2s/watchdog_timeout[L]=60000
c2s/watchdog_ping_type=xmpp

and I see a XEP-0199 every 2 minutes as it is, but it looks that any broken connection isn't ever recognized by the internal watchdog, am I missing something or is there any TCP strict parameter I should setup? I've used ones suggested in linux high performance from the documentation.

According to the documentation, watchdog_timeout should close any broken connection not responsive in the 60 s setup there. Am I misunderstood anything?

Bye

Added by Wojciech Kapcia TigaseTeam almost 5 years ago

How come you see ping every two minutes?

Are all connections disconnected (as in first message) or broken connections are not recognized (second one)? The former may suggest lack of response from the client hence the time of last transmission from the client is not updated and trigger disconnection.

Added by Natale Vinto almost 5 years ago

Hi,

I see ping every two minutes with those settings:

2014-05-27 11:28:10.949 [Watchdog - c2s]   ConnectionManager.writePacketToSocket()  FINEST: c2s@localhost/172.31.30.109_5222_10.0.0.181_38399, type: accept, Socket: ZLIB: TLS: c2s@localhost/172.31.30.109_5222_10.0.0.181_38399 Socket[addr=/10.0.0.181,port=38399,localport=5222], jid: northumberland@sub.domain.net/Smack, Writing packet: from=null, to=c2s@localhost/172.31.30.109_5222_10.0.0.181_38399, DATA=<iq type="get" from="sub.domain.net" to="northumberland@sub.domain.net/Smack" id="tigase-ping-4160"><ping xmlns="urn:xmpp:ping"/></iq>, SIZE=133, XMLNS=null, PRIORITY=NORMAL, PERMISSION=NONE, TYPE=get
2014-05-27 11:30:10.953 [Watchdog - c2s]   ConnectionManager.writePacketToSocket()  FINEST: c2s@localhost/172.31.30.109_5222_10.0.0.181_38399, type: accept, Socket: ZLIB: TLS: c2s@localhost/172.31.30.109_5222_10.0.0.181_38399 Socket[addr=/10.0.0.181,port=38399,localport=5222], jid: northumberland@sub.domain.net/Smack, Writing packet: from=null, to=c2s@localhost/172.31.30.109_5222_10.0.0.181_38399, DATA=<iq type="get" from="sub.domain.net" to="northumberland@sub.domain.net/Smack" id="tigase-ping-4164"><ping xmlns="urn:xmpp:ping"/></iq>, SIZE=133, XMLNS=null, PRIORITY=NORMAL, PERMISSION=NONE, TYPE=get
2014-05-27 11:32:10.958 [Watchdog - c2s]   ConnectionManager.writePacketToSocket()  FINEST: c2s@localhost/172.31.30.109_5222_10.0.0.181_38399, type: accept, Socket: ZLIB: TLS: c2s@localhost/172.31.30.109_5222_10.0.0.181_38399 Socket[addr=/10.0.0.181,port=38399,localport=5222], jid: northumberland@sub.domain.net/Smack, Writing packet: from=null, to=c2s@localhost/172.31.30.109_5222_10.0.0.181_38399, DATA=<iq type="get" from="sub.domain.net" to="northumberland@sub.domain.net/Smack" id="tigase-ping-4168"><ping xmlns="urn:xmpp:ping"/></iq>, SIZE=133, XMLNS=null, PRIORITY=NORMAL, PERMISSION=NONE, TYPE=get

then any broken connection is recognized within about 10 minutes, shoudn't rather enclose broken connection before, thanks to xep-0199 in watchdog?

Added by Wojciech Kapcia TigaseTeam almost 5 years ago

OK, one misconception is that the pinging will always occur every given delay time - this is only true if there wasn't any xmpp packet received (as opposed to whitespace ping witch operate on a lower level). Because it takes into account amount of time since last received xmpp packet then every other time (if the delay and timeout are exactly the same) the amount will be lower hence skipping sending another ping; one solution would be lowering the timeout value.

Added by Natale Vinto almost 5 years ago

Hi,

if I put a timeout set to 10s, I saw xmpp ping every minute but broken connections are not recognized until up to 10 minutes. I wonder what should be the average time for Watchdog to recognized broken connections with lower timeout and delay settings, and optimized global TCP settings.

One "brutal" approach would be to let clients xmpp ping every certain time and the put on the server max-inactivity-time to enclose suspected broken connection if the threshold is reached. But is not very scalable :)

Added by Wojciech Kapcia TigaseTeam almost 5 years ago

I've pushed small change to the repository that should force-close connection if there is any problem with sending ping packet. Will be available in next nightly.

Added by Natale Vinto over 4 years ago

Hi Wojciech,

I've tested it with latest nightly build 2014-06-18 and the broken connection discovery, with same watchdog configuration (timeout 10s, delay 60s), comes in about 17 minutes, as:

2014-06-19 11:04:35.782 [in_1-message-router]  MessageRouter.processPacket()  FINEST:   1. Packet will be processed by: sess-man@localhost, from=c2s@localhost/10.0.0.1_5222_10.0.0.2_52434, to=sess-man@localhost, DATA=<iq to="sess-man@localhost" id="de1069c6-255d-47e6-a7f0-cf37f0bed960" type="set" from="c2s@localhost/10.0.0.1_5222_10.0.0.2_52434"><command xmlns="http://jabber.org/protocol/commands" node="STREAM_CLOSED"><x xmlns="jabber:x:data" type="submit"><field var="user-jid"><value>northumberland@sub.domain.net/Smack</value></field></x></command></iq>, SIZE=347, XMLNS=null, PRIORITY=SYSTEM, PERMISSION=NONE, TYPE=set
2014-06-19 11:04:35.783 [in_5-sess-man]    SessionManager$SessionCloseProc.process()  FINEST: Executing connection close for: from=c2s@localhost/10.0.0.1_5222_10.0.0.2_52434, to=sess-man@localhost, DATA=<iq to="sess-man@localhost" id="de1069c6-255d-47e6-a7f0-cf37f0bed960" type="set" from="c2s@localhost/10.0.0.1_5222_10.0.0.2_52434"><command xmlns="http://jabber.org/protocol/commands" node="STREAM_CLOSED"><x xmlns="jabber:x:data" type="submit"><field var="user-jid"><value>northumberland@sub.domain.net/Smack</value></field></x></command></iq>, SIZE=347, XMLNS=null, PRIORITY=SYSTEM, PERMISSION=NONE, TYPE=set
2014-06-19 11:04:35.788 [in_0-message-router]  MessageRouter.processPacket()  FINEST:   Processing packet: from=sess-man@localhost, to=null, DATA=<presence xmlns="jabber:client" id="cPjr7-2" from="northumberland@sub.domain.net/Smack" to="kingrichard@sub.domain.net" type="unavailable"/>, SIZE=133, XMLNS=jabber:client, PRIORITY=PRESENCE, PERMISSION=NONE, TYPE=unavailable
2014-06-19 11:04:35.789 [in_0-message-router]  MessageRouter.processPacket()  FINEST:   2. Packet will be processed by: sess-man@localhost, from=sess-man@localhost, to=null, DATA=<presence xmlns="jabber:client" id="cPjr7-2" from="northumberland@sub.domain.net/Smack" to="kingrichard@sub.domain.net" type="unavailable"/>, SIZE=133, XMLNS=jabber:client, PRIORITY=PRESENCE, PERMISSION=NONE, TYPE=unavailable
2014-06-19 11:04:35.790 [in_0-sess-man]    SessionManager.processPacket()     FINEST:   Received packet: from=sess-man@localhost, to=null, DATA=<presence xmlns="jabber:client" id="cPjr7-2" from="northumberland@sub.domain.net/Smack" to="kingrichard@sub.domain.net" type="unavailable"/>, SIZE=133, XMLNS=jabber:client, PRIORITY=PRESENCE, PERMISSION=NONE, TYPE=unavailable
2014-06-19 11:04:35.791 [in_0-sess-man]    SessionManager.processPacket()     FINEST:   processing packet: from=sess-man@localhost, to=sess-man@localhost, DATA=<presence domain.netxmlns="jabber:client" id="cPjr7-2" from="northumberland@sub.domain.net/Smack" to="kingrichard@sub.domain.net" type="unavailable"/>, SIZE=133, XMLNS=jabber:client, PRIORITY=PRESENCE, PERMISSION=NONE, TYPE=unavailable, connection: XMPPResourceConnection=[user_jid=kingrichard@sub.domain.net/iMac-di-Bluesman, packets=68, connectioId=c2s@localhost/10.0.0.1_5222_10.0.0.2_51661, domain=sub.domain.net, authState=AUTHORIZED, isAnon=false, isTmp=false]
2014-06-19 11:04:35.793 [in_5-sess-man]    SessionManager.closeSession()      FINE:     Closing connection for: northumberland@sub.domain.net/Smack
2014-06-19 11:04:35.794 [in_5-sess-man]    SessionManager.closeSession()      FINE:     Found parent session for: northumberland@sub.domain.net/Smack
2014-06-19 11:04:35.794 [pool-10-thread-3]  ClientConnectionManager.xmppStreamClosed()  FINE: Service stopped, sending packet: from=c2s@localhost/10.0.0.1_5222_10.0.0.2_52434, to=sess-man@localhost, DATA=<iq to="sess-man@localhost" id="de1069c6-255d-47e6-a7f0-cf37f0bed960" type="set" from="c2s@localhost/10.0.0.1_5222_10.0.0.2_52434"><command xmlns="http://jabber.org/protocol/commands" node="STREAM_CLOSED"><x xmlns="jabber:x:data" type="submit"><field var="user-jid"><value>northumberland@sub.domain.net/Smack</value></field></x></command></iq>, SIZE=347, XMLNS=null, PRIORITY=SYSTEM, PERMISSION=NONE, TYPE=set
2014-06-19 11:04:35.794 [in_0-sess-man]    SessionManager.walk()              FINEST:   XMPPProcessorIfc: Presence (presence)Request: from=sess-man@localhost, to=sess-man@localhost, DATA=<presence xmlns="jabber:client" id="cPjr7-2" from="northumberland@sub.domain.net/Smack" to="kingrichard@sub.domain.net" type="unavailable"/>, SIZE=133, XMLNS=jabber:client, PRIORITY=PRESENCE, PERMISSION=NONE, TYPE=unavailable, conn: XMPPResourceConnection=[user_jid=kingrichard@sub.domain.net/iMac-di-Bluesman, packets=69, connectioId=c2s@localhost/10.0.0.1_5222_10.0.0.2_51661, domain=sub.domain.net, authState=AUTHORIZED, isAnon=false, isTmp=false]
2014-06-19 11:04:35.796 [pool-10-thread-3]  StreamManagementIOProcessor.serviceStopped()  FINEST: c2s@localhost/10.0.0.1_5222_10.0.0.2_52434, type: accept, Socket: ZLIB: TLS: c2s@localhost/10.0.0.1_5222_10.0.0.2_52434 Socket[unconnected], jid: northumberland@sub.domain.net/Smack, service stopped - StreamManagement disabled
2014-06-19 11:04:35.797 [pool-10-thread-3]  StreamManagementIOProcessor.serviceStopped()  FINEST: c2s@localhost/10.0.0.1_5222_10.0.0.2_52434, type: accept, Socket: ZLIB: TLS: c2s@localhost/10.0.0.1_5222_10.0.0.2_52434 Socket[unconnected], jid: northumberland@sub.domain.net/Smack, service stopped - StreamManagement disabled
2014-06-19 11:04:35.797 [in_0-sess-man]    SessionManager.walk()              FINEST:   XMPPProcessorIfc: MessageAmp (amp)Request: from=sess-man@localhost, to=sess-man@localhost, DATA=<presence xmlns="jabber:client" id="cPjr7-2" from="northumberland@sub.domain.net/Smack" to="kingrichard@sub.domain.net" type="unavailable"/>, SIZE=133, XMLNS=jabber:client, PRIORITY=PRESENCE, PERMISSION=NONE, TYPE=unavailable, conn: XMPPResourceConnection=[user_jid=kingrichard@sub.domain.net/iMac-di-Bluesman, packets=69, connectioId=c2s@localhost/10.0.0.1_5222_10.0.0.2_51661, domain=sub.domain.net, authState=AUTHORIZED, isAnon=false, isTmp=false]
2014-06-19 11:04:35.797 [in_0-message-router]  MessageRouter.processPacket()  FINEST:   Processing packet: from=sess-man@localhost, to=c2s@localhost/10.0.0.1_5222_10.0.0.2_51661, DATA=<presence xmlns="jabber:client" id="cPjr7-2" from="northumberland@sub.domain.net/Smack" to="kingrichard@sub.domain.net" type="unavailable"/>, SIZE=133, XMLNS=jabber:client, PRIORITY=PRESENCE, PERMISSION=AUTH, TYPE=unavailable
2014-06-19 11:04:35.798 [in_0-message-router]  MessageRouter.processPacket()  FINEST:   1. Packet will be processed by: c2s@localhost, from=sess-man@localhost, to=c2s@localhost/10.0.0.1_5222_10.0.0.2_51661, DATA=<presence xmlns="jabber:client" id="cPjr7-2" from="northumberland@sub.domain.net/Smack" to="kingrichard@sub.domain.net" type="unavailable"/>, SIZE=133, XMLNS=jabber:client, PRIORITY=PRESENCE, PERMISSION=AUTH, TYPE=unavailable
2014-06-19 11:04:35.799 [in_0-c2s]         ClientConnectionManager.processPacket()  FINEST: Processing packet: from=sess-man@localhost, to=c2s@localhost/10.0.0.1_5222_10.0.0.2_51661, DATA=<presence xmlns="jabber:client" id="cPjr7-2" from="northumberland@sub.domain.net/Smack" to="kingrichard@sub.domain.net" type="unavailable"/>, SIZE=133, XMLNS=jabber:client, PRIORITY=PRESENCE, PERMISSION=AUTH, TYPE=unavailable
2014-06-19 11:04:35.799 [in_0-c2s]         ConnectionManager.writePacketToSocket()  FINEST: c2s@localhost/10.0.0.1_5222_10.0.0.2_51661, type: accept, Socket: ZLIB: TLS: c2s@localhost/10.0.0.1_5222_10.0.0.2_51661 Socket[addr=/10.0.0.2,port=51661,localport=5222], jid: kingrichard@sub.domain.net/iMac-di-Bluesman, Writing packet: from=sess-man@localhost, to=c2s@localhost/10.0.0.1_5222_10.0.0.2_51661, DATA=<presence xmlns="jabber:client" id="cPjr7-2" from="northumberland@sub.domain.net/Smack" to="kingrichard@sub.domain.net" type="unavailable"/>, SIZE=133, XMLNS=jabber:client, PRIORITY=PRESENCE, PERMISSION=AUTH, TYPE=unavailable

Is there any other setting I could try to speed up recognition?

(1-25/31)