Date: Mon, 27 Apr 2015 09:39:40 -0700 From: Alfred Perlstein <bright@mu.org> To: hiren panchasara <hiren@strugglingcoder.info> Cc: Adrian Chadd <adrian@freebsd.org>, FreeBSD Net <freebsd-net@freebsd.org>, "alfred@FreeBSD.org" <alfred@FreeBSD.org>, Jason Wolfe <nitroboost@gmail.com> Subject: Re: Idle connections via accept_filter(9) Message-ID: <B1D4BAE6-2D47-4F58-A92A-4F6F212D2AC4@mu.org> In-Reply-To: <20150427161932.GW28632@strugglingcoder.info> References: <20150410040834.GG61327@strugglingcoder.info> <20150427092236.GV28632@strugglingcoder.info> <CAJ-Vmo=zZ6ExoyAw=anZAwkfPOMfb_LQ%2BPyMJJOXHGTxdhXMww@mail.gmail.com> <20150427161932.GW28632@strugglingcoder.info>
next in thread | previous in thread | raw e-mail | index | archive | help
This is over 15 years old. I currently don't know of a great solution to thi= s problem. Might make sense to create a timer that runs and refs the socket t= hat will occasionally fire and cleanse out the old connections.=20 Shouldn't be that hard to do.=20 Sent from my iPhone > On Apr 27, 2015, at 9:19 AM, hiren panchasara <hiren@strugglingcoder.info>= wrote: >=20 >> On 04/27/15 at 09:10P, Adrian Chadd wrote: >> ask alfred? :) >=20 > Thanks! CCing him. >>=20 >>=20 >> -a >>=20 >>=20 >>> On 27 April 2015 at 02:22, hiren panchasara <hiren@strugglingcoder.info>= wrote: >>> Wanted to see if someone with understanding of accept_filter can >>> comment. >>>=20 >>> 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) whic= h >>>> 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 >>>> =46rom uipc_socket.c: >>>>=20 >>>> * =46rom the passive side, a socket is created with two queues of socke= ts: >>>> * so_incomp for connections in progress and so_comp for connections alr= eady >>>> * made and awaiting user acceptance. As a protocol is preparing incomi= ng >>>> * connections, it creates a socket structure queued on so_incomp by cal= ling >>>> * sonewconn(). When the connection is established, soisconnected() is >>>> * called, and transfers the socket structure to so_comp, making it avai= lable >>>> * 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 >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B1D4BAE6-2D47-4F58-A92A-4F6F212D2AC4>