Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1999-12-16
2004-04-27
Follansbee, John (Department: 2126)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06728788
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates generally to an improved data processing system and, in particular, to a method and apparatus for interprocess or intraprocess communication, specifically remote procedure calling.
2. Description of Related Art
It is known in the art to interconnect multiple computers into a local area network (LAN) to enable such computers to exchange information and share resources. A local area network provides a distributed computing environment in which users can access distributed resources and process applications on multiple computers. Network communications are carried out using so-called communication protocols. By convention, communication architectures in a local area network are typically characterized as conforming to a seven layer model in the following hierarchy: physical layer, logical link layer, network layer, transport layer, session layer, presentation layer and application layer. The physical layer comprises the actual physical devices and medium used to transmit information. The logical link layer frames data packets and controls physical layer data flow, insuring delivery of data regardless of the actual physical medium. The network layer addresses and routes data packets. It creates and maintains a route in the network between a source node and a destination node. The transport layer creates a transport pipeline between nodes and manages the network layer connections. The session layer typically provides remote procedure call (RPC) support, maintains the integrity of the connection between nodes and controls data exchange. The presentation layer encodes and decodes data and provides transparency between nodes. Finally, the application layer provides the interface to end-user processes and provides standardized services to applications.
The seven layer model has many variations depending on the particular network architecture. Thus, for example, in a network architecture based on the TCP/IP (Transmission Control Protocol/Internet Protocol) interface running IBM RISC System/6000™ computer workstations under the AIX Operating System, there is another layer, called the socket layer, that sits between the session and transport layers. The socket layer creates so-called “sockets” which are logical constructs analogous to physical ports. In this architecture, the RPC mechanism is not just supported in the session layer, but also includes functionality of the session layer.
Remote procedure call is the foundation of modern client-server based distributed systems. One well-known distributed system that uses RPC as the basic communication mechanism is Microsoft's DCOM (Distributed Component Object Model). The best-known application using RPC in the Unix world is Sun's NFS (Network File System), which is based on their ONC (Open Network Computing) RPC. In addition, most of the ORB (Object Request Broker) implementations of the OMG's (Object Management Group) CORBA (Common Object Request Broker Architecture) specifications build their remote method calls for object communications on top of a variation of RPC. The Java RMI (Remote Method Invocation) is another variation of the RPC technology.
A known RPC mechanism useful in Distributed Computing Environments (DCE) includes software code provided by the Open Systems Foundation (OSF). The OSF DCE RPC mechanism is used conventionally to manage communication between a “client” and a “server” in a distributed computing environment, with the client requesting a service from a server using a remote procedure call (RPC). A “client” refers to a network participant that is requesting a service accessible somewhere within the computing environment. A “server” provides the requested service to a client. With the OSF DCE RPC mechanism, each client process (namely, a process running on a client machine) has an associated socket created by the socket layer. Each server process likewise is associated with a socket. In response to an RPC, a call directory service returns a data structure, called a “binding handle,” specifying the location of the server process as a network address and the port number where the server process is running. The binding handle is then used by the RPC mechanism to define a communication path between the client process and the server process. The path is defined using IP-based (i.e., network layer) protocol sequences of the Internet Network Address Family (AF_INET) to open the sockets. The path loops down from the client process through the transport and network layers, out on the network and then back up the layers associated with the host on which the server process is running.
Due to its role in distributed processing, RPC is a key factor in the overall performance of a distributed system. There have been various techniques proposed and implemented to improve RPC performance. For example, RPC stubs on both the client side and the server side require a large amount of memory space and large storage space. In U.S. Pat. No. 5,778,228, “Method and System for Transferring Remote Procedure Calls and Responses Over a Network”, a method is disclosed for optimizing the RPC stub routines so as to significantly reduce their impact on system memory and mass storage.
As another example of the need for RPC optimization, the OSF DCE RPC mechanism as described above cannot distinguish whether client and server processes are running on the same host machine. In all cases, the mechanism returns a binding handle to the client process including an AF_INET protocol sequence that sets up a communication path through the transport (TCP or UDP) layer and the network (IP) layer. Communications through TCP use connection-oriented protocol sequences while those through UDP use connectionless protocol sequences. But in either case, when the client and server processes reside on the same host, an RPC generates a so-called loopback message because once the network (IP) layer receives the destination network address, it recognizes that the RPC is “local”; the path must therefore be looped back up through the transport layer to the server process on the applications layer. Because of this loopback requirement, RPCs between client and server processes on the same machine are not optimized from a performance standpoint as they use the transport and network layers unnecessarily.
In U.S. Pat. No. 5,682,534, “Transparent Local RPC Optimization”, a method is disclosed for bypassing heavyweight transport stack operations using local sockets for interprocess calls on the same machine. However, this method still incurs a significant amount of processing overhead for local socket operations and for parameter marshalling and unmarshalling.
Therefore, it would be advantageous to have an improved method and system for optimizing RPCs by completely bypassing RPC setup when possible.
SUMMARY OF THE INVENTION
A method and system for optimizing remote procedure calls by converting the remote procedure call to a local procedure call is provided. A client process resides on a host computer within a distributed data processing system, and the client process requests a remote procedure call for a service procedure. A determination is made as to whether the service procedure is provided by the client process in the following manner: a binding handle of a server process for the service procedure is obtained; a determination is made as to whether the binding handle of the server process points to the client process; and in response to a determination that the binding handle of the server process points to the client process, a positive indication is generated that the service procedure is provided by the client process. In response to a determination that the service procedure is provided by the client process, the service procedure is called using a local procedure call after obtaining a local address for the function within the client process by looking up the service procedure in an interface registry. The conversion of the remote procedure call to a local procedure call is perfo
Ainsworth Spencer James
Bachmann David Werner
Nagarajarao Jayakumar
Wade James Dean
Wei Yi-Hsiu
Follansbee John
International Business Machines - Corporation
Patel Haresh
Roberts Diana L.
Tkacs Stephen R.
LandOfFree
Method and system for converting a remote procedure call to... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for converting a remote procedure call to..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for converting a remote procedure call to... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3207309