Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!kwe
From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Multiple TCP/IP servers on one Host.
Message-ID: <24663@bu-cs.BU.EDU>
Date: 31 Aug 88 16:55:26 GMT
References: <16115.8808301546@brahma.cs.hw.ac.uk>
Reply-To: kwe@buit13.bu.edu (Kent England)
Followup-To: comp.protocols.tcp-ip
Organization: Boston Univ. Information Tech. Dept.
Lines: 54

In article <16115.8808301546@brahma.cs.hw.ac.uk>
> keith@tarantula.spider.co.UK (Keith Mitchell) writes:
>
>In <605@prlhp1.prl.philips.co.uk>, Martin Holland raises the issue of how
>to get several terminal servers acting in "milking machine" mode to the same
>host, to appear as one to other nodes on the network. 
>
	There are actually two problems: How to assign multiple
rotaries (telco terminology) to one box and how to assign multiple
boxes to one rotary.  It seems to me the solutions to both problems are
related and require particular capabilities of both client and host
server telnet implementations.

>This is an interesting problem, and while there are a number of possible
>approaches to solving which fit in with the TCP/IP archectiture, none are
>completely satisfactory, particularly if the requirement is for a scheme
>which is transparent to the incoming (Telnet client) caller.
>
	Seems to me that name server lookup can handle this
transparently, so long as the resolver in the client telnet takes
reasonable actions on the response received.
>
>Another way is to fudge name lookup in some way. If a name server could be
>got at, it could return a different address in response to the same user
>string depending on how loaded the telnet servers are.

	This is the same situation as a multi-homed host and I believe
the name server is set up to handle this with multiple records for a
single host.  Just substitute the concept of "multi-box rotary" for
"multi-homed host".  Name servers return all addresses listed for a
given name.  The resolver on the telnet client would need to be smart
enough to try all returned names before giving up on the connection
request.  So the problem becomes one for the client (ie terminal)
server and not the host (ie, milking machine) server.  If the client
server simply tries the first address returned and drops others, then
this approach fails.

	The other situation is different.  The host server must be
able to associate a subset of its ports to one IP address, possibly
down to one IP address per port.  Then the client telnet requests
service by name and receives either the single IP address that the
host server will associate to, say, three serial ports, or it receives
three separate responses corresponding to the three separate ports of
that rotary.  In the first case, the client only has to try one
connection and the host server handles port contention itself.  The
second case is the same as the multi-box rotary problem above and the
client server must be able to try multiple addresses in sequence
before aborting the attempt and reporting back to the user.

	So it seems to me that the solution is partly in client telnet
(try all addresses in sequence) and partly in the host telnet
(associate one or more ports to one IP address for efficiency).

	Kent England, Boston University