Date: Mon, 27 Apr 2015 02:22:36 -0700 From: hiren panchasara <hiren@strugglingcoder.info> To: freebsd-net@freebsd.org Cc: nitroboost@gmail.com Subject: Re: Idle connections via accept_filter(9) Message-ID: <20150427092236.GV28632@strugglingcoder.info> In-Reply-To: <20150410040834.GG61327@strugglingcoder.info> References: <20150410040834.GG61327@strugglingcoder.info>
next in thread | previous in thread | raw e-mail | index | archive | help
--K6Vt3zCKtaqyTnPU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Wanted to see if someone with understanding of accept_filter can comment. cheers, Hiren On 04/09/15 at 09:08P, hiren panchasara wrote: > 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. >=20 > 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(). >=20 > From uipc_socket.c: >=20 > * From the passive side, a socket is created with two queues of sockets: > * so_incomp for connections in progress and so_comp for connections alre= ady > * made and awaiting user acceptance. As a protocol is preparing incoming > * connections, it creates a socket structure queued on so_incomp by call= ing > * sonewconn(). When the connection is established, soisconnected() is > * called, and transfers the socket structure to so_comp, making it avail= able > * to accept(). >=20 > 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? >=20 > Any insight/help into understanding this scenario and a way to cleanup > these connections would be great. >=20 > (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) >=20 > Cheers, > Hiren --K6Vt3zCKtaqyTnPU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVPf/bXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lDg0H/3wZxqnfBDQGqWUuZTPzj7ZE /Vzbfm1v481TcqcHDKEV4333czTB3Y2YmIzBMLGjEJvq9yE+4YDlJqfG7Yj0ZscD rKq3xhh3Uuqd1zZTO5yrI/vJIAyUVQ9Bfq3hyx+KK5Z2B+pVGU6b2Z1ecuuFsfC+ 5tJcALqZcHnPsxmIuDYyg7N0DIWOELQrSjt5RfuARmVy3rnebJ18j65GOz8HoJ1D pYyqj290p02ZhCiEeeRXHmrMIo8yRr6Dfhul/l2jE9VAslBAEoqbNpF/Pgi9JuFy l4U7ZLVNCz6OvE1mJxRlIo5u4junXlbmJmAkjGeCigntBr9vPHC+LaXzCqZP40E= =a1ui -----END PGP SIGNATURE----- --K6Vt3zCKtaqyTnPU--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150427092236.GV28632>