How tested is djabberd?

Brad Fitzpatrick brad at
Mon Jul 3 20:36:54 UTC 2006

On Mon, 3 Jul 2006, Martin Atkins wrote:

> Karjala wrote:
> > Also, another problem I had with Jabberd v1 was when a modem user hanged
> > up his modem without closing down his jabber connection with the server
> > first, he would appear to be online (and all messages to him would get
> > lost) for around an hour. This was despite me having set some timeout
> > parameter in the config to one minute.
> >
> > Is DJabberd better at handling these cases?
> >
> >
>  From a quick read of the code (see DJabberd::Connection::ClientIn's
> close method if you are interested) DJabberd sends out an offline
> presence when a client disconnects.
> However, I think in the case you're describing the modem is
> disconnecting before the client completes the TCP shutdown, so the
> server can do little about this other than make use of the lack of
> keepalive packets. I'm not sure whether DJabberd ever times out
> connections... I certainly can't spot where it's tracking "last seen" times.
> The best way to detect a downed client, I think, is to just send it a
> packet containing just a space as clients do for keep-alive; that way,
> you'll probably get back either a Host Unreachable response or a TCP RST
> packet depending on whether another client has taken up the same IP
> address in the mean time. I don't think DJabberd currently does anything
> like this, either.

DJabberd doesn't do any idle client or server detection.  It needs to, and
is in the TODO.

I think we can do it in a spec-compliant way, though, without playing ugly

-- track last seen times per connections.

-- if no activity in a couple minutes (or configurable),
   then send an IQ packet to the client, asking it for something
   stupid that it should reply for, forcing it to answer.
   give it 5-10 seconds to answer, then boot it.

   We may have to fake where this IQ comes from
   ("keepalivecheck at", etc), but it should work.

Or, if over SSL, we could force a session regotiation, if I knew how to do
that, which would cause the client to speak.

But I just don't want to use TCP_KEEPALIVE crap:  not portable, and the
wrong way to handle this.  Also don't want to rely on writing a byte until
a buffer fills.  If we could write a single space and ask the TCP layer in
the OS if the remote side had ACKed that packet, that'd work, but that's
extremely non-portable, and I don't even know of a way to do that in
Linux, but I'd love it if anybody here knew.

- Brad

More information about the Djabberd mailing list