Detecting Closed Socket?

jeffv at bisco.kodak.com jeffv at bisco.kodak.com
Tue Mar 19 03:28: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          jeffv at bisco.kodak.com
                           rochester!kodak!bisco!jeffv



More information about the Comp.sys.sun mailing list