How tested is djabberd?

Brad Fitzpatrick brad at danga.com
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
games:

-- 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 magicdomain.com", 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