Subject: | |
From: | |
Reply To: | |
Date: | Sat, 3 Jun 1995 00:56:33 GMT |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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]
|
|
|