carlson@mrcnext.cso.uiuc.edu (06/25/89)
Obviously, NetInfo can only store one entry for a key ("isis").
Do you really need all 3 entries? Or just keep the tcp one?
You might try to add suffixes to isis, like isis_tcp,
although you will then have to patch the isis code.
This does seem like a real pain, I admit.
(Though so far we haven't noticed any problems.)
Maybe the /services table should have a sub-table for each protocol,
i.e. /services/tcp & /services/udp.
Now that I think about it, it might be very useful to apply this
idea elsewhere. Then we could devide /users into groups (we already
segregate their home directories),
and everything under /machines (hosts) could be organized
the same way as the domain-based host naming system.
Of course, this would require re-writing the get* routines (again),
and may or may not increase search times.
Anybody at NeXT care to comment?
--------------------
Brad Carlson <carlson@mrcnext.cso.uiuc.edu> or <b-carlson@uiuc.edu>
University of Illinos--Micro Resource Center--NeXT guru epsilon@wet.UUCP (Eric P. Scott) (06/26/89)
In article <800009@mrcnext.cso.uiuc.edu> carlson@mrcnext.cso.uiuc.edu writes: >Obviously, NetInfo can only store one entry for a key ("isis"). Wrong. Look at it using the NetInfo application or niutil. nidump is broken. >Do you really need all 3 entries? Or just keep the tcp one? >You might try to add suffixes to isis, like isis_tcp, >although you will then have to patch the isis code. RFC 1010 specifies that port number assignments should be consistent across protocols; for example, "domain" is both 53/udp and 53/tcp. This means that nidump services should output all port/protocol properties for a given key. (Yes, isis can have different port numbers for tcp and udp (but why?); RFC 1010 only speaks for ports <256.) >This does seem like a real pain, I admit. >(Though so far we haven't noticed any problems.) >Maybe the /services table should have a sub-table for each protocol, >i.e. /services/tcp & /services/udp. The further NeXT diverges from BSD compatibility, the more attractive Sun (et al.) workstations become. Hint, hint. You better have a *good* reason for proposing this. Eric P. Scott San Francisco State University EPSCOTT@CALSTATE.BITNET