Re: Multiple TCP/IP servers on one Host.


Keith Mitchell (mcvax!tarantula.spider.co.uk!keith@uunet.UU.NET)
Tue, 30 Aug 88 16:41:21 -0100


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. I could suggest
upgrading to a SpiderPort, which has 10 lines to the NTS100's 8, but I don't
think this is really a terribly helpful solution.

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.

One approach could be to use the Telnet Reconnection option (NIC 15391). Here
the connection would be established to a Telnet server which knows when
all the ports on one server were full, and could then tell the client
to try connecting to a different server on another Internet address. However,
this requires the Reconnection option to be implemented on all possible
clients. Since I have never heard of any implementations of this with TCP, I
suspect this approach is a non-starter. Has anyone used the Telnet
Reconnection option over TCP for this sort of thing anywhere ?

There is also an issue here of who does the redirect - should there be a
central server which everybody connects to intially, and which keeps track
of everyone's resources so it knows where to redirect to, or should one
server simply redirect to another when it knows it is full ? The issue
of who knows what ports are free is something which generally needs to be
addressed for various schemes like this. For example, the ARP-based scheme
proposed by Mike Brescia <brescia@park-street.bbn.com>.

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 not very nice
as it blurs functional boundaries between name servers, and what one could
call "resource location servers". This suggests another approach, where the
client sends a request out to find out what server(s) have free ports, and
uses the information returned to decide who to actually connect to (cf
BOOTP). Resource Location Protocol (RFC 887) might be a possibility here.

A cleaner scheme for exploiting the name lookup mechanism as a solution is
to have an alias-on-fail arrangement. For example if a given hostname fails,
prepend a "&" and try again. The host table would then look something like:

spport1 192.35.138.1
&spport1 192.35.138.2
spport2 192.35.138.3

The disadvantages with this are again it requires non-standard client
software, and the cumulative time-out delay could get quite large towards
the end of the list (eg. &&&spport1 ).

Clearly with all these schemes there is a trade-off between cleanness of
approach, and how transparent it is to existing hosts. If one approach could
be standardised on as best, then I think some progress towards solving
this problem might be made.

Keith Mitchell

Spider Systems Ltd. keith@spider.co.uk
65 Bonnington Road 65 Bonnington Road keith%spider@uk.ac.hw.cs
Edinburgh, Scotland keith%spider.co.uk@uunet.uu.net
+44 31-554 9424 ...!uunet!ukc!spider!keith



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:14 GMT