From owner-freebsd-current@FreeBSD.ORG Wed Jul 7 20:49:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07FE716A4CE for ; Wed, 7 Jul 2004 20:49:19 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA91B43D2D for ; Wed, 7 Jul 2004 20:49:18 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i67KnI2G025778; Wed, 7 Jul 2004 13:49:18 -0700 (PDT) Received: from [10.1.1.193] (nfw2.codefab.com [199.103.21.225] (may be forged)) (authenticated bits=0)i67KnH0t029003; Wed, 7 Jul 2004 13:49:18 -0700 (PDT) In-Reply-To: <20040707181327.GE54749@over-yonder.net> References: <6.1.0.6.1.20040707033352.03dbca18@popserver.sfu.ca> <20040707172558.GA17351@Odin.AC.HMC.Edu> <20040707181327.GE54749@over-yonder.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1CDCA4DE-D057-11D8-9FB6-003065ABFD92@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Wed, 7 Jul 2004 16:49:17 -0400 To: current@freebsd.org X-Mailer: Apple Mail (2.618) cc: Colin Percival Subject: Re: bringing /etc/services up to date X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2004 20:49:19 -0000 On Jul 7, 2004, at 2:13 PM, Matthew D. Fuller wrote: > On Wed, Jul 07, 2004 at 10:25:58AM -0700 I heard the voice of > Brooks Davis, and lo! it spake thus: [ ...with regard to Colin's proposal to make /etc/services much larger... ] >> Can you check how much this change slows down inetd startup with a >> few services enabled? The traditional argument against this is that >> reading the whole IANA service file takes too long. If the >> difference isn't measurable, the the argument is bogus, but I'm not >> sure that's the case. Oh, the difference is easy to measure: a trivial program which calls getservbyport() for the first 1000 ports takes 2.17 seconds to run with the 73K /etc/services file. Using a 106K services file from nmap-3.51 takes 2.95 seconds. Using a 587K /etc/services file from http://www.iana.org/assignments/port-numbers gives a time of 16.85 seconds, so the lookup time seems to be closely linear to the file size, about 2.8 ms per lookup per 100K worth of /etc/services file, at least on the machine I was using to test. :-) >> The alternative solution would be to add >> optional database backing. That shouldn't be too hard to do, and >> there are several examples to work from. > > In theory, any program reading the data should be using > getservby{name,port}() and friends, since it avoids code duplication > and handles NIS and such already. So, hashing it into a DB and fixing > those functions to match would probably work. Matthew is exactly correct, programs should be using getservby*(). Lots of systems implement some external caching system (nscd, lookupd, etc) which those library calls access rather than iterating through the /etc/services file and related sources directly within each process which calls getservby*(). I'm not sure whether the sources for Solaris' nscd are handy, but I believe the sources for lookupd and friends are at: http://developer.apple.com/darwin/projects/opendirectory/ -- -Chuck PS: Sources for the trivial program mentioned above: #include int main(int argc, char *argv[]) { int port; struct servent *se; for (port = 1; port <= 1000; port++) { se = getservbyport(port, "tcp"); } }