US005926636A
`5,926,636
`(11) Patent Number:
`115
`United States Patent
`
` Lam etal. [45] Date of Patent: *Jul. 20, 1999
`
`
`[54] REMOTE PROCEDURAL CALL
`COMPONENT MANAGEMENT METHOD
`NPeworieEROGENEOUS COMPUTER
`
`[75]
`
`Inventors: Geoffrey T. Lam, San Jose; Ajay
`Malik, Fremont; Senthil K.
`Ponnuswamy, San Jose; Thomas M.
`Battle, Los Altos Hills, all of Calif.
`
`[73] Assignee: Adaptec, Inc., Milpitas, Calif.
`
`[*] Notice:
`
`This patent issued on a continued pros-
`ecution application filed under 37 CFR
`1.53(d), and is subject to the twenty year
`patent
`term provisions of 35 U.S.C.
`154(a)(2).
`
`[21] Appl. No.: 08/603,531
`.
`Filed:
`[22]
`Feb. 21, 1996
`[51] Unt, CLS oe eeeceesseesentnee GO6F 13/14; GO6F 9/44
`[52] US. Ch coaccccccccscn395/683; 395/200.62; 395/684
`[58] Field of Search oe 395/683, 200.01,
`395/800, 615, 670, 200.12, 200.15, 210.16
`672. 335. 326. 200.61. 200.57. 684. 800.23
`200 79 00 31 500 62: 37960 >45: 329194 3.
`60
`
`[56]
`
`References Cited
`
`5,278,955
`5,329,619
`5,434,908
`
`U.S. PATENT DOCUMENTS
`1/1994 Fortéet ale
`ccecsssssssesssesseeeee 305/200.01
`7/1994 Pagé et al. occ 395/200.01
`7/1995 Klein wee cesecessceeeeseeceneeeeeens 379/88
`
`5,475,836
`12/1995 Harris et al. eee 395/681
`5,581,461
`12/1996 Coll et ab. occeeccccccceesseecseses 395/205
`Primary Examiner—Daniel H. Pan
`Attorney, Agent, or Firm—Forrest Gunnison
`[57]
`ABSTRACT
`
`In response to a component management function call by a
`remote client application, the component managementappli-
`cation programming interface (API) generates a message
`that identifies the called function and the version of the
`component management API. The component management
`APTcalls a local message transfer RPC commandto send the
`message to a RPC command module. The RPC command
`module processes the local message transfer RPC command,
`and packages the message for transfer as a RPC over the
`heterogenous network. The RPC command module sends
`the packaged RPCto a network stack whichin turn transmits
`the packaged RPC over the heterogenous network to a
`network stack in the server computer. The server network
`stack provides the packaged RPC to a server RPC command
`module that unpacks the RPC in a conventional mannerto
`obtain the original message. The message is passed to a
`server component management API. The server component
`management API parses the message to determine the com-
`puter architecture of the client computer. With this
`information, server component management APIreads the
`version specified in the message. If the specified version is
`incompatible with the version of the server component
`management API, a reply indicating the version incompat-
`ibility is transmitted to remote client application and other-
`wise the message is processed further by the server compo-
`Rent management API.
`
`15 Claims, 7 Drawing Sheets
`
`uNoOWS
`CLIENT
`
`
`
`505
`
`
`
`
`
`
`
`
`
`540-1 /
`COMPONENT]
`1
`
`*
`
`*
`
`©
`
`540-n
`COMPONENT
`n
`
`
`
`
`
`SERVER COMPUTER 520
`
`Google Exhibit 1068
`Google v. VirtaMove
`
`REMOTE CLIENT
`APP
`
`
`“APL FEN ©)
`COMPONENT MANAGE [~912
`
`
`API
`TRANSFER
`
`RPC_MESSAGE
`BUFFER
`
`REMOTE RPC
`[515
`
`COMMAND MODULE
`
`NETWORK TRANSPORT [~516
`STACK
`510
`500
`
`z
`
`t
`NETWORK TRANSPORT]
`UNIX
`NT
`see
`SERVER a SERVER
`SERVER RPC
`525
`COMMAND MODULE
`TRANSFER
`T
`RPC_MESSACE
`506
`BUFTER
`SERVER COMPONENT }-522
`
`MANAGEMENT API.
`
`0s/2
`CLIENT
`
`
`
`
`
`
`
` 7
`
`be1Pc_NESSAGE
`[530
`1/0 MANAGER
`
`*
`
`Google Exhibit 1068
`Google v. VirtaMove
`
`

`

`U.S. Patent
`
`Jul. 20, 1999
`
`Sheet 1 of 7
`
`5,926,636
`
`
`OS|OL\0908||dv
`MGAYSSZ/SOYMOMLININ
`
`
`
`‘a0S)NETASESEISENNETASESS
`OC171SMOCNIM¢/S050d
`INAMNOZ|OL|
`SOz/SOsod
`LNALNaN9
`
`LayYOId1old
`
`oor
`
`XIN
`
`(NAS
`
`SMOGNIM
`
`ddVdd¥
`
`
`

`

`U.S. Patent
`
`Jul. 20, 1999
`
`Sheet 2 of 7
`
`5,926,636
`
`
`XDR
` DCE
`SUN
`
`NDR
`
`
`
`
`
`
`
`
`
`
`IEEE
`802.5
`
`(TOKEN RING)|
`
`
`NET BIOS
`
`SOCKETS
`
`TLI
`
`TCP
`IP
`
`SPX
`IPX
`
`NET BEUI
`
`2200
`
`290
`
`
`
`IEEE 802.2
`
`ODI
`
`
`
`IEEE
`802.3
`(ETHERNET)
`
`SDLC
`
`ISDN
`
`FIBER
`OPTIC
`
`COAX
`
`TWISTED
`PAIR
`
`
`
`FIG. ¢
`PRIOR_ART
`
`

`

`U.S. Patent
`
`Jul. 20, 1999
`
`Sheet 3 of 7
`
`5,926,636
`
`
`
`
`
`U-LO¢é—1OeL-LO¢
`
`LNANJDVNVA
`
`ddV
`
`ddV
`
`LNAWADVNVA
`
`ddV
`
`LWNol6Old
`YAAV]
`LNAWSOVNVIN
`
`AIW
`
`ASVEVLV
`
`SOIAUSS JOVAYSLNI
`
`LNSNFOVNVA
`
`L-c0¢ JOVIYSLNI
`
`!—20¢6—-C0E
`
`LNANOdNOD
`
`00¢
`
`
`
`
`
`

`

`FT 71
`REMOTE
`|
`
`12
`|
`:
`REMOTE
`\~415
`
`!
`CLIENT
`ss
`
`IPC
`!
`MODULE
`FC
`
`a 4
`RPC COMMAND
`414
`CLIENT
`
`
`
` Be 4
`
`
`|
`|
`
`!
`|
`
`| |
`
`|
`|
`
`!
`L a
`
`LOCAL
`CLIENT APP
`
`l | | |
`
`|
`|
`
`!
`
`| | | | | | l | j
`
`l
`
`NETWORK STACK
`
`(7429
`
`RPC COMMAND
`SERVER
`
`424
`
`SERVER
`IPC MODULE
`
`403
`
`RPC
`
`|
`
`LOCAL
`IOMAPT |
`422
`|
`___ |
`
`435
`
`ato
`
`430
`
`
`1/0
`
`
`
`MANAGER
`
`W IPC INTERFACE
`
`
`TO SERVER
`
`
`IPC MODULE
`
`
`
`
`U.S. Patent
`
`Jul. 20, 1999
`
`Sheet 4 of 7
`
`5,926,636
`
`CLIENT |
`COMPUTER 410
`|
`!
`
`! | |
`
`¥—411
`
`
`
`
`REMOTE
`CLIENT
`APP
`
`
`IOMAPI
`
`|
`:
`|
`|
`RPC
`!
`|
`
`NETWORKstack[7° |
`
`! |
`
`

`

`U.S. Patent
`
`Jul. 20, 1999
`
`Sheet 5 of 7
`
`
`
`WINDOWS
`CLIENT
`
`TRANSFER
`RPC_MESSAGE
`BUFFER
`
`NETWORK TRANSPORT
`STACK
`
`[~516
`
`5,926,636
`
`902
`
`0S/2
`CLIENT
`
`500
`
`UNIX
`SERVER
`
`506
`
`
`
`NETWORK TRANSPORT
`Stat
`
`
`TRANSFER
`RPC_MESSAGE
`BUFFER
`
`
`
`
`
`COMPONENT
`n
`
`
`
`
`SERVER COMPUTER 520
`
`NT
`SERVER
`
`505
`
`FIG. 5
`
`

`

`U.S. Patent
`
`Jul. 20, 1999
`
`Sheet 6 of 7
`
`5,926,636
`
`
`
`REMOTE
`CLIENT
`APPLICATION
`
`
`
`
`CLIENT
`REMOTE
`COMPONENT
`RPC ADMIN
`MANAGEMENT
`FCN MODULE
`MODULE
`
`CLIENT
`| COMPONENT. _
`
`
`TRANSFER
`
`RPC_MESSAGE
`ADMIN API
`BUFFER
`FCN CALL
`
`REMOTE RPC
`COMMAND
`MODULE
`
`PACKAGED
`RPC
`
`
`
`
`NETWORK
`STACK
`
`

`

`U.S. Patent
`
`Jul. 20, 1999
`
`Sheet 7 of 7
`
`5,926,636
`
` n
`
`COMPONENT
`i/o
`MANAGER
`
`oe COMPUTER 520 |
`
`| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
`
`SERVER
`623
`
`
`COMPONENT
`
`
`MANAGEMENT
`
`
`FCN MODULE
`
`
`odd
`!
`SERVER
`|
`COMPONENT
`|
`| MANAGEMENT
`|
`|
`API
`poAPLNAP |
`FCN CALL
`
`TRANSFER
`RPC_MESSAGE
`LOCAL
`
`BUFFER
`CLIENT
`
`
` APPLICATION
`
`
` SERVER RPC
`
`
`RPC
` PACKAGED
` NETWORK
`STACK
`
`
`COMMAND
`MODULE
`
`SERVER
`
`

`

`5,926,636
`
`2
`DCEis associated with an interface definition language
`(IDL) and compiler that facilitate creation of RPCs. The IDL
`compiler creates source code stubs for both the client and
`server sides of an application. The stubs are compiled and
`linked to the RPC run-time library, which is responsible for
`finding servers in a distributed system, performing the
`message exchanges, packing and unpacking the message
`parameters, and processing any errors that occur. The DCE
`RPC does not support transactions.
`One problem encountered in using RPCsis the represen-
`tation of data across a network with multiple platforms,
`because different CPUs represent data structures differently,
`for example, Big-Endian versus Little-Endian. To maintain
`machine independence, the RPC uses some level of data
`format translation across systems.
`With DCE,the client chooses one of the multiple data
`format representations from the network data representation
`(NDR)service. (See FIG. 2.) The client chooses the data
`format, typically its own native data representation; tags the
`data with the chosen format; and the server must transform
`the data into a format that the server understands.
`
`10
`
`15
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Another common RPCis provided by Sun Microsystems
`of Mountain View, Calif. RPC on Sun Microsystems com-
`puters requires that the client convert the data to a neutral
`canonical
`format using an external data representation
`(XDR). (See FIG. 2.) With the Sun approach,all clients look
`the same to a server.
`In FIG. 2, NetBios, sockets and
`transport layer interface (TLD) are all interfaces between
`RPC and the various network transport stacks. Network
`transport stacks include TCP/IP, NetBIOS,
`IPX/SPX,
`DECnet, AppleTalk, OSI, and SNA/APPN, for example.
`Thereis a logical interface to the network device drivers at
`the bottom of the network transport stack. Examples of
`widely supported logical interfaces to network device driv-
`ers are Microsoft/3Com’s NDIS and Novell’s ODI. The
`remainder of the standards, drivers, and communication
`protocols in FIG. 2 are knownto those of skill in the art and
`are shown only for completeness. A more complete discus-
`Clients and servers are loosely coupled systems that
`interact over network 100. Each interaction betweenaclient
`40
`sion of transport stacks is provided,
`for example,
`in
`Tannenbaum, Computer Networks, Prentice Hall, (1988).
`and a servertells a server which service is requested. After
`Herein, a network stack refers to network stack 250.
`the server receives the request, the server determines how to
`RPCsare used widely. However, for desktop management
`perform the service specified in the request.
`Communications between a client and a server over
`of components within a single desktop computer system,
`another approach is used. A Desktop ManagementInterface
`(DMD) has been defined by the Desktop Management Task
`Force, MIS JF2-51, 2111 N.E. 25th Avenue, Hillsboro, Oreg.
`97124. DMIisa localinterface between management appli-
`cations that manipulate information on components, e.g.,
`physical or logical entities in a computer system, and the
`components. For a detailed description of DMI, see the
`Desktop Management Interface Specification, Version 1.0,
`Apr. 29, 1994, which is incorporated herein by reference in
`its entirety.
`FIG. 3 is a block diagram of DMI within computer system
`300. Management applications 301-1 to 301-n use a man-
`agementinterface 310 to manage components 302-1 to 302-i
`within computer system 300. Management applications
`include a management console, a desktop management
`application, and a local area network management applica-
`tion. In general, a management application is a remote or
`local application thal changes, interrogates, controls, tracks,
`or lists components of a desktop computer system.
`Managementinterface 310 shiclds management applica-
`tions 301-1 to 301-n from the different mechanisms used to
`obtain management information from components 302-1 to
`302-1 within computcr system 300. Typical componcnts
`
`1
`REMOTE PROCEDURAL CALL
`COMPONENT MANAGEMENT METHOD
`FOR A HETEROGENEOUS COMPUTER
`NETWORK
`BACKGROUND OF THE INVENTION
`
`A portion of the disclosure of this patent document
`contains material which is subject to copyright protection.
`The copyright owner has no objection to the facsimile
`reproduction by anyone of the patent documentorthe patent
`disclosure, as it appears in the Patent and ‘lrademark Office
`patent files or records, but atherwise reservesall copyright
`rights whatsoever.
`1. Field of the Invention
`
`The present invention is related generally to communica-
`tions across a computer system network and more specifi-
`cally to methods for managing components in a heteroge-
`neous computer system network.
`2. Description of Related Art
`A current trend in computing is to interconnect a variety
`of computer architectures and computer operating systems
`in a single network 100. As illustrated in FIG. 1, network
`100 includes a variety of servers, 1.e., a Unix server 150, a
`Netware server 160, an OS/2 server 170, and a Windows NT
`server 180. Herein, network 100 and similar networks are
`referred to as heterogeneous networks. Heterogeneous net-
`works include local area networks.
`
`One configuration commonly used for performing opera-
`tions over a network, such as network 100,is a client/server
`architecture. A server process executing on a server com-
`puter is a provider of services. Servers includefile servers,
`database servers, transaction servers, groupware servers and
`object servers.
`is executing either on a server
`that
`A client process,
`computer or another computer, is a consumer of services
`provided bythe server. Thus, in PIG. 1, three computers 110,
`120 and 130, that are each running a client process, are
`illustrated.
`
`heterogeneous network 100 require a method for transport-
`ing requests over network 100 from a client running under
`one operating system to a serverthat is either running under
`another operating system, or the same operating system. One
`widely used method for communication over heterogeneous
`network 100 is a remote procedure call (RPC). Techniques
`for implementing client/server applications, and client/
`server applications with remote procedure calls are knownto
`those skilled in the art. A remote procedure call (RPC) hides
`the physical structure of network 100 and makesa server on
`network 100 appear to be one function call away.
`Specifically, a remote procedure call hides the details of
`network 100 by using a procedure call mechanism that is
`well known.
`
`A common wayto illustrate implementation of a remote
`procedure call is a stack. FIG. 2 is an example of one prior
`art representation of a stack 200 that includes two common
`implementations of a RPC. One widely used RPC standard
`is distributed computing environment (DCE) RPC (FIG.2).
`ADCERPCallowsa clicnt to interoperate with one or more
`servers on other computing platforms, even whenthe client
`and server are from different vendors with different operat-
`ing systems.
`
`

`

`5,926,636
`
`3
`include software applications, operating systems, hardware
`products, peripheral products, and system hardware. Each
`component has a management information file (MIF), that
`describes the manageable characteristics of the component,
`stored in a MIFdatabase 340 within computer system 300.
`Managementinterface 310 is a data interface, as opposed
`to the procedural
`interface used in a RPC. Data blocks
`describe the format for data transfer instead of parameters to
`a function call. Thus, a command is issued from a manage-
`ment application,
`for example, management application
`301-1, to build a data block and pass the data block to
`service layer 320. All commandsare specified with data
`blocks, but there is one function call provided to pass the
`command to service layer 320.
`Service layer 320 is a desk-top resident application that
`controls the flow of information between managementinter-
`face 310 and a componentinterface 330. Service layer 320
`is a permanent background process that is always ready to
`handle an asynchronous request. The operations of the
`service layer are documented in Chapter 2 of the Desktop
`Management Interface Specification.
`Componentinterface 330 receivescalls from service layer
`320. Componentinterface 330 alsois a data interface, and so
`data blocks describe the format for data transfer. Commu-
`nication between componentinterface 330 and service layer
`320 is operating system dependent.
`While DMI provides a useful function for the desktop, the
`data interface, i.c., command blocks, is a departure from
`RPC. The current trend for management of components in a
`heterogeneous network is to use RPC.
`FIG. 4 is a block diagram of a client/server architecture
`used over a network, e.g. a heterogeneous network,
`to
`manage hardware components. A remote client application
`411, that needs to interact with a hardware component on
`server computer 420, uses RPCs to communicate over
`heterogeneous network 400 with server computer 420.
`For example, remote client application 411 is a graphic
`user interface (GUI) such as that used on a Windows
`workstation. A remote I/O management application pro-
`gramming interface 412 COMAPI 412)
`is provided to
`remote client application 411 by a remote client interprocess
`communication module 413.
`
`IOMAPI412 includes general I/O managementfunctions,
`RAID management functions, and an administration appli-
`cation programming interface (API). The functions available
`to remote client application 411 in IOMAPI 412 are the same
`as those made available to a local client application 435 on
`server computer 420 by server IPC module 423. Tunction
`calls to IOMAPI 412 by remote client application 411 result
`in I/O management on server computer 420. The adminis-
`tration calls by remote client application 411 through
`IOMAPI 412 are used for establishing a network session,
`and for ensuring the authentication and access rights of
`applications issuing IOMAPIcalls.
`A call to a function in IOMAPI 412 by remote client
`application 411 is passed to RPC commandclient 414. RPC
`command client 414 packages the function call in a con-
`ventional fashion and transmits the packaged function call to
`network stack 415, which in tum controls transmission of
`the packaged function call over network 400 to network
`stack 425 of server computer 420.
`To package the request, RPC command client 414 con-
`verts the function call and any associated data to a neutral
`canonical
`format using an external data representation
`(XDR). Thus, in FIG. 4, TJOMAPT 412 and RPC command
`clicnt 414 arc functionally the RPC layer of FIG. 2.
`
`10
`
`15
`
`20
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`Networkstack 425 transmits the packaged functioncall to
`server RPC command module 424. Server RPC command
`
`module 424 extracts the function call from the packaged
`request. If the function call is an administration function
`call, server RPC command module 424 processes the admin-
`istration function call and replies to RPC command client
`414that in turn communicates with remote client application
`411. However, if the function call is an IOMAPI function
`call, server RPC command module 424 passes the function
`call to server IPC module 423 Server IPC module 423
`
`transfers the specified function call via a message buffer
`IPC_MESSAGEto an I/O manager 430 with an interface to
`server IPC module 423. Message buffer IPC_MESSAGE,
`sometimes called message IPC_MESSAGE,is transmitted
`using an interprocess communication. In response to mes-
`sage IPC_MESSAGE,I/O manager 430issuesa call to the
`appropriate managementfunction.
`I/O manager 430 performs the called management func-
`tion and returns the result to server IPC module 423. The
`results are returned from server IPC module 423 to remote
`client application 411 in the normal manner for a RPC.
`While the architecture of FIG. 4 overcomes the limita-
`tions of DMI by using a RPC mechanism,the use of RPCs
`introduces limitations on updates and modifications. Any
`change in remote LOMAPI 412 and/or local IOMAPI 422
`requires a change in RPC commandclient 414 and RPC
`command module 424. Any change in RPC commandclient
`414 and RPC command module 424 implies changes in
`remote client application 411. The RPC interface must
`support cvery single commandthat’s defined in the list of
`procedure calls for every possible version and must support
`every one of the parameters that are passed with each of
`these procedure calls.
`Hence, RPC may not work properly in an environment
`with mixed versions of remote JOMAPI 412 and local
`
`IOMAPI422. To assure version capability across heteroge-
`neous network 400, remote client IPC module 413, client
`RPC command module 414, server RPC command module
`424 and server IPC module 423 must be updated to support
`each version, recompiled, and relinked for each of the
`computers on network 400. For heterogeneous networks,
`this is a formidable task. Thus, while the trend is to imple-
`ment RPC for component managementover a heterogeneous
`network, the requirementof the current RPC architecture for
`either consistent versions or support of all versions through-
`out such a network will limit the actual utilization of RPC
`for component management.
`SUMMARY OF THE INVENTION
`
`According to the principles of this invention, a computer
`process for using remote procedure calls over a hetcroge-
`neous computer network overcomesthe problemsassociated
`with supporting different versions of application program-
`ming interfaces by remote procedure call modules on client
`and server computers,
`i.e.,
`first and second computers.
`Moreover, the remote procedure call process of this inven-
`tion is independent of the architecture of the computer
`platforms on the network,
`i.e.,
`the process can be used
`between computers having different computer architectures.
`Unlike prior art RPC modules that were required to
`support every single command that was defined inthelist of
`procedurecalls for every possible version, the RPC modules
`of this invention support only a single RPC commandthat
`transfers a buffer of information. The particular information
`in the buffer does not affect
`the operation of the RPC
`module. Consequently, the RPC modules are independent of
`
`

`

`5,926,636
`
`5
`the client applications and application programming inter-
`faces with which the RPC modulesinteract.
`
`In one embodiment, a message buffer in a first computer
`is filled with information (including a version of an appli-
`cation programming interface on the first computer) by the
`client application, executing on the first computer, calling a
`function in the application programming interface. The
`application programminginterface issues a messagetransfer
`remote procedure call to a remote procedure call module on
`the first computer to transfer the message buffer over the
`heterogeneous computer network to a second computer.
`Each ofa plurality of functions called in the application
`programming interface fill the message buffer and then call
`the single remote procedure call commandto transfer the
`message buffer. Preferably, the information in the message
`buffer is one byte-aligned.
`When the message buffer is received in the second
`computer, the version of the application programminginter-
`face in the message buffer is compared with a version of an
`application programminginterface on the second computer.
`Specifically, in one embodiment a plurality of version iden-
`tifiers of the application programming interface on thefirst
`computer are compared with a plurality of version identifiers
`of the application programming interface on the second
`computer.
`If the comparison of the version of the application pro-
`gramminginterface in the message buffer with a version of
`an application programming interface on the second com-
`puter indicates that the versions are compatible, processing
`of the message is continued on the second computer.
`Conversely, if the versions are incompatible, an error is
`placed in the message and the message is returnedto the first
`computer.
`Prior to comparing the versions on the second computer,
`a field is read in the messagethat includesanidentifier of the
`computer architectureofthe first computer, e.g., the address-
`ing format. If the computer architecture of the first computer
`is incompatible with the computer architecture of the second
`computer, the message is converted to a form that is com-
`patible with the second computerprior to making the version
`comparison.
`In another embodiment of this invention, a component
`management function call is issued from a remote client
`application on a remote client computer to a remote client
`component managementapplication programminginterface
`on the remote client computer. In response to the remote
`client component management function call,
`the remote
`client component management application programming
`interface builds a message in a buffer memoryof the remote
`client computer. The message includes an identifier for the
`called component managementfunction and a version ofthe
`component managementapplication programminginterface.
`The remote client component management application
`programming interface sends the message to a server com-
`puter on a heterogeneous computer network using a remote
`procedure call command module. The remote procedure call
`command module is independent of the called component
`management function.
`Specifically, to send the message, the remote client com-
`ponent management application programming interface
`calls a local message transfer remote procedure call com-
`mand to transfer the message from the client component
`management application programming interface to the
`remote procedure call module on the client computer.
`The remote procedure call module packages the message
`for transfer over the hetcrogencous computer network. The
`
`10
`
`20
`
`25
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`remote call module transmits the packaged messageto a first
`network stack on the client computer whichin turn transmits
`the packaged message from the first network stack to a
`second network stack on a server computer. The packaged
`message is transmitted from the second network stack to a
`server RPC command module on the server computer. The
`server RPC command module converts the packaged mes-
`sage back to the message. The message is then transferred
`from the server RPC command module to a server compo-
`nent managementapplication programminginterface on the
`server computer.
`The server component managementapplication program-
`ming, interface reads a field in the message to determine
`whether an addressing format of the client computer is
`compatible with an addressing format of the server com-
`puter. If the addressing formats are not compatible,
`the
`server component management application programming
`interface converts the message to an addressing format
`compatible with the server computer.
`After the checking of the addressing format and the
`conversion if necessary,
`the versions are checked as
`described above. The elimination of the version dependency
`of the RPC module facilitates use of RPCs in a wide variety
`of heterogeneous networks.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a diagram of a prior art heterogeneous network.
`FIG. 2 is an illustration of a prior art network stack.
`FIG. 3 is a diagram of the prior art desktop management
`interface in a desktop computer system.
`FIG. 4 is anillustration of a structure used to implement
`RPCsover a heterogeneous network for management of a
`RAID structure.
`
`FIG. 5 is an illustration of a structure and processof this
`invention for implementing, over helerogeneous networks,
`version independent RPCs for component management.
`FIGS. 6A and 6B are a more detailed illustration of the
`
`structure and process of this invention for implementing,
`over heterogeneous networks, version independent RPCsfor
`component management.
`
`DETAILED DESCRIPTION
`
`According to the principles of this invention, a remote
`procedure call process for management of components on a
`heterogeneous network 500 eliminates problems associated
`with differing versions of the remote procedure call process
`on a client and a server. The remote procedure call process
`of this invention minimizes, and in some applications
`eliminates, updating the remote procedure call modules;
`simplifies the distribution of updates; and is platform inde-
`pendent.
`In this embodiment, heterogeneous network 500 includes
`multiple types of clients, e.g. Windowsclient 501, remote
`client application 511, and OS/2 client 502, and multiple
`types of servers, e.g., Windows NT server 505, a server
`computer 520 that includes I/O manager server 530, and
`Unix server 506. According to the principles of this
`invention, a remote client component management applica-
`tion programming interface 512 is interposed between a
`remote client application 511 on a remote client computer
`510 and a remote client RPC command module 515. Herein,
`a clicnt application, application programming intcrfaccs,
`modules, and stacks are referenced. Those skilled in the art
`will understand that such applications, interfaces and mod-
`ules represent software processes that execute on a computer
`
`

`

`5,926,636
`
`7
`while a network slack represents a combination of software
`processes and hardware operations.
`Remote client component managementapplication pro-
`gramming interface 512 does not directly provide compo-
`nent managementfunction calls with parameters to remote
`clicnt RPC command module 515, as in prior art RPC.
`Rather, according to the principles of this invention,
`in
`response to a component management function call by
`remote client application 511, remote client component
`management application programming interface (API) 512
`generates a message RPC_MESSAGEREQUEST that
`identifies the called function and the version of remote client
`
`10
`
`15
`
`8
`RPCis the local message transfer RPC command, message
`RPC_MESSAGE_REQUESTis passed to server compo-
`nent managementapplication programming interface 522.
`Server component managementapplication programming
`interface 522 parses message RPC_MESSAGE _
`REQUESTpassed from server RPC command module 525
`to determine the computer architecture of remote client
`computer 510, ¢.g., the addressing format used on remote
`client computer 510. With this information, server compo-
`nent management API 522 reads the version specified in
`message RPC MESSAGE REQUEST.Thespecified ver-
`sion is compared with the version of server component
`management API 522. If the specified version is incompat-
`component management API 512.
`ible with the version of server component management API
`After remote client component management API 512
`522, a reply indicating the version incompatibility is placed
`builds message RPC_MESSAGE_REQUEST,remotecli-
`in the message that in turn is transmitted to remote client
`ent component management API 512 calls a local message
`application 511 by server component management API 522.
`transfer RPC command to send message RPC_
`MESSAGE_REQUEST 1o remote client RPC command
`When the specified version is compatible with server
`component management API 522, message RPC_
`module 515. Consequently, remote client RPC command
`20
`MESSAGE_REQUESTis passed to I/O manager 530, as
`module 515 supports only a single function call and not each
`message IPC_MESSAGEin a format compatible with I/O
`component management function supported by server com-
`manager 530, using standard operating system interprocess
`ponent managementapplication programminginterface 522.
`communication. As is known to those of skill in the art, the
`This configuration decouples the RPC from the particular
`addressing format may not be the same on remote client
`version of server component management API 522, and so
`computer 510 and server computer 520. It is the responsi-
`eliminates the prior art problems associated with incompat-
`bility of server component management API 522 to assure
`ible versions of function calls supported by remote client
`and server RPC command modules 515, and 525 over
`that message RPC_MESSAGE_REQUESTis converted to
`message IPC_MESSAGE in a form, ¢.g., addressing
`network 500. This configuration also supports changes to
`format, that can be processed by I/O manager 530. If no
`remote client RPC command module 515 without affecting
`conversion is necessary, message RPC_MESSAGE_
`component management APIs 512 and 522, and converscly.
`REQUESTis simply passed through as message IPC__
`In addition to the single function call for all component
`MESSAGEafter the version comparison.
`management function calls, in one embodiment, adminis-
`In this embodiment, I/O manager 530 interfaces with a
`tration application programming interface calls by remote
`plurality of components 540-1 to 540-n. Components 540-1
`client application 511 to component management API 512
`to 540-n can include software applications, operating
`are passed to remote client RPC command module 515.
`systems, hardware products, peripheral devices, and system
`Administration application programming interface calls are
`used to establish a network session, and to ensure the
`hardware. In response to message IPC_MESSAGE, I/O
`manager 530 performsthe called function for the specified
`authentication and access rights of remote applications issu-
`component and if necessary places a reply in message
`ing component managementfunction calls.
`IPC_MESSAGE.
`Thus, in this embodiment, remote client RPC command
`module 515 supports two sets of operations. A first set of
`operations processes the local message transfer RPC
`command, and packages the message for transfer as a RPC
`over network 500. A second set of operations handles the
`administration functions supported by the administration
`API, and packages the administration function call for
`transfer as a RPC over network 500. In both cases,
`the
`message is packaged using the prior art techniques for the
`particular type of RPC implemented on remote client com-
`puter 510.
`Remote clicnt RPC command module 515 scnds the
`
`35
`
`40
`
`45
`
`50
`
`packaged RPC to network stack 516 which in turn transmits
`the packaged RPC over heterogeneous network 500 to
`network stack 526 in server computer 520. Any of the
`various network stacks illustrated in FIG. 2 may used with
`this invention. Server computer 520 is not identified as any
`particular type of server, because the principles of this
`invention are independent of the particular type of server.
`Those skilled in the art, in view of this disclosure, will be
`able to implement the invention in a wide variety of servers.
`Network stack 526 provides the packaged RPC to server
`RPC command module 525. Server RPC command module
`
`525 unpacks the packaged RPC in a conventional mannerto
`obtain the RPC. If the RPC is a procedure call
`to the
`administration API, server RPC command module 525 pro-
`cesses the procedure call and responds appropriatcly. If the
`
`55
`
`60
`
`65
`
`/O manager 530 returns message [IPC_MESSAGE,that
`includes the result, to server component management API
`522. Server component management API 522 passes
`returned message IPC_MESSAGE as message RPC__
`MESSAGE_RESULT