Idle connections via accept_filter(9)

[hiren panchasara]

On 04/27/15 at 09:10P, Adrian Chadd wrote:
> ask alfred? :)

Thanks! CCing him.
> 
> 
> -a
> 
> 
> On 27 April 2015 at 02:22, hiren panchasara <hiren at strugglingcoder.info> wrote:
> > 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
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20150427/679c1b1c/attachment.sig>