From owner-freebsd-net Sun Apr 14 23:52:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d27.as28.nwbl0.wi.voyager.net [169.207.69.27]) by hub.freebsd.org (Postfix) with ESMTP id A9BE137B4C2 for ; Sun, 14 Apr 2002 23:51:52 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g3FCpLLx003543; Mon, 15 Apr 2002 07:51:21 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g3FCpKRt003540; Mon, 15 Apr 2002 07:51:21 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 15 Apr 2002 07:51:20 -0500 (CDT) From: Mike Silbersack To: Yusuf Goolamabbas Cc: freebsd-net@freebsd.org Subject: Re: What does FreeBSD do when listen queue is full ? In-Reply-To: <20020415062451.13653.qmail@yusufg.portal2.com> Message-ID: <20020415074210.V3157-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On 15 Apr 2002, Yusuf Goolamabbas wrote: > Subsequently, we changed the listen backlog to 128 via > DAEMON_OPTIONS(`Port=smtp, Name=MTA, Listen=128') > and turned ConnectionRateThrottle back on with a value of 20. Now, the > immediate reset is triggered but quite infrequently > > I thought that FreeBSD might be sending a RESET when the listen queue is > full but that would be contrary to what the listen(2) man page says > > 'If a connection request arrives with the queue full the client may > receive an error with an indication of ECONNREFUSED, or, if the > underlying protocol supports retransmission, the request may be ignored > so that retries may succeed.' There used to be two listen queues; one for completed connections and one for incomplete connections. (Complete referring to the TCP three-way handshake completing.) The syncache replaces the incomplete connection queue, meaning that the listen queue depth is no longer relevant there. I just did a quick look over the code, and it appears that the complete connection queue is still intact, and takes on 3/2*listen backlog as its length. Therefore, if sendmail is deciding to not accept() all connections ASAP, a backlog will build up, and RSTs will be sent to incoming connections. This should be true under 4.4 or 4.5. The listen manpage looks to be pretty accurate in its description. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message