CN111666164B

CN111666164B - Method and device for remote method call of transaction-level modeling

Info

Publication number: CN111666164B
Application number: CN202010430025.0A
Authority: CN
Inventors: 姜先刚
Original assignee: New H3C Semiconductor Technology Co Ltd
Current assignee: New H3C Semiconductor Technology Co Ltd
Priority date: 2020-05-20
Filing date: 2020-05-20
Publication date: 2025-09-19
Anticipated expiration: 2040-05-20
Also published as: CN111666164A

Abstract

The invention discloses a method and a device for remote method call of transaction-level modeling, which are used for completing the communication between modules based on TLM irrelevant to business based on Interface class Interface, stub unit Stub and Proxy unit Proxy, and realizing the transfer of call parameters and the return of call results of remote method call based on the communication, thereby realizing remote method call. The framework provided by the invention can realize automatic generation of codes irrelevant to services, lightens the workload of code writing, only needs to automatically regenerate the codes of the three classes after the remote method is modified, does not need to be manually modified, and reduces the possibility of manual modification errors. The invention can concentrate on the realization of specific business functions in the service module by the developer, does not need to care the details of the TLM, and greatly reduces the programming difficulty.

Description

Method and device for remote method call of transaction-level modeling

Technical Field

The invention relates to the technical field of chip simulation verification, in particular to a method and a device for remote method call of transaction-level modeling.

Background

Transaction level modeling (Transaction Level Modeling, TLM) is a set of SystemC-based c++ library code that performs transaction level modeling on a chip, the core idea of which is to use a memory-mapped-based bus to interconnect the various modules on the chip. This is very compatible with current System on Chip (SoC) architecture, which is shown in fig. 1, so that TLM can be used to model SoC at the transaction level well. The TLM model structure corresponding to the SoC is shown in fig. 2, where the Initiator may initiate access to the Target, data being transferred on the memory mapped bus. The Interconnect component forwards the transmitted data for arbitration or routing, etc.

Besides the core characteristics described above, the TLM has the characteristics of high simulation speed, capability of providing a prototype machine for software and the like, so that the software can be developed in parallel before a chip is not developed, and the TLM is widely applied.

The Initiator and the Target in the TLM are connected through sockets, the respective sockets are instantiated before the Initiator initiates access to the Target, then binding is carried out through a binding bind function, and then the Initiator can initiate access to the Target through a function such as b_transport. After receiving the transferred tlm_generation_payload (the generic load class abstracted by the TLM can bear information such as command, address, data, access type, etc.), the Target parses it to complete the read-write operation of the memory.

The TLM is not only applicable to this memory access form modeling, but also to modeling of module interconnections in chips in non-memory access forms. Taking simulation verification modeling of network packet processing as shown in fig. 3 as an example, when the Serdes (Ser stands for Serializer/des stands for Deserializer) receives data to be further processed by a medium access Control (MEDIA ACCESS Control, MAC) device, the Serdes serves as an Initiator, the MAC serves as a Target, the Serdes encapsulates the received data packet in a generic payload tlm_generator_payload class, and then invokes a transport b_transport function to send the data to the MAC for further processing. Conversely, when the MAC has data that needs to be sent by Serdes, the same is true, except that the data is in the opposite direction. It should be apparent that the MAC herein is not a memory device.

In order to be as compatible as possible with the complex interface requirements of the individual IP (where IP refers to the chip internal modules such as Serdes, MAC in the above examples) vendors, tlm_genericjpayload is designed very commonly as its name so that IP modules written by the individual IP vendors can be interconnected. However, this also makes the class of tlm_genec_payload more complex to design, and sets up each member of the tlm_genec_payload before each invocation of the b_transport function for transmission, which increases the difficulty of calling side code writing, which is especially prominent when using modules provided by other IP vendors (since it is necessary to know in detail how to correctly construct the object of the tlm_genec_payload before it can be successfully parsed by the other party). For example, taking network packet transmission as an example, if Serdes receives a packet to be sent to the MAC for further processing, serdes needs to instantiate its own socket first, then bind with the socket of the MAC, set up each member of the tlm_genetic_payload strictly according to the requirement of the MAC, and finally call the b_transport function to send the packet to the MAC for further processing, which will write more codes and increase the possibility of errors.

Disclosure of Invention

In view of the above, the present invention provides a method and apparatus for transaction-level modeling remote method invocation for improving simulation verification efficiency of module interconnection modeling in a chip.

