Date: Mon, 28 Jan 2013 18:02:38 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-hackers <freebsd-hackers@FreeBSD.org> Subject: Re: Sockets programming question Message-ID: <20130128160238.GT2522@kib.kiev.ua> 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
--LBl8gXKyGkO5T0RG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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? =20 >=20 > 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. --LBl8gXKyGkO5T0RG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRBqEeAAoJEJDCuSvBvK1BJVUP/2CJIOO4MBob58JspdeeIafM OzzGrGZy64GQnhs2+BCgR1bPxt4bt53rhP4KnsXc9F3LEZhmesDmb4zY8U2zliop Q3sTPoesCzDqWwP6rNzQgQEjrWX6LKq798uO4LdJksMTSz1fPZnuTdKFiszPHMd1 mG3/TDju2Z8WhHK3iEetu82HNdrpXTxe4z7ZLEteUfZ25zZE9aw830w3a/eNdtE7 7rH1UfL+X82O74ayW8pM579JQgIA6W+jKWfVYdsGXXKj2sk+5Bd6RpDdgP6JMa2v brncs9zbUu8KKeyQy30tSwLlZ5o7AOf2uIAZuIrHcfRcw0gxpxwgoeAsroYLEBZV ZU0xR7Q2Q3L5lNMBj74fqBagb5GDZuxivlxun1mmo8O53+hbtsugSAMxaJxjQaMG ChUkvnkpfGCZI8CYFbGzPkPMTFllVmDWyTadqWWbjxor7WEPcNkTZ5j/jX6RO2Nf 7l1nhCQKj1E3OWH3OlVNwFElHoCehREyEJNT9TuLmkbmGQ9KtkJilQrDbbks8GvT Xcnv/TsFpTTTQFC8kHoCCwKQYH25WTTnB9NXDflNJoam+8uRuU3JjPhihcIFU2rr 7/fL4EurxplecixZhV2uuvKELkdecYiM8+sJsPcjtKZTDt4qfj9s7FR1bVg0cL38 UhZytb2q9/9k9X9OWPpt =7kI4 -----END PGP SIGNATURE----- --LBl8gXKyGkO5T0RG--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130128160238.GT2522>