HP3000-L Archives

June 1995, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Tom Emerson <[log in to unmask]>
Reply To:
Tom Emerson <[log in to unmask]>
Date:
Sat, 3 Jun 1995 00:56:33 GMT
Content-Type:
text/plain
Parts/Attachments:
text/plain (50 lines)
In <[log in to unmask]> [log in to unmask] (Eero Laurila) responded:
>
>- No offence meant, just a little correction.  The number of "sockets"
>  you are referring to is really the max allowed number of TCP-connections
>  (I assume you are referring to NMMGR screen NETXPORT.GPROT.TCP).
>  This value is loaded in TCP KSO (Known System Object), KSO number #333 and
 
>  TCPSIP.NET.SYS code will check it every time an inbound or outbound
>  connection is attempted to see whether it should allow or deny the new
>  connection.
 
none taken - in my rough draft of my response, I talked about TCP
connections, but as I couldn't remember the exact name of the field and NMMGR
screen, I re-wrote that line to read "sockects" instead.  (see the reason why
below)
 
>  I'm surprised to hear that in your case only 30 sessions were able to
>  logon although 128 TCP connections were configured.  I can see two
possible
>  reasons for it:
>
> 1) Since any NS server requires only one TCP connection, I would think
>    that you may have some other applications (such as unispool, other
>    client/server) that open TCP connections.  Maybe unispool spools to
>    20 different systems and thus chews up that many TCP connections???
 
close on this one - each user that was logging in was also DSLINE-ing out to
three or four classic systems, and all this is on top of the fact that we are
using netbase to shadow a couple of files.  We actually got up to about 36
sessions total.
 
> 2) There have been couple of bugs within last year where not all sockets
>    were closed (and TCP connection entries released) by some NS servers.
>    You may also have some 3rd party or home-grown software that has
>    similar bug.  Most often those bugs have been results of people coding
>    for TCP's graceful release of a connection without realizing that it
>    will require two calls to IPCSHUTDOWN to completely kill the connection.
 
This makes something I saw make more sense - although we had the max TCP
connections configured at 128, the TCPSTAT routine in NETTOOL showed we had
as many as 140 open.  The other confusing issue (and perhaps why I got
TCP connections and sockets confused in the first place) was that the
SOCKINFO utility in NETTOOL showed a socket in use for each incoming
and outgoing VT session, and I noted we seemed to run out of resources
when this number reached 75 or so.
 
Till next time.
Tom Emerson
[log in to unmask]

ATOM RSS1 RSS2