A cross-language network message encapsulation method based on function signatures

Abstract

This invention discloses a cross-language network message encapsulation method based on function signatures, belonging to the field of cross-language network message encapsulation technology, including the following steps: S1, function signature parsing; S2, parameter preparation; S3, intelligent serialization; S4, message header assembly; S5, checksum calculation; S6, message assembly and transmission; S7, cross-language parsing. This cross-language network message encapsulation method based on function signatures uses the high 3 bits of the first byte to identify the data type and the low 5 bits to store control information or decimal values, achieving optimal encoding for values ​​in different ranges. It also maintains an independent string cache table for each communication session, with strings as keys and unique integers as indexes. When transmitting a string for the first time, the index and string are transmitted simultaneously; when transmitting the same string subsequently, only the index is transmitted, allowing the receiving end to quickly look up and restore the string, significantly reducing the amount of duplicate strings transmitted.

Description

Technical Field

[0001] This invention relates to the field of cross-language network message encapsulation technology, specifically a cross-language network message encapsulation method based on function signatures. Background Technology

[0002] With the rapid development of online games, metaverse, and distributed applications, software systems are increasingly characterized by complex architectures and heterogeneous components. In the field of online games, backend servers are often developed using languages ​​such as C++ and Go, while frontend clients are developed using languages ​​such as C# (Unity engine), JavaScript (Web environment), and Lua (script layer). Efficient data communication in heterogeneous environments has become a core requirement of the system.

[0003] The core challenge of cross-language communication lies in data serialization or deserialization and cross-language compatibility. Existing solutions mainly fall into two categories: one is JSON or XML over WebSocket text protocol solutions, which serialize messages through text formats and rely on pre-defined document structures to define message formats. However, these solutions suffer from low communication efficiency, high resource consumption, weak type systems, and easy loss of data precision, making them unsuitable for real-time communication needs in games. The other category is IDL pre-compiled binary protocol solutions such as Protocol Buffers and Apache Thrift, which require defining message formats through interface description languages ​​and compiling them to generate target language code. While these solutions offer superior performance, they suffer from cumbersome development processes, inflexible iteration, and poor support for dynamic scripting languages, making them unsuitable for the rapid iteration needs of game logic. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a cross-language network message encapsulation method based on function signatures, which solves the problems mentioned in the background section.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a cross-language network message encapsulation method based on function signatures, comprising the following steps:

[0006] S1. Function signature parsing:

[0007] When the system is running, when a business function is triggered and called, the parsing process is automatically intervened. Through the reflection mechanism provided by the programming language, the complete signature information of the function is obtained, including the function name, parameter types, parameter order and number of parameters. This information is integrated into a structured data contract, which becomes the core specification for cross-language communication.

[0008] S2, Parameter Arrangement:

[0009] After obtaining the function signature, the framework performs a deep traversal of all parameters of the function and accurately determines the type of each parameter through a type detection mechanism, classifying it as a numeric type, string type, or composite type. This step lays the foundation for subsequent serialization operations. Parameters of different types will adopt specific encoding strategies.

[0010] S3, Smart Serialization:

[0011] After being categorized as a numeric type, string type, or composite type;

[0012] For numeric types: a range-adaptive encoding strategy is adopted, in which the system predefines multiple numeric ranges and automatically selects the optimal byte length for encoding based on the specific numeric size;

[0013] For string types: Using session-level cache index encoding technology, the system maintains a string cache pool in a single communication session. When a duplicate string is encountered, the complete content is no longer transmitted repeatedly. Instead, the index number of the string in the cache pool is sent. The receiving end can quickly retrieve the original string from the cache based on the index, which greatly reduces network bandwidth usage.

[0014] For composite types: a hybrid structure encoding method is adopted. For composite types containing nested parameters, the system will recursively parse its internal structure and serialize it in the order of the parameters. During this process, corresponding metadata will be generated for each nesting level so that the receiving end can accurately restore the data structure.

[0015] S4, Message Header Assembly:

[0016] The message header, as a key component of network messages, contains three core fields:

[0017] Magic number: A fixed sequence of bytes defined by the developer to verify the validity of a message. When the receiving end receives a message, it first checks the magic number field. If the magic number does not match, the message is discarded to prevent illegal data from entering the system.

[0018] Message type identifier: Used to distinguish messages for different purposes. It adopts an enumeration or fixed encoding method to facilitate the receiving end to quickly identify the message type and process it accordingly.

[0019] Message body length: Records the length of the message body in bytes. The receiving end uses this field to accurately parse the message boundaries and avoid issues such as packet merging and incomplete packet processing.

[0020] S5. Checksum calculation:

[0021] To ensure message integrity during transmission, CRC32 or MD5 checksum algorithms are used to process the serialized message body.

[0022] S6. Message assembly and transmission:

[0023] The assembled message header, the calculated checksum, and the serialized binary message body are assembled into a complete network message packet in a pre-defined fixed order. The message packet is then sent to the receiving end via the network using the TCP or WebSocket transmission protocol.

[0024] S7, Cross-language parsing:

[0025] After receiving a network message packet, the receiving end performs the following steps:

[0026] Legality verification: First, check whether the magic number in the message header matches, and then perform verification and calculation on the message body, comparing it with the received checksum to ensure that the message is legal and has not been tampered with.

[0027] Message body extraction: Accurately extract message body data based on the length field in the message header;

[0028] Parameter restoration: Based on the unified serialization rules adopted by the sender and combined with the pre-established function signature mapping relationship, the binary message body is restored to the original parameter list;

[0029] Function call and result return: Based on the restored parameter list, the corresponding language business function is called to execute the specific logic; after execution, the result is reversed according to the above message encapsulation process to generate a response message and send it back to the sender.

[0030] Furthermore, in step S1, the reflection mechanism provided by the programming language includes Java's java.lang.reflect and Python's inspect module.

[0031] Furthermore, in step S1, the information is integrated according to a predefined pattern to form a structured data contract, specifically:

[0032] First, the parameter names, types, and return value types in the function signature are categorized and extracted, and a data structure is constructed using JSON or Protocol Buffers serialization format. Then, metadata descriptions are added to each parameter, including the value range and default value. Finally, context information related to the function call, including call frequency and timeout, is added to the data structure in key-value pairs, thus forming a structured data contract.

[0033] Furthermore, in step S2, the type detection mechanism includes Python's type() function and Java's instanceof operator; numeric types include integers and floating-point numbers; and composite types include arrays, objects, and structures.

[0034] Furthermore, in step S3, multiple numerical ranges are predefined, including 8 bits, 16 bits, 32 bits, and 64 bits. The specific process of automatically selecting the optimal byte length for encoding based on the specific numerical value is as follows:

[0035] When the value n satisfies -128≤n≤127, 8-bit two's complement encoding is used, and integers within this range are directly mapped to an 8-bit binary system;

[0036] If the value n exceeds the range of 8 bits, but satisfies -32768≤n≤32767, then 16-bit two's complement encoding is selected;

[0037] For values ​​of -2147483648≤n≤2147483647, 32-bit two's complement encoding is used;

[0038] If the value exceeds the 32-bit range, it will automatically switch to 64-bit two's complement encoding to cover a larger range of values.

[0039] Furthermore, in step S3, the composite type containing nested parameters includes multi-level nested JSON objects;

[0040] The system will recursively parse its internal structure, and the serialization process according to the parameter order is as follows:

[0041] Starting from the root node, determine the current data structure type, including objects, arrays, and primitive data types;

[0042] Basic data types: If it is a basic data type, including integers, strings, and booleans, it will be serialized directly according to the protocol rules, and the data type metadata will be recorded.

[0043] Object type: Traverse the object's properties, recursively parse the property values ​​in order of property name, and generate metadata for each property, including the property name and data type;

[0044] Array type: Recursively parse array elements in index order to generate metadata containing the number of elements and the data type of each element, which is stored in correspondence with the serialized element sequence;

