[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference irocz::terminal_servers

Title:Terminal Servers
Notice:See Note 2 for Directory of important notes. Please use keywords.
Moderator:LAVC::CAHILLON
Created:Tue May 14 1991
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3547
Total number of notes:12300

3473.0. "Associating a TCP port with a physical port." by KERNEL::FREKES (Like a thief in the night) Wed Mar 19 1997 13:27

Folks

I have a question, that I feel I already have the answer to. When telneting from
a terminal server to a VMS host, you are assigned a TCP port number, that seems
to increment with each connection made.

Host: DS9001.uvo.digital.com Port: 1034
				    ^
				    |----- this is the number that gets 
					   incremented.

My customer would like to know if there is a way of associating this number
with the physical port on his terminal server. I know that when the telnet 
session gets established the source TCP port increments each time the connection
to the host is established. 
The number you are seeing when you do a $show user frekes/full, is the TCP 
port number on the server. But I do not know if a way from the server end of 
associating this with the physical port. Another question is, when I disconnect
the session and re-connect the number still increments. I guess it eventually
times out, or ages. What is this process, and typically how long is it?

Any input would be greatly appreciatted.

Regards
	Steven F

    
T.RTitleUserPersonal
Name
DateLines
3473.1It's a feature that's been discussed beforeLAVC::CAHILLJim CahillWed Mar 19 1997 13:5315
See 3100 and several other notes about this subject.

The reason for the increasing port number is because TCP requires a unique
"address/port number" for each connection.  We'd have to guarantee a user
could never start a session, hit break, and at some later time create another
session to the same host which would reuse the same TCP port number as the
first session.  I'm told some implementations don't react gracefully when
presented with that situation.

It's certainly not an impossible problem to solve.  It's a question of how
high a priority is this request, what's the business need for such a feature,
and what tradeoffs have to be made in order to free up a resource to do this
work.

Jim
3473.2Thanks for the info.KERNEL::FREKESLike a thief in the nightWed Mar 19 1997 14:3811
    Jim
    
    Thanks for you prompt reply. I don't feel this is a serious enough
    request for anyone to go and spend any serious time working on it.
    
    It is more of a "this would be nice" type feature. 
    
    Thanks for your help.
    
    Regards
    	Steven F.
3473.3We are making some progress on this...IROCZ::D_NELSONDave Nelson LKG1-3/A11 226-5358Wed Mar 19 1997 14:4038
RE: .0

We have a partial solution today.

That solution allows a manual correlation of host sessions to DECserver
sessions.  The host show displays will give you the source (DECserver)
TCP port number (as well as IP address).  The SHOW PORT STATUS command
in DNAS has been enhanced to give the same information.  Thus with two
commands (one on the host and one on the NAS) you can match up the 
TCP port numner to a physical port number.

Local> show port status

Port  1: n                             Server: DIGITAL

Access:         Local                  Current Service:              IROCZ
Status:    Local Mode                  Current Node:          16.20.104.42
Sessions:           1                  Current Port:                    23
                                       Current Source Port:           1024

Input XOFFed:      No                  Output Signals: DTR
Output XOFFed:     No                  Input Signals:  DSR RXD

The Current Port is the TCP destination port the Current Source Port is
the TCP source port.

We have also investigated a more elgant way to solve this problem.  That
solution involves assigning a unique range to TCP source port numbers to
each physical port, such that you could map the results of the host side
show display back to a DECserver physical port by an algorithm (that could
be put in a script of program, for example).  That feature was not 
completed, and not released, although significant work was done on it.
This solution is the one offered by many of our competitors, BTW.

Regards,

Dave