Sockets programming question

[Konstantin Belousov]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20130128/c3412dd0/attachment.sig>