Based on one aspect of the embodiment of the invention, the invention provides a method for remotely calling a transaction-level modeling method, which comprises the following steps:

The client module calls a local method provided by a Stub unit Stub in the service module to provide data for the Stub unit, and the local method of the Stub rewrites a virtual Interface method in a base class Interface;

The local method of the Stub packages remote method names and call parameters into transaction-level modeling universal load class tlm_generic_ payload, and transmits the tlm_generic_ payload to a Proxy unit Proxy in a service module;

The Proxy unit Proxy analyzes the tlm_genetic_payload transmitted from the Stub, and invokes a remote method for actually processing data in the service module according to the analysis result, wherein the remote method also rewrites the virtual Interface method in the base class Interface.

The method further comprises the steps that Proxy packages result information of the remote method in the service module and returns the result information to the Stub, and the local method in the Stub unpacks the result information and returns the calling result to the client module.

Further, the method further comprises:

the preprocessing module identifies the remote method by macro definition identification rmc_api;

the preprocessing module reads each source file, scans code lines with RMC_API, and if the code lines with RMC_API are scanned, extracts method definition information of a remote method identified by the RMC_API according to grammar rules, wherein the definition information comprises a return value type, a method name, each parameter type and a parameter name of the method;

The preprocessing module automatically generates the base class Interface according to the scanning result, and automatically generates the virtual Interface method according to the method definition information of the remote method;

The preprocessing module automatically generates a Stub unit Stub class of a derived class of a base class Interface, and generates the local method in the Stub class according to the method definition information of the remote method;

The preprocessing module automatically generates a derivative class Proxy unit Proxy class of the base class Interface, and generates codes for analyzing the tlm_genetic_payload and calling a remote method in the service module in the Proxy class;

The preprocessing module automatically generates an initialization method rmc _init and an exit method rmc _exit of the service module, and generates codes for instantiating both the Stub class and Proxy class and the binding in rmc _init.

Further, the Stub serves as a starter in transaction level modeling, the Proxy serves as a Target in transaction level modeling, and both parties establish session connection for transmitting returned results of the tlm_genetic_payload and a remote method.

Further, a starter in the Stub and a Target in the Proxy establish session connection through Socket to perform information interaction.

Based on another method of the invention, the invention also provides a device for calling the transaction-level modeling remote method, which comprises a client module and a service module, wherein the service module comprises a stub unit and a proxy unit;

The client module is used for calling a local method provided by the stub unit in the service module and providing data for the stub unit, and the virtual Interface method in the base class Interface is rewritten by the local method of the stub unit;

the stub unit is used for packing the remote method name and the calling parameter into a transaction-level modeling general load class through a local method and transmitting the transaction-level modeling general load class to the proxy unit;

and the proxy unit is used for analyzing the transaction-level modeling general load class transmitted by the stub unit, and calling a remote method for actually processing data in the service module according to the analysis result, wherein the remote method also rewrites the virtual Interface method in the base class Interface.

The proxy unit is further used for packaging the result information of the remote method in the service module and returning the result information to the stub unit, and the stub unit is further used for unpacking the result information through the local method and returning the calling result to the client module.

Further, the apparatus further comprises:

A preprocessing unit for reading each source file, scanning code lines with RMC_API, and if the code lines with RMC_API are scanned, extracting method definition information of a remote method identified by the RMC_API according to grammar rules, wherein the definition information comprises a return value type, a method name, each parameter type and a parameter name of the method;

The preprocessing unit is also used for automatically generating the base class Interface according to the scanning result and automatically generating the virtual Interface method according to the method definition information of the remote method;

The preprocessing unit is also used for automatically generating a Stub class of a derived class of the base class Interface, and generating the local method in the Stub class according to the method definition information of the remote method;

the preprocessing unit is also used for automatically generating a derivative class Proxy unit Proxy class of the base class Interface, and generating codes for analyzing the transaction-level modeling general load class and calling a remote method in the service module in the Proxy class;

The preprocessing unit is further configured to automatically generate an initialization method rmc _init and an exit method rmc _exit of the service module, and generate codes that instantiate both the Stub class and the Proxy class and the binding in rmc _init.

Further, the stub unit is used as a starter in transaction level modeling, the proxy unit is used as a Target in transaction level modeling, and the two parties establish session connection for transmitting the returned results of the transaction level modeling general load class and the remote method.

