Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 05 Apr 2004 18:11:41 -0600
From:      Brandon Erhart <berhart@ErhartGroup.COM>
To:        Andre Oppermann <andre@freebsd.org>
Cc:        freebsd-net@freebsd.org
Subject:   Re: FIN_WAIT_[1,2] and LAST_ACK
Message-ID:  <6.0.2.0.2.20040405180951.01c8d898@mx1.erhartgroup.com>
In-Reply-To: <4071D923.A7E0D93F@freebsd.org>
References:  <20040405171756.90E3BF8F2@gemini.nersc.gov> <6.0.2.0.2.20040405133109.01c755c8@mx1.erhartgroup.com> <4071D923.A7E0D93F@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hello,

They are not timing out after 2MSL. I set my MSL to the lowest possible 
setting (10) as to make TIME_WAIT connections disappear. The FIN_WAIT_[1,2] 
and LAST_ACK seem to be sticking around for a while. However, not ALL of 
them stick around for a "long time"(more on this in a sec) -- e.g., after I 
kill my program, and say I've got 6,000 connections sitting in 
FIN_WAIT_[1,2] or LAST_ACK, about a minute afterwards 90% of them have 
disappeared. There seem to be a few stick around for as long as 30 minutes 
or more, and in fact, a few of them stuck around until I rebooted the computer.

Is this bad? :)

Brandon

At 04:09 PM 4/5/2004, you wrote:
>Brandon Erhart wrote:
> >
> > Well, I responded to the group that I had taken one of the fellows advice
> > posting here, and modified the tcp_usrclosed in netinet/tcp_usrreq.c.
> >
> > So all is well -- it gets TCPS_CLOSED state and the tcps_close() function
> > called on the tuple IMMEDIATELY. It doesn't switch states depending on
> > which state the connection is currently in. I also made a sysctl variable
> > for it (to turn the "feature" on or off), and will post the small patch
> > along w/ some other small changes I have made soon.
>
>As far as I am aware (I was looking through and testing the FIN_WAIT states
>in 5.2 around last christmas) our TCP stack is behaving correctly.
>
>Do the FIN_WAIT_1|2 and LAST_ACK time out after 2MSL or do they stick
>around forever?  If they stick around forever, then there is something
>broken.
>
>But I suspect you are just running out of the small space of local ports
>with your application as I said in the previous email.
>
>--
>Andre
>
>
> > Thanks,
> >
> > Brandon
> >
> > At 11:17 AM 4/5/2004, you wrote:
> >
> > >In reply to Brandon Erhart <berhart@ErhartGroup.COM> :
> > >
> > > > Hello everyone,
> > >
> > > > However, I have run into a new problem. I am getting a good amount of
> > > > blocks stuck in FIN_WAIT_1, FIN_WAIT_2 or LAST_ACK that stick 
> around for a
> > > > long while.
> > >
> > >Could you define "long" in this case?  Are we talking about 60
> > >seconds, or 60 minutes?  I get the feeling that your requirements
> > >might make your perception of "long" different from others' notion of
> > >"long."
> > >
> > >The reason I ask is that there was a bug once upon a time that made
> > >some connections stick in LAST_ACK forever....
> > >
> > >                 --eli
> > >
> > >
> > >
> >
> > _______________________________________________
> > freebsd-net@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>_______________________________________________
>freebsd-net@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-net
>To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.0.2.0.2.20040405180951.01c8d898>