Detecting Closed Sockets

Jeffrey J Vanepps LordBah at cup.portal.com
Sun Mar 10 08:13:00 AEST 1991


I have a problem with telling when the other side of a socket connection
has exited.  Normally a read/recv which returns zero after select(2) says
that there is data to be read signifies a closed connection.  In my case,
the application can't use this technique.  Here's the situation:

Program R is a communications router.  It accepts connections from data
producers and data consumers.  Normally, it waits until data is available
from some producer, reads the data, and then writes the data to each
consumer who requested the type of data being generated by that producer.
However, data is not allowed to be lost or thrown away, so if a producer
produces data for which there is not yet a consumer, then R does not
read that data.  It is left in the socket buffer, eventually blocking
the producer.  

Now, after this has happened, and there is a buffer full of data waiting 
to be read from a producer, R has no way to tell that the producer process 
has exited.  Normally when one side of a socket connection exits, the
other side is told via select(2) that there is data to be read, but the
recv(2) call returns zero bytes.  But in the case described above, R can't
try to recv because it has nowhere to put the data.

This is on a Sparc 1+ and IPC, SunOS 4.1.1.

Some attempted solutions:

- Always reading all available data and queueing it (in memory or on disk)
  is not acceptable.  Data volumes under consideration are too high.  We
  basically want the producer to block while there is no consumer.

- The FIONREAD ioctl(2) call always says that there are many bytes to read,
  since there are many bytes left in the buffer.

- getsockopt(SO_ERROR) never returns any error.

- getpeername(2) still thinks that the socket is connected.

- select(2) still thinks that the socket is writeable, even though the
  other side has exited.

- No exceptional condition is ever apparent to select(2).  Given what I've
  seen written about exceptional conditions, I didn't expect this to work.

- I don't receive SIGURG or even SIGPIPE when the other side closes.

So, is there any method provided by the system for determining whether the
other side of a socket has closed?  I'd rather not do any type of handshaking
because throughput is also an issue with R.

--
--------------------------------------------------------------------
    Jeff Van Epps    amusing!lordbah at bisco.kodak.com
                     lordbah at cup.portal.com
                     sun!portal!cup.portal.com!lordbah



More information about the Comp.unix.programmer mailing list