From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 28 15:50:18 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D107CEFD; Mon, 28 Jan 2013 15:50:18 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C1B3771C; Mon, 28 Jan 2013 15:50:18 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (207.110.29.135.ptr.us.xo.net [207.110.29.135]) by elvis.mu.org (Postfix) with ESMTPSA id 361051A3C1B; Mon, 28 Jan 2013 07:50:10 -0800 (PST) Message-ID: <51069E30.5020003@mu.org> Date: Mon, 28 Jan 2013 10:50:08 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Sockets programming question References: <1359385907.93359.84.camel@revolution.hippie.lan> In-Reply-To: <1359385907.93359.84.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 15:50:18 -0000 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