On Mon, Jan 28, 2013 at 08:11:47AM -0700, Ian Lepore wrote: > I've got a question that isn't exactly freebsd-specific, but > implemenation-specific behavior may be involved. > > I've got a server process that accepts connections from clients on a > PF_LOCAL stream socket. Multiple clients can be connected at once; a > list of them is tracked internally. The server occasionally sends data > to each client. The time between messages to clients can range > literally from milliseconds to months. Clients never send any data to > the server, indeed they may shutdown that side of the connection and > just receive data. > > The only way I can find to discover that a client has disappeared is by > trying to send them a message and getting an error because they've > closed the socket or died completely. At that point I can reap the > resources and remove them from the client list. This is problem because > of the "months between messages" thing. A lot of clients can come and > go during those months and I've got this ever-growing list of open > socket descriptors because I never had anything to say the whole time > they were connected. > > By trial and error I've discovered that I can sort of "poll" for their > presence by writing a zero-length message. If the other end of the > connection is gone I get the expected error and can reap the client, > otherwise it appears to quietly write nothing and return zero and have > no other side effects than polling the status of the server->client side > of the pipe. > > My problem with this "polling" is that I can't find anything in writing > that sanctions this behavior. Would this amount to relying on a > non-portable accident of the current implementation? > > Also, am I missing something simple and there's a cannonical way to > handle this? In all the years I've done client/server stuff I've never > had quite this type of interaction (or lack thereof) between client and > server before.
Check for the IN events as well. I would not trust the mere presence of the IN in the poll result, but consequent read should return EOF and this is good indicator of the dead client.
pgpetdMu2vn_M.pgp
Description: PGP signature
