Idle connections via accept_filter(9)

[hiren panchasara]

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
-------------- 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/20150409/f56bd1ad/attachment.sig>