Idle connections via accept_filter(9)

[Alfred Perlstein]

This is over 15 years old. I currently don't know of a great solution to this problem. Might make sense to create a timer that runs and refs the socket that will occasionally fire and cleanse out the old connections. 

Shouldn't be that hard to do. 

Sent from my iPhone

> On Apr 27, 2015, at 9:19 AM, hiren panchasara <hiren at strugglingcoder.info> wrote:
> 
>> 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"