1. Field of the Invention
The present invention is related to networking computer systems, and more specifically to a method and system for implementing remote procedure call (RPC) programs in a manner that ensures their accessibility.
2. Description of Related Art
In networked computer systems, and in particular, in systems that include multiple network interfaces per processing node, there are typically multiple sub-nets and in larger networks, multiple domains. Each sub-net or domain will typically include many computer systems, each of which is executing an operating system that may provide RPC programs to client applications both within the same computer system, and to remote RPC clients that are connected to the computer system through a network path. The daemon that manages RPC connections is named rpcbind.
An RPC application registers one or more RPC programs that it supports by calling an interface on rpcbind daemon: rpcb_reg( ) The rpcb_reg( ) call provides an RPC program number, and a successful call registers the program provider as the provider of that program. Subsequent rpcb_getaddr( ) calls to the rpcbind daemon by prospective clients provide a program number, which the rpcbind daemon satisfies by returning a universal network address associated with the RPC application that supports the RPC program that was requested.
However, in the multi-horned system described above, a prospective RPC client cannot necessarily use the address for an RPC application that the RPC bind daemon may return. For example, if an RPC application that serves a particular RPC program is on a first sub-net of the network and the prospective client is on a second sub-net, the address returned by the RPC bind daemon for the RPC application in the first sub-net may not have a routing path from the second sub-net. Further, even if such a path is present, there may be a firewall or filtering present, or the route may be very inefficient. The particular location of a prospective RPC client is typically not known, since the request may have originated anywhere in the network and from any network adapter connected to the operating system hosting the rpcbind daemon reached by the request. Further, when complex network connections are involved, a request could prospectively reach multiple rpcbind daemon instances and/or an rpcbind instance could potentially be aware of multiple applications that service a program number, configurations that are either avoided, or in the case of multiple applications servicing a program number, typically rejected by the rpcbind daemon. While alternate rpcbind daemons and/or multiple RPC applications servicing a program number could provide improved connectivity to RPC programs, the structure of the RPC mechanism typically prohibits such arrangements.
Therefore, it would be desirable to provide a rpcbind daemon that can provide accessible RPC program addresses in a network including multi-horned computer systems. It would further be desirable to provide RPC functionality for a given program number from multiple applications and to provide multiple distributed rpcbind daemons within a network.
The invention is embodied in a computer-performed method, computer program product and computer system that respond to RPC program address requests in a manner that ensures accessibility to the application providing the RPC program by a requesting client. The computer system is a system that carries out the steps of the method and the computer program product is a computer-readable storage medium containing program instructions for carrying out the steps of the method.
The method receives a request for the address of an RPC program from a prospective RPC client. A network path to a RPC application providing the program is selected and the corresponding universal address returned, by determining through which of multiple network interfaces the prospective client can access an RPC application, which may effectively select an RPC application, accordingly. If multiple network paths to an RPC application providing the program number are accessible to the prospective client (and optionally multiple RPC applications), then a heuristic can be applied to select the network path to the RPC application, such as a network path to the prospective client that is not firewalled, has the least number of links, has a lowest cost, is set as “preferred” by the system, and so forth.
The routing path to the prospective client can be discovered using a module that monitors the network stack for rpcb_getaddr( ) requests and builds a table of entries relating the requestors to the particular network interface from which the rpcb_getaddr( ) requests arrived. The entries are discarded according to an aging criteria to maintain proper dynamics of the network. When an RPC program request arrives, the rpcbind daemon can query the module to obtain an interface identifier. The interface identifier is then used to select the proper network path to use to connect an RPC application to the prospective client.
The foregoing and other objectives, features, and advantages of the invention will be apparent from the following, more particular, description of the preferred embodiment of the invention, as illustrated in the accompanying drawings.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives, and advantages thereof, will best be understood by reference to the following detailed description of the invention when read in conjunction with the accompanying Figures, wherein like reference numerals indicate like components, and:
The present invention relates to remote procedure call (RPC) services, and specifically with techniques to ensure that an RPC client receives an accessible universal address for an RPC application or program, in particular in multi-horned systems where a client may exist on a different sub-net than some of the RPC servers within the system. Upon receiving an rpcb_getaddr( ) request that connects a prospective RPC client to a program interface, the rpcbind daemon determines through which network interface(s) the RPC client can access the system and selects a network path over which the prospective RPC client can access the RPC application, e.g. by selecting a universal network address to return to the prospective RPC client. If multiple network paths to the RPC application are accessible by the prospective RPC client, a heuristic may be used to select from among the multiple network paths, such as least-cost, minimum links, not firewalled, system preferred, or other criteria that indicates a particular network interface and/or network path is preferred over another. The techniques of the present invention can also be used to select from among multiple RPC applications that service a given program number, since the universal address/network path returned by the rpcbind daemon of the present invention also uniquely specifies the RPC application. Further, multiple rpcbind daemons could potentially exist in a network without creating a conflict, since an rpcbind daemon that is reachable by a prospective client should then be able to identify which network interface to use in selecting an RPC application to provide the requested RPC program.
A service module provides physical network interface identification in response to receiving a request from the rpcbind daemon. The module may provide a system application programming interface (API) or may be an RPC application that provides a program that returns the network interface identifier given the prospective client's response address as input. The module monitors network traffic for rpcb_getaddr( ) requests, generally by insertion as part of the network stack. When an rpcb_getaddr( ) request is detected, the corresponding requestor address is inserted in a table as an entry that also includes the network interface identifier. The entries are retired according to an aging function to match the dynamic nature of the network. When an rpcb_getaddr( ) request is received by the rpcbind daemon, the rpcbind daemon queries the service module to return the network interface identifier for the provided prospective client's response address. When the request to map the prospective client's response address to a network interface is received by the module, the module returns the interface identifier from an entry in the table that corresponds to the client's response address.
Referring now to
In the illustrated example, workstation memory MEM includes an application program 14 that uses RPC services and is therefore an RPC client. Application program 14 contacts rpcbind daemon 12 to obtain an address of an RPC application 16 that provides a needed RPC program number. In the present invention, the universal address provided in response to the request (a rpcb_getaddr( ) request) is selected from among multiple network paths by which the prospective RPC client (application program 14) can read RPC application 16. Exemplary processes and structures for performing the selection are set forth in further detail below. The present invention concerns RPC techniques that are not limited to a specific computer system configuration, workstation/server arrangements or requiring workstations at all, as some embodiments of the present invention are applicable to multiple server computer systems in which RPC services accessed on a first server by a second server. Finally, the specification of a server 20A and a workstation 10A and the location of their specific memories MEM and SMEM does not imply a specific client-server relationship or hierarchical organization, as the techniques of the present invention may be employed in distributed systems in which no particular machine is identified as a server, but at least one of the machines provides an RPC daemon and RPC applications for providing RPC program interfaces, and in which addresses of the RPC applications are mapped according to techniques of the present invention.
As illustrated in
Referring now to
Referring now to
Referring now to
Referring now to
In the illustrated example, an additional RPC application 16A is depicted as executing within server 20C, an additional rpcbind daemon 12A is depicted as executing within server 20B, and an additional RPC client 14A is illustrated as executing within workstation 10C, for generality. Since there are multiple rpcbind daemon instances 12, 12A, an rpcb_getaddr( ) request will generally be processed by the first rpcbind daemon that filters the network stack of a machine in the network path over which the rbcp_getaddr( ) request travels. So, for example, if RPC client 14 issues an rpcb_getaddr( ) request, rpcbind daemon 12 will generally respond to the request as described above with reference to
While the invention has been particularly shown and described with reference to the preferred embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form, and details may be made therein without departing from the spirit and scope of the invention.
Number | Name | Date | Kind |
---|---|---|---|
5452459 | Drury et al. | Sep 1995 | A |
5491800 | Goldsmith et al. | Feb 1996 | A |
5511197 | Hill et al. | Apr 1996 | A |
5548723 | Pettus | Aug 1996 | A |
5761507 | Govett | Jun 1998 | A |
6101188 | Sekine et al. | Aug 2000 | A |
6295276 | Datta et al. | Sep 2001 | B1 |
6321275 | McQuistan et al. | Nov 2001 | B1 |
6728788 | Ainsworth et al. | Apr 2004 | B1 |
6901072 | Wong | May 2005 | B1 |
7075895 | Hanam | Jul 2006 | B1 |
7145866 | Ting et al. | Dec 2006 | B1 |
7779086 | Gammo et al. | Aug 2010 | B1 |
7853962 | Romano et al. | Dec 2010 | B1 |
7913262 | Brabson et al. | Mar 2011 | B2 |
20030140124 | Burns | Jul 2003 | A1 |
20050152355 | Henriques | Jul 2005 | A1 |
20060045098 | Krause | Mar 2006 | A1 |
20060268863 | Chang et al. | Nov 2006 | A1 |
20060274752 | Jain et al. | Dec 2006 | A1 |
20070283367 | Brabson et al. | Dec 2007 | A1 |
Number | Date | Country | |
---|---|---|---|
20110138404 A1 | Jun 2011 | US |