Electrical computers and digital processing systems: multicomput – Distributed data processing – Client/server
Reexamination Certificate
1998-09-25
2002-07-09
Maung, Zarni (Department: 2152)
Electrical computers and digital processing systems: multicomput
Distributed data processing
Client/server
C709S227000
Reexamination Certificate
active
06418464
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to the field of computer software, and, more specifically, to completing input/output transactions.
Portions of the disclosure of this patent document contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever. Apple, Macintosh, AppleTalk, AppleScript, and all Apple-based trademarks and logos are trademarks or registered trademarks of Apple Computer, Inc. in the United States and other countries.
2. Background Art
A computer interacts with and communicates with various peripheral devices (also referred to as input-output (I/O) devices) such as printers, scanners, video displays, keyboards, disk drives, modems, CD drives, etc. I/O devices convert information from one physical representation to another for processing and storage within a computer. Thus, I/O devices are the means by which a computer communicates with the outside world. The processing and storing of I/O device information occurs within the main memory or central processing unit (CPU) of a computer.
In modern computer operating systems, functions, operations and processes may be carried out through asynchronous interaction between client and server processes. For example, a client may be a high-level device driver (a software component that contains the computer code needed to use an attached device) and a server may be the software component that directly manages the physical device. Through a client process, the client requests a specific function, action, or resource of the server.
One aspect of such computer operating systems is to ensure that each client request completes and is only acted on exactly once (i.e., no request may be lost and none may be processed twice). For example, a request may complete normally or it may complete abnormally due to user action, a hardware failure, or a time-out (i.e., the specified time limit for the server to respond to the client request expired). The underlying operating system must also permit clients to terminate requests after they have been issued without regard to the precise state of the request (e.g., the request may not have been forwarded to the server, or may already have been completed when the client's request to terminate the request was received). Furthermore, in a multi-processing system, there may be multiple clients and servers executing on independent hardware processors (so called “symmetric multiprocessing”) that can initiate, process, abort, or complete a request, and the operating system must ensure that exactly one of these competing processes actually operates on the request even if it had been initiated, processed, or aborted on a different processor.
One prior art method to ensure process completion and single execution consists of the client setting a flag to indicate whether the server process should continue or be terminated. In such a method, the server must periodically examine the status of the flag.
Prior art methods do not precisely track client I/O requests resulting in two process paths of completion, one path from the client, and one path for the server. Further, the notification to clients (regarding completion of a request) and notification to the server (of a standard request or a request to terminate a standard request) is dependent on the type of request, and the procedure that implements and completes the request. Thus, when a request is initiated by a client, the client waits for the completion of the request and is not informed and cannot obtain the status of the request. For example, some implementations of the UNIX operating system has a client start and wait or sleep approach. In such an approach, a client request is initiated and then waits for the server to complete the request. The client enters a “sleep” mode until the request is completed. Alternatively, the Macintosh environment, when a client request is started, the client specifies the address of a subroutine to be called when the request is completed by the server. If no address is provided, the client process waits for completion of the process and performs no other functions.
In the prior art, the client is unable to pick and choose which processes to complete or wait for subsequent to initiating the request. Consequently, there is no defense against a process that is initiated and never completes (e.g., due to a hardware failure, time-out, etc.). Further, the various stages of completion of a client request are intertwined specifically to the implementation of the client request or the server response.
SUMMARY OF THE INVENTION
The invention provides for the coordination of client/server processes. One aspect of computer operating systems is to ensure that a request to perform an I/O operation or server operation completes and is only acted on exactly once (i.e., no request should be lost and none should be processed twice). The underlying operating system should also permit clients to terminate requests after they have been issued without regard to the precise state of the request (e.g., the request may not have been forwarded to the server, or may already have been completed when the client's request to terminate the request was received). Furthermore, in a multi-processing system, there may be multiple clients and servers executing on independent hardware processors (so called “symmetric multiprocessing”) that can initiate, process, abort, or complete a request, and the operating system must ensure that exactly one of these competing processes actually operates on the request even if it had been initiated, processed, or aborted on a different processor.
One or more embodiments of the invention provide for a completion object in an object oriented environment comprised of various states of completion of a client request. The completion object may be manipulated to transition from one state to another by both the client and server. One or more embodiments provide for the following states of completion: idle, ready, active, completing, completed, and acknowledged. In the idle state, the completion object is obtained by the client (by constructing a new object or retrieving an existing object that has been recycled). In the ready state, the request has been initialized but not yet issued to the server or I/O device. In the active state, the server processes the I/O request. In the completing state, the server has completed the I/O operations requested but has not yet stored the results. In the completed state, the server stores the results to be returned to the client and notifies the client. In the acknowledged state, the client examines the results, performs additional operations and frees up the completion object for use by another client request.
Depending on the state of the completion object, a request to cancel the I/O operations may require varying actions. The completion object provides the ability to easily and quickly determine where in the completion process an I/O request is. Further, when a client request is canceled, the completion object provides the ability to easily identify the actions necessary to properly cancel the request.
REFERENCES:
patent: 5109486 (1992-04-01), Seymour
patent: 5696910 (1997-12-01), Pawlowski
patent: 5781737 (1998-07-01), Schmidt
patent: 5889944 (1999-03-01), Butt et al.
patent: 5931919 (1999-08-01), Thomas et al.
patent: 5956509 (1999-09-01), Kevner
patent: 5978846 (1999-11-01), Kimishima
patent: 6052722 (2000-04-01), Taghadoss
patent: 6076108 (2000-06-01), Courts et al.
patent: 6112015 (2000-08-01), Planas et al.
patent: 6128657 (2000-10-01), Okanoya et al.
Lieberman, Henry, “Using prototypical objects to implement shared behavoir in object-oriented systems”, OOPSLA '86 proceedings, pp. 214-223, Oct. 1986.*
Agha, Gul, “Concurrent Object-Oriented Programming” Comm. of the ACM, vol. 33, No. 9
Apple Compunter, Inc.
Cardone Jason D.
Maung Zarni
The Hecker Law Group
LandOfFree
Method and apparatus for coordination of client/server... 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 coordination of client/server..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for coordination of client/server... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2895275