[jdev] XMPP Ping/Keepalive: Recommended method ?

[JD Conley]

Sending a <presence/> to a server is probably the worst thing you could
possibly do for a keep-alive. J Aside from login and logout, and some
more complicated JEP's like MUC or PubSub, it's the most intensive
operation an XMPP server performs and in most cases causes multiple hits
to the back end database (whether that be a file or RDBMS) as well as a
cascading effect of network traffic to the set of contacts on the user's
roster. From the perspective of a server I'd much rather see a message
sent to yourself than presence announced. At the worst case this might
cause a single write to a persistent store for message archiving
purposes, vs. the presence overhead. I'd prefer time or version vs.
presence as well.

 

-JD

 

From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf
Of ennova2005-jabber at yahoo.com
Sent: Thursday, June 22, 2006 3:16 PM
To: ennova2005-jabber at yahoo.com; jdev at jabber.org
Subject: Re: [jdev] XMPP Ping/Keepalive: Recommended method ?

 

Assuming (for legacy reasons), the only injection point available in the
code for this uni-directional "keepalive" is a message or presence
packet, how "bad" is it to send a <presence /> to the server  (vs. say a
jabber:iq:version or jabber:iq:time) ?

Will most servers ignore this safely and will it be considered a no-op ?




----- Original Message ----
From: ennova2005-jabber at yahoo.com
To: jdev at jabber.org
Sent: Sunday, June 18, 2006 10:47:19 PM
Subject: [jdev] XMPP Ping/Keepalive: Recommended method ?

Given that the protocol itself does not seem to have a defined
keep-alive element, what is the recommended way for a client to keep its
connection alive to a XMPP server ?

Can someone provide an exact wire representation of the "space keep
alive" method that will not break current xmpp servers  ? ( I tried to
observe the debug output of a couple of popular xmpp clients without
much luck)

This is for an ad-hoc client that open a raw tcp socket and sends a few
things ( it is not using a full xmpp client library)   There is only one
instance of this client so we were otherwise thinking of using
jabber:iq:time or jabber:iq:version 

Are there other low overhead no-op packets we could be sending instead ?
At the moment I am interested only in sending some valid traffic for
this purpose (and not quite looking for  a valid response as long - as
it does not terminate the connection)

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20060622/ff6dfd87/attachment-0002.htm>