Date: Thu, 18 Apr 2002 16:17:55 -0700 From: jayanth <jayanth@yahoo-inc.com> To: Mike Silbersack <silby@silby.com> Cc: Mark Delany <markd@BushWire.Net>, Bill Fenner <fenner@research.att.com>, freebsd-net@FreeBSD.ORG Subject: Re: What does FreeBSD do when listen queue is full ? Message-ID: <20020418161755.A19016@yahoo-inc.com> In-Reply-To: <20020418004301.K17506-100000@patrocles.silby.com>; from silby@silby.com on Thu, Apr 18, 2002 at 12:49:45AM -0500 References: <20020417213805.A91259@bushwire.net> <20020418004301.K17506-100000@patrocles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020418161755.A19016>