I have a socket-based server which, when connected to,
runs an external command and send the output of the
external program back to the client program.

The external program is long running (a render job), so if
the client dies or disconnects I would like to terminate
the external program.

I'm adding the socket to my poll() loop like this:

ufd[n].fd = sock;
ufd[n].events = POLLIN|POLLPRI|POLLOUT|POLLERR|POLLHUP;
++n;

But I get no events if the client terminates, until the
external program terminates, in which case I get revents=5
(POLLOUT|POLLIN).

Is this something I should be able to detect?  I'm testing
by telnetting to the server, and while the external program
is running quitting out of the telnet session.

Many TIA!
Mark

--
Mark Harrison
Pixar Animation Studios

[ Post a follow-up to this message ]

Mark Harrison wrote:
> I have a socket-based server which, when connected to,
> runs an external command and send the output of the
> external program back to the client program.
>
> The external program is long running (a render job), so if
> the client dies or disconnects I would like to terminate
> the external program.
>
> I'm adding the socket to my poll() loop like this:
>
>         ufd[n].fd = sock;
>         ufd[n].events = POLLIN|POLLPRI|POLLOUT|POLLERR|POLLHUP;
>         ++n;
>
> But I get no events if the client terminates, until the
> external program terminates, in which case I get revents=5
> (POLLOUT|POLLIN).

If the TCP client terminates in any way its OS should send FIN or RST
if linger option was modified. The server should detect this fact by
getting POLLIN event and reading from the socket. The read should
eventually return 0 (EOF) for FIN or -1 and errno == ECONNRESET for
RST.

If you also want to detect the occurrence when client's OS has crashed
then the client should sent keep-alives to the server.

[ Post a follow-up to this message ]

On 2006-06-08, Mark Harrison <mh@pixar.com> wrote:
> The external program is long running (a render job), so if
> the client dies or disconnects I would like to terminate
> the external program.
[...]
> But I get no events if the client terminates, until the
> external program terminates, in which case I get revents=5
> (POLLOUT|POLLIN).

Are you sure that you are checking the connection while your external
program runs? Could it be that you only write into socket and don't read
from it?

Normally if the peer application has closed connection, then your socket
becomes readable (POLLIN) and call to recv should return 0 to indicate
EOF.

--
Minds, like parachutes, function best when open

[ Post a follow-up to this message ]

Maxim Yegorushkin <maxim.yegorushkin@gmail.com> wrote:
> If the TCP client terminates in any way its OS should send FIN or
> RST if linger option was modified. The server should detect this
> fact by getting POLLIN event and reading from the socket. The read
> should eventually return 0 (EOF) for FIN or -1 and errno ==
> ECONNRESET for RST.

Given that RST's are not retransmitted, if the client is poorly
written and uses an abortive close (RST) there is a good chance that
the other side may never see the RST and so come-out of the poll()
call.

Strictly speaking the best thing to do is to have the application send
periodic "hey are you there" messages each way.  Then they can either
XXX-u-me that no response in N time units means the remote is dead, or
they may see a locally generated abort when TCP times-out trying to
retransmit the "hey are you there" message.

This is better than simply setting SO_KEEPALIVE because it gives the
application better control over how long to wait for replies.

> If you also want to detect the occurrence when client's OS has
> crashed then the client should sent keep-alives to the server.

I think they need it even for the non-crash case.

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway... 
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

[ Post a follow-up to this message ]

Three fine points:

1) There is no such thing as a "closed socket". As soon as you close a
socket, it ceases to exist. The 'close' function destroys a socket.
(What it does to any underlying connection or port depends upon whether
the destroyed socket was the last reference to that connection or port
and the rules of the protocol.)

2) TCP does not guarantee that a lost connection will be detected by an
end that is not attempting to send any data. (Keep alives sort of
guarantee this, depending upon your definition of 'lost'.)

3) The 'poll' function will report a socket the refers to a TCP
connection that can no longer send or receive data due to a normal
shutdown or abortive close assuming it has detected that shutdown or
abortive close.

DS

[ Post a follow-up to this message ]

davids@webmaster.com wrote:
> Three fine points:
>
> 1) There is no such thing as a "closed socket". As soon as you close a
> socket, it ceases to exist. The 'close' function destroys a socket.
> (What it does to any underlying connection or port depends upon whether
> the destroyed socket was the last reference to that connection or port
> and the rules of the protocol.)

When a socket is closed, the connection is not closed in some cases.
If the program did fork, the connection is held by each forked
instance.
Every instances must close the socket or one instance must shutdown(2)
the socket in order to close the connection.

> 2) TCP does not guarantee that a lost connection will be detected by an
> end that is not attempting to send any data. (Keep alives sort of
> guarantee this, depending upon your definition of 'lost'.)

Absolutly. I think by default keep-alive packets are sent every 3
hours. So don't expect this to be fast. (only root user should be able
to change this value)

> 3) The 'poll' function will report a socket the refers to a TCP
> connection that can no longer send or receive data due to a normal
> shutdown or abortive close assuming it has detected that shutdown or
> abortive close.

[ Post a follow-up to this message ]