🚀 go-pugleaf

In article <4b278ff2.20b6d@apollo.HP.COM>, mishkin@apollo.HP.COM
(Nathaniel Mishkin) writes:

> In article <jwright.645863199@quonset>, jwright@cfht.hawaii.edu (Jim
> Wright) writes:
|> Could either/both of you address the issue of "server selection".
|> As I understand it now, RPCs have to be directed at a specific
|> server, while NCS provides some sort of "broker" to arbitrate calls
|> at runtime.  Might this be a significant differentiation?

> I think there's probably some bit of confusion here.  (It's a little
> hard to tell since I never got a copy of the innermost article above.)
> The "LB" consists of two pieces:  The Global Location Broker (GLB) and
> the Local Location Broker (LLB).
> 
> An LLB runs on every machine and does the forwarding job (i.e.,
> transparently forwards a request sent to the MACHINE to the appropriate
> server PROCESS on the machine).  We believe that the facts that this
> scheme results in only one real network message exchange and that it's
> all transparent to the application are important.
> 
> The GLB is a place a client can look to find the address of a particular
> machine.  Clients make an RPC to the GLB and then use the results to
> make a call to another machine.  While these two steps can be pretty much
> concealed (via NIDL's auto-binding mechanism), from the point of view
> of the wire, two message exchanges occur, as opposed to the one that
> occurs when using (just) the LLB (i.e., because you know the machine
> you want to talk to a priori).

...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?

Netwise uses the native naming(s) that is provided in the environment.
Some environments (e.g., NetBIOS) provide something similar to
rendezvous by via a "locator". Contrary to earlier postings, Sun's native
rpcbind naming provides a rendezvous-like service via datagram
broadcast:

1. client broadcasts to rpcbind servers for PROG #, VERS #, REV #
2. if a machine's rpcbind has had a worker register with PROG #, VERS #, the
   request is forwarded to the worker.

Some naming environments do not provide anything like rendezvous.

Rendezvous is a useful thing. More generally, dynamic X.500-style
naming/directory services seem to be the wave of the future. There appear
to be several problems in the current LLB/GLB strategy:

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.

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.

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?


Phil Earnhardt          Netwise, Inc.  2477 55th St.  Boulder, CO 80301
Phone:303-442-8280      UUCP: onecom!wldrdg!pae
My opinions do not reflect any official position of Netwise.