From owner-freebsd-net@FreeBSD.ORG Mon Apr 27 16:10:57 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A6FECF0 for ; Mon, 27 Apr 2015 16:10:57 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E951B18AF for ; Mon, 27 Apr 2015 16:10:56 +0000 (UTC) Received: by igbhj9 with SMTP id hj9so66127842igb.1 for ; Mon, 27 Apr 2015 09:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MTm/d7H9AwOaQQ8HD3DxjCldHayCventGf1GQ0PQbMc=; b=RGNV+JRxcFIc4l5kWO3UF89/xQFBAaAieTf+gNOYiqldptPK0NkzxWSuxyrs1Ju0Vd hTqKQXvC4Slqd0vpU0iYPq/6TKJtE7LghRJHfHV04vR4sniyNzM25pJjAGmCojse9Zrr a6qvch1YTvZUd/sYgbzzA0vsnmUfPNFW96ctLzek8il1FRAlqWTSo/5qLZt4acMa1cmH w4Pfja/sWbWmFMcP2tutw9E04GphhL/WHZAb+H85cJyNIZFgfJIOmmCiV7eoeIx+fMaE ITt6QfeK4a3QGmyLQShUhmo3A/T8vC6V+ow7foviecmU1sWL8hq65Kbi4+vhO8M70Jj+ YPng== MIME-Version: 1.0 X-Received: by 10.107.46.39 with SMTP id i39mr14821119ioo.8.1430151056198; Mon, 27 Apr 2015 09:10:56 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Mon, 27 Apr 2015 09:10:56 -0700 (PDT) In-Reply-To: <20150427092236.GV28632@strugglingcoder.info> References: <20150410040834.GG61327@strugglingcoder.info> <20150427092236.GV28632@strugglingcoder.info> Date: Mon, 27 Apr 2015 09:10:56 -0700 X-Google-Sender-Auth: KTO4wPOspuGJZRo2X2YNvDvzMOw Message-ID: Subject: Re: Idle connections via accept_filter(9) From: Adrian Chadd To: hiren panchasara Cc: FreeBSD Net , Jason Wolfe Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 16:10:57 -0000 ask alfred? :) -a On 27 April 2015 at 02:22, hiren panchasara 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