In reply to Brandon Erhart <[EMAIL PROTECTED]> : > 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.
I understand that -- I was trying to discover if you'd come across
something that needed a more general fix (see note from Mike
Silbersack). If your application can't wait for whatever the
standard timeout is, that's fine -- you've got your fix, and you're
good to go. However, if there is a problem with connections hanging
out forever in the process of closing, that something that might be
good to look at independently.
So, do you remember how long the "problem connections" were sticking
around in FIN_WAIT_? or LAST_ACK? Are we talking seconds, minutes,
hours, days?
Thanks,
--eli
>
> 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.
>
> Thanks,
>
> Brandon
>
> At 11:17 AM 4/5/2004, you wrote:
>
> >In reply to Brandon Erhart <[EMAIL PROTECTED]> :
> >
> > > 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
> >
> >
> >
>
pgp00000.pgp
Description: PGP signature
