My original request read as follows:
======================================================================
Newsgroups: comp.sys.sun.admin
From: C.R.Ritson@newcastle.ac.uk (C R Ritson)
Date: Mon, 18 Jan 1993 17:52:29 GMT
I have recently reported a bug to my vendor (Encore Computer
Corporation) complaining that the getservbyname() lookup was very
slow, and seemed to be using a sequential search through the
services.byname map which we had just created. The response was so
slow that other things were timing out before they got the correct
map entry (we had a big services map).
[ See also item 18 in the FAQ for this newsgroup ]
The response was to send back a modified library which uses a direct
lookup in the services.byname map, using yp_match to do the work.
Encore supplied a new Makefile with the bug-fix, on the assumption
that I wanted a master server with both a services.byname map (keyed
on service name and protocol) and a services.byport map (keyed on
port number and protocol). The services.byname map was then used in
the new getservbyname routine. This looked right to me until I
discovered what the server's maps really contained....
What I found was that our sun servers have a services.byname map
which is keyed on the port number and protocol. They have no
services.byport map.
Can anyone enlighten me as to what services maps are supposed to
exist. Was there once upon a time an error on Sun's part which for
historical reasons cannot now be corrected? Are we stuck with the
following?
services.byname keyed on port number and protocol
services.byport keyed on service name and protocol.
These are my own personal opinions, and are not intended to be a
criticism of either Sun or Encore. I just want to know if I can use a
services map with keyed access.
======================================================================
These are slightly condensed highlights from the discussion so far. If
anyone wants the full un-edited set of replies, please let me know,
ASAP.
Chris Ritson <C.R.Ritson@newcastle>
======================================================================
From: Steinar.Haug@delab.sintef.no (Steinar Haug)
Date: 18 Jan 93 20:32:29 GMT
Organization: SINTEF DELAB, Trondheim, Norway.
As far as I know there is definitely an error on Sun's part, and you should
complain *strongly* to Sun about this. It has been pointed out many times.
But you're not stuck with this. At least on your Suns you can replace the
shared library version of libc with a version which does lookup in a *real*
services.byname map. Code to do this already exists, you can pick it up with
anonymous FTP from kaa.cs.few.eur.nl, file ~/pub/getservent.tar.Z. To use it,
you will of course have to make a new NIS map which is keyed on service name
and protocol.
At DELAB, we run a mixed Sun/HP environment, and we cannot rebuild the shared
libraries on our HPs (wonder when HP will let us do this?). Therefore we can't
simply change the "services.byname" map to have different keys, since the code
on the HPs would be sorely confused. What I did instead was to create a new
map, called "services.byname2", which contains the *real* (keyed on name and
protocol) services map, while the original "services.byname" still exists for
compatibility with the HPs. This was an extremely simple (two line) change to
the code in getservent.c.
On all our Suns we now use the modified libc, and it works like a charm. The
reduction in network traffic to our NIS servers, for instance when restarting
inetd, is dramatic.
======================================================================
Date: Mon, 18 Jan 93 13:54:06 PST
From: guy@auspex.com (Guy Harris)
Cc: blyon@legato.com
Oh, Bob....
Once upon a time I noticed the same thing, and I think I asked Mr. Lyon
why the "by port number" map was called "services.byname".
Did I indeed ask that and, if so, what was the answer?
We're probably stuck with "services.byname" being keyed on port number
and protocol, because the SunOS "getservbyport()" call looks up the
entry in "services.byname". As such, "services.byport" would end up
being the map keyed by service name and protocol, although Sun's
"getservbyname()" doesn't use that map - it linearly searches the
"services.byname" map instead (at least as of SunOS 4.1.1).
This may be fixed in NIS+.
======================================================================
Date: Mon, 18 Jan 93 16:13:17 PST
From: blyon@Legato.COM (Bob Lyon)
| Did I indeed ask that and, if so, what was the answer?
Indeed you did. The answer is not memorable.
Someone (who will remain nameless) correctly surmised that
the services database needed to be YP-ized. He drew this
conclusion by looking at netstat output.
In less than a morning he got the netstat case implemented
and checked in and worked fine with netstat. This person
was great at stealing code, but not very good at changing
names inside the code. So the new map went in with the
wrong map name and with no design or code review.
It is now history.
By the way, Legato tried using getservbyname() in SunOs 4.1.x
and it often (about 1% of the time) returned NULL rather
than the answer. The bug is not timeout related. Like most
other code, we hard wired the values into our code...
======================================================================
Date: Mon, 18 Jan 93 16:40:55 PST
From: guy@auspex.com (Guy Harris)
Cc: chuck.mcmanis@sun.com
| This may be fixed in NIS+.
According to the SunOS 5.x "passwd(4)", the "passwd" database comes from
"the NIS maps passwd.byname and passwd.bygid" (by which they presumably
mean "passwd.byuid") "and the NIS+ table passwd".
The "nis(1)" manual page seems to be saying that NIS+ tables have
multiple keys per entry, so that you don't need separate "passwd.byname"
and "passwd.byuid" maps, but can just have one "passwd" table.
As such, it may be the case that the "services" NIS+ table can be
searched either by service name and protocol, or by port and protocol.
Is that the case, Chuck?
However, in SVR4, you're "supposed" to treat transport endpoints as
having addresses that *aren't* necessarily "[host address, port]" paris,
because that's Politically Incorrect in the ISO world; the official
name-to-address mapping routines in SVR4 map host name + service name
into a transport address. The SunOS 5.x "getservbyname(3N)" manual page
indicates that "getservbyname()" is implemented in terms of
"netdir_getbyname()", and may be somewhat Internet-protocol-specific.
======================================================================
Chris Ritson
-- EMAIL: C.R.Ritson@newcastle.ac.uk Chris Ritson, PHONE: +44 91 222 8175 Department of Computing Science FAX : +44 91 222 8232 University of Newcastle upon Tyne, TELEX: uk+53654-UNINEW_G UK, NE1 7RU
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:24 CDT