Date: Thu, 9 Apr 2015 21:08:34 -0700 From: hiren panchasara <hiren@strugglingcoder.info> To: freebsd-net@freebsd.org Cc: nitroboost@gmail.com Subject: Idle connections via accept_filter(9) Message-ID: <20150410040834.GG61327@strugglingcoder.info>
next in thread | raw e-mail | index | archive | help
--TdkiTnkLhLQllcMS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable If a connections comes on a socket with accf_data(9) (for example) but never sends any data, it'll occupy resources via staying forever in listen queue of partial unaccepted connections (socket->so_incomp) which can be seen as incqlen in 'netstat -Lan'. Kernel will never pass this connection down to the application as the filter criteria hasn't been met (no data) and application would never know about this connection. What I am not sure is what would be the state of the connection and state of the socket when in this situation. We do come here after finishing 3WHS but before handing this over to the application i.e. before the accept(). =46rom uipc_socket.c: * From the passive side, a socket is created with two queues of sockets: * so_incomp for connections in progress and so_comp for connections already * made and awaiting user acceptance. As a protocol is preparing incoming * connections, it creates a socket structure queued on so_incomp by calling * sonewconn(). When the connection is established, soisconnected() is * called, and transfers the socket structure to so_comp, making it availab= le * to accept(). So, it looks like the connection would be in ESTABLISHED state but socket would be stuck in the so_incomp queue. Other than this special condition of accpet_filter, can such a situation occur? Any insight/help into understanding this scenario and a way to cleanup these connections would be great. (I know tcp doesn't care/worry about idle sitting connections; we have keepalives to check the health of the connection but that's it, afaik) Cheers, Hiren --TdkiTnkLhLQllcMS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVJ0zBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l+scH/1Kbtqk9r05PTMCnZqXfe7PG Qh/USdnXzGcnxhZKIIT1F/c+pb2+YfTAa8CzdiD0kh+IV+zgTPsRNOfc1eKnLMTt jhh2umZ2KX8PDy2KMk8/WTPmyrNz7I9ifFOBI5wGLpItau7NvQsFBQGQO0P6Mypo YsD2S3Bqu2MaK1An9dhlc9jHK10P242S/nbMEmsaLDp2euGTCVyXZdgGa+oqUTkt BMbrHEHKbyZssfrzcJnzwMCAlF1Ut8CK3kJ9m92yAJlm6rHgdct9E+fjP9XM4Tuw 1EMbp5nSzAjpQvSlW8U4wxEB6/FmJVULf2iO9bCJZggFB+/k6ZfY6YgvQlSC+4A= =5rNB -----END PGP SIGNATURE----- --TdkiTnkLhLQllcMS--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150410040834.GG61327>