[0045] Each time a new nested level is entered, a level identifier metadata is generated and associated with all data and metadata of the current level to ensure that the receiving end can accurately reconstruct the data structure according to the hierarchical relationship; the serialized data and corresponding metadata are packaged in a specified format to form a complete message packet for transmission.

[0046] Furthermore, in step S4, messages for different purposes include request messages, response messages, and heartbeat messages.

[0047] Furthermore, in step S5, taking CRC32 as an example, the processing flow is as follows:

[0048] The system performs byte-by-byte calculations on the message body data to generate a 32-bit checksum. After receiving the message, the receiving end performs the same CRC32 calculation on the message body and compares the result with the received checksum. If they do not match, it means that the message has been tampered with or damaged during transmission.

[0049] Furthermore, in step S6, during the transmission process, the transmission mechanism of the TCP protocol or the bidirectional communication characteristics of WebSocket can ensure that messages are delivered stably and in an orderly manner.

[0050] Furthermore, in step S7, the pre-established function signature mapping relationship is stored in a function signature and encoding rule lookup table on the receiving end.

[0051] This invention provides a cross-language network message encapsulation method based on function signatures, which has the following beneficial effects:

[0052] 1. This cross-language network message encapsulation method based on function signatures uses the high 3 bits of the first byte to identify the data type and the low 5 bits to store control information or decimal values, achieving optimal encoding for values ​​in different ranges. For example, small integers are directly stored in the low bits of the first byte, while large integers and floating-point numbers have their storage format specified for subsequent bytes through control identifiers, balancing encoding efficiency and data integrity. Furthermore, it maintains an independent string cache table for each communication session, using strings as keys and unique integers as indexes. When transmitting a string for the first time, both the index and the string are transmitted synchronously; when transmitting the same string subsequently, only the index is transmitted, allowing the receiving end to quickly look up and restore the string, significantly reducing the amount of duplicate strings transmitted.

[0053] 2. This cross-language network message encapsulation method based on function signatures establishes a unified type mapping rule, mapping the native types of various languages ​​(such as int in C++, Number in JavaScript, and string in Lua) to standard intermediate types, ensuring unambiguous data parsing between different languages. Dynamic languages ​​are integrated using native parameter binding, eliminating the need to generate additional adaptation code and preserving their development flexibility. Attached Figure Description

[0054] Figure 1 This is a flowchart illustrating a cross-language network message encapsulation method based on function signatures according to the present invention. Detailed Implementation

[0055] The embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and should not be construed as limiting the scope of the invention.

[0056] like Figure 1As shown, the present invention provides a technical solution: a cross-language network message encapsulation method based on function signatures, comprising the following steps:

[0057] S1. Function signature parsing:

[0058] When the system is running, when a business function is triggered and called, the parsing process is automatically intervened. Through the reflection mechanism provided by the programming language, the complete signature information of the function is obtained, including the function name, parameter types, parameter order and number of parameters. This information is integrated into a structured data contract, which becomes the core specification for cross-language communication.

[0059] Through reflection mechanisms provided by programming languages, including Java's `java.lang.reflect` and Python's `inspect` module, information is integrated into a structured data contract according to a predefined pattern. Specifically:

[0060] First, the parameter names, types, and return value types in the function signature are categorized and extracted, and a data structure is constructed using JSON or Protocol Buffers serialization format. Then, metadata descriptions are added to each parameter, including the value range and default value. Finally, the context information related to the function call, including the call frequency and timeout, is added to the data structure in the form of key-value pairs, thus forming a structured data contract.

[0061] S2, Parameter Arrangement:

[0062] After obtaining the function signature, the framework performs a deep traversal of all parameters of the function and accurately determines the type of each parameter through a type detection mechanism, classifying it as a numeric type, string type, or composite type. This step lays the foundation for subsequent serialization operations. Parameters of different types will adopt specific encoding strategies.

[0063] Type checking mechanisms include Python's `type()` function and Java's `instanceof` operator; numeric types include integers and floating-point numbers; composite types include arrays, objects, and structs.

