JPH06208519A - Communication interface generating system and method therof - Google Patents

Abstract

PURPOSE: To produce a symmetrical communication interface by using an asymmetrical tool. CONSTITUTION: Interface files having first and second functions are produced by translating two interface definition files. The first interface file from the first interface definition file and the second interface file from the second interface definition file are invalidated and the remaining files are copied to a plurality of systems on a network. A preferable means which produces the second interface definition file from the first interface definition file is an automatic interface definition file editor which corrects the character string of each function name in the first interface definition file.

Description

Detailed Description of the Invention

FIELD OF THE INVENTION This invention relates to communications within local area networks. In particular, it relates to generating a symmetrical set of replicas in multiple nodes using customer server-oriented tools.

BACKGROUND OF THE INVENTION It is becoming more and more common to connect multiple data processing systems in a distributed environment through local area networks, wide area networks or other similar means. Networks are made more complex by several different LAN communication protocols coupled to data processing systems from multiple vendors of networks. A common model for local area networks is the customer server or master-slave model. In this type model, a process on a customer or master data processor requests service from a process on a server or slave data processing device. A comparable model is a peer-to-peer relationship, where each server, or at least a subset thereof, is essentially a duplicate of the others in the network. Since the customer and server are asymmetric, the tools developed in the customer server system environment are difficult to use to construct programs with peer relationships. The program components created by such tools typically have intermediate code segments that are error prone and hard to maintain. To illustrate the problem, consider the following: Suppose a distributed name service is created on multiple data processing devices of the network. There is one name server on each machine. Customers from any machine in the network can query the local server. Each server only has a subset of all names in the entire distributed name service. When the server receives a query for a name with no information, it calls the peer name server for resolution. At the replicated server, as with all running program sets, the name lookup interface must be the same whether the call is from a customer or a remote peer. The advantage of this uniformity is that none of the servers have to deal with special cases. That is, there is no need to check whether the call is from a peer server or an external customer. If a set of replicas is developed by traditional customer server tools, the calls from one server to another are the same calls that the server itself answers. This has the effect of shorting out all remote calls, making remote procedure calls look like recursive calls rather than calls to their peers. To prevent such short circuits, it has been proposed in the Distributed Computing System Environment (DCE) that two names be used for each server function. One name is used by the server customer and the other name is used for the actual implementation of the server function. The module that performs the function is called the manager. The manager entry point vector is used to associate the name used by the customer and the actual realized name. While this method is performed, the programmer must change the manager entry point vector whenever manager functionality is added or removed. Further, the scheme is implemented by matching the serial number of the server interface function with the serial number of the manager function of the manager entry point vector. It may not be checked at compile time, so there may be an error in a number parameter match, for example. This can lead to unexpected run-time errors. The second method the prior art has sought to solve the problem is to eliminate the customer switch file on the customer side and require the server to call the peer using the customer entry point vector instead of the normal function name. That is. This reveals to developers of distributed server programs how remote procedure calls (RPCs) work, and requires their understanding of RPCs. This is not desirable. The present invention is
It suggests a way to achieve peer-to-peer communication with customer server tools with less errors and easily sustainable code.

It is an object of the present invention to create a symmetric communication interface for networks using asymmetric tools. Another object of the invention is to reduce operator-induced errors in a symmetric communication interface. Another object of the invention is to automate the process of creating a symmetric communication interface.

