| 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
|
| 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
|