[0064] S3, Smart Serialization:

[0065] After being categorized as a numeric type, string type, or composite type;

[0066] For numeric types: a range-adaptive encoding strategy is adopted, in which the system predefines multiple numeric ranges and automatically selects the optimal byte length for encoding based on the specific numeric size;

[0067] For string types: Using session-level cache index encoding technology, the system maintains a string cache pool in a single communication session. When a duplicate string is encountered, the complete content is no longer transmitted repeatedly. Instead, the index number of the string in the cache pool is sent. The receiving end can quickly retrieve the original string from the cache based on the index, which greatly reduces network bandwidth usage.

[0068] For composite types: a hybrid structure encoding method is adopted. For composite types containing nested parameters, the system will recursively parse its internal structure and serialize it in the order of the parameters. During this process, corresponding metadata will be generated for each nesting level so that the receiving end can accurately restore the data structure.

[0069] The specific process of automatically selecting the optimal byte length for encoding based on the specific value size, which predefines multiple numerical ranges including 8 bits, 16 bits, 32 bits, and 64 bits, is as follows:

[0070] When the value n satisfies -128≤n≤127, 8-bit (1 byte) two's complement encoding is used, and integers within this range are directly mapped to an 8-bit binary system;

[0071] If the value n exceeds the 8-bit range, but satisfies -32768≤n≤32767, then 16-bit (2-byte) two's complement encoding is selected;

[0072] For values ​​of -2147483648≤n≤2147483647, 32-bit (4-byte) two's complement encoding is used;

[0073] If the value exceeds the 32-bit range, it will automatically switch to 64-bit (8-byte) two's complement encoding to cover a larger range of values; composite types containing nested parameters include multi-level nested JSON objects;

[0074] The system will recursively parse its internal structure, and the serialization process according to the parameter order is as follows:

[0075] Starting from the root node, determine the current data structure type, including objects, arrays, and primitive data types;

[0076] Basic data types: If it is a basic data type, including integers, strings, and booleans, it will be serialized directly according to the protocol rules, and the data type metadata will be recorded.

[0077] Object type: Traverse the object's properties, recursively parse the property values ​​in order of property name, and generate metadata for each property, including the property name and data type;

[0078] Array type: Recursively parse array elements in index order to generate metadata containing the number of elements and the data type of each element, which is stored in correspondence with the serialized element sequence;

[0079] Each time a new nested level is entered, a level identifier metadata is generated and associated with all data and metadata of the current level to ensure that the receiving end can accurately reconstruct the data structure according to the hierarchical relationship; the serialized data and the corresponding metadata are packaged in a specified format to form a complete message packet for transmission.

[0080] S4, Message Header Assembly:

[0081] The message header, as a key component of network messages, contains three core fields:

[0082] Magic number: A fixed sequence of bytes defined by the developer to verify the validity of a message. When the receiving end receives a message, it first checks the magic number field. If the magic number does not match, the message is discarded to prevent illegal data from entering the system.

[0083] Message type identifier: Used to distinguish messages for different purposes. It adopts an enumeration or fixed encoding method to facilitate the receiving end to quickly identify the message type and process it accordingly.

[0084] Message body length: Records the length of the message body in bytes. The receiving end uses this field to accurately parse the message boundaries and avoid issues such as packet merging and incomplete packet processing.

[0085] Messages for different purposes include request messages, response messages, and heartbeat messages;

[0086] S5. Checksum calculation:

[0087] To ensure message integrity during transmission, CRC32 or MD5 checksum algorithms are used to process the serialized message body. Taking CRC32 as an example, the processing flow is as follows:

[0088] The system performs byte-by-byte calculations on the message body data to generate a 32-bit checksum. After receiving the message, the receiving end performs the same CRC32 calculation on the message body and compares the result with the received checksum. If they do not match, it means that the message has been tampered with or damaged during transmission.

[0089] S6. Message assembly and transmission:

[0090] The assembled message header, the calculated checksum, and the serialized binary message body are assembled into a complete network message packet in a pre-defined fixed order. The message packet is then sent to the receiving end via the network using the TCP or WebSocket transmission protocol.

[0091] During transmission, the TCP protocol's transmission mechanism or WebSocket's bidirectional communication features can ensure that messages are delivered stably and in an orderly manner.

[0092] S7, Cross-language parsing:

[0093] After receiving a network message packet, the receiving end performs the following steps:

[0094] Legality verification: First, check whether the magic number in the message header matches, and then perform verification and calculation on the message body, comparing it with the received checksum to ensure that the message is legal and has not been tampered with.

[0095] Message body extraction: Accurately extract message body data based on the length field in the message header;

[0096] Parameter restoration: Based on the unified serialization rules adopted by the sender and combined with the pre-established function signature mapping relationship, the binary message body is restored to the original parameter list. The pre-established function signature mapping relationship is stored in the function signature and encoding rule comparison table on the receiver's local machine.

[0097] Function call and result return: Based on the restored parameter list, the corresponding language business function is called to execute the specific logic; after execution, the result is reversed according to the above message encapsulation process to generate a response message and send it back to the sender;

[0098] Specific example: Function definition and signature parsing:

[0099] Client-side Lua definition of business functions:

[0100] SkillCast(skillId:number,posX:float,posY:float,targetId:string);

[0101] When a function is called, the function signature is automatically parsed to obtain the communication contract: the function name is "SkillCast", the parameter types are "number", "float", "float", and "string" in order, and the number of parameters is 4.

[0102] Parameter processing and serialization:

[0103] Skill ID (skillId=101): Integer type, ranging from [-32768, 32767], using 2-byte encoding (compatible with the byte description system mentioned above), the first byte is "00100001" (type identifier + control identifier), and the last byte stores the binary data of 101;

[0104] Release position (posX=123.45, posY=678.90): Floating-point type, each using 8-byte encoding (compliant with IEEE 754 double precision standard), the first byte is "00100100", and the following 7 bytes store the actual data;

[0105] Target player ID (targetId="player_12345"): String type. During the first transmission, the cache table allocates index "1", and "1 byte of index + 8 bytes of string" are transmitted; when the same player ID is transmitted in subsequent transmissions, only index "1" is transmitted.

[0106] Message header assembly and checksum calculation:

[0107] Message header: Magic number "0x1F2E3D4C" (used to verify message validity), message type identifier "01" (function call type message), message body length "2+8+8+(1-byte index + 8-byte string) = 27 bytes";

[0108] Checksum: Calculate the CRC32 checksum on the serialized 27-byte message body. The result is "0xABCDEF12".

[0109] Message transmission: The message header (4-byte magic number + 2-byte type identifier + 4-byte length = 10 bytes), checksum (4 bytes), and message body (27 bytes) are concatenated to form a complete 41-byte message packet, which is then transmitted to the server via the TCP protocol;

[0110] Server parsing and function calls:

[0111] After receiving the message packet, the server first verifies the magic number and checksum to confirm that the message is legal and complete.

[0112] Parse the message header to obtain the message body length, extract the message body and restore the parameters according to the serialization rules: skillId=101, posX=123.45, posY=678.90, targetId="player_12345";

[0113] Find the corresponding C++ business function voidSkillCast(int skillId, float posX, float posY, std::string targetId) through function signature mapping, and pass in the restored parameters to execute the logic;

[0114] Result return: After the server finishes execution, it will encapsulate the result (such as the skill release success indicator) in reverse according to the above process and transmit it to the client to complete a cross-language communication.

[0115] Based on the above description, this invention achieves optimal encoding for different ranges of values ​​by using the high 3 bits of the first byte to identify the data type ("001" corresponds to the numeric type) and the low 5 bits to store control information or small values. For example, small integers are directly stored in the low bits of the first byte, while large integers and floating-point numbers are stored in the format of subsequent bytes by using control identifiers, thus balancing encoding efficiency and data integrity. Furthermore, it maintains an independent string cache table for each communication session, using strings as keys and unique integers as indexes. When transmitting a string for the first time, both the index and the string are transmitted simultaneously. When transmitting the same string subsequently, only the index is transmitted, allowing the receiving end to quickly look up and restore the string, significantly reducing the amount of repeated string transmissions.

