Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.unix.questions
Subject: Re: reading on sockets when connection breaks
Message-ID: <1990Dec12.060545.7673@Think.COM>
Date: 12 Dec 90 06:05:45 GMT
References: <25205@adm.brl.mil> <1990Dec6.055353.23846@Think.COM> <5727@navy40.UUCP>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 51

In article <5727@navy40.UUCP> damenf@motcid.UUCP (Frederick Damen) writes:
>1) After reading some related information on SIGPIPE and running a test program
>   it seems as though SIGPIPE is only raised on a pipe/socket that has been 
>   written to.

Someone please correct me if I'm wrong (my answers are mostly educated
guesses), but I think Unix keepalives are implemented by periodically
retransmitting a packet with the sequence number of the last one sent.  The
other host acknowledges having received all bytes up to that point, and
this acknowledgement serves as the indication that it is still alive.  But
if you haven't yet written anything, then there is nothing to retransmit

>   Q: When is the SIGPIPE sent:
>         After n(n=1) messages are not responded to?
>         When the next I/O operation is performed on this socket after a nonresponce?

After n (n > 1, possibly a settable kernel parameter) messages are not
responded to.  There would be no reason to use a signal if it waited for
an I/O operation to be performed, as it could simply return an error in
that case.

>   Q: Define processess *using* the socket.
>      Is this:
>         Processes that have written to the socket?
>         Processes that have an open file descriptor for this socket?
>         Processes at both ends of socket connection?
>         Processes that are currently performing and I/O operation on the socket?

I would expect the second definition.  The third definition is unlikely,
because the process at the other end of the socket isn't likely to be on
this host, so it's not possible to send a Unix signal to it (it might not
even be on a Unix system); also if the keepalive is accurately detecting a
crashed host, the process at the other end doesn't even exist.  The fourth
definition is also unlikely for the reason I gave in the answer to the
previous question.  And the first definition seems unlikely because I don't
think the kernel keeps track of which processes have written to a socket;
there's a single buffer that all file descriptors for the socket reference.

>3) After the signal handler for SIGPIPE is called how do/should you tell which
>   socket caused the SIGPIPE?

I don't think there's a reliable way.  I think the intent of the keepalive
mechanism was to provide a way for the process to be killed automatically
if the other end died.  It doesn't provide for much fine control.  It's
probably the case that trying to read on a socket that caused a SIGPIPE
will get an error, but I wouldn't stake much on it.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar