Electrical computers and digital processing systems: multicomput – Distributed data processing – Client/server
Reexamination Certificate
1999-02-11
2001-11-27
Harrell, Robert B. (Department: 2152)
Electrical computers and digital processing systems: multicomput
Distributed data processing
Client/server
C709S241000, C707S793000, C707S793000, C707S793000, C714S052000, C714S048000, C714S049000
Reexamination Certificate
active
06324567
ABSTRACT:
FIELD OF THE INVENTION
The present invention is related to computer software and more specifically to client-server computer software.
BACKGROUND OF THE INVENTION
Commands sent to a server may be implemented as remote procedure calls. A remote procedure call allows a client to invoke any simple or complex operation on the server by means of a simple procedure call abstraction. An RPC subsystem generates client server stubs to send and receive parameters, freeing the application from this complexity.
Many client-server systems implement each invocation of a command as a separate “round trip” to the server. In such a scenario, each command invocation is delayed due to the network latency, the delay (approximately 4 milliseconds in many networks) that occurs when a client command is sent to the server. In addition, execution of each command requires the server to perform context switches, requiring resources on the server for each such command it receives.
Another problem with single remote procedure calls is that they use system resources extremely inefficiently. Basic system resources include the client, the network and the server. When a client prepares a single RPC, the server and the network connection between the client and server sit idle. When the client sends the RPC over the network, the client and server sit idle. When the server processes the RPC, the client and the network connection between the client and server sit idle. When the response is transmitted to the client over the network, the server and client sit idle. As a result of this inefficiency, the throughput of the system, that is, the number of requests for service processed in a given amount of time, is low.
To amortize the network latency and context switching over several commands, multiple commands may be bundled together. However, this approach does not achieve optimal efficiency of the system. The client still sits idle during transmission of the bundle and its result and during server processing of the bundle. The server and network are still idle while the client assembles the bundle.
Although the efficiency, and therefore, throughput, of a bundled RPC system improves over that of a single-RPC-at-a-time, response time is actually worse, because the first RPC to arrive in the bundle must wait until additional RPCs arrive to produce the bundle. Conventional systems which perform bundling in the client using a process external to the application are especially prone to this problem, because the application had no control over the process. If the client has a high priority RPC, it would be placed by the external process into a queue of the external process waiting for enough RPCs to arrive to produce a bundle before the high-priority RPC would be sent.
It would be possible to allow the client bundling to be performed by the application to give the application more control over the bundling process, allowing high priority commands to be sent right away and low priority commands to be bundled. However, such an approach causes other problems. If the application sends too many small bundles, the overhead associated with calling the RPC system too often will cause its own efficiency problems. If the application sends too few large bundles, the response time problem above is made worse. In addition, the application is made more complex because the application is required to perform its own memory management functions. Another problem with this approach is that it would likely increase the memory requirements in the client because not only would the application require a buffer for storage of the bundle, but when the bundle is provided to a transport process, the transport process will require its own buffer for reliable transmission of the bundle.
Whether the bundling is performed by the application or an external process, the error handling required to recover from errors becomes extremely complex because there may be outstanding RPCs at the time the error occurs and correct handling of any error may depend on which command caused the error.
Therefore, a system and method is desirable that improves the efficiency and throughput of the system by reducing or even eliminating idle time of the client, network connection and server, amortizes network latency, context switching and RPC subsystem overhead without imposing significant delay, does not require the application to perform complex memory management functions nor requires two buffers to queue and reliably send the bundles, and simplifies programming of error handling.
SUMMARY OF INVENTION
A method and apparatus intercepts server commands, such as remote procedure calls, which are generated by an originator such as an application program. The method and apparatus queries the originator of the remote procedure call whether it desires other commands, such as remote procedure calls, to be sent to the server. If the originator assents to the query, it may provide any parameters to use in building the other commands. The original command is tagged with an identifier, and any other commands built are also tagged with the same tag as the original command. The command received and the commands built are provided, for example to a queue to be sent to a server, either as they are built or in small batches, for execution. This arrangement maximizes throughput by bundling related commands in a manner that is easy to program. It also allows related application state to be monitored as and when required. Memory requirements are not significantly increased because only one command is processed at a time. If an error is detected by the application program, it may instruct the method and apparatus to flush from the queue the commands tagged with the same tag as the command that caused the error in order to prevent additional commands from being sent to the server. Additionally, the method and apparatus can instruct the server to abort processing the commands tagged with the same tag as the command that caused the error. Errors detected and reported by the server include the tag or other identifier of the command that caused the error. The server may abort processing of commands having a similar tag, and then flush similarly-tagged commands from the server queue as described above, either automatically, or in response from the application program after a description of the error and the tag are passed to it.
REFERENCES:
patent: 5611050 (1997-03-01), Theimer et al.
patent: 5613155 (1997-03-01), Baldiga et al.
patent: 5675796 (1997-10-01), Hodges et al.
patent: 5712971 (1998-01-01), Stanfill et al.
patent: 5740362 (1998-04-01), Buickel et al.
patent: 5774668 (1998-06-01), Choquier et al.
patent: 5802298 (1998-09-01), Imai et al.
patent: 5832219 (1998-11-01), Pettus
patent: 5884316 (1999-03-01), Bernstein et al.
patent: 5926636 (1999-07-01), Lam et al.
patent: 5935211 (1999-08-01), Osterman
patent: 5956509 (1999-09-01), Kevner
patent: 5978577 (1999-11-01), Rierden et al.
patent: 5978813 (1999-11-01), Foltz et al.
patent: 5999938 (1999-12-01), Bliss et al.
patent: 6006230 (1999-12-01), Ludwig et al.
patent: 6006278 (1999-12-01), Cottrill
Chandrasekaran Sahikanth
Chidambaran Luxi
Gotlieb Charles E.
Harrell Robert B.
Innovation Partners
Oracle Corporation
Vaughn, Jr. William C.
LandOfFree
Method and apparatus for providing multiple commands to a... 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 apparatus for providing multiple commands to a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for providing multiple commands to a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2580609