🚀 go-pugleaf

In article <1990Jul5.041344.16511@athena.mit.edu>, pae@athena.mit.edu
(Philip Earnhardt) writes:
> ...and presumably the GLB is what is doing the "rendezvous". Under
> TCP/IP, the analogue to the LLB is Yellow Pages, or rpcbind, or
> perhaps lookup in a local database. Are we in agreement on the
> terminology?

I think not.  By TCP/IP, I assume you mean Sun RPC on TCP/IP.  If you're
comparing NCS and Sun RPC, then the LLB is somewhat analogous to the
Sun RPC Portmapper not to YP.  (Note that unlike the Portmapper, the
LLB does forwarding/portmapping transparently to the client.) I supposed
you could draw an analogy between the GLB and YP, in that they both
maintain a database for network-wide (as opposed to host-wide) consumption.
However, YP doesn't specify a way to make dynamic updates.  Updates happen
by having an administrator edit some text file and then "push" the data
to slave YP servers.  The GLB supports dynamic update of the database
directly from application processes.

> 1. From what we've heard, the LLB/GLB is an add-on application.
>    Normally, an RPC developer pays for the development toolkit,
>    develops his distributed application, then produces his distributed
>    application without paying a royalty to the toolkit manufacturer
>    (except for the Sun "toolkit", which is free). However, the LLB/GLB
>    must be available on the machine running the distributed
>    application. If the LLB/GLB isn't on the target machine, the
>    provider of the application must get it installed there in order to
>    use it. This is, in effect, a royalty payment to HP for use of the
>    NCS RPC.

To be able to do rendezvous -- i.e., to support clients that don't
essentially hardwire a server host name ("hardwire" == accept on the
command line or take from a local config file) -- you need something
like YP or the GLB.  Sun does not give away the source to YP nor do they
support it in binary form on non-Sun platforms.  Some (all right, many)
vendors have licensed YP from Sun.  We don't give away the GLB.  At NCS
1.5, we sell it in binary form for certain non-HP systems.  We also sell
the source for the entire NCS runtime, including the GLB and LLB, for
somewhere in the small thousands of dollars.  There are no royalties
due from a source licensee who ships binaries derived from licensed source.

To support the hardwired case, yes, you need the LLB on the server system
(as you need the Portmapper for Sun RPC).  The LLB is available in binary
for for various systems (it comes with the NCS runtime binary product).
We should simply allow 3rd parties to re-ship the LLB binary with their
products.  I don't know if we do.  That would be easy enough to fix.
At worst, the 3rd party could buy the NCS runtime source and build and
re-ship the LLB themselves.  (They wouldn't really wouldn't even have
to build it.  After they bought the source, they could just ship our
binaries.  No one could tell the difference after all.  Thus, we should
simply tell people they can re-ship the LLB binary without buying the
source.  We're not making big bucks off of selling the NCS runtime source.)

> 2. Until recently, the GLB was apparently available on very few
>    platforms (e.g. Apollo workstations). Unless you were using those
>    machines, or were willing to have your customers buy one for their
>    network, the GLB was unavailable.

See above.

> 3. In a complex network, there may be serveral subnets. Customers need
>    to have control of the granularity of their subnet broadcasts--they
>    may want to talk to a GLB that's available on their local subnet,
>    or they may want to talk to GLBs on other subnets. Does the LLB/GLB
>    scheme provide control of the granularity of broadcasts?

First of all, it IS possible to have multiple disjoint GLB database in
a single environment.  But I really don't want to argue the virtues of
the GLB.  For all I care, people can use YP to do rendezvous for their
NCS applications.  Nothing precludes it as far as I can tell.  You'd
simply call the appropriate YP functions (yp_bind, yp_match) supplying
the database name and key value and get back a network address or host
name or whatever you've decided to put in your YP map.  You then make
your NCS RPC binding using the returned data.

What I'm saying is that NCS can use "the native naming(s) that is provided
in the environment" too.  We just so happen to supply a "naming system"
of our own too (GLB).  We think it has certain virtues.  We think other
systems have virtues too.  The OSF DCE will have a version of DEC's naming
server, which supports a hierarchical name space based on replicated
database.  Names in the name space can have arbitrary attribute/value
pairs stored with them.  You can use this data to do RPC rendezvous.

                    -- Nat Mishkin
                       Cooperative Object Computing Operation
                       Hewlett-Packard Company
                       mishkin@apollo.hp.com