From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 28 16:02:46 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 504AC84D; Mon, 28 Jan 2013 16:02:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B63CA825; Mon, 28 Jan 2013 16:02:45 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0SG2cFN085268; Mon, 28 Jan 2013 18:02:38 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0SG2cFN085268 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0SG2cNt085267; Mon, 28 Jan 2013 18:02:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 28 Jan 2013 18:02:38 +0200 From: Konstantin Belousov To: Ian Lepore Subject: Re: Sockets programming question Message-ID: <20130128160238.GT2522@kib.kiev.ua> References: <1359385907.93359.84.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LBl8gXKyGkO5T0RG" Content-Disposition: inline In-Reply-To: <1359385907.93359.84.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home 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 16:02:46 -0000 --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--