jeffv@bisco.kodak.com (03/19/91)
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@bisco.kodak.com rochester!kodak!bisco!jeffv