Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!decwrl!ucbvax!MIT-MULTICS.ARPA!JSLove From: JSLove@MIT-MULTICS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Port Collisions Message-ID: <860517211919.829547@MIT-MULTICS.ARPA> Date: Sat, 17-May-86 17:19:00 EDT Article-I.D.: MIT-MULT.860517211919.829547 Posted: Sat May 17 17:19:00 1986 Date-Received: Mon, 19-May-86 20:24:16 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 63 Approved: tcp-ip@sri-nic.arpa Apparently the most controversial thing that I said in my last message was that I thought all the TCP services should be supported by the service multiplexor. The service side of the multiplexor could offer two types of service: service associated with a port number and service not associated with a port number. If no multiplexor service is associated with a port number, then the services are divided into two groups: those available by contact name, and those available by local port. It would probably be simpler to implement the service side of the multiplexor this way. However, from my point of view, if ANY service is available by both mechanisms, then the simplest way to implement it is to have the multiplexor able to access ALL well known TCP services which are available by port number. By "well known" services, I mean services where one or more server processes will accept any number of connections for the service. This has several advantages. First, I can easily imagine circumstances where for some service, access by both methods is desired, perhaps temporarily during cutover. Second, the multiplexor service list can easily list all the TCP services offered, not just those offered through the multiplexor. I would like to be able to obtain complete symbolic service lists. The biggest and most controversial advantage is that I think the Internet made a big mistake in not using contact names in general in this way. There is a simple way of proving me wrong: implement the service multiplexor and see if, once they become fairly widespread, there does not appear a definite preference for using the multiplexor for new applications indefinitely. I am not suggestion that existing user programs like TELNET be converted. I am noting my belief that this will seem like a good idea later. If this belief is mistaken, the multiplexor will still be useful for addressing the needs of stream protocol developers. Rather than implement TCBs which have no local port number associated with them, I expect that the service port multiplexor would be simplest to implement by having the server scan a list of listening TCBs. This means that every service would be available by both a port number and a multiplexor name. The services like TELNET would have "well known" port numbers from 1 to 255, while private services could be available on more obscure or even randomly chosen higher numbered ports. If all services are available both ways, it is true that there is some duplication of effort. However, the user sides need not change. In the near term, we can't expect every host to run the multiplexor, so user programs should still contact services with assigned numbers by the port numbers. Changing user programs may be considered only if the multiplxor servers of this type become nearly universal. Special operations like the service list might be implemented by passing off the connection to a service which lists the services, or by handing them in the multiplexor server. I would prefer to implement certain standard reserved operations like the service list as part of the multiplexor protocol specification, so this choice may be covered by an eventual specification. I'd rather see symbolic names than a service which maps 32 bit service numbers onto 16 bit service numbers, with the mappings from symbolic names to 32 bit numbers done at the user host, and the mapping from 32 bit to 16 bit service identifiers done at the server host. Perhaps this description of the Sun protocol is defective, but if not, why have the 32 bit numbers at all?