Christof Meerwald <> writes:

> On Sun, Aug 28, 2016 at 02:13:34PM +0200, Tomasz Sterna wrote:
>> W dniu 27.08.2016, sob o godzinie 14∶55 -0400, użytkownik Greg Troxel
>> napisał:
>> >   should jabberd2 force TCP keepalive on?
>> I'm not sure whether it is possible.
>> At least on Linux it is a system-wide setting and requires root to
>> change.
> Are you sure? There appear to be some socket options that can be set
> for each socket:

I'm not running Linux, so we're talking more or less about what POSIX
specifies for the BSD sockets interface.  But, that page describes in
the SO_KEEPALIVE case exactly the traditional BSD socket option for
keepalive, which I suspect dates from about 4.2BSD but my memory of the
late 80s is now a bit fuzzy.

So yes, I meant to have a way to enable keepalive via SO_KEEPALIVE on
all sockets.  But that's not really the right thing.

Tomasz's point about Linux and system-wide setting is probably about
what the default value is if a program doesn't ask for keepalives. OS X
has a sysctl for this.  NetBSD doesn't; it's up to the program, as it
was historically.

On the system in question, it is surely behind a buggy firewall.
However, that's beyond my control.  It's interesting that this doesn't
show up, because I would expect the mobile to lose the data connection
and fail to close the TCP connection fairly often.

Arguably I have a system-wide problem, not a jabber problem.   But
still, given that clients just vanish, it seems like there should be
some mechanism for connections to get cleaned up.

I will check out the application-level keepalive.   What I think I want
is that for a connection from a client, if there has been no traffic in
or out for 24h, to send a space.  That will break the stale connections
after a day, and it should not cause any additional traffic on real
connections.  For now I can just send a keepalive every 24h, and that's
close enough.

Attachment: signature.asc
Description: PGP signature

Reply via email to