[0116] It also establishes a unified type mapping rule to map the native types of various languages ​​(such as int in C++, number in JavaScript, and string in Lua) to standard intermediate types, ensuring that data parsing between different languages ​​is unambiguous. Dynamic languages ​​are integrated using native parameter binding, without the need to generate additional adaptation code, thus preserving their development flexibility.

[0117] The embodiments of the present invention are given for illustrative and descriptive purposes only, and are not intended to be exhaustive or to limit the invention to the forms disclosed. Many modifications and variations will be apparent to those skilled in the art. The embodiments were chosen and described in order to better illustrate the principles and practical application of the invention, and to enable those skilled in the art to understand the invention and to design various embodiments with various modifications suitable for a particular purpose.

Claims

1. A cross-language network message encapsulation method based on function signatures, characterized in that: Includes the following steps: S1. Function signature parsing: When the system is running, when a business function is triggered and called, the parsing process is automatically intervened. Through the reflection mechanism provided by the programming language, the complete signature information of the function is obtained, including the function name, parameter types, parameter order and number of parameters. This information is integrated into a structured data contract, which becomes the core specification for cross-language communication. S2, Parameter Arrangement: After obtaining the function signature, the framework performs a deep traversal of all parameters of the function and accurately determines the type of each parameter through a type detection mechanism, classifying it as a numeric type, string type, or composite type. This step lays the foundation for subsequent serialization operations. Parameters of different types will adopt specific encoding strategies. S3, Smart Serialization: After being categorized as a numeric type, string type, or composite type; For numeric types: a range-adaptive encoding strategy is adopted, in which the system predefines multiple numeric ranges and automatically selects the optimal byte length for encoding based on the specific numeric size; For string types: Using session-level cache index encoding technology, the system maintains a string cache pool in a single communication session. When a duplicate string is encountered, the complete content is no longer transmitted repeatedly. Instead, the index number of the string in the cache pool is sent. The receiving end can quickly retrieve the original string from the cache based on the index, which greatly reduces network bandwidth usage. For composite types: a hybrid structure encoding method is adopted. For composite types containing nested parameters, the system will recursively parse its internal structure and serialize it in the order of the parameters. During this process, corresponding metadata will be generated for each nesting level so that the receiving end can accurately restore the data structure. S4. Message Header Assembly: The message header, as a key component of network messages, contains three core fields: Magic number: A fixed sequence of bytes defined by the developer to verify the validity of a message. When the receiving end receives a message, it first checks the magic number field. If the magic number does not match, the message is discarded to prevent illegal data from entering the system. Message type identifier: Used to distinguish messages for different purposes. It adopts an enumeration or fixed encoding method to facilitate the receiving end to quickly identify the message type and process it accordingly. Message body length: Records the length of the message body in bytes. The receiving end uses this field to accurately parse the message boundaries and avoid issues such as packet merging and incomplete packet processing. S5. Checksum calculation: To ensure message integrity during transmission, CRC32 or MD5 checksum algorithms are used to process the serialized message body. S6. Message assembly and transmission: The assembled message header, the calculated checksum, and the serialized binary message body are assembled into a complete network message packet in a pre-defined fixed order. The message packet is then sent to the receiving end via the network using the TCP or WebSocket transmission protocol. S7, Cross-language parsing: After receiving a network message packet, the receiving end performs the following steps: Legality verification: First, check whether the magic number in the message header matches, and then perform verification and calculation on the message body, comparing it with the received checksum to ensure that the message is legal and has not been tampered with. Message body extraction: Accurately extract message body data based on the length field in the message header; Parameter restoration: Based on the unified serialization rules adopted by the sender and combined with the pre-established function signature mapping relationship, the binary message body is restored to the original parameter list; Function call and result return: Based on the restored parameter list, the corresponding language business function is called to execute the specific logic; after execution, the result is reversed according to the above message encapsulation process to generate a response message and send it back to the sender.

