The Location Broker provides clients with information about the locations of objects and interfaces. Servers register their socket addresses and the objects and interfaces to which they provide access with the Location Broker. Clients issue requests to the Location Broker for the locations of objects and interfaces they wish to access. The broker returns database entries that match an object, type, interface, or combination, as specified in the request.
The Location Broker also implements the Remote Procedure Call (RPC) message-forwarding mechanism. If a client sends a request for an interface to the forwarding port on a host, the Location Broker automatically forwards the request to the appropriate server on the host.
The Location Broker consists of these interrelated components:
The Location Broker Software figure shows the relationships among application programs, the Location Broker components, and the Location Broker databases.
Each entry in a Location Broker database contains information about an object and an interface, and it contains the location of a server that exports the interface to the object. The records in a database entry are as follows:
Each database entry contains one object UUID, one interface UUID, and one socket address. This means a Location Broker database must have an entry for each possible combination of object, interface, and socket address. For example, the database must have 10 entries for a server that does the following:
The server must make a total of 10 calls to the lb_$register routine to completely register its interfaces and objects.
You can look up Location Broker information by using any combination of the object UUID, type UUID, and interface UUID as keys. You can also request the information from the GLB database or from a particular LLB database. Therefore, you can obtain information about all objects of a specific type, all hosts with a specific interface to an object, or even all objects and interfaces at a specific host. For example, you can find the addresses of all remotely available array processors by looking up all entries with the arrayproc type.
The Location Broker client agent is a set of library routines that applications use to access and modify the LLB and GLB databases. When a program issues any Location Broker call, the call goes to the local host's client agent. The client agent does the work to add, delete, or look up information in the appropriate Location Broker database.
The Client Agent and a Global Location Broker figure illustrates a typical case in which a client requires a particular interface to a particular object, but does not know the location of a server exporting the interface to the object. In this figure, an RPC server registers itself with the Location Broker by calling the client agent in its host (step 1a). The client agent, through the LLB, adds the registration information to the LLB database at the server host (not shown). The client agent also sends the information to the GLB (step1b). To locate the server, the client issues a Location Broker lookup call (step 2a). The client agent on the client host sends the lookup request to the GLB, which returns the server location through the client agent to the client (step 2b). Then, the client can use RPC calls to communicate directly with the located server (steps 3a and 3b).
If a client knows the host where the object is located but does not know the port number used by the server, the client agent can query the remote host's LLB directly, as illustrated in the Client Agent Performing a Lookup at a Known Host figure.
The LLB, which runs as the llbd daemon, maintains a database of the objects and interfaces exported by servers running on the host. In addition, it acts as a forwarding agent for requests.
An llbd daemon must be running on hosts that run RPC servers. However, it is recommended to run an llbd daemon on every host in the network or internet.
The database maintained by the LLB provides location information about interfaces on the local host. This information is used by both local and remote applications. To look up information in an LLB database, an application queries the LLB through a client agent. For applications on a local host, the client agent accesses the LLB database directly. For applications on a remote host, the remote client agent accesses the LLB database through the LLB process. You can also access the LLB database manually by using the lb_admin command.
The LLB's forwarding facility eliminates the need for a client to know the specific port a server uses. It is intended to limit the number of well-known port numbers reserved for specific purposes.
The forwarding agent listens on one well-known port for each address family. It forwards any messages received to the local server that exports the requested object. Forwarding is particularly useful when the requester of a service already knows the host on which the server is running. For example, you do not need to assign a well-known port to a server that reports load statistics, nor do you need to register the server with the GLB. Each such server registers only with its host's LLB. Remote clients access the server by specifying the object, the interface, and the host, but not a specific port, when making a Remote Procedure Call.
The Global Location Broker (GLB), which can run as either the glbd daemon or the nrglbd daemon, manages information about the objects and interfaces available to users on the network. In an internet, at least one GLB must be running on each network.
The GLB database is accessed manually by using the lb_admin command. The lb_admin command is useful to manually correct errors in the database. For example, if a server starts while the GLB is not running, you can manually enter the information for the server in the GLB database. Similarly, if a server terminates abnormally without unregistering itself, you can use the lb_admin command to manually remove its entry from the GLB database.
