Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-03-20
2001-08-07
Coulter, Kenneth R. (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06272559
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to a system and method for transmitting objects between machines in a distributed system and more particularly relates to deferred reconstruction of objects for event notification in a distributed system.
BACKGROUND OF THE INVENTION
Distributed programs which concentrate on point-to-point data transmission can often be adequately and efficiently handled using special-purpose protocols for remote terminal access and file transfer. Such protocols are tailored specifically to the one program and do not provide a foundation on which to build a variety of distributed programs (e.g., distributed operating systems, electronic mail systems, computer conferencing systems, etc.).
While conventional transport services can be used as the basis for building distributed programs, these services exhibit many organizational problems, such as the use of different data types in different machines, lack of facilities for synchronization, and no provision for a simple programming paradigm.
Distributed systems usually contain a number of different types of machines interconnected by communications networks. Each machine has its own internal data types, its own address alignment rules, and its own operating system. This heterogeneity causes problems when building distributed systems. As a result, program developers must include in programs developed for such heterogeneous distributed systems the capability of dealing with ensuring that information is handled and interpreted consistently on different machines.
However, one simplification is afforded by noting that a large proportion of programs use a request and response interaction between processes where the initiator (i.e., program initiating a communication) is blocked waiting until the response is returned and is thus idle during this time. This can be modeled by a procedure call mechanism between processes. One such mechanism is referred to as the remote procedure call (RPC).
RPC is a mechanism for providing synchronized communication between two processes (e.g., program, applet, etc.) running on the same machine or different machines. In a simple case, one process, e.g., a client program, sends a message to another process, e.g., a server program. In this case, it is not necessary for the processes to be synchronized either when the message is sent or received. It is possible for the client program to transmit the message and then begin a new activity, or for the server program's environment to buffer the incoming message until the server program is ready to process a new message.
RPC, however, imposes constraints on synchronism because it closely models the local procedure call, which requires passing parameters in one direction, blocking the calling process (i.e., the client program) until the called procedure of the server program is complete, and then returning a response. RPC thus involves two message transfers, and the synchronization of the two processes for the duration of the call.
The RPC mechanism is usually implemented in two processing parts using the local procedure call paradigm, one part being on the client side and the other part being on the server side. Both of these parts will be described below with reference to FIG.
1
.
FIG. 1
is a diagram illustrating the flow of call information using an RPC mechanism. As shown in
FIG. 1
, a client program
100
issues a call (step
102
). The RPC mechanism
101
then packs the call as arguments of a call packet (step
103
), which the RPC mechanism
101
then transmits to a server program
109
(step
104
). The call packet also contains information to identify the client program
100
that first sent the call. After the call packet is transmitted (step
104
), the RPC mechanism
101
enters a wait state during which it waits for a response from the server program
109
.
The RPC mechanism
108
for the server program
109
(which may be the same RPC mechanism as the RPC mechanism
101
when the server program
109
is on the same platform as the client program
100
) receives the call packet (step
110
), unpacks the arguments of the call from the call packet (step
111
), identifies, using the call information, the server program
109
to which the call was addressed, and provides the call arguments to the server program
109
.
The server program receives the call (step
112
), processes the call by invoking the appropriate procedure (step
115
), and returns a response to the RPC mechanism
108
(step
116
). The RPC mechanism
108
then packs the response in a response packet (step
114
) and transmits it to the client program
100
(step
113
).
Receiving the response packet (step
107
) triggers the RPC mechanism
101
to exit the wait state and unpack the response from the response packet (step
106
). RPC
101
then provides the response to the client program
100
in response to the call (step
105
). This is the process flow of the typical RPC mechanism modeled after the local procedure call paradigm. Since the RPC mechanism uses the local procedure call paradigm, the client program
100
is blocked at the call until a response is received. Thus, the client program
100
does not continue with its own processing after sending the call; rather, it waits for a response from the server program
109
.
The Java™ programming language is an object-oriented programming language that is typically compiled into a platform-independent format, using a bytecode instruction set, which can be executed on any platform supporting the Java virtual machine (JVM). This language is described, for example, in a text entitled “The Java Language Specification” by James Gosling, Bill Joy, and Guy Steele, Addison-Wesley, 1996, which is incorporated herein by reference. The JVM is described, for example, in a text entitled “The Java Virtual Machine Specification,” by Tim Lindholm and Frank Yellin, Addison Wesley, 1996, which is incorporated herein by reference. Java and Java-based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
Because the JVM may be implemented on any type of platform, implementing distributed programs using the JVM significantly reduces the difficulties associated with developing programs for heterogenous distributed systems. Moreover, the JVM uses a Java remote method invocation (RMI) system that enables communication among programs of the system. RMI is explained in, for example, the following document, which is incorporated herein by reference: Remote Method Invocation Specification, Sun Microsystems, Inc. (1997), which is available via universal resource locator (URL)
www.javasoft.com/products/jdk/1.1/docs/guide/rmi/spec/rmiTOC.doc.html.
FIG. 2
is a diagram illustrating the flow of objects in an object-oriented distributed system
200
including machines
201
and
202
for transmitting and receiving method invocations using the JVM. In system
200
, machine
201
uses RMI
205
for responding to a call for object
203
by converting the object into a byte stream
207
including an identification of the type of object transmitted and data constituting the object. While machine
201
is responding to the call for object
203
, a process running on the same or another machine in system
200
may continue operation without waiting for a response to its request.
Machine
202
receives the byte stream
207
. Using RMI
206
, machine
202
automatically converts it into the corresponding object
204
, which is a copy of object
203
and which makes the object available for use by a program executing on machine
202
. Machine
202
may also transmit the object to another machine by first converting the object into a byte stream and then sending it to the third machine, which also automatically converts the byte stream into the corresponding object.
The automatic reconstruction of the objects from the byte stream in this manner sometimes requires unnecessary processing. For example, there are times when a call is made that does not require actual or immedi
Arnold Kenneth C. R. C.
Jones Peter C.
Waldo James H.
Wollrath Ann M.
Coulter Kenneth R.
Finnegan Henderson Farabow Garrett & Dunner L.L.P.
Sun Microsystems Inc.
LandOfFree
Deferred reconstruction of objects and remote loading for... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Deferred reconstruction of objects and remote loading for..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Deferred reconstruction of objects and remote loading for... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2463027