Detailed Description
The present invention will be described in further detail with reference to the accompanying drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting of the invention. It should be further noted that, for the convenience of description, only some of the structures related to the present invention are shown in the drawings, not all of the structures.
Currently, the virtual machine applied in the block chain and used for executing the intelligent contract may include: EVM of Ether Fang 1.0, can carry out EVM byte code; DJVM by Corda, which may execute Java's class bytecode; the Nervos is based on a virtual machine of RISC-V, and can execute an ELF executable file with an internal instruction set of RISC-V; docker, used by Fabric, for executing chaincode; EWasm virtual machine of EtherFan 2.0 and virtual machine based on WebAssembly such as EOS can execute wasm byte code. The WebAssembly is an emerging binary instruction format used for the stack-based virtual machine, is applied to a browser as a compiling target of system programming languages such as C, Rust and the like, has the advantages of high efficiency, safety, instruction set standardization, rapid tool chain development, high portability and the like, is widely applied to a block chain, and runs in the WebAssembly virtual machine as the compiling target of an intelligent contract.
The deployment process of the intelligent contract based on the WebAssembly virtual machine comprises the following steps:
contract development: users write intelligent contracts using some intelligent contract programming language and a corresponding Integrated Development Environment (IDE).
And (3) contract compiling: and compiling and linking the intelligent contract codes into byte codes corresponding to the underlying virtual machine by using the corresponding tool chain.
Contract deployment: the developer constructs a transaction with intelligent contract bytecode and sends the transaction to the chain, checks the validity of the bytecode and stores the transaction persistently.
Contract execution: the subsequent user packages the contract invoking request on a transaction center and sends the contract invoking request to a chain to trigger the execution of the contract.
When the 4 th contract is executed, the WebAssembly virtual machine is started to load the intelligent contract bytecode for execution, in order to ensure security and certainty, if external data (for example, contract metadata) is acquired in the contract execution process, the virtual machine needs to be implemented through an environment interface, all the external data and the intelligent contract bytecode are stored separately (the external data is not stored in the bytecode), the storage mode of the external data depends on the implementation of a block chain, even if some read-only contract metadata may be acquired through more complex search, and therefore the search efficiency is low.
In view of this, in the data search method provided in the embodiments of the present invention, when a contract is deployed, the blob link nodes store the contract metadata (read-only data) in the contectinfo section (a Custom section) of the WebAssembly bytecode according to a specified target format, and when the expanded virtual machine loads and executes, the virtual machine can parse and store information in the contectinfo section in the memory. By doing so, on one hand, a user can quickly access the related data loaded into the memory by the virtual machine through the environment interface during contract execution, so that the access efficiency is improved; on the other hand, when the contract is deployed, the contract metadata is injected into byte codes, so that the storage structure is more compact.
In an embodiment, fig. 1 is a flowchart of a data searching method according to an embodiment of the present invention, which is applicable to a case of quickly searching contract metadata. This embodiment may be performed by a data lookup device. The data search device may be a virtual machine. As shown in fig. 1, the present embodiment may include the following steps:
and S110, receiving a target extension section which carries contract metadata and is sent by the block chain node.
The block link nodes may be referred to as full nodes, common nodes, etc. It will be appreciated that where the blockchain nexus is a full node, the blockchain nexus can download each block and each blockchain transaction and check against the consensus rules for the blockchain. In actual operation, one blockchain node can perform data interaction with other blockchain nodes. Of course, the block link point may be implemented in a server or a computer, and this is not limited thereto. Each blockchain node may correspond to one or more physical hardware devices or virtual devices, and the physical hardware devices or virtual devices may be coupled with the blockchain nodes through a communication protocol. Illustratively, the virtual appliance may be a virtual machine.
Where contract metadata refers to contract-related information that may be validated at the time of contract deployment. Illustratively, the contract metadata may include: a Hash value (Hash value) of the contract, a transaction to deploy the contract, a block number, a deployer and signature, etc. It is understood that contract metadata is read-only data, i.e., data information that cannot be altered during contract deployment.
In an embodiment, the target extension section refers to a memory section obtained by extension based on a target bytecode. In one embodiment, the target bytecode includes: WebAssembly bytecode; the target extension section is a Custom section. It can be understood that, according to the standard structural specification of Custom section, Custom extension is performed on the basis of the target bytecode to obtain a corresponding target extension section. Illustratively, in the case that the virtual machine is a WebAssembly, the corresponding target bytecode thereof is a WebAssembly bytecode. It can be understood that the contract metadata is stored in the target extension node of the target byte code through the block link node, so as to achieve the effect of existing the contract metadata in the target byte code, thereby enabling the storage structure to be more compact.
And S120, storing the contract metadata in the target extension section into a corresponding contract metadata area.
Wherein, the contract metadata area refers to an independent memory for storing the contract metadata separately. In an embodiment, in the process of instantiating the received intelligent contract, the virtual machine instantiates the corresponding memory according to the memory section defined in the target bytecode, and represents the corresponding memory in the process of executing the contract. It can be understood that the virtual machine is instantiated into a corresponding contract metadata region according to a customized target extension section in the target bytecode, that is, an additional region is added in the running process of the virtual machine and is marked as a contract metadata region, and when a contract is instantiated, the contract metadata in the target extension section is stored into the contract metadata region.
S130, searching and reading contract metadata in the contract metadata area through a pre-configured target environment interface.
Wherein the target environment interface is an interface to read contract metadata directly from a contract metadata region of the virtual machine. It should be noted that, during the process of executing the contract by the virtual machine, the environment interface may be linked to the virtual machine instance, that is, the environment interface is an interface that interacts with the blockchain when the contract is executed in the virtual machine (for example, operations such as modifying the state and acquiring data may all be implemented by the environment interface). In an embodiment, a target environment interface is configured to read contract metadata in a target extension directly from a virtual machine while a regular environment interface is configured.
It can be understood that, in the process of contract deployment, the block link nodes store the contract metadata into the target extension section of the target bytecode, and when the virtual machine after the target bytecode is extended is loaded and executed, the virtual machine can analyze and store the contract metadata in the target extension section into the corresponding contract metadata region.
According to the technical scheme of the embodiment of the invention, the contract metadata are stored to the target expansion node through the block link node, and the contract metadata in the target expansion node are stored to the corresponding contract metadata area; when a contract execution instruction is received, the contract metadata in the contract metadata area is directly searched and read through a special target environment interface of the contract metadata area, the effect of quickly accessing the contract metadata through the target environment interface is achieved, and the accessing and searching efficiency is improved.
In an embodiment, fig. 2 is a flowchart of another data searching method according to an embodiment of the present invention. This embodiment is further described with reference to the above embodiments. As shown in fig. 2, the data searching method in this embodiment includes the following steps:
s210, receiving a target extension section which carries contract metadata and is sent by the block chain node.
The configuration process of the target expansion section comprises the following steps: and coding the contract metadata according to a target format through the block chain link points to obtain the corresponding target expansion link. Wherein the target format refers to the structural specification required by the target extension. In an embodiment, when the target bytecode is a WebAssembly bytecode, the target extension section is a Custom section, that is, the contract metadata is encoded according to the specification of the Custom section to obtain a corresponding target extension section.
In an embodiment, encoding the contract metadata according to a target format by the block link point to obtain a corresponding target extension link includes: splitting the contract metadata through the block link points to obtain a contract metadata subset; and coding the contract metadata subsets according to a target format to obtain corresponding target expansion sections. In an embodiment, the process of splitting the contract metadata may be understood as a process of classifying the contract metadata according to data types, that is, taking data of each data type in the contract metadata as a contract metadata subset, and storing each contract metadata subset into a preconfigured blank extension section according to a target format to obtain a corresponding target extension section.
Illustratively, the structure of the target extension segment may include the following: code id of the section, size of the bearing content, byte length of the name, the name and the bearing content; the structure of the bearer content may include the following: the number of entries and entries; the types of the entries are info types, and the info structure comprises the following contents: the byte length of the key, the byte length of the name, and the name. In embodiments, the type of each content is different, illustratively the code id of a section may be varuint 7; the size of the bearer content may be varuint32, etc., and this is not limited to one, and the configuration may be adjusted according to the actual situation.
In an embodiment, the target expansion node is inserted to a preset position of the target bytecode through the block link node. Wherein the predetermined position may be the last of the target bytecode. In the embodiment, the target extension section is inserted into the last of the target bytecode, so that the effect of merging and storing the contract metadata and the target bytecode is realized, and the integrity of data contained in the target bytecode without the target extension section is ensured.
S220, configuring a corresponding target environment interface for the target expansion section.
And establishing one-to-one access relationship between the target environment interface and the contract metadata area. In the embodiment, in the process of executing the intelligent contract by the virtual machine, the virtual machine configures a special target environment interface for the target extension section besides the conventional environment interface, so as to quickly access the contract metadata in the target extension section directly through the target environment interface.
And S230, instantiating a corresponding contract metadata area according to the target expansion section.
In the embodiment, in the process of executing the intelligent contract by the virtual machine, the virtual machine instantiates the corresponding memory according to the self-defined function, table, global variable and memory section in the target bytecode, and the memory is represented when the contract is executed. It will be appreciated that the target extension in the target bytecode is instantiated into a corresponding contract metadata region.
And S240, storing the contract metadata into the contract metadata area.
In an embodiment, when the virtual machine instantiates the intelligent contract, the contract metadata in the target extension section is stored to the contract metadata area.
And S250, accessing the associated contract metadata area through a preset target environment interface.
And S260, searching and reading contract metadata in the contract metadata area.
In an embodiment, during the process of executing the intelligent contract by the virtual machine, the corresponding contract metadata region can be directly accessed through the target environment interface, and the corresponding contract metadata is searched and read in the contract metadata region.
According to the technical scheme of the embodiment of the invention, the corresponding target expansion section is obtained by expanding on the basis of the target byte code, and the contract metadata is stored in the target expansion section, so that the storage structure is more compact; in addition, the virtual machine can directly access the contract metadata in the contract metadata region through the target environment interface, so that the data access and search efficiency is improved.
In an embodiment, fig. 3 is a flowchart of another data searching method provided by an embodiment of the present invention. This embodiment may be performed by block link points. As shown in fig. 3, the data searching method applied to the blockchain node includes the following steps:
s310, encoding the contract metadata according to the target format to obtain the corresponding target extension section.
And S320, sending the target expansion section to the virtual machine so that the virtual machine searches and reads contract metadata in the target expansion section.
The target expansion section is a memory section obtained by expanding on the basis of the target byte codes. In the embodiment, in the contract deployment process, the block chain nodes encode the contract metadata according to a target format to obtain corresponding target expansion nodes, and when the block chain nodes receive a contract execution command, the block chain nodes take out target byte codes to be executed, create a virtual machine instance, load the target byte codes, and send the target expansion nodes carrying the contract metadata to the virtual machine, so that the virtual machine can quickly access the contract metadata according to a pre-configured target environment interface, and the access and search efficiency of the virtual machine on the contract metadata is improved.
In an embodiment, the data lookup method applied to the blockchain node further includes: and after the contract metadata is coded according to the target format to obtain a corresponding target expansion section, inserting the target expansion section into a preset position of a target byte code. The preset position may be the end of the target bytecode. In the embodiment, after the block link point encodes the contract metadata to obtain the corresponding target extension node, the target extension node is inserted to the end of the target bytecode, so that the storage structure of the target bytecode is more compact on one hand, and on the other hand, the integrity of data contained in the target bytecode before the target extension node is not added is ensured.
It should be noted that, the explanation of the parameters such as the target format, the contract metadata, the target extension node, the target bytecode, and the like in the data lookup method applied to the blockchain node is described above in the data lookup method applied to the virtual machine, and is not described in detail here.
In an embodiment, the procedure of contract deployment is described by taking an example that the target bytecode is a WebAssembly bytecode and the target extension section is a contectinfo section. FIG. 4 is a flow diagram of a contract deployment provided by an embodiment of the invention. As shown in fig. 4, the contract deployment process in this embodiment includes the following steps:
and S410, developing a contract.
In an embodiment, a contract developer develops contract code using a high-level language (a language such as C, Rust that can be compiled into a wasm target). Among them, wasm may also be called WebAssembly.
And S420, compiling the contract.
In an embodiment, a contract developer compiles contract code into wasm bytecode via an IDE or directly using a corresponding compiler (e.g., Emscript, ruttc, etc.).
And S430, constructing the transaction.
In an embodiment, the contract developer packages the wasm bytecode and necessary information into a transaction through the client.
And S440, sending contract deployment transaction.
In an embodiment, a contract developer sends a constructed contract deployment transaction to a blockchain node through a client.
S450, verifying the transaction.
In an embodiment, a block link point receives a contract deployment transaction and verifies the contract deployment transaction. Wherein the verification of the contracting deployment transaction comprises a verification of the validity of the bytecode.
And S460, modifying the WebAssembly byte code.
In an embodiment, a chunk link will encode contract metadata for a deployment contract into a ContractInfo segment in a target format and insert it into the last location of the wasm bytecode. Wherein, the contract metadata is logically in a form of Key-Value pairs.
In an embodiment, table 1 is a schematic table of a contectinfo section structure provided in an embodiment of the present invention, and as shown in table 1, a binary representation of the contectinfo section is as follows (where varutin N represents LEB128 unsigned integer coding, N represents a bit number, and a representation range of values is [0,2^ N-1 ]):
TABLE 1 schematic of ContractInfo section Structure
Table 2 is a schematic table of a payload structure provided in the embodiment of the present invention, and as shown in table 2, domain names, types, and descriptions included in the payload structure are as follows:
TABLE 2 schematic diagram of payload structure
Table 3 is a schematic table of an info structure provided in the embodiment of the present invention, and as shown in table 3, domain names, types, and descriptions included in the info structure are as follows:
TABLE 3 schematic diagram of info structure
S470, packing the blocks, and identifying the uplink.
In an embodiment, after the block link point completes the verification of the contract deployment transaction, and the contract deployment transaction passes the verification, the executed transaction of the intelligent contract therein is packaged into a block, and after the consensus with other block link nodes is completed, the block is stored persistently.
In an embodiment, the process of executing the contract by the chunk link node is described by taking the target bytecode as the WebAssembly bytecode and the target extension node as the contectinfo node as an example. Fig. 5 is a flowchart of a block link point execution contract according to an embodiment of the present invention. As shown in fig. 5, the process of executing contracts by the block link points in the present embodiment includes the following steps:
and S510, constructing a transaction.
In an embodiment, a contract user constructs a transaction through a client using invoked contract parameters and a contract address.
And S520, sending a contract to call the transaction.
In an embodiment, a contract user sends a constructed contract invocation transaction to a blockchain node through a client.
S530, checking contract and calling transaction.
In an embodiment, a block link point receives a contract invocation transaction and verifies the contract invocation transaction.
And S540, executing the contract.
In an embodiment, a block chain link point acquires a contract byte code to be executed, loads the contract byte code through a virtual machine, transmits parameters and executes a specified function.
S550, a packing block, common identification of the uplink.
In an embodiment, after the block link point completes the verification of the contract deployment transaction, and the contract deployment transaction passes the verification, the executed transaction of the intelligent contract therein is packaged into a block, and after the consensus with other block link nodes is completed, the block is stored persistently.
In an embodiment, the process of executing the contract by the virtual machine is described by taking the target bytecode as the WebAssembly bytecode and the target extension section as the contectinfo section as an example. Fig. 6 is a flowchart of a virtual machine execution contract according to an embodiment of the present invention. As shown in fig. 6, the process of executing the contract by the virtual machine in the present embodiment includes the following steps:
s610, loading contract byte codes.
In an embodiment, the blockchain node fetches the WebAssembly bytecode to be executed from the persistent storage, creates a virtual machine instance, and loads the bytecode.
S620, dynamically linking the environment interface.
In an embodiment, the virtual machine links an environment interface to the virtual machine instance, where the environment interface is an interface with which the virtual machine interacts with the chain when executing the contract (e.g., operations such as modifying the state, obtaining the account balance, etc. are all performed through the environment interface). In addition to the regular environment interface, a new environment interface is configured as a target environment interface and used for directly reading the contract metadata of the ContractInfo section from the virtual machine.
S630, instantiating the contract.
In an embodiment, the virtual machine is instantiated as a corresponding memory representation (runtime representation) according to functions, tables, global variables, memory sections defined in the WebAssembly bytecode. In an embodiment, an additional region "contract metadata region" is newly added in the virtual machine runtime, and when the region is instantiated, the contract metadata in the bytecode contectinfo section is stored in the region, and the value of the contract metadata can be read through a specified target environment interface when the contract is executed.
Fig. 7 is a block diagram of a memory structure when a virtual machine operates according to an embodiment of the present invention. As shown in fig. 7, when the virtual machine runs, the virtual machine instantiates the function, the table, the global variable, and the memory section defined in the wasm bytecode into the corresponding memory. Illustratively, the function is instantiated as a corresponding function instance, the table is instantiated as a corresponding table instance, the memory is instantiated as a corresponding memory instance, the global variable is instantiated as a corresponding global variable instance, and the target extension node is instantiated as a corresponding contract metadata region. The stack is instantiated into a region where the corresponding stack is located, and the local variable is instantiated into a corresponding local variable table.
And S640, executing the contract.
In an embodiment, the block link node transfers the contract parameters to the virtual machine and calls the corresponding execution function to execute, the virtual machine based on the interpreted execution generates a logical structure such as an operand stack, a function stack, a local variable table and the like to assist the program execution in the execution process, and the value in the contract metadata area can be effectively read through a specified environment interface in the execution process of the contract.
According to the embodiment of the invention, on the basis of using WebAssembly byte codes as an intelligent contract format, Custom sections in the standard are used for expansion, ContractInfo sections are newly added for storing contract metadata, a corresponding contract metadata area is added when a virtual machine runs, and the data in the contract can be accessed very efficiently in the execution process by providing a corresponding target environment interface. Meanwhile, the contract related information is stored in the byte codes, so that the storage structure is more compact.
In one embodiment, fig. 8 is a block diagram of a data search apparatus according to an embodiment of the present invention, which is suitable for use in a case where contract metadata is quickly searched, and the apparatus may be implemented by hardware/software. The embodiment is applied to the virtual machine. As shown in fig. 8, the apparatus includes: a receiving module 810, a storing module 820, and a searching module 830.
The receiving module 810 is configured to receive a target extension node which carries contract metadata and is sent by a blockchain node;
a storage module 820, configured to store the contract metadata in the target extension section into a corresponding contract metadata region;
and the searching module 830 is configured to search and read the contract metadata in the contract metadata region through a preconfigured target environment interface.
According to the technical scheme of the embodiment, the contract metadata are stored to the target expansion node through the block link node, and the contract metadata in the target expansion node are stored to the corresponding contract metadata area; when a contract execution instruction is received, the contract metadata in the contract metadata area is directly searched and read through a special target environment interface of the contract metadata area, the effect of quickly accessing the contract metadata through the target environment interface is achieved, and the accessing and searching efficiency is improved.
On the basis of the above embodiment, the data search apparatus applied to the virtual machine further includes:
and the configuration module is used for configuring a corresponding target environment interface for the target extension section before the contract metadata in the target extension section is stored in the corresponding contract metadata area.
On the basis of the above embodiment, the configuration process of the target extension node includes:
and coding the contract metadata according to a target format through the block chain link points to obtain the corresponding target expansion link.
On the basis of the above embodiment, the encoding the contract metadata according to the target format by the block link point to obtain the corresponding target extension link includes:
splitting the contract metadata through the block link points to obtain a contract metadata subset;
and coding the contract metadata subsets according to a target format to obtain corresponding target expansion sections.
On the basis of the above embodiment, the target expansion node is inserted to the preset position of the target bytecode through the block link node.
On the basis of the above embodiment, the storage module includes:
the instantiation unit is used for instantiating the target extension section into a corresponding contract metadata area;
a storage unit configured to store the contract metadata to the contract metadata area.
On the basis of the above embodiment, a one-to-one access relationship is established between the target environment interface and the contract metadata region.
On the basis of the above embodiment, the search module includes:
the access unit is used for accessing the associated contract metadata area through a preset target environment interface;
and the searching unit is used for searching and reading the contract metadata in the contract metadata area.
On the basis of the above embodiment, the target bytecode includes: WebAssembly bytecode; the target expansion section is a Custom section.
The data searching device can execute the data searching method applied to the virtual machine provided by any embodiment of the invention, and has the corresponding functional module and the beneficial effect of executing the data searching method.
In one embodiment, fig. 9 is a block diagram of another data search apparatus according to an embodiment of the present invention, which is suitable for use in a case where contract metadata is quickly searched, and the apparatus may be implemented by hardware/software. The embodiment is applied to the block chain node. As shown in fig. 9, the apparatus includes: an encoding module 910 and a transmitting module 920.
The encoding module 910 is configured to encode the contract metadata according to a target format to obtain a corresponding target extension section;
a sending module 920, configured to send the target extension section to a virtual machine, so that the virtual machine searches for and reads the contract metadata in the target extension section.
On the basis of the above embodiment, the data search apparatus applied to the block chain node further includes:
and the inserting module is used for inserting the target expansion section into the preset position of the target byte code after the contract metadata is coded according to the target format to obtain the corresponding target expansion section.
The data searching device can execute the data searching method applied to the block chain node provided by any embodiment of the invention, and has corresponding functional modules and beneficial effects of executing the data searching method.
Fig. 10 is a schematic diagram of a hardware structure of a data searching device according to an embodiment of the present invention. The device in the embodiment of the present invention is described by taking a virtual machine as an example. As shown in fig. 10, the data search device provided in the embodiment of the present invention includes: a processor 1010, a memory 1020, an input device 1030, and an output device 1040. The number of the processors 1010 in the cloud server may be one or more, one processor 1010 is taken as an example in fig. 10, the processor 1010, the memory 1020, the input device 1030, and the output device 1040 in the cloud server may be connected by a bus or in other manners, and the processor 1010, the memory 1020, the input device 1030, and the output device 1040 in the cloud server are taken as an example in fig. 10.
The memory 1020 of the data search apparatus, which is a computer-readable storage medium, may be used to store one or more programs, which may be software programs, computer-executable programs, and modules, such as program instructions/modules corresponding to the data search method (e.g., modules in the data search apparatus shown in fig. 8, including the receiving module 810, the storage module 820, and the search module 830) according to embodiments of the present invention. The processor 1010 executes various functional applications and data processing of the cloud server by running software programs, instructions and modules stored in the memory 1020, that is, the data searching method in the foregoing method embodiment is implemented.
The memory 1020 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store data created according to use of the device, and the like. Further, the memory 1020 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some examples, the memory 1020 may further include memory located remotely from the processor 1010, which may be connected to devices over a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
The input unit 1030 may be used to receive numeric or character information input by a user to generate key signal inputs related to user settings and function control of the terminal device. Output device 1040 may include a display device such as a display screen.
And, when the one or more programs included in the above data lookup apparatus are executed by the one or more processors 1010, the programs perform the following operations: receiving a target extension node which carries contract metadata and is sent by a block chain node; storing the contract metadata in the target extension section into a corresponding contract metadata area; and searching and reading the contract metadata in the contract metadata area through a pre-configured target environment interface.
When the data lookup apparatus is a blockchain node, when one or more programs included in the data lookup apparatus are executed by the one or more processors 1010, the programs perform the following operations: encoding contract metadata according to a target format to obtain a corresponding target expansion section; and sending the target expansion section to a virtual machine so that the virtual machine searches and reads contract metadata in the target expansion section.
An embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements a data lookup method applied to a virtual machine, where the method includes: receiving a target extension node which carries contract metadata and is sent by a block chain node; storing the contract metadata in the target extension section into a corresponding contract metadata area; and searching and reading the contract metadata in the contract metadata area through a pre-configured target environment interface.
An embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements a data lookup method applied to a blockchain node, where the method includes: encoding contract metadata according to a target format to obtain a corresponding target expansion section; and sending the target expansion section to a virtual machine so that the virtual machine searches and reads contract metadata in the target expansion section.
Computer storage media for embodiments of the invention may employ any combination of one or more computer-readable media. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a Read-Only Memory (ROM), an Erasable Programmable Read-Only Memory (EPROM or flash Memory), an optical fiber, a portable Compact Disc Read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + +, or the like, as well as conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).
It is to be noted that the foregoing is only illustrative of the preferred embodiments of the present invention and the technical principles employed. It will be understood by those skilled in the art that the present invention is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the invention. Therefore, although the present invention has been described in greater detail by the above embodiments, the present invention is not limited to the above embodiments, and may include other equivalent embodiments without departing from the spirit of the present invention, and the scope of the present invention is determined by the scope of the appended claims.