[jdev] XMPP Ping/Keepalive: Recommended method ?

Michal vorner Vaner michal.vaner at kdemail.net
Mon Jun 19 02:40:38 CDT 2006

On Mon, Jun 19, 2006 at 11:15:40AM +0400, Sergei Golovan wrote:
> On 6/19/06, Michal vorner Vaner <michal.vaner at kdemail.net> wrote:
> >On Sun, Jun 18, 2006 at 10:47:19PM -0700, ennova2005-jabber at yahoo.com 
> >wrote:
> >>    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 ?
> >
> >Since XML allows any number of whitespace between elements that is just
> >ignored, you can send a whitespace if you are not in the middle of
> >stanza. It will do, NATs and other beasts will see data flowing,
> The problem is that this "ping" is not a ping at all because it only
> sends data and does not expect reply.
> So, some NATs and proxies still break connection if they don't see
> bidirectional flow.

Then the thing is even more broken. That thing should be thrown out of
window and not expect software to work around its bugs.

Strictly speaking, in my opinion, NATs are disease and should be
exterminated, but that is another story.

> Another issue is that with this "ping" you can't control the
> connection. If TCP connection breaks (but before TCP timeout reaches -
> and it is a quite long timeout) both messages and "pings" goes to
> black hole and there's no way to work around this (to set some short
> internal timeout or whatever).
Theoretically, you should get some ICMP packet telling you the machine
is gone or the connection was closed. I know, the reality is different.

There is some work (I hope there still is) how to add stanza acking, so
you know when it does not get through.

If you really want some workaround, client can ping its server by
sending a stanza to its own JID. The server should take it and send back
like it is. I would prefer a <message> stanza containing some extension
I would make myself (maybe even undocumented, since you do not need
anyone to understand it and cooperate).

One semi-random fortune:

Einstein argued that there must be simplified explanations of nature, because
God is not capricious or arbitrary.  No such faith comforts the software
                -- Fred Brooks

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20060619/94a7d436/attachment-0002.pgp>

More information about the JDev mailing list