On 2021-06-01, Cameron Simpson <cs@cskk.id.au> wrote:
> If I had TCP keep alive turned on, both ends might tidy themselves up.
> I can't enable that on the clients (various mail readers) or,
> apparently, on the server configuration. I can't do it in PF because PF
> just copies packets. I can't seem to do it in relayd either, though that
> seems the obvious way to intercept the connection for this purpose.
It looks like courier-imap does enable SO_KEEPALIVE if available.
By default, keepalive timers are long; on a random Linux I had handy:
$ grep . /proc/sys/net/ipv4/tcp_keepalive_*
/proc/sys/net/ipv4/tcp_keepalive_intvl:75
/proc/sys/net/ipv4/tcp_keepalive_probes:9
/proc/sys/net/ipv4/tcp_keepalive_time:7200
7200s (2h) initially, then every 75 seconds. (OpenBSD default times are
long too; 14400 "slowhz" intervals = also 2h).
> Plan B is to build the latest courier-imap from source if I find the
> time, but there may be no build option for this. I guess a single
> setsockopt() call in the source would be enough, _if_ that can be done
> on the accept end, which I haven't checked.
https://tldp.org/HOWTO/TCP-Keepalive-HOWTO/addsupport.html but I don't think
you'll need it.
So you probably just need to lower tcp_keepalive_time, and perhaps adjust
tcp_keepalive_intvl. Note there is a tradeoff especially with mobile
clients; they will need to wake and transmit more often, so faster
keepalives will result in more battery/data use.
> Plan B0 might be to disable IMAP IDLE support. Hmm.
Depends on timings whether that will help; think it's a last ditch effort
though, I think it will make things noticably worse for clients.
No comments:
Post a Comment