From owner-cvs-src@FreeBSD.ORG Thu Sep 7 13:03:28 2006
Return-Path: <owner-cvs-src@FreeBSD.ORG>
X-Original-To: cvs-src@FreeBSD.org
Delivered-To: cvs-src@FreeBSD.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id BCBED16A4DF;
Thu, 7 Sep 2006 13:03:28 +0000 (UTC)
(envelope-from glebius@FreeBSD.org)
Received: from cell.sick.ru (cell.sick.ru [217.72.144.68])
by mx1.FreeBSD.org (Postfix) with ESMTP id BE17943D5C;
Thu, 7 Sep 2006 13:03:24 +0000 (GMT)
(envelope-from glebius@FreeBSD.org)
Received: from cell.sick.ru (glebius@localhost [127.0.0.1])
by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k87D3MqZ015992
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Thu, 7 Sep 2006 17:03:22 +0400 (MSD)
(envelope-from glebius@FreeBSD.org)
Received: (from glebius@localhost)
by cell.sick.ru (8.13.4/8.13.1/Submit) id k87D3LXl015991;
Thu, 7 Sep 2006 17:03:21 +0400 (MSD)
(envelope-from glebius@FreeBSD.org)
X-Authentication-Warning: cell.sick.ru: glebius set sender to
glebius@FreeBSD.org using -f
Date: Thu, 7 Sep 2006 17:03:21 +0400
From: Gleb Smirnoff <glebius@FreeBSD.org>
To: Mike Silbersack <silby@silby.com>
Message-ID: <20060907130321.GA40020@FreeBSD.org>
References: <200609061356.k86DuZ0w016069@repoman.freebsd.org>
<20060906091204.B6691@odysseus.silby.com>
<20060906143204.GQ40020@FreeBSD.org>
<20060906093553.L6691@odysseus.silby.com>
<20060906150129.GT40020@FreeBSD.org>
<20060907000939.J12826@odysseus.silby.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
In-Reply-To: <20060907000939.J12826@odysseus.silby.com>
User-Agent: Mutt/1.5.6i
Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/sys/netinet in_pcb.c tcp_subr.c tcp_timer.c
tcp_var.h
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Sep 2006 13:03:28 -0000
On Thu, Sep 07, 2006 at 12:18:56AM -0500, Mike Silbersack wrote:
M> >I think we should free the oldmost tcptw entry in a case if we can't
M> >find the local endpoint. We can tell definitely that we can't find one
M> >only in in_pcbbind_setup() in the "do {} while (in_pcblookup_local)" cycle,
M> >where EADDRNOTAVAIL is returned. We can't definitely tell this in
M> >in_pcblookup_local() since we don't know whether tried port is the
M> >last one.
M> >
M> >The oldmost tcptw entry can be taken simply from the ordered list, like
M> >tcp_timer_2msl_tw() does this.
M>
M> That's something along the lines of what I was thinking. However, I think
M> it'll be slightly more complex than taking just the oldest entry from the
M> list. We could have time_wait states that are for sockets such as
M> remoteip:ephemeralport <-> localip:80 and also
M> localip:ephemeralport <-> remoteip:80. We'd have to find one of the ones
M> of the second type to recycle.
It think we need to purge one entry if _we have found a match_ in
in_pcblookup_local(). And _do not jump_ up to the beginning of the cycle.
M> I think I know why my implementation went so wrong - I was testing the
M> case where I had http_load (or was it apachebench?) connecting to apache
M> on another machine. The case I was trying to solve was where the http
M> benchmark tool created all the time_wait sockets on the client, thereby
M> preventing new connections from being made. In that case, the heuristic
M> would (probably) recycle the first socket it came upon, and be done. In
M> your case, it would recycle the first socket it came upon, but it would be
M> one of the remoteip:ephemeralport <-> localip:80 sockets, which wouldn't
M> help it at all. Does that sound like what was happening?
Probably it does.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE