Sockets programming question
Konstantin Belousov
kostikbel at gmail.com
Mon Jan 28 16:02:46 UTC 2013
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>
More information about the freebsd-hackers
mailing list