From owner-freebsd-net  Wed Apr 17 21:10:45 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
	by hub.freebsd.org (Postfix) with ESMTP id 7E09F37B41A
	for <freebsd-net@FreeBSD.ORG>; Wed, 17 Apr 2002 21:10:41 -0700 (PDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id EF20F4CE5C; Thu, 18 Apr 2002 00:10:40 -0400 (EDT)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id AAA20936;
	Thu, 18 Apr 2002 00:10:40 -0400 (EDT)
From: Bill Fenner <fenner@research.att.com>
Received: (from fenner@localhost)
	by windsor.research.att.com (8.8.8+Sun/8.8.5) id VAA07075;
	Wed, 17 Apr 2002 21:10:40 -0700 (PDT)
Message-Id: <200204180410.VAA07075@windsor.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: markd@BushWire.Net
Subject: Re: What does FreeBSD do when listen queue is full ?
Cc: freebsd-net@FreeBSD.ORG
References:  <20020417213805.A91259@bushwire.net> <20020418004301.K17506-100000@patrocles.silby.com> <20020418011320.60326.qmail@prefix.bushwire.net>
Date: Wed, 17 Apr 2002 21:10:39 -0700
Versions: dmail (solaris) 2.4/makemail 2.9b
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


>So, if backlog is a threshold for communicating to clients, then I
>think RST is the right choice as it communicates server state
>unambiguously.

I disagree; RST does not communicate server state unambiguously.
RST is used in response to an erroneous packet on a synchronized
connection, in response to a packet to a connection that doesn't
exist (e.g. SYN to a closed port), or in response to an ACK that
acknowledges something that hasn't been sent.  None of these
applies to this situation.

Dropping the ACK and allowing the TCP backoff to retry the connection
is exactly the right behavior when there is one server supplying the
service, because the retries are subject to exponential backoffs.
Please don't break the normal case for the load-balanced case.

  Bill

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message