Poštni seznam arhiviranih sporo?il

Od: "Lewis G Rosenthal" <ecs-isp@2rosenthals.com> Glava
Izvorno E-sporo?ilo
Zadeva: Re: [eCS-ISP] socket - no buffer space availble
Datum: Thu, 31 Jul 2025 15:43:12 -0400
Za: 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
-------------------------------------------------------------


Naro?iti: Poro?ilo (Feed), Izvle?ek (Digest), Indeks.
Odjava
E-pošta za mojstra za sezname