On 9/19/2016 10:02 PM, ellie timoney via Cyrus-devel wrote:
I've been looking at tcp_keepalive a bit lately and I'm wondering how it
interacts with this?
It's my understanding that, in most cases, tcp_keepalive will do the job
of detecting clients that have dropped out, and allow us to close the
connection on our end. Since we're generally either waiting for a
command from the client, or producing and about to send output to the
client, this works -- because if tcp_keepalive detects that the client
isn't there, reads and writes to the socket will start failing.
This is why KEEPALIVE is affectionately known as MAKEDEAD ;-)
But during the IDLE state, we only read from the client socket if select
reports it as having data ready for reading (presumably containing
"DONE"), and we only write to the client socket if there is activity on
the selected mailbox.
If the client's connection has dropped out, no data will ever appear on
the socket, so select will never flag it as readable, so we will never
try to read from it, so we will never receive the read error even though
tcp_keepalive detected the dropout. And if this client was idling with
Not true on any flavour of UNIX of which I'm aware. select() marks a fd
as readable on EOF. poll() marks the fd as either POLLIN, POLLHUP, or
both (sadly implementation specific).
--
Carson
