Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!agate!ucbvax!NIC.DDN.MIL!tcp-ip-RELAY
From: tcp-ip-RELAY@NIC.DDN.MIL
Newsgroups: comp.protocols.tcp-ip
Subject: (none)
Message-ID: <9101230223.AA18742@ucbvax.Berkeley.EDU>
Date: 23 Jan 91 02:23:35 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 67

To: John Stewart
    <zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!news-server.csri.to
    ronto.edu!utgpu!cunews!jstewart@tut.cis.ohio-state.edu>
cc: tcp-ip@nic.ddn.mil, gwilliam
Subject: Re: When is a link saturated? 
In-reply-to: Your message of 21 Jan 91 14:15:30 +0000.
             <1991Jan21.141530.7031@ccs.carleton.ca> 
Date: Tue, 22 Jan 91 13:52:16 -0500
From: "George Williams" <gwilliam@sh>


    Date:    21 Jan 91 14:15:30 GMT
    From:    John Stewart <zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!news
	      -server.csri.toronto.edu!utgpu!cunews!jstewart@tut.cis.ohio-state
	      .edu>
    Subject: Re: When is a link saturated?

    In article <1991Jan20.040130.18339@quick.com> srg@quick.com (Spencer Garret
    t) writes:
    >-> I don't understand why the "remember the first exchange" is necessary. 
    >-> Both telnet and rlogin use a reserved port number that appears in eithe
    r
    >-> the source or destination TCP port fields on *every* packet that is
    >-> routed for the entire session.
    >
    >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.
    -- 
    ---
    Artificial Intelligence: What some programmers produce.
    Artificial Stupidity:    What the rest of us produce.

>>> The above ( multiple sessions ) is certainly true. Additionally,
>>> it is worth noting based on past development efforts:

>>> () TCP, in lieu a formal session layer, allows flexibility that facilitates
>>>    not only 'one to many' but  also 'many to many' or 'many to one' address
>>>    mapping and resulting entity or process association. 
>>>
>>>    OSI does much the same but in an ostensibly more convulatuted fashion,
>>>    i.e. cum more overhead.

>>> () The above has proven helpful in many implementations that desire a high
>>>    degree of concurrency ( as noted above ) or paralellism of processing.

>>>    This has been true whether the implementation was running 'inetd' or
>>>    some other os-based process level dispatch that is network addressable.

>>> () It works because most, if not all, transport or application level inter-
>>>    faces to TCP ( I have seen ) use logical port assigments which permit 
>>>    loose association with a 'well known' ( reserved if you will ) network
>>>    port. 

>>>    Hope this helps to clarify or add further background to this
>>>    increasingly important area, Concurrency of processing in TCP based 
>>>    networks.(note: my observations are limited to TCP transport. UDP merits
>>>    a different discussion )

      George Williams