Remote procedure calling using an existing descriptor mechanism

Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing

Utility Patent

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C707S793000

Utility Patent

active

06170018

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to communication between computer processes and, in particular, to a particularly efficient system and method for remote procedure calling which uses existing mechanisms to provide a seamless and relatively uncomplicated programmer interface.
BACKGROUND OF THE INVENTION
Doors are a relatively efficient mechanism for communication between computer processes (i.e., inter-process communication or “IPC”) and, in particular, for remote procedure calling (i.e., “RPC”) in which a first computer process invokes a procedure which is defined and executed by a second computer process. Doors are known and are described, for example, in Graham Hamilton and Panos Kougiouris, “The Spring nucleus: A microkemel for objects,”
Usenix Conference
1993, at 147-160 (June 1995). Doors are briefly described for completeness.
In general, a door is a portion of memory in the kernel of an operating system which is used to facilitate a secure transfer of control and data between a client thread of a first computer process and a server thread of a second computer process. Some of the components of a computer system which are used to implement doors are briefly described. An operating system is generally a set of computer programs which enable a computer to (i) understand and process commands, (ii) control input and output of the computer through various input and output devices, (iii) schedule computer processes for execution, (iv) manage data stored in various storage devices of the computer, and (v) control the operation of peripheral devices coupled to the computer. The kernel of an operating system is that portion of the operating system which (i) manages the interface between user programs and input/output devices, (ii) manages main memory, (iii) schedules computer processes for execution, and (iv) maintains a file system which in turn manages storage of data on various storage devices. The kernel of the Unix operating system is the only part of the Unix operating system which interacts with the hardware components of the computer system in which the Unix operating system executes. All interaction between computer processes and hardware components of the computer system is through the kernel. Accordingly, when an operating system which executes on a first type of computer system is modified to execute on a second type of computer system, only the kernel of the operating system must be so modified.
A computer program is a series of computer instructions and data which, when executed within a computer system, perform a task. A computer process is an execution of a computer program. A single computer program can be executed any number of times, and each execution is a different computer process. Most computer systems in use today permit several computer processes to execute simultaneously within a computer system. In addition to the computer instructions and data of a defining computer program, a computer process includes information stored within the kernel identifying the computer instruction which is currently being executed, the computer instruction which is to be executed next, and the current state of the computer process, including a stack which is used to save previous computer process states for later restoration. In some operating systems, a computer process can create new execution states which are sometimes called “threads,” which are independent of the execution state of the computer process, and which execute concurrently with one another and with the computer process within the computer system. Each thread which executes concurrently is independently scheduled for execution by the kernel. Such a computer process having multiple threads is generally called a “multi-threaded” computer process or is sometimes referred to as a “light-weight process.” Each thread of a computer process executes in the context of the computer process. In particular, each thread shares the address space of the computer process and resources are allocated to a computer process, and therefore all threads of the computer process, rather than an individual thread.
It is sometimes desirable to allow a computer process to perform an operation without granting to the computer process the authority to perform similar, but different, operations. For example, it can be desirable to permit one computer process to monitor the status of other computer processes without granting to the former computer process other access to the other computer processes. Therefore, a computer process, which is called the server process and which generally has the authority to perform an operation called the subject operation, can allow other computer processes, which are called client processes and which generally do not have such authority, to perform the operation within the address space of and under the authority of the server process. For example, a server process can monitor the status of various computer processes at the request of a client process which has no direct access to the other computer processes.
Doors are a particularly efficient mechanism for RPC. In invoking RPC using a door, a client process (i) transfers to the kernel a buffer which contains arguments consumed by performance of the subject operation and which will contain results produced by performance of the subject operation and (ii) instructs the kernel to initiate performance of the subject operation. In creating the door, the server process creates and sets aside a thread, sometimes referred to as a “server thread,” which typically exists solely for the purpose of performing the subject operation at the request of a client process. When the kernel invokes performance of the subject operation, the kernel immediately executes the server thread in place of the client process and immediately executes the client process in place of the server thread when the subject operation terminates. While the client process executes, the server thread is ready to execute; and while the server thread executes, the client process is ready to execute. Since the kernel immediately suspends execution of one computer process for execution of another, very little processing is required to transfer control from the client process to the server thread and back again in comparison to other RPC mechanisms in which the kernel uses conventional computer process scheduling mechanisms to temporarily suspend execution of the client process and resume execution of the server process. Thus, overhead associated with other, more complex synchronization objects such as semaphores and condition variables is avoided.
Doors are a safe IPC mechanism since the server thread executes in the context of the computer process which creates the door and the server thread. Accordingly, a client process can invoke a door securely, i.e., without concern that execution of the subject operation in the context of the server process will cause harm to the client process, since a thread of one computer process is generally not permitted to interfere with a thread of another computer process. The subject operation retrieves the arguments from the buffer in the kernel, acts in accordance with the computer instructions of the subject operation, and stores in the buffer results produced by execution of the subject operation. Upon completion of the subject operation, the subject operation notifies the kernel of the completion, and the kernel, in response to such notification, immediately executes the client process in place of the server thread as described above. Thus, in performing the subject operation and in returning processing to the client process, the server thread has no direct access to the client process.
In addition, doors are created by the server process and cannot be created by the client process. Therefore, the client process cannot create its own door to access other computer processes. Thus, doors are secure in that each computer process must explicitly grant to other computer processes access to itself.
Doors have yet to be implemented in any commercial

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Remote procedure calling using an existing descriptor mechanism does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Remote procedure calling using an existing descriptor mechanism, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Remote procedure calling using an existing descriptor mechanism will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2556206

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.