Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!ucsd!ucbvax!FTP.COM!jbvb
From: jbvb@FTP.COM (James B. Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: When is a link saturated?
Message-ID: <9101221418.AA05365@ftp.com>
Date: 22 Jan 91 14:18:09 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jbvb@ftp.com
Organization: The Internet
Lines: 27


    >Alas, no.  A server is free to answer the connection request
    >with a different port number, and they commonly do.  (The reason
    >for this eludes me.  It is permitted by the RFC's, but not
    >required or particularly encouraged.)
    
    The main reason for doing so is to facilitate multiple sessions.  For
    example if 10 people telnet to a machine, each user will get their own
    telnetd process communicating to them via a unique set of ports.  Now
    imagine how difficult this would be to do if you could only have one
    process running connected to the well known telnet port.

I'm sorry, you're both badly misinformed.  All Telnet connections share
a common well-known port number (23) on the server for the life of the
connection (Rlogin servers do the same with port 513).  The uniqueness
of the individual connections is based on the remote host IP address and
remote TCP port values, and the TCP API has to allow multiple processes
on a single local port number.  The client's originating port is usually
randomly assigned a unique value by the client's TCP, so that it can
tell its various connections apart as well.

You may have gotten Telnet (RFC 854, over TCP) confused with TFTP (RFC
783? over UDP), which does have server-side port-switching as part of
the connection startup.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901