Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!apollo!apollo.hp.com!mishkin From: mishkin@apollo.HP.COM (Nathaniel Mishkin) Newsgroups: comp.protocols.misc Subject: Re: RPC Technologies Message-ID: <4b69b513.20b6d@apollo.HP.COM> Date: 5 Jul 90 18:26:00 GMT References: <4b423481.20b6d@apollo.HP.COM> <1990Jul5.040529.16093@athena.mit.edu> <1990Jul5.041344.16511@athena.mit.edu> Sender: root@apollo.HP.COM Reply-To: mishkin@apollo.HP.COM (Nathaniel Mishkin) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Lines: 86 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