Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!tut.cis.ohio-state.edu!ucbvax!ultra.UUCP!ted
From: ted@ultra.UUCP (Ted Schroeder)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Interaction of wildcard bind() with services database
Message-ID: <8903172034.AA24396@bottom.ultra.com>
Date: 17 Mar 89 20:34:53 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 33

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?