Efficient inter-process object and interface pinging

Details Efficient inter-process object and interface pinging Efficient inter-process object and interface pinging

1995-07-14

2002-06-11

Oberley, Alvin (Department: 2151)

Electrical computers and digital processing systems: multicomput

Computer-to-computer data routing

Least weight routing

C709S203000

Reexamination Certificate

active

06405262

ABSTRACT:

TECHNICAL FIELD
This invention relates to object-oriented systems utilizing inter-process pinging methods.
BACKGROUND OF THE INVENTION
In multi-process computer systems it is desirable to provide facilities for allowing one process to utilize the resources of another process. The process using the resources is referred to as a client process and the process providing the resources is referred to as a server process. In many cases, a particular process might be both a client process and a server process, in that it uses the resources of other server processes while also providing resources of its own for use by other client processes.
It is also desirable to provide a standard interface mechanism between processes so that application programs from different vendors can conveniently share resources using a common protocol. One type of such interface mechanisms utilizes the concept of “objects” and “object interfaces” to specify interactions between computers. An object in this environment is a unit of functionality that implements one or more interfaces to expose that functionality. An interface is a contract between the user, or client, of some object and the object itself. In more practical terms, an object is a collection of related data and functions grouped together for some distinguishable common purpose. The purpose is generally to provide services to client processes. An interface is a grouping of semantically related functions through which a client process can access the services of the object.
The invention described below has been implemented in a Microsoft Windows NT® programming environment using features of Object Linking and Embedding (OLE). OLE is based on a protocol referred to as the Component Object Model (COM). COM specifies how objects interact with each other using interfaces. OLE and COM have been well documented and will not be explained in detail here except for general concepts which are particularly pertinent to this invention. For more information regarding OLE and COM, refer to “OLE 2 Programmer's Reference” and “Inside OLE 2,” both published by Microsoft Press of Redmond, Wash., and both of which are hereby incorporated by reference.
In the COM environment, an interface is a block of memory containing an array of function pointers—that is, a function table. Through a standard object interface referred to as IUnknown, a client process can obtain a pointer to any interface supported by an object. When such an interface pointer has been obtained, it is said that the client process has obtained an interface on the object. The pointer does not provide access to the entire object; instead, it allows access to one interface on that object.
Objects and their interfaces are conventionally illustrated as shown in
FIG. 1. A
circle is used to represent each interface.
The services or functions of an object can be used by both in-process clients and by out-of-process clients. In addition, an interface can be used by a client executing on a different computer. The COM protocol covers all of these situations. Calling a remote interface (one that is in a different address space than the calling process) requires the use of “stubs” and “proxies,” and involves topics such as “marshalling” and “unmarshalling” of procedure parameters. These mechanisms are well understood and are documented in the books mentioned above. In regard to these topics, also refer to “X/Open DCE: Remote Procedure Call,” published by X/Open Company Ltd., U.K, which is also incorporated by reference.
Objects must be instantiated in memory before they can be used. Once instantiated, they must be kept alive (remain in memory in a running or active state) until they are no longer needed. To maximize available memory, it is desirable to destroy objects (remove them from memory) and their interfaces when they are no longer needed. In order for the server process to keep track of when it is safe to destroy an object, COM implements reference counting. Through reference counting, a server object can keep track of whether any clients are still holding one or more interfaces on a server object. A client process is said to be holding an interface if it has obtained a pointer to the interface (usually by calling QueryInterface, a method of the IUnknown interface) and has not released it (by calling Release, another method of the IUnknown interface). An object must be is kept alive if there are one or more client processes holding one or more interfaces on the object. Reference counting involves simply incrementing a variable every time a pointer to an interface is obtained, and decrementing the variable every time a pointer to the interface is released. In some cases (such as in OLE), the practice is to maintain a single variable for an object—the single variable is incremented or decremented regardless of which interface on the object is obtained or released. Other operating systems might maintain an individual variable for each interface so that the resources associated with an individual interface can be destroyed apart from the associated object. In this case, an interface is destroyed if its reference count goes to zero. An object is destroyed when all its interfaces have been destroyed.
Although reference counting works well in theory, it assumes that all client processes are well behaved and that they cooperate properly with reference counting procedures. However, this is not always the case, and it is not uncommon for a client process to somehow neglect to release an interface. This can happen through software design error or through hardware failure. Instances of this problem are even more frequent in multi-computer environments, where client and server processes reside on different computers. A failure in the client computer or in communications channels can make it impossible for a client process to notify the server process that it has released an interface.
In order to deal with this potential problem, some computer network systems employ what is referred to as “pinging.” Periodically, at selected ping periods, every client process that holds an interface on an object sends a keep-alive signal to the interface. As long as the interface continues to get keep-alive signals, the server process will keep the interface alive. After a pre-defined time without receiving a keep-alive signal, the server process will assume that there are no surviving client processes needing the interface, and the interface will be destroyed. The object with which the interface is associated will be destroyed only if all of its interfaces are destroyed.
The combination of reference counting and pinging would be effective except that pinging puts a tremendous load on computer resources and inter-process communications facilities. This is because of the great number of interfaces which might be implemented by a particular object and the potentially large number of client processes which might hold such interfaces. It would not be unusual for an object to receive 1000 periodic keep-alive signals. Regardless of the communications medium used, this would impose a large overhead on the system.
SUMMARY OF THE INVENTION
The invention provides several improvements which, together, make pinging techniques much more practical than they have been in the past. In one aspect of the invention, keep-alive messages between individual pairs of client and server processes are coalesced into single, inter-process messages to reduce communications overhead. In a further aspect of the invention, each client process registers with a ping manager, and the ping manager sends the appropriate keep-alive messages while monitoring its registered client processes to determine whether they are still executing.
A still further aspect of the invention involves client-side ping managers and server-side ping managers. Each client process registers interfaces it is holding with a client-side ping manager. Server processes register with a server-side ping manager. Each client-side ping manager periodically sends messages to the server-side ping m

Affiliated with

Also associated with

Rating

Efficient inter-process object and interface pinging does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Efficient inter-process object and interface pinging, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Efficient inter-process object and interface pinging will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2908185