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. > > 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(). > > From 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 available > * 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
pgpszDVfjjajb.pgp
Description: PGP signature