2. The method for encapsulating cross-language network messages based on function signatures according to claim 1, characterized in that: In step S1, the reflection mechanisms provided by programming languages ​​include Java's java.lang.reflect and Python's inspect module.

3. The method for encapsulating cross-language network messages based on function signatures according to claim 1, characterized in that: In step S1, the information is integrated according to a predefined pattern to form a structured data contract, specifically: First, the parameter names, types, and return value types in the function signature are categorized and extracted, and a data structure is constructed using JSON or Protocol Buffers serialization format. Then, metadata descriptions are added to each parameter, including the value range and default value. Finally, context information related to the function call, including call frequency and timeout, is added to the data structure in key-value pairs, thus forming a structured data contract.

4. The method for encapsulating cross-language network messages based on function signatures according to claim 1, characterized in that: In step S2, the type detection mechanism includes Python's type() function and Java's instanceof operator; numeric types include integers and floating-point numbers; and composite types include arrays, objects, and structures.

5. The method for encapsulating cross-language network messages based on function signatures according to claim 1, characterized in that: In step S3, multiple numerical ranges are predefined, including 8 bits, 16 bits, 32 bits, and 64 bits. The specific process of automatically selecting the optimal byte length for encoding based on the specific numerical value is as follows: When the value n satisfies -128≤n≤127, 8-bit two's complement encoding is used, and integers within this range are directly mapped to an 8-bit binary system; If the value n exceeds the range of 8 bits, but satisfies -32768≤n≤32767, then 16-bit two's complement encoding is selected; For values ​​of -2147483648≤n≤2147483647, 32-bit two's complement encoding is used; If the value exceeds the 32-bit range, it will automatically switch to 64-bit two's complement encoding to cover a larger range of values.

6. The method for encapsulating cross-language network messages based on function signatures according to claim 1, characterized in that: In step S3, the composite type containing nested parameters includes multi-level nested JSON objects; The system will recursively parse its internal structure, and the serialization process according to the parameter order is as follows: Starting from the root node, determine the current data structure type, including objects, arrays, and primitive data types; Basic data types: If it is a basic data type, including integers, strings, and booleans, it will be serialized directly according to the protocol rules, and the data type metadata will be recorded. Object type: Traverse the object's properties, recursively parse the property values ​​in order of property name, and generate metadata for each property, including the property name and data type; Array type: Recursively parse array elements in index order to generate metadata containing the number of elements and the data type of each element, which is stored in correspondence with the serialized element sequence; Each time a new nested level is entered, a level identifier metadata is generated and associated with all data and metadata of the current level to ensure that the receiving end can accurately reconstruct the data structure according to the hierarchical relationship; the serialized data and corresponding metadata are packaged in a specified format to form a complete message packet for transmission.

7. The method for encapsulating cross-language network messages based on function signatures according to claim 1, characterized in that: In step S4, messages for different purposes include request messages, response messages, and heartbeat messages.

8. The method for encapsulating cross-language network messages based on function signatures according to claim 1, characterized in that: In step S5, taking CRC32 as an example, the processing flow is as follows: The system performs byte-by-byte calculations on the message body data to generate a 32-bit checksum. After receiving the message, the receiving end performs the same CRC32 calculation on the message body and compares the result with the received checksum. If they do not match, it means that the message has been tampered with or damaged during transmission.

9. The method for encapsulating cross-language network messages based on function signatures according to claim 1, characterized in that: In step S6, during the transmission process, the transmission mechanism of the TCP protocol or the bidirectional communication characteristics of WebSocket can ensure that messages are delivered stably and in an orderly manner.

10. The method for encapsulating cross-language network messages based on function signatures according to claim 1, characterized in that: In step S7, the pre-established function signature mapping relationship is stored in the function signature and encoding rule comparison table on the receiving end.

Images