Date: 18 Apr 2002 01:13:20 +0000 From: "Mark Delany" <markd@BushWire.Net> To: "Mike Silbersack" <silby@silby.com> Cc: "Bill Fenner" <fenner@research.att.com>, freebsd-net@FreeBSD.ORG Subject: Re: What does FreeBSD do when listen queue is full ? Message-ID: <20020418011320.60326.qmail@prefix.bushwire.net> 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
On Thu, Apr 18, 2002 at 12:49:45AM -0500, Mike Silbersack allegedly wrote: > > On Wed, 17 Apr 2002, Mark Delany wrote: > > > Are we discussing what happens when the number of pending connections > > exceeds the backlog? If the suggestion is to leave such connections > > pending then the question becomes what's the real purpose of backlog? > > Yes, that is what we're discussing. Goodo. > > For arguments sake, say I have a web server that I know handles 10 > 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. Agreed. I think that RST is the right choice actually. > I understand your method, but it seems perhaps a bit too simplistic. Have Right. It was really only intended as an example to demonstrate the concept. It raises the question as to the purpose of backlog. Is it really only intended as a resource hint or does it represent a firm threshold beyond which the OS should act differently? If the latter, then the purpose of the threshold can only be of real benefit to the client as the server can trivially track its own resource usage, true? So, if backlog is a threshold for communicating to clients, then I think RST is the right choice as it communicates server state unambiguously. Conversely dropping the ACK is ambiguous to the client - is the server busy or is the network dropping packets? Additional dropping the ACK is a painfully slow way to communicate as the client has to timeout the connection attempt to find out that service is not forthcoming. Regards. 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?20020418011320.60326.qmail>