The object of the invention is achieved by defining two interface definition files for a particular distributed application for the interfaces between replicas in a network. The first interface definition file is used by the replica of the second mission to call the second replica of the first mission,
The second interface definition file is used for the replica performing the first task to define its service. The first and second missions are, for example, server and customer missions. Both interfaces use the same interface identification number, typically the identification number is in the first line of the file. In the preferred embodiment, each interface definition file is
Identical to the corresponding server codeline, except for the prefix or suffix for all feature names in the file. Subsequent steps are performed in the process of the invention. Two interface definition files are fixed I
Defined by D. Both interface files are run through the interface definition compiler to produce interface files for distributed applications. In the distributed computer system environment to which the present invention applies, the interface files are called customer and server stub files. The server stubs from the first interface definition file are invalidated and the customer stubs from the second interface definition file are invalidated. Or vice versa. The resulting set of customers and server stubs is replicated for a set of peer systems executing applications within the network. When linking a peer application to perform the function defined in the interface definition file, the customer and server stub that occurred earlier is used. Customer stubs are used when linking regular customer programs.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT The present invention is applicable to many different operating systems.
・ Various computers or computers under the system
Can be run on a group of data. Computer
For example, personal computer, mini computer or
Is available for mainframe computers. Shi
Scarecrow, local area network, wide area network
Or a large teleprocessing system
Used by multiple computers that are part of a large network
Preferably. The specific choice of computer
Limited by disk and disk storage requirements
However, the IBM PS / 2 Lot Series computer book
It can be constructed according to the invention. IBM PS / 2 series
For more information, please see the following references: Technical record
Reference Manual, Personal Systems / 2
Models 50 and 60, Part No.68X2224 Order No. S68X-
2224, and Technical Reference Manual,
Personal Systems / 2 (Model 80), Part N
o. 68X2256 Order No. S68X-2254. IBM PS / 2 Personal Co
The operating system that the computer runs
One is IBM OS / 2 2.0. Details of IBM OS / 2 2.0
See the references below. OS / 2 Technical Library
Re, programming guide Vo.1, 2, 3 version 2.0
0. Order No. 10G6261, 10G6495, 10G6494. Also a calculator
The system runs on the AIX (TM) operating system.
A running IBM RISC System / 6000 (TM) computer
It is possible. The various model models of RISC System / 6000 are
RISC System / 6000, 7-073 and -7016 Power Ste
Option and Power Server Hardware Tech
Like Nical Reference Order No. SA23-2644-00
It is described in many IBM publications. AIX operation
Rating system is a general concept
And Procedure-AIX Version 3 for RIS
IBM Systems such as C System / 6000 Order No. SC23-2202-00
It is described in many publications. In Figure 1, Compu
The system 10 includes a system unit 11, a keyboard 12, and a mouse.
13 and a display 14. Display
The screen 16 of the device 14 provides a visual representation of the data object.
Used to indicate a change. Operating system
The pictorial user interface supported by Tem is
The user selects the data object at a specific position on the screen 16.
Move the pointer 15 to the icon shown in
Using the "Insert and Shoot" method.
Selecting one of the user commands by pressing one of the buttons on the mouse
To enable. Selected data object selected
Appears in the window that presents the view. FIG. 2 corresponds to FIG.
Multimedia personal computer shown in
3 shows a block diagram of the components of FIG. The system unit 11 is
Various components are connected and communication between components is achieved.
1 or more system buses 21 are included. My
The black processor 22 is connected to the system bus 21 and
Storage device (ROM) connected to the system bus 21
23 and a direct storage device (RAM) 24
It TBM multimedia PS / 2 computer series
The microprocessor is a microprocessor 386 or
Is one of the Intel product microprocessors including 486
Is. However, 68000, 68020 or 680
Motorola product microphones such as 30 microprocessors
Not only microprocessors but also other microprocessors
It In addition, IBM, Hewlett-Packard, Sun
Manufactured by Intel, Motorola, and others.
Various reduced instruction set computer (RISC) microphones
The processor can be used in this specification computer.
You can ROM 23 is an interactive function, disk drive
Basic hardware operators such as keyboard and keyboard
Basic input / output system (BIOS) or other
Including code. RAM 24 is the operating system
System and multimedia application programs loaded
It is the main memory that is used. The memory management chip 25
Connected to system bus 21, RAM 24, hard disk drive
Between live 26 and floppy disk drive 27
Direct memory access operation including data exchange
Control the solution. Similarly, connect to the system bus 21.
CD ROM 32 is a multimedia program or
Used to store large amounts of presentation data
Used. Various I / O controllers, keyboards,
Controller 28, mouse controller 29, bi
Deo controller 30 and audio controller
Keyboard 31 and keyboard controller 28
For the board 12, the mouse controller 29 is
Providing a hardware interface for us 13
To serve. The video controller 30 has a display 14
Audio controller 31 for speaker 1
Hardware interface for 5A and 15B
It is the source. In addition, a speaker system is connected to the system bus 21.
Corrects the sound produced by the
The digital signal processor 33 connected to the controller 31 is connected
is doing. Speakers 15A and 15B are audio
It is used to present the object to the user. Finally,
I / O controller 40 such as Token Ring adapter
Connect to the system bus and connect the system to a local area
Connect to the network 50. Distributed computer system environment
Boundary (DCE) is a solution for a set of problems in a distributed environment.
Includes BM, DEC and Hewlett-Packard
It is the result of efforts by a group of companies. Some of the problems are DC
E There is a remote procedure call (RPC) execution. RPC
Is a model of communication between application customers and servers
It Communication between multiple peer applications in a distributed environment
Adapted by the present invention. Traditional local procedure
Remote procedure calls, as in
Control from one code module to another
And then go back to the original code module.
However, local procedure calls are typically the same
Code modules in the same address space on the machine
use. RPC is a different system connected to the network.
Remote procedure that executes in different address spaces on the system
Call you. When calling a remote procedure,
And return value is a message for transfer on the network
Must be packed in. The RPC mechanism is
As Silla looks like a local procedure call,
Used to make application programmers understandable
To be done. The RPC mechanism is a network transfer between peer applications.
Eliminates the need for the programmer to know the delivery details. Remote procedure
Caller call allows different structures,
Network details such as
Must be rewritten by the application for each possible situation.
No need. RPC is almost a local call in DCE
looks like. Interface definition file and
Its compiler, universally unique identifier generator and RP
Used to mask networks with C execution time
There are several components that are: Two RPC communication rules
Is supported. Connection-oriented transmission control
Internet Protocol / Internet Protocol (TCP /
IP), and connectionless user datagram protocol
/ Internet Protocol. Interface definition
The file is written in DCE Interface Definition Language (IDL).
Stated. The interface definition file is an IDL
Compiled into a computer language like C using Pyler
Then, the application server and application customer
Two interface file objects
-Compiled into code. These interfaces
Stub files are called server stubs and customer stubs.
Be exposed. The traditional implementation of the DCE concept is the customer switch
A second customer interface file called
Contains. The interface definition file is for each RPC
Used to define the interface. Interface
Interface can be executed by a particular server application.
It is a group of functions that can be done. For example, financial applications
Perform a debit, credit, or balance read / write operation
To do. Each of these functions is a financial application interface.
Must be defined in the face definition file. DC
In E, call in rather than execute procedure
Only the interface is defined. After compiling
Tabs are from other parts of the application, traditionally customers
Calls across the network for your services
Linked to the calling part of the application to be done. server·
A stub is an interface definition file that is usually a server.
As part of the application that performs the function defined in the
To be killed. RPC runtime library on the network
Set of routines to perform peer-to-peer communication for distributed applications
including. The tasks to be performed include
Finding the server, communication between the customer and the server, the request
There is state management during communication error handling. Universally unique identifier
The generator is a unique identifier for each RPC interface
To pay. DCE RPC module also provides secure communication
Warranty service for, put the server in the network
Name service API to help
RPC daemon and RPC daemon for managing transfer endpoints
It includes a control program to manage the software. Network / total
Computer System System (NES) 1.0 is part of AIX
The distributed computer system environment extension 1.0 to AIX is IDL
It is an example of an RPC product including a computer. Interf
After the base file is generated, call the distributed application.
The issuing part is the part of the application that performs the requested function.
Have to find. This process is called binding.
Be exposed. The call application is for the service that was executed.
Mold, controlled object mold and supported interface
Specific interface to find out information including
Database for the location of the application running the
You can access the directory service. I
Server application running the interface or other
Application of the server in the directory service
Described to "advertise" the screw. RPC daemon
Is a directory server that changes each time the server starts
Accurate network end point of server application in bis
Used to update. Figure 3 shows the server and
Customer interface file or stub is generated
After the two data processing connected to the network 99
Diagram of code modules in systems 100, 110
To show. The distributed application and stubs of the present invention are numerous systems.
Copied to the stem, but two cis
Only the system is shown. Direct writing of each system 100, 110
The storage device has a copy 103 of the network application,
03 ', which is another system of network 99
Request service from. For this application 103
Two interface definition files 104 and 105
But the first system 1 with the same interface definition ID
It is generated in 00. Each interface definition file
Interface definition compiling from
La 106 generates two or three stub files
It One stub file is the server stub 10
7, 117, called a distributed application server or server
It is connected to the bus part. The other two are customer stubs 108,
118 and customer switch stubs 109, 119
be called. These are selectable and suitable for your local system.
Related to customer copy of work. First interface
Customer definition file 104 from the customer definition file 104
Tab 108 and customer switch stub 109 disabled
Then, the server stub 107 is saved. Second Inn
Server stub from the interface definition file 105
117 is invalidated, the customer stub portion, the customer stub 11
8 and customer switch stub 119 are saved. I
Interface definition editors 112, 113
From the interface definition file 104 to the second interface
Used to generate the interface definition file 105.
Be done. The AIX system is used while the special purpose editor is used.
An ordinary SED-like stream editor in a mobile environment
Can be used. System 100, 110
Each of the RPC execution time modules 114 and 115 is suitable.
Providing communication services between business replicas. Figure 4
Extra server and customer star from the first system 100
File is deleted and the remaining server and customer
After the copy file is replicated on the second system 110
The code in the two workstations 100, 110
-Illustrate the module. First interface definition
Server stub 107 and second from file 104
From the client interface definition file 105
Servers 118 and 119 are replicated across the network.
Of customer and application program 103 replicas
Linked to the server part. Distributed application is remote machine
Second interface when communicating to a replica on
Use the customer stubs generated by the
Therefore, the short circuit problem is solved. Application is a server
When it wants to work like
Use the server stub generated by the definition file
It The two interfaces may have different names or
While having a sequencer, the same for interface definition
Share the same ID number. In the DCE system,
The face ID number is used to identify the interface.
Used. Nets for specific procedures from the server
Network calls are within the scope of the interface.
Interface number and function serial number
It does not include the actual function name used by the business. Minute
This feature of the computer system environment allows the present invention to function.
can do. Essentially two interfaces
Called by the name of. Interface with server
Function in the server stub.
Is used. Interface acts as a customer
Other name sets in the customer stub are used when
It When the service is called using the customer set name,
The service is ultimately the service that is actually providing the service.
Arrive at the basset name. In FIG. 4, according to the invention
Remote procedure calls are illustrated. First system
Application in the system 100 and the second system 110
The peers 103 and 103 'are activated and roam in the network.
"Advertise" applications to directory services.
In this example, the application peers 103, 103 'are decentralized finance
Assume it is part of an application. Thus the application
Financial service required or financial application peer 1
When 03 needs to contact his peer 103 ',
The application knows where to send the RPC. Last
The peer 103 on the first system 100 is
Because I can't answer the request about myself,
Call peer 103 'on system 110. Peer 103
Is a directory for peer network addresses
・ Call the service and remote procedure to the customer stub 118.
Caller 131 is sent. The customer stub 118 is a network
The call argument of the call message 133
Message 13 at runtime 115 on the system 110
Call the runtime library that sends 5. RPC is a server
Send network message 137 to stub 107 '
Execution time library 1 on the second system 110
Received by 15. Server stub 107 '
Unpacks the argument and performs the requested function
In order to hand over to the corresponding part of peer 103 '. Customer stub
RPC 131 generated by application 103 in 118
By the customer side of the application and the customer stub 118
Use a shared feature name. For example, RPC131
Assume it is for the third function starting with the letters "pqr"
It Customer stub is interface ID, function serial number
No. and network regulations including network agreement information
Compile this into about a call. For application 103
Assume that the interface ID to be used is "A1O3B"
And the network message 133 is "A103B | 3 | ...
| ... ”. "A103B" is the ID number and "3" is the third
In the interface of "pqr ..."
It is a number. Message 137 reaches server stub
The procedure call that the server part can understand.
Will be packed. Server stub has the same interface
Search function that has serial number "3"
"RC_pqr ..." is searched and passed to the server part when
It The process in which the server part responds is exactly the opposite.
Is. Server sends RPC result to server stub
And the server stub will send it to the network message.
Pack them. Server stub is local execution time
Send network messages to the library,
Local runtime library is runtime on customer system
Send it to the library for a while. Runtime library
Is responsible for unpacking the message to the calling peer.
Send a message to the customer stub. Designed a distributed application
The same programmer designed the interface definition file
So that the programmer can
Know the rules used in the server or customer mission
Make the application perform the appropriate RPC when fulfilling the
be able to. An editor like a stream editor
The second interface definition by using
The process of generating files is easily automated
It For example, "sample.idl" is the first interface
In the definition file AIX, execute the following command.
By executing the second interface definition file
(SampleTwo.idl) is created: "sed's / RC-// s
ample.idl> sampleTwo.idl ”. Sed runs all UNIX platforms.
Stream Editor, a standard program for programs
Is. On the other hand, the second interface definition
You can also design a tool to generate
It Utility “m” valid on other versions of AIX and UNIX
ake ”to create the final product, such as a program,
Document or object code library
When making, you can automate a series of steps
It "Make" is a reference that contains a set of rules and
Read a file that is typically called a "makefile". Servant
A generic instruction has a prerequisite target name and list. Premise
The condition is valid or made before the goal is made
A file or other object that must be present. Regulation
The rule is which program must be run to make a goal
Must be specified or identified from prerequisite file. for example
For example, from the C source file "myprog.c" file to "myprog.
To create a goal program called "g"
Specify street dependency: "myprog: myprog.c". I was demanded to
Specify the following to show the rules for generating goals
R: "cc -o myprog myprog.c". Thus, call it "cc"
The C compiler to be executed is executed on "myprog.c".
And the final result is written in a file called "myprog"
Be done. "Myprog.c" itself is the result of executing another program
If it is the result, then "make" searches for the appropriate rule and returns "my".
Run the program that produces "prog.c". Generally, "ma
ke was requested, starting with those that have no prerequisites
Until the goal is created, one step at a time
Ku. Also, which program you are using to create the latest goals.
File to see if you need to rerun
Use the date and time stamp above. Above example
So whenever "myprog.c" changes
Consistent "my by typing gram" make "
"prog" is rebuilt. So the "make" utility
I is distributed application, interface definition file,
Interface files, server and customer stubs
It is an easy method to automate the update process. First inn
Taking the modification of the interface definition file as an example, for example,
Suppose you want to add new functionality provided by the server mission.
"Makefile" is the second interface definition file
By the IDL compiler.
Interface definition file to compile the server
And generate a first and a second set of customer stubs,
Except for minute stubs, remaining stubs are distributed application peers
Used to link to. In this way other peers are new
You can learn about new features. interface
An example of the definition file is shown below. Each function has a function name with "RC
Note that it contains an _. (The following part is a program
I don't translate because it's lamb. ) / * * @ (#) Master.idl 1.6 12/21/90 10:11:18 (c) IBM Corp. 1990 * /% c (uuid (4cbf3dbO1d34.02.81.23.1c.d8.00.00.00), port (ip: [6666]), version (1)] interface PODmaster {#include || <data.const.h>#include<data.types.h> || void RC_registerShadow (handle_t [in] h, ObjRef [in] newPod, Mode [in] m); || void RC_unregisterShadow (handle_t [in] h, Objref [in] oldPod); | | int || RC_requestToken (handle_t [in] h, || || ObjRef [in] shadow, int [in, out] * shadoVersion, || || string0 [MTHD_NAME_MAX] [in] * methodname, || || LogRecord [out] * logBuf); || void RC_releaseToken (handle_t [in] h, ObjRef [in] shadow, stringO [MTHD_NAME_MAX] [in] * methodname); || || / * how do you indicates params to method ?? * / || MasterBidRetCode RC_WantToBeMaster (handle_t [in] h, ObjRef [in] shadow); || void RC_applyUpdates (handle_t [in] h, VerNumber [in] ver, LogRecord [in] &lRec); || void RC_sendRefresh (handle_t [in] h, ObjRef [in] shadow, VerNumber [in] version. LogRecord [in, out] * lRec); An example of the second interface definition file is shown below.
You The function name is shortened by omitting "RC_"
Please note that (The following part is the program
So I don't translate. ) / * * @ (#) Master.idl 1.6 12/21/90 10:11:18 (c) IBM Corp. 1990 * /% c (uuid (4cbf3dbOld34.02.81.23.1c.d8.00.00.00), port (ip: [6666]), version (l)] interface PODmaster {#include || <data.const.h>#include<data.types.h> || void registerShadow (handle_t [in] h, ObjRef [in] newPod, Mode [in] m); || void unregisterShadow (handle_t [in] h, ObiRef [in] oldPod); | | int || requestToken (handle_t [in] h, || || 0bjRef [in] shadow, int [in, out] * shadoVersion, || || string0 [MTHD_NAME_MAX] [in] * methodname, || || LogRecord [out] * logBuf); || void releaseToken (handle_t [in] h, ObjRef [in] shadow, stringO [MTHD_NAME_MAX] [in] * methodname); || || / * how do you indicates params to method ?? * / || MasterBidRetCode WantToBeMaster (handle__t [in] h, ObjRef [in] shadow); || void applyUpdates (handle_t [in] h, VerNumber [in] ver, LogRecord [in] &lRec); || void sendRefresh (handle_t [in] h, ObjRef [in] shadow, VerNumber [in] version, LogRecord (in, out] * lRec); || void savePOD (handle_t [in] h, ObjRef [in] shadow);} This file is AIX Use the following instructions above to select `` Sample.
It is generated from the "idl" file. Sed 's / RC-11'sample.idl> sample2.idl Sed is a standard stream editor for all UNIX systems.
It is. First interface with IDL compiler
Server stub generated by compiling the definition file
-A simplified example of the file in C language is shown below. Inn
Includes the first two functions from the Tarfs definition file
Has been. (Because the following part is a program, do not translate
Yes. ) #Define NIDL_GENERATED #define NIDL_SSTUB #include "master.h" static RC_registerShadow_ssr #ifdef __STDC__ (handle_t h, rpc_ $ ppkt__t * ins, ndr __ $ ulong_int ilen, rpc_ $ ppkt_t * outs, ndr_ $ d rpc_int, outdr_ $ d, rdr $$ rong_int rpc_ $ ppkt_t ** routs, ndr_ $ ulong_int * olen, ndr_ $ boolean * free_outs, status_ $ t * st) #else (h, ins, ilen, outs, omax, drep, routs, olen, free-outs, st) handle_t h; rpc_ $ ppkt_t * ins; ndr_ $ ulong_int ilen; rpc_ $ ppkt_t * outs; ndr- $ ulong_int omax; rpc_ $ real.drep_t drep; rpc_ $ ppkt_t ** routs; ndr_ $ ulong_int * olen; ndr_ $ boolean * free_outs; status_ $ t * st; #endif {/ * marshalling variables * / ndr_ $ ushort_int data_offset; ndr_ $ ulong_int bound; rpc_ $ mp_t mp, dbp; ndr_ $ ushort_int count; / * local variables * / Mode m_; ndr_ $ char newPod_; / * unmarshalling init * / data_offset = h->data_offset; rpc_ $ init_mp (mp, dbp, ins, data_offset); if (rpc_ $ equal_drep (drep, rpc_ $ local_drep)) (/ * unmarshalling * / rpc_ $ unmarshall_char (mp, newPod_); rpc_ $ advance_mp (mp, 1); rpc_ $ align_ptr_relative (mp, dbp, 4); rpc_ $ unmarshall_ulong_int (mp, m_);} else {rpc_ $ convert_char (drep, rpc_ $ local_drep, mp, newPod_); rpc_ $ advance_mp (mp, 1); rpc_ $ align__ptr_relative (mp, dbp, 4); rpc_ $ convert_ulong_int (drep, rpc_ $ local drep. mp, m_);} / * server call * / RC_registerShadow (h, & newPod_, m_); / * buffer non-allocation * / * free_outs = false; * routs = outs: * olen = O; 2. st-> all = status_ $ ok;} static RC-unregisterShadow_ssr #ifdef __STDC__ (handle_t h, rpc_ $ ppkt_t * ins.ndr_ $ ulong_int ilen, rpc_ $ ppkt_t * outs, ndr_ $ ulong_int omax, rpc_ $ real_drep_t drep, rpc_ $ ppkt_t ** routs.ndr_ $ ulong_int * olen, ndr_ $ boolean * free_outs, status_ $ t * st) #else (h, ins, ilen, outs, omax, drep, routs, olen, free_outs, st) handle_t h; rpc_ $ ppkt_t * ins; ndr_ $ ulong_int ilen; rpc_ $ ppkt_t * outs; ndr_ $ ulong_int omax; rpc_ $ real_drep_t drep; rpc_ $ ppkt_t ** routs; ndr_ $ enong_int ; ndr_ $ boolean * free_outs; status_ $ t * st; #endif {/ * marshalling variables * / ndr_ $ ushort_int data_offset; ndr_ $ ulong_int bound: rpc_ $ mp_t mp, dbp; ndr_ $ ushort_int count; / * local variables * / ndr_ $ char oldPod_; / * unmarshalling init * / data_offset = h->data_offset; rpc_ $ init_mp (mp.dbp, ins, data_offset) .; if (rpc_ $ equal_drep (drep, rpc_ $ local_drep)) {/ * unmarshalling * / rpc_ $ unmarshall_char (mp, oldPod_);} else (rpc_ $ convert_char (drep, rpc_ $ local_drep, mp, oldPod_);} / * server call * / RC_unregisterShadow (h, & oldPod_ ); / * buffer non-allocation * / * free_outs = false; * routs = outs; * olen = O; st-> all = status_ $ ok; globaldef PODmaster $ epv_t PODmaster $ manager_epv = (RC_registerShadow, RC_unregisterShadow, RC_requestToken, RC_releaseToken , RC_WantToBeMaster, RC_applyUpdates, RC_sendrefresh. RC_savePOD}; static rpc_ $ server_stub_t PODmaster $ server_epva [] = {(rpc_ $ server_stub_t) RC_registerShadow_s_r ____________ r__r__________________ rpc_ $ server_stub_t) RC_WantToBeMaster_ssr, (rpc_ $ server_stub_t) RC_applyUpdates_ssr, (rpc_ $ server_stub_t) RC_sendRefresh_ssr, (rpc_ $ server_stub_t) RC_savePOD_ssr}; globaldefrpc _ $ epv _t PODmaster $ server_epv = (rpc_ $ epv_t) PODmaster $ server_epva; Second interface definition file with IDL compiler
C of the customer stub file generated by compiling
The following is a simplified example of words. Interface definition
The first two functions from the file are included. (Less than
The part of is a program and is not translated. ) 1. # define NIDL_GENERATED #define NIDL_CSTUB #include "master.h"#include"pfm.h" static void registershadow_csr #ifdef__STDC__ (handle__t h_, ObjRef newPod_, Mode m_) #else (h_, newPod_, m_) #endif # ifndef __STDC__ / * parameter declarations * / handle_t h_; ObjRef newPod_, Mode m_; #endif {/ * rpc_ $ sar arguments * / rpc_ $ ppkt_t * ip; ndr_ $ ulong_int ilen; rpc_ $ ppkt_t * op .: rpc_ $ ppkt_t * routs; ndr_ $ ulong_int olen; rpc_ $ real__drep_t drep; ndr_ $ boolean free_outs; status_ $ t st; / * other client side local variables * / rpc_ $ ppkt_t ins; rpc_ $ ppkt_t outs; ndr_ $ ushort_int data offset; ndr_ $ ulong_int bound; rpc_ $ mp_t mp, dbp; ndr_ $ ushort_int count; ndr_ $ boolean free_ins; / * marshalling init * / data_offset = h _->data_offset; bound = O; / * bound calculations * / bound + = 8; / * buffer allocation * / if (free_ins = (bound + data_offset> sizeof (rpc_ $ ppkt_t))) ip = rpc_ $ alloc_pkt (bound); else ip = &ins; rpc_ $ init_mp (mp, dbp, ip, data_offset); / * marshalling * / rpc_ $ marshall_char (mp, (* newPod_)); rpc_ $ advance_mp (mp , 1), rpc_ $ align_ptr_relative (mp, dbp, 4); rpc_ $ marshall_ulong_int (mp. M_); rpc_ $ advance_mp (mp, 4); / * runtime call * / ilen = mp-dbp; op = &outs; rpc_ $ sar (h_, (long) O, & PODmaster $ if_spec.OL, ip, ilen, op, (long) sizeof (rpc_ $ ppkt_t), & routs, & olen, (rpc_ $ drep_t *) & drep, & free_outs, &st); if (free_ins) rpc_ $ free_pkt (ip);} 2.static void unregisterShadow_csr #ifdef __STDC__ (handle_t h ObjRef oldPod_) #else (h_, oldPod_) #endif #ifndef __STDC__ / * parameter declarations * / handle_t h_; ObjRef oldPod_. # endif {/ * rpc_ $ sar arguments * / rpc_ $ ppkt_t * ip; ndr_ $ ulong_int ilen; rpc_ $ ppkt_t * op; rpc_ $ ppkt_t * routs; ndr_ $ ulong_int olen; rpc_ $ real_drep_t drep; ndr_ $ boolean free_outs; status_ $ t st; / * other client side local variables * / rpc_ $ ppkt_t ins; rpc_ $ ppkt_t outs; ndr_ $ ushort_int data_offset; ndr_ $ ulong_int bound; rpc_ $ mp_t mp, dbp; ndr_ $ ushort_int count; ndr_ $ boolean free_ins; / * marshalling init * / data_offset = h _->data-offset; bound = O; / * bound calculations * / bound + = 1; / * buffer allocat ion * / if (free_ins = (bound + data_offset> sizeof (rpc_ $ ppkt_t))) ip = rpc_ $ alloc_pkt (bound); else ip = &ins; rpc_ $ init_mp (mp, dbp, ip, data_offset); / * marshalling * / rpc_ $ marshall_char (mp, (* oldPod_)); rpc_ $ advance_mp (mp, 1); / * runtime call * / ilen = mp-dbp; op = &outs; rpc_ $ sar (h_, (long) O, & PODmaster $ if_spec, 1L, ip, ilen. Op. (Long) sizeof (rpc_ $ ppkt_t), & routs. & Olen, (rpc_ $ drep_t *) & drep, & free_outs, &st); if (free__ins) rpc_ $ free_pkt (ip); } globaldef PODmaster $ epv_t PODmaster $ client_epv = {registerShadow_csr.unregisterShadow_csr, requestToken_csr, releaseToken_csr, WantToBeMaster_csr, applyUpdates_csr, sendRefresh_csr, savePOD_csr}; Second interface definition file with IDL compiler
C in the customer switch file generated by compiling
Below is a simplified example of the language. (The following part is a professional
I don't translate because it's gram. ) #Define NIDL_GENERATED #define NIDL_CSWTCH #include "master.h" void registerShadow (h, newPod, m) handle_t h: ObjRef newPod; Mode m; {(* PODmaster $ client_epv.registerShadow) (h, newPod, m);} void unregisterShadow (h, oldPod) handle_t h; ObjRef oldPod; {(* PODmaster $ client_epv.unregisterShadow) (h, oldPod);} The present invention uses DCE terminology to view customer and server missions.
Although described in terms of points, multiple symmetric replicas are asymmetrical.
Apply this in any situation made from a mathematical model
can do. For example, Master Slave or Raw
Producer-Consumer Model Programed With Data Processing Systems
Used to model behavior. Master Sley
Slave requests access by slave
Control system resources. In the producer-consumer relationship,
Producers need essentials, such as messages that consumers demand,
Is the source of. Symmetric decentralized application of these models
When made from one, each peer takes one mission
Can switch from that mission to another.
Therefore, in the producer-consumer model, the peer is the consumer
One version of the interface when working in
Of the interface when the peer is running a producer mission
There is another edition. A specific process from a remote peer
Interface definition file,
Interface file and above remote procedure call
Stock is used. But including a list of processes
Interface is not what the local peer calls
Can include a list of things. Object oriented program
Ramming is becoming more and more common. Object
Using a text-oriented interface is a discussion of the present invention.
It is a logical extension. The present invention has been described above with respect to specific embodiments
Although described, it does not depart from the spirit and scope of the invention.
It's clear to technicians in this area that
It's mild. The above embodiment includes a set of replicas
Use distributed applications, but provided by distributed applications
Standard customer applications that require customized service.
It can also be built into the network. Customer application minutes
Customer and server star linked to scattered replicas
Customers only
Only linked with stubs. These examples are examples and
For the purpose of illustration, the scope of the invention should be claimed.
It is not more restrictive than the fence.

Since the present invention is configured as described above, it is possible to generate a symmetric communication interface for a network using an asymmetric tool.

[Brief description of drawings]

FIG. 1 illustrates an exemplary computer connecting to a network system environment in accordance with the present invention.

2 is a block diagram of the components of the computer shown in FIG.

FIG. 3 shows a code module in two networked workstations in which a symmetric communication interface is created and replicated.

FIG. 4 shows a code module in two networked workstations in which a symmetric communication interface is created and replicated.

[Explanation of symbols]

 10 computer 11 system unit 12 keyboard 13 mouse 14 display 15 pointer 15A, B speaker 16 screen 21 system bus 22 microprocessor 23 ROM 24 RAM 25 memory management chip 26 hard disk drive 27 floppy disk drive 28 keyboard controller 29 mouse controller 30 video -Controller 31 Audio controller 33 Digital signal processor 40 I / O controller 50 Local area network 99 Network 100, 110 system 103 Application 104, 105 Interface definition file 106 Interface definition compiler 107 Server stub 108, 118 Customer stub 109 119 Customer Switch stubs 112 and 113 interface definition editor 114 and 115 RPC runtime module 131 RPC 133 and 137 network message 135 message

Claims (9)

[Claims] 1. A step of providing first and second interface definition files having the same identification number, and compiling the first and second interface definition files to provide first and second interface numbers having the identification numbers. Generating first and second sets of mission interface files, generating the first mission interface file generated from the first interface definition file and generating the second interface definition file And a step of invalidating the interface file of the above second task, and a method of generating a symmetric communication interface using an asymmetric tool including 2. A plurality of systems on a network that includes the interface file of the first mission generated from the second interface and the interface file of the second mission generated from the first interface definition file. Claim 1 including replicating to
The method described in. 3. A step of providing the first interface definition file, and a step of generating the second interface definition file by modifying a character string of a plurality of function names on the first interface definition file. The method of claim 1, comprising: 4. The method of claim 3, wherein the generating step is performed by a generic file definition editor. 5. Invoking a first service call from a first peer posting the first mission by a second peer posting the second mission, and the first service. Converting the call to a message containing an interface file identification number and a serial number of the service of the interface file of the second mission; forwarding the message to the first peer; The method of claim 1, comprising: converting to a service call, wherein the second service call has a service name different than the service name of the first service call. 6. The first and second interface definition files having the same identification number resident in the memory and the first and second interface definition files are compiled, and the first and second interface numbers having the identification numbers are compiled. A memory resident compiler for generating first and second sets of mission interface files; the first mission interface file generated from the first interface definition file; and the second interface definition file A system for generating a symmetric communication interface using an asymmetric tool having a processor and memory connected by a system bus, the means for invalidating the second mission interface file generated from. 7. A plurality of systems on a network that includes the interface file of the first mission generated from the second interface and the interface file of the second mission generated from the first interface definition file. 7. The system of claim 6 including means for replicating to. 8. A memory-resident automatic interface definition file for generating the second interface definition file by adding a character string to each function name on the first interface definition file.
7. The system of claim 6, comprising an editor. 9. Means for invoking a first service call from a first peer posting the first mission by a second peer posting the second mission, and the first service. Means for converting the call into a message containing an interface file identification number and the serial number of the service of the interface file of the second mission; means for forwarding the message to the first peer; 7. The system of claim 6, further comprising: means for converting to a service call, wherein the second service call has a service name different from the service name of the first service call.