Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!ames!pasteur!ucbvax!tarantula.spider.co.UK!keith From: keith@tarantula.spider.co.UK (Keith Mitchell) Newsgroups: comp.protocols.tcp-ip Subject: Re: Multiple TCP/IP servers on one Host. Message-ID: <16115.8808301546@brahma.cs.hw.ac.uk> Date: 30 Aug 88 17:41:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 62 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 . 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 keith%spider@uk.ac.hw.cs Edinburgh, Scotland keith%spider.co.uk@uunet.uu.net +44 31-554 9424 ...!uunet!ukc!spider!keith