Further, a Initiator in the stub unit and a Target in the proxy unit establish session connection through Socket to perform information interaction.

The invention completes the communication between the TLM-based modules irrelevant to the service based on Interface class Interface, stub unit Stub and Proxy unit Proxy, and realizes the transfer of the calling parameters and the return of the calling result of remote method call based on the communication, thereby realizing remote method call. The framework provided by the invention can realize automatic generation of codes irrelevant to services, lightens the workload of code writing, only needs to automatically regenerate the codes of the three classes after the remote method is modified, does not need to be manually modified, and reduces the possibility of manual modification errors. The invention can concentrate on the realization of specific business functions in the service module by the developer, does not need to care the details of the TLM, and greatly reduces the programming difficulty.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following description will briefly describe the drawings required to be used in the embodiments of the present invention or the description in the prior art, and it is obvious that the drawings in the following description are only some embodiments described in the present invention, and other drawings may be obtained according to these drawings of the embodiments of the present invention for a person having ordinary skill in the art.

FIG. 1 is a schematic diagram of a SoC system architecture;

fig. 2 is a schematic structural diagram of a TLM model corresponding to the SoC;

FIG. 3 is a schematic diagram of a client module and a service module interconnected by a socket using TLM;

FIG. 4 is a schematic diagram of a TLM-based remote method call for implementing data interaction between a client module and a service module;

FIG. 5 is a flowchart illustrating method steps for transaction level modeling remote method invocation according to one embodiment of the present invention;

FIG. 6 is a schematic diagram of an apparatus for transaction level modeling remote method invocation according to an embodiment of the present invention;

fig. 7 is a schematic diagram illustrating a processing step of a preprocessing module according to an embodiment of the invention.

Detailed Description

The terminology used in the embodiments of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of embodiments of the invention. As used in the examples and claims of the present invention, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term "and/or" as used in this disclosure refers to any or all possible combinations comprising one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in embodiments of the present invention to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information, without departing from the scope of embodiments of the present invention. Depending on the context, furthermore, the word "if" used may be interpreted as "at..once" or "when..once" or "in response to a determination".

In an application scenario of performing chip function verification by adopting a transaction level modeling manner, TLM modules are interconnected through sockets, so as to reduce the code amount of a data transmission Initiator (such as Serdes in fig. 3), the Initiator in Serdes in fig. 3 can be moved to a data receiver (such as MAC in fig. 3) to be implemented, which forms a structure as shown in fig. 4. Because there is no Initiator in Serdes, if a data transfer is to be initiated on the Serdes side, a local call interface for Serdes in FIG. 4 needs to be implemented in the MAC in FIG. 4, such as:

int rx_packet(int length,unsigned char*packet);

Thus, when Serdes needs to pass the data to the MAC for further processing, the previous Initiator construct, socket binding, tlm_genericjpayload construct and b_transport function call are no longer performed, only the local call interface rx_packet provided by the MAC is called. The Initiator construction, socket binding, tlm_genericpa construction and b_transport function call are completed by the local call interface rx_packet, so that the code on the Serdes side is very simplified. The Target in the MAC of fig. 4, after receiving the tlm_generator_payload transmitted from the Initiator, parses it and finally further processes the transmitted data.

While the use of the above-described solution brings about some optimizations, there are also some significant drawbacks. For example, the tlm_genetic_payload parsed code and the data processed code are mixed, and the function of the code is not classified clearly, which is disadvantageous for code modification and maintenance. In addition, while the code amount and complexity of Serdes is reduced, the code of MAC is also increased. If the code of the native call interface rx_packet needs modification, then both the encapsulated and parsed code of the tlm_genericjpayload may involve modification. I.e., both the amount of code written by hand and the amount of code modified may be relatively large.

In order to improve the development efficiency and verification efficiency of a chip simulation verification program comprising an inter-module data communication module, the embodiment of the invention provides a method for calling a transaction-level modeling remote method, which can reduce the coupling between service codes and non-service codes and realize multiplexing and automatic generation of basic communication function codes. Fig. 5 is a schematic flow chart of the method. The method is applied to chip function simulation verification equipment comprising a client module and a service module, wherein the service module comprises a stub unit stub and a Proxy unit Proxy, and the method comprises the following steps:

step 501, a client module calls a local method provided by a Stub unit Stub in a service module to provide data for the Stub unit, and the local method of the Stub rewrites a virtual Interface method in a base class Interface;

Step 502, the local method of the Stub packages the remote method name and the call parameter into a transaction-level modeling universal load class tlm_generation_payload, and transmits the tlm_generation_payload to a Proxy unit;

Step 503, the Proxy unit Proxy analyzes the tlm_genetic_payload transmitted from the Stub, and invokes a remote method for actually processing data in the service module according to the analysis result, where the remote method also rewrites the virtual Interface method in the base Interface.

In the embodiment of the invention, the Stub unit Stub and the service module are both connected with a socket class, a data processing virtual interface method is declared in the interface class, and the Stub unit and the service module realize respective data processing methods based on the interface data processing virtual interface method. The data processing method provided in the Stub is functionally different from the data processing method provided by the service module, the data processing method provided by the service module is used for performing actual business processing on the received data, the data processing method implemented in the Stub is used for providing a locally called method for the client module, the client module provides the data to be transmitted to the Stub through the locally called data processing method provided by the Stub, the Stub packages the name of a remote method and parameters input by calling the remote method into a transaction-level modeling universal load tlm_gene_payload in the own data processing method (namely, a local method), and transmits the tlm_gene_payload to the Proxy.

Because the data processing methods of the Stub and the service module are inherited from the interface class, the Stub and the service module have the same data processing method names, parameters and return types, and therefore after the Proxy analyzes the remote method names and the call parameters in the tlm_generico_payload, the service module can be directly called according to the remote method (namely the actual data processing method) in which the remote method names call the service module, and the data processing method of the service module performs actual business processing on the data.

The invention abstracts three classes of Interface, stub unit Stub and Proxy unit Proxy which are irrelevant to specific service on the basis of remote method call based on communication among TLM modules, and the three classes realize the specific implementation details of TLM communication, remote method call parameter packaging, parameter unpacking, parameter analysis and unpacking of returned result information. Because it is independent of specific services and is implemented mainly around TLM communication and remote methods, regularity is strong and automatic generation is convenient.

Fig. 6 is a schematic structural diagram of an apparatus 600 for transaction-level modeling remote method invocation according to an embodiment of the present invention, where the apparatus 600 includes a client module 610 and a service module 620, and the service module 620 includes a stub unit 621 and a proxy unit 622.

The client module 610 is configured to invoke a local method provided by the stub unit 621 in the service module 620, and provide data to the stub unit 621, where the local method of the stub unit 621 rewrites a virtual Interface method in the base class Interface. The stub 621 packages the remote method name and call parameters into a transaction-level modeling generic load class by the local method, and transfers the transaction-level modeling generic load class to the proxy unit 622. The proxy unit 622 parses the transaction-level modeling generic load class transmitted from the stub unit 621, and invokes a remote method for actually processing data in the service module 620 according to the parsed result, which also rewrites the virtual Interface method in the base class Interface.

Hereinafter, description will be made taking a client module as Serdes and a service module as MAC as an example. In this embodiment, the Stub unit Stub in the service module MAC provides a local method rx_packet, and the service module MAC also provides a packet processing method rx_packet for final processing of the data packet, where the two methods are not only named as such, but also have consistent parameters and return value types, so that a single Interface class can be abstracted, such as an Interface class in fig. 6, in which a pure virtual Interface method rx_packet is declared, and both Stub and MAC inherit the Interface class, and implement the rx_packet methods therein. Although the rx_packet method is realized, the completed functions are different, the rx_packet method in the Stub is called by the client module Serdes, and the main function of the method is to be called remotely, and the method name and calling parameters and other information are packaged together and transmitted to the Proxy through the Socket. Conversely, after the remote call is completed, proxy packages the call result information and returns the call result information to the Stub, and the rx_packet in the Stub needs to unpack the result information and finally returns the call result to the Serdes. And the rx_packet method implemented in the MAC performs actual processing on the received data packet.

The abstract Proxy unit Proxy is specially responsible for analyzing the tlm_genetic_payload transmitted by the Stub, and calling an rx_packet remote method for realizing the MAC for actually processing the data packet according to the analysis result. On the other hand, proxy packages the called result and returns the result to the Stub. If there is more than one remote method within the MAC, proxy may also provide for registering these remote methods so that different remote methods may be invoked based on different parsing results.

