penneyj@servio.UUCP (D. Jason Penney) (03/16/89)
I want some opinions whether or not what I have been seeing should be regarded as a TCP/IP bug or a feature. We have some entries in our services database that are above 1024 and refer to services that are usually not in use. When we call bind() with the requested port INADDR_ANY, bind() *can*, upon occasion, actually return a port that is listed in the services database. I think it is bug. Suppose a booting system invokes two different services, both of which allocate both a predeclared port (from the services database) and a wildcard port. In theory, it might never be possible for the system to boot properly because the wildcard bind allocates the second service's predeclared port. I have seen this problem on SunOS, VAX/VMS Wollongong (WIN) TCP/IP, and an unnamed System V Unix derivative. Is there any reason I shouldn't call up these vendors and tell them it's a bug? -- D. Jason Penney Ph: (503) 629-8383 Servio Logic Corporation uucp: ...ogccse!servio!penneyj 15220 NW Greenbrier Parkway #100 Beaverton, OR 97006
ted@ultra.UUCP (Ted Schroeder) (03/18/89)
D. Jason Penney writes: > We have some entries in our services database that are above 1024 and > refer to services that are usually not in use. When we call bind() > with the requested port INADDR_ANY, bind() *can*, upon occasion, actually > return a port that is listed in the services database. > I think it is bug. Suppose a booting system invokes two different > services, both of which allocate both a predeclared port (from the > services database) and a wildcard port. In theory, it might never > be possible for the system to boot properly because the wildcard > bind allocates the second service's predeclared port. > I have seen this problem on SunOS, VAX/VMS Wollongong (WIN) TCP/IP, > and an unnamed System V Unix derivative. > Is there any reason I shouldn't call up these vendors and tell them > it's a bug? This is perfectly reasonable behavior. All you've told TCP/IP is to get an unused port number. Having a well-defined port in your services table does not make the port "in use". It only means that you've now got a name to use "getservbyname" with. If you really want to keep these ports reserved, then you'll have to have a listen hung on them or something. Ted Schroeder ted@Ultra.com Ultra Network Technologies ...!ames!ultra!ted 101 Daggett Drive San Jose, CA 95134 408-922-0100 Disclaimer: I don't even believe what I say, why should my company?
jam@RADC-LONEX.ARPA (Joel A. Mussman) (03/18/89)
>From: killer!rpp386!ditka!bucket!servio!penneyj@ames.arc.nasa.gov > >I want some opinions whether or not what I have been seeing should >be regarded as a TCP/IP bug or a feature. > >We have some entries in our services database that are above 1024 and >refer to services that are usually not in use. When we call bind() >with the requested port INADDR_ANY, bind() *can*, upon occasion, actually >return a port that is listed in the services database. > >I think it is bug. Suppose a booting system invokes two different >services, both of which allocate both a predeclared port (from the >services database) and a wildcard port. In theory, it might never >be possible for the system to boot properly because the wildcard >bind allocates the second service's predeclared port. > >I have seen this problem on SunOS, VAX/VMS Wollongong (WIN) TCP/IP, >and an unnamed System V Unix derivative. > >Is there any reason I shouldn't call up these vendors and tell them >it's a bug? The only definition I have ever seen puts services below 1024. Bind() doesn't actually know what ports services reside at, and there probably isn't any simple way for it to find out. On UNIX applications automagically get a port above 1024 based on the idea that services are below 1024. But that is a UNIX convention, not universal. 4.3BSD UNIX declares that supposedly non-privileged services should have port numbers above 5000, which of course would prevent bind() from getting to them on any normal machine (if you can support that many open sockets, and still maintain performance, can I come work for you?) You have no contest on your argument that this is a bug, and on two counts. First, TCP/IP as a protocol doesn't provide for service allocation. It just allows connections to be established. Services are a soft flexible construct above the network protocol level. Second, the network by convention has placed all service port assignments below 1024. If your's are above, they are non-standard network services, and therefore conflicts fall outside of the rules. You can't have a bug if there aren't any rules to follow. Joel A. Mussman