Path: utzoo!attcan!uunet!lll-winken!csd4.milw.wisc.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!RADC-LONEX.ARPA!jam
From: jam@RADC-LONEX.ARPA (Joel A. Mussman)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Interaction of wildcard bind() with services database
Message-ID: <8903172052.AA16042@radc-lonex.arpa>
Date: 17 Mar 89 20:52:10 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 46

>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