From: |
"Lewis G Rosenthal" <ecs-isp@2rosenthals.com> |
Full Headers Undecoded message |
Subject: |
Re: [eCS-ISP] socket - no buffer space availble |
Date: |
Thu, 31 Jul 2025 15:43:12 -0400 |
To: |
eCS ISP Mailing List <ecs-isp@2rosenthals.com> |
|
---|
Hi...
On 07/30/25 03:01 pm, Steven Levine wrote:
In <list-13730496@2rosenthals.com>, on 07/30/25
at 11:54 AM, "Lewis G Rosenthal" <ecs-isp@2rosenthals.com> said:
Hi,
I would expect lingertime or realslow to impact FIN_WAIT_2. Does neither?
I don't know. The relevant code is in afinetk.os2, but I've not had a
need to look at it in detail.
The possibly equivalent FreeBSD code is
tcp_usrreq.c:786
if (tp && tp->t_state >= TCPS_FIN_WAIT_2) {
soisdisconnected(tp->t_inpcb->inp_socket);
/* To prevent the connection hanging in FIN_WAIT_2 forever. */
if (tp->t_state == TCPS_FIN_WAIT_2)
tp->t_timer[TCPT_2MSL] = tcp_maxidle;
}
maxidle is set by
tcp_timer.c:131
tcp_maxidle = tcp_keepcnt * tcp_keepintvl;
tcp_keepintvl can vary. I'm pretty sure this is the keepalive timeout,
but I've not verified this 100%.
That would surely make sense, but as you say, without verifcation, it's only a supposition.
realslow sets the time in ticks for closing slow TW connections, and I
thought that FIN_WAIT_2 implied a slow connection (I need to pull that
book off the shelf when I get home, I guess).
realslow does not seem to exist in the FreeBSD sources. It appears to
have been added by IBM. Afinetk.os2 defines the symbols
afinetk.sys\6_3100\afinetk.map:125
0001:00001B34 tcp_keepidle
0001:00001B38 tcp_keepintvl
0001:00001B3C tcp_maxpersistidle
0001:00001B40 RealSlowTimer
0001:00001B48 route_timer
0001:00001B4C syncookietimer
among others. As you can see, camel case symbol style differs from the
standard FreeBSD source style. I've not looked in any detail at how the
code uses RealSlowTimer. This should happen if this dicussion continues
sufficiently long.
How about that? I thought that realslow was added longl, long ago, in a galaxy far, far away. Perhaps not so far, far away, after all. Hmmm...
I think once the socket number is returned to the pool, identifying these
"cling-ons" (Klingons?) will be tricky.
Agreed. There's also the issue that we don't know the socket number we
want to hack away at.
Yes, there is that. You have a point though, in that without the stack "remembering" which socket is which, it would be hard to *not* reuse these ad hoc.
Now I'll have to look at the 3.2 sources myself. As you are wont to say,
some people do crossword puzzles... LOL
FWIW, my reference is
g remote -v
origin https://github.com/freebsd/freebsd (fetch)
g tag
release/3.2.0
gl log -1
commit c37538200ebdef38051ba82b76e6b2dab3bd2fdc
Author: cvs2svn <cvs2svn@FreeBSD.org>
Date: Mon May 24 16:47:10 1999 +0000
This commit was manufactured by cvs2svn to create tag
'RELENG_3_2_0_RELEASE'.
Thanks. I'll bookmark that and add to my late night reading list. ;-)
--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA
Rosenthal & Rosenthal, LLC www.2rosenthals.com
visit my IT blog www.2rosenthals.net/wordpress
-------------------------------------------------------------
|