Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-03-13
2001-10-02
Banankhah, Majid (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000, C709S241000
Reexamination Certificate
active
06298391
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to remote procedure calls across a distributed network of potentially heterogeneous computers, and more particularly relates to marshaling and unmarshaling pointers of arbitrary sizes not conforming to an on-wire data representation in a reader-makes-right remote procedure call protocol.
BACKGROUND AND SUMMARY OF THE INVENTION
The Microsoft Distributed Component Object Model (DCOM) provides a remote procedure call (RPC) remoting facility (hereafter “DCOM RPC remoting facility”) that allows transparent interface function calls across process and machine (i.e., computer) boundaries. (See, e.g., Brockschmidt,
Inside OLE, Second Edition
277-338 (1995).) For transparency, the DCOM RPC remoting facility provides marshaling code (referred to as a “proxy”) inside the process of a client program or component (the “client”) that is making an interface call to an out-of-process or remote-computer-resident component (the “server component”), and also provides unmarshaling code (referred to as a “stub”) in the process of the server component. The proxy receives the client's in-process interface call and marshals all data needed for the call (e.g., arguments and in-memory data) into a buffer for transfer to the stub over a communications channel (the “RPC channel”) between the client and server processes or machines. The stub unmarshals the data from the buffer at the server component's process and machine and directly invokes the interface call on the server component. The stub also marshals any return value and “out” parameters returned from the interface call for transfer to and unmarshaling by the proxy for passing on to the client. This remote procedure calling is transparent to the client and server component in that the DCOM RPC remoting facility automatically provides the proxy, the stub and the RPC channel for marshaling the interface call across process and machine boundaries, such that the client and server component can perform the interface call as if both are on the same computer and in the same process.
The DCOM RPC remoting facility automatically creates the proxy and stub with marshaling code appropriate to a given server component interface based on a text description of the interface (including any data structures used by the interface). The interface description is written by the server component's developer in the Microsoft Interface Description Language (MIDL). MIDL is based on an industry standard RPC interface language called the Open Software Foundation Distributed Computing Environment Interface Definition Language (OSF DCE IDL). The DCOM RPC remoting facility includes a MIDL compiler that generates the proper marshaling code for the proxy and stub from the MIDL description of the interface being called.
The marshaling and unmarshaling code generated by the MIDL compiler for the proxies and stubs exchange data in a reader-makes-right protocol. In a reader-makes-right protocol, the proxy and stub write data into the RPC buffer (e.g., the proxy during the initial call, or the stub for return data) in a multicanonical representation (meaning that the representation supports multiple data formats) using any data format convenient to the writer, which is typically the data format of the computer on which the writer resides. The code on the other end that reads data from the RPC buffer (e.g., the stub during the initial call, or the proxy for return data) is then responsible for converting the RPC buffer data into the reader computer's native data format. In the case of an RPC call between processes on a same computer or between two homogenous computers (e.g., two computer with 32-bit Intel microprocessors running Microsoft Windows), both the reader and the writer have the same data format and therefore generally no conversion is needed. In the case of an RPC call between heterogeneous computers, conversion only takes place on the reading side of each exchange. By contrast, in a writer-makes-right protocol, the writer of the RPC buffer always converts data being marshaled into the RPC buffer from its native data format to a neutral or platform independent data format, and the reader always converts the RPC buffer data from the neutral format to the reader computer's native data format. The reader-makes-right RPC protocol thus is usually more efficient because data format conversions on one or both ends of the RPC call are avoided.
The DCOM RPC facility's proxies and stubs use the industry standard, DCE Network Data Representation (NDR) as the multicanonical representation of the RPC buffer data on the wire (i.e., for transmission between the proxy and stub). Pursuant to the NDR representation, the proxy and stub tag the RPC buffer data with the chosen data format of the RPC buffer data by including a header with flags set to indicate characteristics of the chosen data format. For example, the proxy and stub set header flags to indicate big-/little-endian, ASCII/EBCDIC, floating point variations, etc. This allows the reader of the RPC buffer to determine the data format of the RPC buffer data and perform translations to the reader's native data format if needed.
The NDR representation has the drawback that it supports only data formats with 32-bit pointers. This limitation constrains the DCOM RPC remoting facility to on-the-wire data formats with only 32-bit pointers. The native data format of several computer platforms, however, employ pointer sizes other than 32-bits. For example, some older computers (e.g., with 16-bit Intel microprocessors) use 16-bit pointers, whereas newer generation computers are now being introduced that use a 64-bit pointer size (e.g., computers based on the DEC Alpha processor). It is expected that computer platforms will be introduced in the future with other non-32-bit pointer sizes, e.g., 128-bit pointers. An effective cross-platform RPC facility, however, desirably provides interoperability in a heterogeneous computing environment including such computers whose native data format has a pointer size other than 32-bits. Accordingly, there is a problem of interoperability of the RPC remoting facility with computers whose natural data formats have pointer sizes that do not conform to the “on-the-wire” representation. This problem is hereafter referred to as the non-conformant pointer size problem.
A further constraint in this environment is that the DCOM RPC remoting facility is already deployed as the communications mechanism in many distributed network installations. It is therefore desirable to not change the RPC facility already installed on existing computers in these environments when computers having non-wire-representation-conformant pointer sizes are added.
Additional constraints on an effective solution to the non-conformant pointer size problem is that the optimized performance of the reader-makes-right protocol is preferably retained. Preferably, the solution also maximizes code retention, minimizes design changes, and does not alter the user interface of the existing deployed RPC facility.
Prior solutions have addressed the non-conformant pointer size problem on a case-by-case basis. In other words, prior solutions have provided marshaling/unmarshaling code that is effective for only a particular non-conformant pointer size. For example, the DCOM RPC remoting facility includes a non-conformant code path in the MIDL compiler to produce marshaling/unmarshaling code (i.e., proxies and stubs) specific to a computer with a 16-bit pointer size native data format (i.e., a computer platform employing the Microsoft Windows 3.x operating system, which has a 16-bit pointer size, on an Intel microprocessor). This non-conformant code path is specific to marshaling and unmarshaling the 16-bit Windows data format into the NDR representation RPC buffers, and does not handle any other non-conformant pointer sizes.
The present invention provides a generic solution to the non-conformant pointer size problem that supports marshaling and unmarshaling into the RPC
Brown Nathaniel S.
Ewbank Christopher Gustav
Gaertner Dietmar
Goertzel Mario C.
Kennedy Terry
Banankhah Majid
Klarquist & Sparkman, LLP
Microsoft Corporation
LandOfFree
Remote procedure calling with marshaling and unmarshaling of... 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 with marshaling and unmarshaling of..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Remote procedure calling with marshaling and unmarshaling of... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2612194