Idle connections via accept_filter(9)

[Adrian Chadd]

ask alfred? :)


-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