With the above unified code format, another preprocessing module can then be written to automatically generate the relevant code. The preprocessing module can be implemented by a plurality of programming languages such as a script language, a C/C++ language or a Java language, and the specific implementation methods of the languages are different, so that the preprocessing module mainly describes the code which needs to be automatically generated and the step of generating the code, as shown in fig. 7.

For ease of description, the various steps and example code in FIG. 7 are described in detail below using Serdes and MAC as examples.

Step 1. The writer of the mac module will first determine an interface method that can be invoked remotely, such as the packet processing method rx_packet method mentioned earlier. In order for the preprocessing module that automatically generates code to recognize the Interface method to generate the Interface, stub and Proxy code required around the method, it is necessary to add an identification to the method, but the added identification cannot break its grammar rules, and can be implemented in the following form (here shown in the C/c++ language, since TLM itself is developed in the c++ language).

#define RMC_API

RMC_API int rx_packet(int length,unsigned char*packet);

The macro of rmc_api is used as the identifier, and any macro conforming to the syntax specification may be actually programmed. The macro of rmc_api is defined as empty, added in front of the function declaration, and after being developed by the preprocessor of the compiler, it is equivalent to no macro, i.e. no breaking grammar rules, and the compilation will not be error due to the introduction of the macro.

The definition of this macro is automatically generated, and in the rmc.h file, the example code is as follows:

#ifndef_RMC_H_

#define_RMC_H_

#define RMC_API

#endif

Step 2. The MAC implementer manually writes the code of the MAC class and adds the rmc_api macro before the declaration of the remote method. In order to better explain the meaning of the automatically generated code, an example of the code of the MAC class will be given and described in the following step 2a, which is not separately labeled in fig. 7.

And 3, reading each source file by the preprocessing module, and scanning code lines with RMC_API. If a code line with rmc_api is scanned, then the recipe definition information is extracted according to the grammar rules to get the return value type, recipe name, each parameter type of recipe, and parameter name.

And 4a, the preprocessing module newly builds an Interface file defining an Interface class, such as mac_if.h, and writes the codes similar to the following into the file according to the method definition information of the packet processing method extracted in the step 3.

The above code mainly defines a mac_if interface abstract class, wherein the packet processing method rx_packet is a pure virtual method (or called pure virtual interface method), and a derivative class requiring the inheritance of the class is required to implement the virtual interface method. Such as the two classes Stub and MAC mentioned later.

4B, the preprocessing module newly builds a file defining the Stub class, such as mac_stub.h, and writes the codes similar to the following into the file according to the function information extracted in the step 3.

The mac stub acts as an Initiator and requires a simple Initiator socket to communicate with the socket on the Target side. In addition, the mac_stub class needs to inherit the mac_if class and implement the rx_packet method, which is called by Serdes, but the method in Stub does not perform specific processing on the received packet, but forwards it to Proxy through Socket of TLM, and then forwards it to MAC by Proxy to perform specific processing. To accomplish this, i.e., to accomplish remote invocation of the rx_packet method in the MAC, the invoked parameters need to be packed into an object, such as xxx in the code above. The object contains information such as the name of a remote calling method, the value of a called parameter and the like, and can be realized through the category of binary_ oarchive in an archive in C++. After the calling information is packed into the xxx object, the data pointer of the current transmission is set through the following codes:

trans->set_data_ptr(reinterpret_cast<unsigned char*>(&xxx));

the b_transport method of socket is then invoked to pass it to Proxy.

socket->b_transport(*trans,delay);

The Proxy parses the received packaged call parameters and then invokes the corresponding remote method. After the remote call returns, proxy packages the return information, etc., into an object (e.g., yyy in the example code) and sets it in the trans object. The Stub obtains the packed return information from the trans, and then unpacks the return information to obtain a return value and returns the return value. Unpacking the return message may be accomplished using the archive:: binary_ iarchive in the boost library.

4C, the preprocessing module newly builds a file defining the Proxy class, such as mac_proxy.h, and writes the codes similar to the following into the file according to the method definition information of the packet processing method obtained in the step 3.

The mac_proxy class is used as a Target, a simple_target_socket socket is required to communicate with a socket on the Initiator side, and a b_transport method is implemented to receive a packet transmitted from the Initiator. In the b_transport method, call information (such as func_name, length and packet in example codes) packaged in the trans is analyzed to obtain a method name, parameters and the like to be called remotely, and then a corresponding remote method is called. After the remote call is completed, the return value is saved in the yyy object (yyy is to be accessed through the trans, and the Stub side can acquire the return value from the trans). The mac_proxy class also provides a set_mac method, which mainly can acquire the MAC object and call the rx_packet method provided by it.

