Re: Port Collisions


J. Spencer Love (JSLove@MIT-MULTICS.ARPA)
Sat, 17 May 86 17:19 EDT


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?



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