Path: utzoo!attcan!uunet!cs.utexas.edu!yale!mintaka!bloom-beacon!pae From: pae@athena.mit.edu (Philip Earnhardt) Newsgroups: comp.protocols.misc Subject: Re: RPC Technologies Message-ID: <1990Jul5.041344.16511@athena.mit.edu> Date: 5 Jul 90 04:13:44 GMT References: <4b423481.20b6d@apollo.HP.COM> <1990Jul5.040529.16093@athena.mit.edu> Sender: onecom!wldrdg!pae Organization: Netwise, Inc. Lines: 76 In article <4b278ff2.20b6d@apollo.HP.COM>, mishkin@apollo.HP.COM (Nathaniel Mishkin) writes: > In article , 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.