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:
|Local Location Broker (LLB)||An RPC server that maintains a database of information about objects and interfaces located on the local host. The LLB provides access to its database for application programs and also provides the Location Broker forwarding service. An LLB must run on any host that runs RPC servers. The LLB runs as the daemon program, llbd.|
|Global Location Broker (GLB)||An RPC server that maintains information about objects and interfaces throughout the network or internet. The GLB can run as either the glbd or nrglbd daemon program. The glbd daemon supports replicatable GLB databases in the network; the nrglbd daemon does not.|
|Location Broker Client Agent||A set of library routines that application programs call to access LLB and GLB databases. Any client using Location Broker library routines is actually making calls to the client agent. The client agent interacts with LLBs and GLBs to provide access to their databases.|
The following Location Broker Software figure shows the relationships among application programs, the Location Broker components, and the Location Broker databases.
Figure 5-1. Location Broker Software. This diagram shows the local host contains the following components which are connected: local application, client agent, LLB, and LLB database. The GLB Host contains the following components which are connected: GLB and the GLB Database. The remote host contains the following components which are connected: remote application and the client agent. The client agent in the local host is connected to the GLB. The LLB in the local host is connected to the client agent of the remote host.
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:
|Object UUID||Specifies a universally unique identifier (UUID) of the object.|
|Type UUID||Identifies a unique identifier that specifies the type of the object.|
|Interface UUID||Indicates a unique identifier of the interface to the object.|
|Flag||Specifies a flag that indicates if the object is global (and should be registered in the GLB database).|
|Annotation||Contains 64 characters of user-defined information.|
|Socket Address Length||Specifies the length of the socket address field.|
|Socket Address||Indicates the location of the server that exports the interface to the object.|
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).
Figure 5-2. Client Agent and a Global Location Broker
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 following Client Agent Performing a Lookup at a Known Host figure.
Figure 5-3. Client Agent Performing a Lookup at a Known Host. This diagram shows that after the client agent queries the remote host's LLB, the client can use RPC calls to communicate directly with the requested object.
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.