The implementer of the mac in step 2a needs to write a code like that which is not automatically generated.

The mac class needs to inherit the interface class mac_if and realize the rx_packet method, and the rx_packet method in the mac class is called after being analyzed in Proxy and needs to perform specific processing on the received data packet. As previously described, when declaring the method, a macro such as an RMC_API needs to be added so that the designed preprocessing module can recognize the method and automatically generate the corresponding code. Two pointers s and p are used for storing the Stub and Proxy objects respectively in the MAC class, and if the MAC writer needs to know the presence of the Stub and Proxy as much as possible, a general base class can be written, the two pointers are defined in the base class, the Stub and the Proxy objects are stored, and the MAC class inherits the base class. Two methods, the service module class initialization method rmc _init and the exit method rmc _exit, are required to be declared in the mac class, which are generated by the preprocessing module, and the implementer of the mac class does not need to implement the corresponding code. These two methods are mainly used to instantiate the Stub and Proxy and complete the binding of both, as will be explained in more detail below. Both methods must be called separately in the constructor and destructor of the mac class. The mac class also defines a get_if method for providing the Serdes with a Stub-side Interface, the code being described later.

Step 4d. The preprocessing module creates a file defining rmc _init, rmc_exit, and get_if function implementations of the mac class, such as mac_impl.

Wherein rmc _init instantiates a Stub and a Proxy object respectively, and calls a set_mac method of Proxy to transfer a mac object pointer to Proxy, so that Proxy can call an rx_packet method in a mac class through the object after parsing a call parameter. The bind method of the socket is to bind the socket of the Initiator and the Target together, so that the two sockets can communicate, and finally, pointers of two objects of the Stub and the Proxy are saved, which is convenient for releasing the memory space occupied by the two objects in the rmc _exit function. The get_if method transforms the mac_stub up to mac_if, thus returning the mac_if object on the Stub side to the Serdes, so that the Serdes calls to the rx_packet interface method on the Stub side through the object pointer.

The foregoing is merely exemplary of the present invention and is not intended to limit the present invention. Various modifications and variations of the present invention will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. which come within the spirit and principles of the invention are to be included in the scope of the claims of the present invention.

Claims

1. A method of transaction-level modeling remote method invocation, the method comprising:

The local method of the Stub packages remote method names and call parameters into transaction-level modeling universal load types tlm_generic_ payload, and transmits the tlm_generic_ payload to a Proxy unit Proxy in a service module, wherein the service module comprises a Stub unit Stub and the Proxy unit Proxy;

2. The method according to claim 1, wherein the method further comprises:

The Proxy packages the result information of the remote method in the service module and returns the result information to the Stub;

and unpacking the result information by the local method in the Stub, and returning the calling result to the client module.

3. The method according to claim 2, wherein the method further comprises:

4. The method of claim 3, wherein the step of,

And the Stub is used as a starter in transaction level modeling, the Proxy is used as a Target in transaction level modeling, and session connection is established between the two parties for transmitting returned results of the tlm_genetic_payload and the remote method.

5. The method of claim 4, wherein the step of determining the position of the first electrode is performed,

And establishing session connection by the Initiator in the Stub and the Target in the Proxy through Socket to perform information interaction.

6. The device for remote method call of transaction-level modeling is characterized by comprising a client module and a service module, wherein the service module comprises a stub unit and a proxy unit;

7. The apparatus of claim 6, wherein the device comprises a plurality of sensors,

The proxy unit is also used for packaging the result information of the remote method in the service module and returning the result information to the stub unit;

the stub unit is also used for unpacking the result information through a local method and returning the calling result to the client module.

8. The apparatus of claim 7, wherein the apparatus further comprises:

9. The apparatus of claim 8, wherein the device comprises a plurality of sensors,

The stub unit is used as a starter in transaction level modeling, the proxy unit is used as a Target in transaction level modeling, and the two parties establish session connection for transmitting the returned results of the transaction level modeling general load class and the remote method.

10. The apparatus of claim 9, wherein the device comprises a plurality of sensors,

And the Initiator in the stub unit and the Target in the proxy unit establish session connection through Socket to perform information interaction.