From owner-freebsd-net Thu Apr 18 16:18:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by hub.freebsd.org (Postfix) with ESMTP id E881D37B416 for ; Thu, 18 Apr 2002 16:18:15 -0700 (PDT) Received: from milk.yahoo.com (milk.yahoo.com [216.145.52.137]) by mrout2.yahoo.com (8.11.6/8.11.6/y.out) with ESMTP id g3INHuE77559; Thu, 18 Apr 2002 16:17:56 -0700 (PDT) Received: (from root@localhost) by milk.yahoo.com (8.11.0/8.11.0) id g3INHtG20060; Thu, 18 Apr 2002 16:17:55 -0700 (PDT) (envelope-from jayanth) Date: Thu, 18 Apr 2002 16:17:55 -0700 From: jayanth To: Mike Silbersack Cc: Mark Delany , Bill Fenner , freebsd-net@FreeBSD.ORG Subject: Re: What does FreeBSD do when listen queue is full ? Message-ID: <20020418161755.A19016@yahoo-inc.com> References: <20020417213805.A91259@bushwire.net> <20020418004301.K17506-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20020418004301.K17506-100000@patrocles.silby.com>; from silby@silby.com on Thu, Apr 18, 2002 at 12:49:45AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > For arguments sake, say I have a web server that I know handles 10 > > requests per second and I want to offer a 2 second response time. To > > do this I set the backlog to 20 on each of the web servers and > > configure the load balancer to periodically check each server by > > attempting to establish a session. > > > > If the load balancer connection attempt fails then it knows that that > > particular server already has 2 seconds worth of work so it should not > > consider that server as available at the moment (note that some load > > balancer configurations mean that connection counting is not possible > > and, oftentimes they don't do so accurately anyway). > > Well, 4.5+ would already be considered broken by your standards; it does > not send a RST when dropping connections that have exceeded the backlog. It does not send a RST immediately, but will send one if the peer retransmits the ACK or sends data. In syncache_socket() /* * Ok, create the full blown connection, and set things up * as they would have been set up if we had created the * connection when the SYN arrived. If we can't create * the connection, abort it. */ so = sonewconn(lso, SS_ISCONNECTED); if (so == NULL) { /* * Drop the connection; we will send a RST if the peer * retransmits the ACK, */ tcpstat.tcps_listendrop++; goto abort; } when the listen queue is full and the syncache entry is dropped there is a side effect that will cause the subsequent ACK or ACK w data to be rejected because the syncookie lookup code for the ACK packet always returns NULL. The reason NULL is returned is because of the following check in syncookie_lookup(). if (tcp_secret[idx].ts_expire < ticks || sototcpcb(so)->ts_recent + SYNCOOKIE_TIMEOUT < ticks) return (NULL); ts_recent will be zero at this point. The ts_recent flag of the listening socket is used as a timer and an indicator that a syncache entry has been removed. A dropped entry due to listen q full should be treated the same way as zone allocation failure, bucket or cache overflow, by updating ts_recent. This will not reject the ACK assuming that the listen queue is not full again. jayanth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message