Date: Mon, 28 Jan 2013 10:50:08 -0500 From: Alfred Perlstein <bright@mu.org> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-hackers <freebsd-hackers@FreeBSD.org> Subject: Re: Sockets programming question Message-ID: <51069E30.5020003@mu.org> In-Reply-To: <1359385907.93359.84.camel@revolution.hippie.lan> References: <1359385907.93359.84.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/28/13 10:11 AM, 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. I may be mistaken, but doesn't poll(2) allow you to see this as well? I think you should see POLLHUP in revents if POLLOUT is set in events. I think there also is an analogous way to do this with kevent as well. -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51069E30.5020003>