A method and system for encapsulating inter-process communication of heterogeneous operating system hosts

Abstract

The application provides a heterogeneous operating system host inter-process communication packaging method and system, and relates to the technical field of heterogeneous host communication.The application obtains a communication request of a source process containing a target process identifier and communication data in a source host, identifies the heterogeneity of the operating systems of the source host and the target host, and determines a packaging protocol corresponding to data conversion specification and process identifier mapping rules; then serializes the communication data according to the specification, encodes the target process identifier into a general process identifier according to the rules, combines the two into a transmission package, and sends the transmission package to the target host through a TCP network; finally, the target host analyzes the transmission package header, extracts the general process identifier and system type information, decodes the local process identifier, deserializes the payload area data, and delivers the data to the target process, so that the standardized packaging and cross-platform data interaction of process communication between heterogeneous operating system hosts can be realized.

Description

Technical Field

[0001] This application relates to the field of heterogeneous host communication technology, and in particular to a method and system for encapsulating inter-process communication between heterogeneous operating system hosts. Background Technology

[0002] The encapsulation method for inter-process communication between heterogeneous operating system hosts is a core supporting technology for enabling collaborative work between processes in different system environments. This technology is widely adaptable to distributed scenarios such as cloud computing, edge computing, and the Internet of Things, providing communication guarantees for multi-platform resource integration and business collaboration, and has a very broad application prospect.

[0003] Currently, among the existing encapsulation methods for inter-process communication between heterogeneous operating system hosts, the most common encapsulation scheme is based on general middleware. This involves deploying middleware clients and servers on the source and target hosts respectively, capturing and processing inter-process communication requests, converting communication data using a fixed serialization format, and locating the target process through preset port mapping.

[0004] However, the middleware of this existing technology requires customized development for different operating systems, and the fixed serialization format and port mapping method are difficult to adapt to diverse heterogeneous system combinations, easily leading to data conversion failures or process location errors, resulting in poor compatibility and reliability of cross-platform communication. Therefore, existing technologies suffer from insufficient compatibility and reliability in inter-process communication between heterogeneous operating system hosts. Summary of the Invention

[0005] The purpose of this application is to provide a method and system for encapsulating inter-process communication between heterogeneous operating system hosts, so as to solve the problems of insufficient compatibility and reliability of inter-process communication between heterogeneous operating system hosts in the prior art.

[0006] To address the aforementioned technical problems, in a first aspect, this application provides an encapsulation method for inter-process communication between heterogeneous operating system hosts, comprising: On the source host, obtain the process communication request issued by the source process, the process communication request including the target process identifier and the communication data to be sent; The heterogeneity between the first operating system running on the source host and the second operating system running on the target host where the target process is located is identified, and a corresponding encapsulation protocol is determined based on the heterogeneity. The encapsulation protocol includes data conversion specifications and process identifier mapping rules. The communication data is serialized according to the data conversion specification to generate serialized data, and the target process identifier is encoded into a general process identifier according to the process identifier mapping rule. The general process identifier and the serialized data are combined into a transport packet, and the transport packet is sent to the target host through the Transmission Control Protocol network; On the target host, the header area of ​​the transmission packet is parsed to extract the general process identifier and operating system type information, and the general process identifier is decoded into a local process identifier for the target process under the second operating system based on the process identifier mapping rule; The payload area of ​​the transmitted packet is deserialized to reconstruct the serialized data into the original communication data, and the original communication data is delivered to the target process specified by the local process identifier.

[0007] Optionally, the step of identifying the heterogeneity between the first operating system running on the source host and the second operating system running on the target host where the target process resides, and determining the corresponding encapsulation protocol based on the heterogeneity, includes: Obtain the first operating system type information of the source host; The network location information of the target host is parsed from the target process identifier; Based on the network location information, query the preset configuration library of storage host network location and operating system type mapping relationship to obtain the second operating system type information of the target host; The first operating system type information is combined with the second operating system type information to form a heterogeneous operating system combination pair. Using the heterogeneous combination of the operating systems as the search criteria, the encapsulation protocol that uniquely corresponds to the heterogeneous combination of the operating systems is searched and determined in the configuration library.

[0008] Optionally, the serialization process includes network byte order conversion, data structure alignment adjustment, and checksum appending; The steps of serializing the communication data according to the data conversion specification to generate serialized data, and encoding the target process identifier into a generic process identifier according to the process identifier mapping rule, include: Traverse each multi-byte data field within the communication data and adjust the byte order of each data field according to the byte order rules defined in the data conversion specification; Based on the memory alignment rules defined in the data conversion specification, calculate the number of padding bytes required between each data field, and insert the specified number of padding bytes at the corresponding positions; For the data block formed after byte order adjustment and padding byte insertion, a predetermined calculation process is performed to generate a check value, and the check value is appended to the end of the data block to form serialized data; Using the target process identifier as an index, search and obtain the general process identifier corresponding to the target process identifier in the Zhang mapping table defined by the process identifier mapping rule.

[0009] Optionally, the transmission packet includes a header area and a payload area, wherein the header area is used to store the general process identifier and operating system type information, and the payload area is used to store the serialized data; The step of combining the generic process identifier and the serialized data into a transport packet and sending the transport packet to the target host via a Transmission Control Protocol (TCP) network includes: A memory buffer is created as the storage space for the transmission packet, and the memory buffer is divided into a header area and a payload area; Write the general process identifier into the predetermined process identifier field in the header area; Write the operating system type information of the target host into the predetermined system type field in the header area; The serialized data is copied completely to the payload area; The data content of the memory buffer is submitted to the network transmission interface of the source host to complete the transmission.

[0010] Optionally, the step of parsing the header region of the transmission packet on the target host to extract the generic process identifier and operating system type information, and decoding the generic process identifier into a local process identifier specifying the target process under the second operating system based on the process identifier mapping rule, includes: From the header region of the received transmission packet, data is read according to a predetermined offset and length, and the general process identifier and operating system type information are extracted respectively. Using the general process identifier as an index, query the reverse mapping table stored on the target host, where the reverse mapping table is defined by the process identifier mapping rules; Obtain the local process identifier that is uniquely corresponding to the general process identifier and is valid within the second operating system from the reverse mapping table.

[0011] Optionally, the deserialization process includes local byte order restoration, data structure reconstruction, and checksum verification; The step of deserializing the payload region of the transmission packet to reconstruct the serialized data into original communication data, and delivering the original communication data to the target process specified by the local process identifier, includes: Data blocks and additional checksums are separated from the payload region of the transmitted packet; Perform the same predetermined calculation process as in the serialization process on the data block to obtain a new calculated check value, and compare the new calculated check value with the separated check value; If the comparison is consistent, allocate target memory space for the reconstructed original communication data and traverse the data blocks; For each multi-byte data field in the data block, perform a byte order adjustment that is the reverse of the serialization process to restore it to the local byte order of the second operating system; Each data field, after being restored to its original byte order, is copied sequentially into the target memory space according to the original data structure layout, skipping all padding bytes, thus completing the reconstruction of the original communication data; A pointer or handle to the target memory space is passed to the target process represented by the local process identifier.

[0012] Optionally, the step of searching and determining the encapsulation protocol uniquely corresponding to the heterogeneous combination of operating systems in the configuration library using the heterogeneous combination of operating systems as the search condition includes: Access the configuration library, which contains multiple mapping entries. Each mapping entry consists of key-value pairs, where the key part stores an operating system heterogeneous combination pair and the value part stores an encapsulation protocol identifier. Using the heterogeneous combination of the operating system as the input key, the key portion of the configuration library is traversed by item-by-item comparison to find a mapping entry that is completely consistent with the input key. When a matching mapping entry is located in the configuration library, the corresponding encapsulation protocol identifier is extracted from the value portion of the mapping entry; Based on the encapsulation protocol identifier, query the additional protocol details library to obtain the complete encapsulation protocol content associated with the encapsulation protocol identifier. The complete encapsulation protocol content includes data conversion specifications and process identifier mapping rules.

[0013] Secondly, this application provides an encapsulation system for inter-process communication between heterogeneous operating system hosts, comprising: The acquisition module is used to acquire, on the source host, a process communication request issued by the source process, wherein the process communication request includes a target process identifier and communication data to be sent; The determination module is used to identify the heterogeneity between the first operating system running on the source host and the second operating system running on the target host where the target process is located, and to determine the corresponding encapsulation protocol based on the heterogeneity. The encapsulation protocol includes data conversion specifications and process identifier mapping rules. The encoding module is used to serialize the communication data according to the data conversion specification to generate serialized data, and to encode the target process identifier into a general process identifier according to the process identifier mapping rule. The sending module is used to combine the general process identifier and the serialized data into a transmission packet, and send the transmission packet to the target host through the transmission control protocol network; The decoding module is used on the target host to parse the header area of ​​the transmission packet to extract the general process identifier and operating system type information, and decode the general process identifier into a local process identifier of the target process under the second operating system based on the process identifier mapping rule. The reconstruction module is used to deserialize the payload area of ​​the transmission packet to reconstruct the serialized data into the original communication data, and deliver the original communication data to the target process specified by the local process identifier.

[0014] Thirdly, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor, used to execute the computer program, implements the steps of the encapsulation method for inter-process communication between heterogeneous operating system hosts as described in the first aspect above.

[0015] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps of the encapsulation method for inter-process communication between heterogeneous operating system hosts as described in the first aspect above.

[0016] The encapsulation method for inter-process communication between heterogeneous operating systems provided in this application can clearly identify the communication object and core data by obtaining the process communication request issued by the source process on the source host, which contains the target process identifier and the communication data to be sent; by identifying the heterogeneity of the operating systems of the source and target hosts and determining the corresponding encapsulation protocol containing data conversion specifications and process identifier mapping rules, it can achieve accurate adaptation to the differences of heterogeneous systems and ensure the targeted nature of subsequent processing; by serializing the communication data according to the data conversion specifications to generate serialized data and encoding the target process identifier into a general process identifier according to the process identifier mapping rules, it can realize the communication data and process identifier. Standardized processing eliminates format differences between heterogeneous systems; by combining a universal process identifier and serialized data into a transmission packet and sending it to the target host via TCP, reliable transmission of standardized data can be achieved, ensuring complete data delivery; by parsing the header area of ​​the transmission packet on the target host to extract the universal process identifier and operating system type information, and decoding it based on the process identifier mapping rules to obtain the local process identifier, the target process can be accurately located, ensuring the accuracy of the communication object; by deserializing the payload area of ​​the transmission packet to reconstruct the original communication data and delivering it to the target process, the accurate restoration and targeted delivery of the original data can be achieved, completing the entire communication process.

[0017] Furthermore, the first operating system type information of the source host is obtained, and then the network location information of the target host is parsed from the target process identifier. Subsequently, based on the network location information, a preset configuration library is queried to obtain the second operating system type information of the target host. The two types of operating system type information are combined to form a heterogeneous operating system pair. Finally, this pair is used as the search condition to find and determine the unique corresponding encapsulation protocol in the configuration library. By accurately obtaining the operating system types of the source and target ends and constructing heterogeneous pairings to match the unique encapsulation protocol, the encapsulation protocol can be automatically and accurately matched, improving the efficiency and accuracy of protocol matching, further enhancing the adaptability to heterogeneous systems, and ensuring the smooth operation of subsequent communication processes. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a method for encapsulating inter-process communication between heterogeneous operating system hosts, provided in an embodiment of this application; Figure 2A flowchart illustrating a specific implementation of an encapsulation method for inter-process communication between heterogeneous operating system hosts, provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an encapsulation system for inter-process communication between heterogeneous operating system hosts, provided in an embodiment of this application. Detailed Implementation

[0020] In inter-process communication scenarios between heterogeneous operating system hosts, existing encapsulation solutions based on general-purpose middleware have significant shortcomings: middleware needs to be custom-developed for different operating systems and uses fixed communication data conversion formats and process location methods, making it difficult to adapt to diverse combinations of heterogeneous systems. This directly leads to two key problems: data conversion failure and target process location deviation, ultimately making cross-platform inter-process communication unstable and unsmooth, significantly reducing compatibility and reliability. The core of this problem lies in the fact that existing solutions do not address the specific differences in system heterogeneity, urgently requiring a communication encapsulation solution that can flexibly adapt to different heterogeneous systems.

[0021] To address the aforementioned issues, this application proposes an encapsulation method for inter-process communication between hosts with heterogeneous operating systems. The core idea is to first identify the differences between the operating systems of the source and target hosts, and then match corresponding dedicated encapsulation rules to achieve standardized processing and precise conversion of communication data and process identifiers. Specifically, after the source host receives a communication request, it first determines the heterogeneity of the operating systems at both ends and identifies the appropriate encapsulation protocol. According to the protocol, the communication data is converted into a standard format, and the target process identifier is converted into a universal identifier. These are then combined and sent over the network. At the target host, the standard data and universal identifier are then converted back into a locally recognizable format and accurately delivered to the target process. This method overcomes the drawbacks of fixed formats and custom development in existing solutions. By specifically adapting to the differences between heterogeneous systems and standardizing the processing of key communication elements, it fundamentally solves the problems of insufficient cross-platform communication compatibility and reliability in existing technologies, ensuring smooth and stable inter-process communication between hosts with different operating systems.

[0022] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] The core of this application is to provide an encapsulation method for inter-process communication between heterogeneous operating system hosts, and a flowchart of one specific implementation is shown below. Figure 1 As shown, the method includes: S101. On the source host, obtain the inter-process communication request issued by the source process.

[0024] The process communication request includes the target process identifier and the communication data to be sent; the source host is the computer device that initiates the communication request; the target process identifier is used to uniquely identify the target program that needs to receive data; the communication data to be sent is various types of information that the source process wants to pass to the target process, such as instructions, parameters, file fragments, etc.

[0025] In one specific implementation, the source host continuously monitors the communication behavior of the local source process through a preset process communication monitoring module. After capturing the process communication request issued by the source process, it parses the fixed fields of the request message, synchronously extracts the target process identifier and the communication data to be sent contained in the request, and performs preliminary verification on the extracted information to ensure data integrity.

[0026] For example, suppose the source host is an office computer running Windows, and its file synchronization process acts as the source process, needing to transmit file update information to other hosts. The source host's process communication monitoring module monitors the operation of this synchronization process in real time. When it detects that the file synchronization process has initiated a communication request, it immediately parses the request message, extracting the target process identifier CloudSync_Service_001. This identifier corresponds to the cloud synchronization service process on the target host. Simultaneously, it extracts the communication data to be sent, which includes information such as the name of the updated file, modification time, and data summary. Then, it verifies whether this information is missing or formatted incorrectly. Once confirmed to be correct, the data acquisition step is completed.

[0027] S102. Identify the heterogeneity between the first operating system running on the source host and the second operating system running on the target host where the target process is located, and determine the corresponding encapsulation protocol based on the heterogeneity.

[0028] The encapsulation protocol, comprising data conversion specifications and process identifier mapping rules, is a set of rules adapted to communication between heterogeneous operating systems. Heterogeneity refers to the differences in operating system type, data format, and process identifier rules between the source and target hosts. The data conversion specifications define the format conversion standards for communication data between different operating systems, ensuring correct data identification across heterogeneous systems; the process identifier mapping rules establish the correspondence between process identifiers under different operating systems, enabling precise process location across systems.

[0029] Optionally, such as Figure 2 As shown, step S102 may specifically include the following steps: S1021. Obtain the first operating system type information of the source host.

[0030] In this embodiment of the application, the system information interface built into the source host operating system is called to read the type identification information of the operating system. This identification information can directly represent the specific type of the operating system.

[0031] For example, assuming the source host is a computer used for file management in an office setting, by calling the "Win32_OperatingSystem" interface of the Windows system, the system type identifier is read as "Windows10_64bit", thus determining the first operating system type information as a Windows 10 64-bit operating system. The above example is only one example of this application. In practical applications, it can also be obtained by reading system configuration files, etc., as needed. This application does not limit this.

[0032] S1022. Parse the network location information of the target host from the target process identifier.

[0033] In this step, network location information is used to locate the specific location of the target host in the network. It usually includes IP address, port number, etc., which can enable accurate addressing of the target host.

[0034] Specifically, the target process identifier is stored in a combined format of "network location information - process-specific identifier". Using string splitting technology, the network location information portion is extracted from the target process identifier according to a preset delimiter. The splitting and parsing can be implemented using the following core code: # Target process identifier resolution def parse_target_process_id(target_process_id, separator='-'): # Split identifiers by preset separator parts = target_process_id.split(separator, 1) # Split only once to avoid process-specific identifiers containing separators if len(parts) == 2: return parts[0] # Returns the network location information section else: raise ValueError("Target process identifier format is incorrect") The code above implements the parsing function for the target process identifier: by defining a parsing function that receives the target process identifier and a preset delimiter as input parameters, it uses a single-splitting strategy to split the target process identifier into strings, thus avoiding interference from delimiters that may exist in the process-specific identifier. When two parts are obtained after splitting, the network location information of the first part is output; if the splitting result does not conform to the preset format, an exception is thrown to indicate an identifier format error, thereby ensuring the accuracy and reliability of the parsing process.

[0035] In practical applications, continuing the office document management application scenario described earlier, let's assume the obtained target process identifier is "192.168.1.105:8080-CloudSync_Service_001", with the default separator "-". By splitting this target process identifier using string splitting technology, we obtain the first half, "192.168.1.105:8080", where 192.168.1.105 is the target host's IP address, and 8080 is the communication port number. Together, they constitute the target host's network location information. The above example is merely one illustration of this application; other combinations of formats and separators can be used in practical applications, and this application does not limit this.

[0036] S1023. Based on the network location information, query the preset configuration library of the mapping relationship between storage host network location and operating system type to obtain the second operating system type information of the target host.

[0037] The configuration library is a pre-built structured database specifically designed to store the mapping relationship between host network location information and corresponding operating system type information, enabling quick retrieval of the corresponding operating system type based on network location information.

[0038] In one specific implementation, the parsed target host network location information is first used as search keywords, and a precise matching search algorithm is used to query the configuration database. The configuration database stores multiple mapping entries for "network location information - operating system type". During the search, each entry in the database is compared with the search keywords. When a network location information entry that perfectly matches is found, the operating system type information corresponding to that entry is extracted, which is the second operating system type information of the target host.

[0039] For example, continuing the previous scenario, the known network location information of the target host is "192.168.1.105:8080". The preset configuration library contains the following mapping entries: 192.168.1.101:8080-Linux CentOS 7, 192.168.1.105:8080-Ubuntu 22.04, 192.168.1.108:8080-macOS Ventura. Using "192.168.1.105:8080" as the search keyword for precise matching, after finding a matching entry, the corresponding operating system type information is extracted as Ubuntu 22.04, that is, the second operating system type information is Ubuntu 22.04 operating system. The above example is only one example of this application. In actual applications, the content and number of entries in the configuration library can be adjusted according to the actual network environment, and this application does not limit this.

[0040] S1024. Combine the first operating system type information with the second operating system type information to form a heterogeneous operating system combination pair.

[0041] In the above steps, the operating system heterogeneous combination pair is a set used to characterize the combination relationship between the operating system types of the source host and the target host.

[0042] In this embodiment, a fixed format of "first operating system type - second operating system type" is used to concatenate the first operating system type information obtained in S1021 and the second operating system type information obtained in S1023 to form a heterogeneous operating system combination pair. If the two operating system types are different, the combination pair represents heterogeneity; if they are the same, it represents no heterogeneity.

[0043] For example, continuing the previous scenario, the first operating system type information is Windows 10 64-bit, and the second operating system type information is Ubuntu 22.04. Concatenating them according to the format "first operating system type - second operating system type" yields the heterogeneous operating system pair "Windows 10 64-bit - Ubuntu 22.04". Since the two operating system types are different, this pair clearly indicates that the source host and the target host have heterogeneous operating systems. The above example is merely one example of this application; other concatenation formats can be used in practical applications, and this application does not limit them.

[0044] S1025. Using the heterogeneous combination of the operating systems as the search criteria, search and determine the encapsulation protocol that uniquely corresponds to the heterogeneous combination of the operating systems in the configuration library.

[0045] Step S1025 may specifically include the following process: accessing the configuration library, which contains multiple mapping entries, each consisting of key-value pairs, where the key part stores an operating system heterogeneous combination pair and the value part stores an encapsulation protocol identifier; using the operating system heterogeneous combination pair as the input key, traversing the key part of the configuration library using an item-by-item comparison method to find a mapping entry that is completely consistent with the input key; when a matching mapping entry is located in the configuration library, extracting the corresponding encapsulation protocol identifier from the value part of the mapping entry; and querying an additional protocol details library based on the encapsulation protocol identifier to obtain the complete encapsulation protocol content associated with the encapsulation protocol identifier, wherein the complete encapsulation protocol content includes data conversion specifications and process identifier mapping rules.

[0046] The mapping entries are the basic data units stored in the configuration library, consisting of key-value pairs. The key stores heterogeneous combinations of operating systems, and the value stores the encapsulation protocol identifier. The encapsulation protocol identifier is coded information that uniquely identifies a specific encapsulation protocol, allowing for quick location of the corresponding complete encapsulation protocol. The protocol details library is a dedicated database storing the complete encapsulation protocol content. Each encapsulation protocol is associated with a unique encapsulation protocol identifier and includes the corresponding data conversion specifications and process identifier mapping rules.

[0047] Specifically, the system first accesses the configuration library, which contains multiple mapping entries consisting of key-value pairs. Using the heterogeneous combination of S1024 as the input key, it iterates through the key portion of the configuration library using a step-by-step comparison method to find a mapping entry that perfectly matches the input key. The core implementation logic is as follows: # Configuration library search matching def find_matching_protocol(config_lib, os_heterogeneous_pair): # Traverse configuration library key-value pairs for pair, proto_id in config_lib.items(): if pair == os_heterogeneous_pair: return proto_id # Returns the matching encapsulation protocol identifier return None # Returns an empty string if no match is found The code above implements the configuration library retrieval and matching function: A retrieval function is defined that receives the configuration library and the heterogeneous operating system pair to be retrieved as input parameters. The configuration library is stored in a dictionary structure, with the key being the heterogeneous operating system pair and the value being the corresponding encapsulation protocol identifier. The function iterates through the key-value pairs in the configuration library, matching each pair. When a key that completely matches the input heterogeneous pair is found, the corresponding encapsulation protocol identifier is output; otherwise, an empty value is returned, ensuring the simplicity and efficiency of the retrieval logic. Subsequently, the extracted encapsulation protocol identifier is used as a search keyword to query an additional protocol details library to obtain the complete encapsulation protocol content associated with that identifier.

[0048] In another specific implementation, to improve retrieval efficiency, an index structure for the key portion can be established in the configuration library, associating heterogeneous operating system combinations with index addresses. During retrieval, the index structure is first used to quickly locate the index address corresponding to the input key, and then the corresponding mapping entry is directly obtained based on the index address. The subsequent process of extracting the encapsulation protocol identifier and querying the protocol details library is consistent with the aforementioned implementation.

[0049] In practical applications, continuing with the office document management scenario described earlier, the known heterogeneous operating system pair is "Windows 10 64bit-Ubuntu 22.04". Accessing the configuration library, some mapping entries are as follows: Windows 10 64bit-Ubuntu 22.04-Protocal_003, Windows 10 64bit-macOS Ventura-Protocal_005, and Linux CentOS 7-Ubuntu 22.04-Protocal_008. Using "Windows 10 64bit-Ubuntu 22.04" as the input key, each key in the library is compared. After finding a matching entry, the encapsulation protocol identifier in the extracted value is Protocol_003. Next, the protocol details library is queried. The complete encapsulation protocol content corresponding to Protocol_003 in this library includes: a data conversion specification of "converting UTF-16 encoded data from the Windows system to UTF-8 encoded data from the Ubuntu system", and a process identifier mapping rule of "mapping the process ID of the Windows system to the process name of the Ubuntu system one-to-one". The above example is only one example of this application. In actual applications, the contents of the configuration library and protocol details library can be set according to the actual heterogeneous system combination requirements. This application does not limit this.

[0050] This application achieves automated and precise matching of encapsulation protocols by accurately identifying the operating system types of the source and target systems, constructing heterogeneous pairings, and matching them with dedicated encapsulation protocols. This effectively solves the problem of insufficient flexibility in adapting encapsulation protocols to heterogeneous systems in existing technologies. This technology combination can complete heterogeneity identification and protocol matching without manual intervention, improving the efficiency of communication configuration between heterogeneous operating system hosts while ensuring accurate adaptation of encapsulation protocols to heterogeneous system combinations.

[0051] S103. The communication data is serialized according to the data conversion specification to generate serialized data, and the target process identifier is encoded into a general process identifier according to the process identifier mapping rule.

[0052] Serialization, including network byte order conversion, data structure alignment, and checksum appending, is a process that converts communication data to be transmitted between heterogeneous systems into a unified format, ensuring that data can be correctly transmitted and parsed between different operating system hosts. A universal process identifier is a process identifier that conforms to cross-system communication standards and can be recognized by different operating system hosts, used to achieve unified process location in heterogeneous environments.

[0053] Optionally, step S103 may specifically include the following steps: S1031. Traverse each multi-byte data field in the communication data and adjust the byte order of each data field according to the byte order rules defined in the data conversion specification.

[0054] In this step, multibyte data fields refer to data units consisting of two or more bytes, such as file size and modification timestamps. Network byte order rules are standardized byte arrangement rules agreed upon in heterogeneous system communication, used to eliminate parsing discrepancies caused by differences in byte order between different operating system hosts.

[0055] Specifically, firstly, all multi-byte data fields in the communication data are traversed to identify the original byte order of each field; then, according to the network byte order rules defined in the data conversion specification, the byte order of fields whose original byte order does not conform to the rules is adjusted to obtain multi-byte data fields that conform to the unified standard.

[0056] For example, continuing with the office document management scenario mentioned earlier, assume that the communication data contains a multi-byte data field for file size, with an original value of 0x12345678 and a corresponding byte sequence of [0x12, 0x34, 0x56, 0x78]. The source host operating system uses little-endian byte order. The network byte order rule defined in the data conversion specification is big-endian byte order. By traversing and identifying that the original byte order of this field does not conform to the rule, the byte order is adjusted. After adjustment, the byte sequence is [0x78, 0x56, 0x34, 0x12], and the corresponding value is still 0x12345678, but the byte arrangement conforms to the unified standard.

[0057] S1032. Based on the memory alignment rules defined in the data conversion specification, calculate the number of padding bytes required between each data field, and insert the specified number of padding bytes at the corresponding positions.

[0058] Memory alignment rules are established to ensure the correct storage and retrieval of data in the memory of hosts running different operating systems. They specify the starting address offset requirements for different types of data fields in memory. Padding bytes are invalid bytes inserted between data fields to avoid data parsing errors caused by differences in memory alignment methods across different systems.

[0059] In this embodiment, the memory alignment length of each data field is first determined according to the memory alignment rules in the data conversion specification; then the difference between the current starting address of each data field and the starting address that conforms to the alignment rules is calculated, and this difference is the number of padding bytes required; finally, a specified number of padding bytes are inserted before the corresponding data field so that the starting address of the data field conforms to the memory alignment rules.

[0060] In practical applications, continuing the previous scenario, assume the memory alignment rule defined in the data conversion specification is "aligned to 4 bytes," meaning the starting address of a data field must be a multiple of 4. The communication data adjusted by S1031 contains two consecutive fields: the first field is the filename, a string type with a length of 3 bytes and a starting address of 0; the second field is the file size, a 4-byte integer. Calculating the number of padding bytes required for the second field: the ending address of the first field is 2, and the next address that is a multiple of 4 is 4, the difference being 2, therefore 2 padding bytes need to be inserted. After inserting 2 0x00 padding bytes between the filename field and the file size field, the starting address of the file size field becomes 4, conforming to the memory alignment rule. The above example is merely one example of this application; in practical applications, the number of padding bytes can be calculated according to different memory alignment rules, and this application does not limit this calculation.

[0061] S1033. For the data block formed after byte order adjustment and padding byte insertion, perform a predetermined calculation process to generate a check value, and append the check value to the end of the data block to form serialized data.

[0062] In this step, the checksum is a data value obtained through a predetermined calculation process to verify data integrity. If data is lost or tampered with during transmission, the checksum will change. Serialized data is a uniformly formatted data block formed after byte order adjustment, memory alignment adjustment, and checksum appending, and can be directly used for network transmission between heterogeneous systems.

[0063] Specifically, firstly, the data block after S1031 byte order adjustment and S1032 padding byte insertion is obtained; then, the cyclic redundancy check algorithm is used as a predetermined calculation process to calculate and generate a check value for the data block; finally, the generated check value is appended to the end of the data block to form complete serialized data.

[0064] The Cyclic Redundancy Check (CRC) algorithm first shifts the data block left by 16 bits, where 16 is the order of the standard generator polynomial 0x8005. Then, it takes the modulus of the shifted data block with this generator polynomial. Finally, it performs an XOR operation between the shifted data block and the modulus, and the result is the check value. Here, the XOR operation is used for logical binary bit judgment, the left shift operation is used for overall data bit offset, and the modulus operation is used to obtain the remainder after dividing the data block by the generator polynomial.

[0065] For example, continuing the office document management scenario described earlier, the data block after byte order adjustment in S1031 and padding byte insertion in S1032 is [0x46,0x69,0x6C,0x65,0x00,0x00,0x78,0x56,0x34,0x12]. The first 4 bytes are the file name "File", the middle 2 bytes are padding bytes, and the last 4 bytes are the adjusted file size. A cyclic redundancy check (CRC) algorithm is used to calculate the checksum. First, the data block is shifted left by 16 bits. Then, the modulo value is obtained by taking the modulus of the standard generator polynomial 0x8005. Finally, the left-shifted data block is XORed with the modulo value to generate the checksum 0x1A2B. The checksum is appended to the end of the data block to obtain the serialized data [0x46,0x69,0x6C,0x65,0x00,0x00,0x78,0x56,0x34,0x12,0x1A,0x2B].

[0066] S1034. Using the target process identifier as an index, search for and obtain the general process identifier corresponding to the target process identifier in the Zhang mapping table defined by the process identifier mapping rule.

[0067] The mapping table is the specific carrier of process identifier mapping rules. It stores the correspondence between local process identifiers and general process identifiers under different operating systems, and can support fast querying using local process identifiers as indexes to achieve accurate mapping between local identifiers and general identifiers.

[0068] In this embodiment of the application, the mapping table defined by the process identifier mapping rule is first determined. The mapping table contains key-value pairs of local process identifiers and general process identifiers corresponding to the target host operating system. Then, the target process identifier obtained in S101 is used as an index to search in the mapping table. When a matching key is found, the corresponding value is extracted. This value is the general process identifier corresponding to the target process identifier.

[0069] For example, continuing with the office document management scenario described earlier, the target process identifier obtained in S101 is CloudSync_Service_001. The process identifier mapping rule used in this step corresponds to a preset mapping table. This mapping table is specifically adapted to the mapping requirements of local process identifiers and general process identifiers on the target host Ubuntu 22.04 operating system. The specific content is shown in Table 1 below:

[0070] During the search, the mapping table is matched using CloudSync_Service_001 as the index. After finding the corresponding key-value pair, the value part, Universal_Sync_003, is extracted. This value is the universal process identifier that can be recognized across systems. The above example is only one example of this application. In actual applications, the key-value pair content of the mapping table can be set according to the actual process configuration requirements, and this application does not limit it.

[0071] This application effectively solves the practical problems of incompatible data transmission formats, incompatibility of process identifiers, and error-prone data transmission between heterogeneous operating system hosts by combining technologies such as unified byte order adjustment, memory alignment adaptation, data integrity verification, and standardized process identifier mapping. This combination of technologies achieves cross-system adaptation and integrity assurance of communication data, while simultaneously achieving unified identification of process identifiers, breaking through the bottlenecks of cumbersome format adaptation and poor reliability in traditional heterogeneous communication.

[0072] S104. Combine the general process identifier and the serialized data into a transmission packet, and send the transmission packet to the target host through the Transmission Control Protocol network.

[0073] A transmission packet is a standardized data unit used for network transmission, comprising a header area and a payload area. The header area stores general process identifiers and operating system type information, allowing the target host to quickly parse and locate the data upon receipt. The payload area stores serialized data, which is the core, valid data for transmission. A Transmission Control Protocol (TCP) network is a network environment that uses the TCP for data transmission, characterized by reliable transmission and on-order delivery, ensuring that transmission packets are delivered to the target host completely and accurately.

[0074] Optionally, step S104 may specifically include the following steps: S1041. Create a memory buffer as the storage space for the transmission packet.

[0075] In this step, the memory buffer is a contiguous storage space allocated in the source host's memory, specifically used to temporarily store the data of the transmission packets to be assembled, avoiding data storage chaos. The header area and payload area are divisions of the memory buffer according to the structural requirements of the transmission packets. The size and starting address of each area are preset fixed values ​​to ensure the standardization of data writing and reading.

[0076] Specifically, firstly, based on the preset packet structure parameters, the total storage space required for the header and payload regions is calculated; then, the source host's memory allocation interface is called to allocate a contiguous memory space of the corresponding size as a memory buffer; finally, according to the preset partitioning rules, the memory buffer is divided into a header region and a payload region, and the starting address and size of the two regions are recorded to prepare for subsequent data writing. The core implementation logic is as follows: # Creation and partitioning of transport packet memory buffer def create_transport_buffer(header_size=64, payload_size=None): # Calculate the total buffer size (header is fixed at 64 bytes, payload size is determined by serialized data). total_size = header_size + payload_size if payload_size else header_size + 1024 # Default payload buffer is 1024 bytes # Allocate a memory buffer buffer = bytearray(total_size) # Divide the header region and the payload region (header starts at address 0, payload starts at address equal to the size of the header). header_region = buffer[0:header_size] payload_region = buffer[header_size:total_size] return buffer, header_region, payload_region The code above defines a creation function that receives the preset header area size and payload area size as parameters. After calculating the total buffer size, it allocates a corresponding byte array as a buffer. Then, it divides the buffer into two areas according to the rule that the header area starts at address 0 and the payload area starts at address equal to the header size. Finally, it returns the complete buffer and the two partitions, providing structured storage space for subsequent data writing.

[0077] For example, continuing with the office document management scenario described earlier, the default header size of the transmission packet is 64 bytes, and the serialized data generated by S103 is 12 bytes. Therefore, the payload size must be at least 12 bytes. Calling the above function calculates the total buffer size to be 64 + 12 = 76 bytes. After allocating a 76-byte memory buffer, the first 64 bytes are divided into the header area, starting at address 0-63; the last 12 bytes are divided into the payload area, starting at address 64-75.

[0078] S1042. Write the general process identifier into the predetermined process identifier field in the header area.

[0079] The predefined process identifier field is a fixed byte segment in the header area specifically used to store the general process identifier. Its starting offset and the number of bytes occupied are both preset values ​​to ensure that the target host can accurately extract the general process identifier.

[0080] In this embodiment, the general process identifier obtained in S1034 is first acquired, along with the preset starting offset and number of bytes occupied by the predetermined process identifier field in the header area; then, the general process identifier is converted into a byte format that meets the field requirements; finally, the converted general process identifier byte data is written into the predetermined process identifier field in the header area according to the preset starting offset, thus completing the storage of the general process identifier.

[0081] In practical applications, continuing the previous scenario, the universal process identifier obtained by S1034 is Universal_Sync_003, with a corresponding byte format of 0x556E6976657273616C5F53796E635F303033. The default starting offset of the predefined process identifier field in the header area is 8 bytes, occupying 18 bytes. The byte data of the aforementioned universal process identifier is written starting from the header area's starting address 0+8=8, continuously occupying 18 bytes of space, thus completing the writing of the universal process identifier.

[0082] S1043. Write the operating system type information of the target host into the predetermined system type field in the header area.

[0083] The predefined system type field is a fixed byte segment within the header area specifically used to store the target host's operating system type information. Its starting offset and the number of bytes occupied are also preset values, which are used to enable the target host to quickly identify the parsing rules corresponding to its own operating system.

[0084] Specifically, first, the target host operating system type information obtained in S1023, as well as the preset starting offset and number of bytes occupied by the predetermined system type field in the header area, are obtained; the operating system type information is converted into a byte format that meets the field requirements; then, the converted byte data is written into the predetermined system type field in the header area according to the preset starting offset. Since this field and the predetermined process identifier field in S1042 are both located in the header area and have different preset offsets, no data writing conflict will occur.

[0085] For example, continuing the previous scenario, the target host operating system type information obtained in S1023 is Ubuntu 22.04, with a corresponding byte format of 0x5562756E74752032322E3034. The default starting offset of the predefined system type field in the header area is 32, occupying 12 bytes. The byte data of the operating system type information is written starting from the header area's starting address 0+32=32, continuously occupying 12 bytes. At this point, bytes 8-25 in the header area are the general process identifier, and bytes 32-43 are the operating system type information; these fields do not interfere with each other.

[0086] S1044. Copy the serialized data completely to the payload area.

[0087] In this embodiment, the serialized data generated in S1033 and the starting address of the payload area divided in S1041 are first obtained; then the data copy interface is called to copy the serialized data completely to the payload area in byte order. The starting address of the copy is the preset starting address of the payload area, and the copy length is consistent with the byte length of the serialized data, ensuring that the serialized data is stored in the payload area completely without any omissions.

[0088] In another specific implementation, if the serialized data size exceeds the preset initial size of the payload area, the memory reallocation interface can be called first to expand the payload area space before data copying is performed to avoid data overflow.

[0089] For example, continuing the previous scenario, the serialized data generated in S1033 is [0x46,0x69,0x6C,0x65,0x00,0x00,0x78,0x56,0x34,0x12,0x1A,0x2B], totaling 12 bytes. The payload region divided in S1041 starts at address 64. The data copy interface is called to copy the aforementioned 12 bytes of serialized data sequentially from address 64 to the payload region. After completion, bytes 64-75 of the payload region store the complete serialized data.

[0090] S1045. Submit the data content of the memory buffer to the network transmission interface of the source host to complete the transmission.

[0091] Among them, the network transmission interface is a standardized interface provided by the source host operating system for data network transmission. It can encapsulate the data content in memory into transmission control protocol data packets and send them to the specified target host, realizing the flow of data from memory to the network.

[0092] Specifically, first, the complete memory buffer is obtained, containing all data in the header and payload regions, as well as the network location information of the target host; then, the network transmission interface of the source host is called, using the data content of the memory buffer as the transmission data and the network location information of the target host as the transmission destination parameter. After receiving the parameters, the network transmission interface encapsulates the data into a Transmission Control Protocol (TCP) data packet and sends it to the target host through the TCP network, completing the entire transmission packet sending process.

[0093] For example, continuing the previous scenario, the memory buffer created by S1041 contains 64 bytes of header data and 12 bytes of payload data, totaling 76 bytes of data content; the network location information of the target host is 192.168.1.105:8080. The source host's network transport interface is called, passing in the 76 bytes of buffer data and the target host's network location information. The interface encapsulates the data into a Transmission Control Protocol (TCP) data packet and sends it to port 8080 of 192.168.1.105 via the office network.

[0094] This application effectively solves the practical problems of chaotic data transmission formats, easy loss of core information, and poor transmission reliability in heterogeneous system communication by combining structured transmission packet construction, precise partitioning and writing, and reliable protocol transmission. This combination of technologies achieves standardized encapsulation and orderly storage of transmitted data, and relies on transmission control protocols to ensure complete data delivery, breaking through the bottlenecks of non-standardized transmission packet construction and error-prone data in traditional heterogeneous communication.

[0095] S105. On the target host, the header area of ​​the transmission packet is parsed to extract the general process identifier and operating system type information, and the general process identifier is decoded into a local process identifier of the target process under the second operating system based on the process identifier mapping rule.

[0096] Decoding is the process of converting a universal process identifier used across systems into a local process identifier that can be recognized by the target host's second operating system. Its core is the reverse conversion of identifiers based on a mapping rule established by process identifiers. The local process identifier is the unique identification information used within the second operating system to locate the target process.

[0097] Optionally, step S105 may specifically include the following steps: S1051. Read data from the header area of ​​the received transmission packet according to a predetermined offset and length, and extract the general process identifier and operating system type information respectively.

[0098] In this step, the predetermined offset refers to the byte offset of each information field in the header region relative to the header start address, and the predetermined length refers to the number of bytes occupied by each information field.

[0099] Specifically, the process first receives the transmission packet on the target host and locates the starting address of the packet header area; then, according to the pre-agreed offset and length, it locates the storage locations of the general process identifier field and the operating system type information field in the header area; finally, it reads data of a specified length from the corresponding locations to complete the extraction of the general process identifier and the operating system type information.

[0100] For example, continuing the office document management scenario described earlier, after the target host receives the transmission packet, it determines that the starting address of the header region is 0. The pre-agreed header configuration is as follows: the universal process identifier field has an offset of 8 and a length of 18; the operating system type information field has an offset of 32 and a length of 12. Based on the configuration, the starting address of the universal process identifier field is 0+8=8, and 18 bytes of data (bytes 8-25) are read, which are then decoded to obtain Universal_Sync_003; the starting address of the operating system type information field is 0+32=32, and 12 bytes of data (bytes 32-43) are read, which are then decoded to obtain Ubuntu 22.04.

[0101] S1052. Using the general process identifier as an index, query the reverse mapping table stored on the target host. The reverse mapping table is defined by the process identifier mapping rule.

[0102] The reverse mapping table is the specific carrier of the process identifier mapping rules on the target host. It stores the correspondence between general process identifiers and local process identifiers of the second operating system. It corresponds in reverse to the mapping table on the source host and is specifically used for the conversion query from general process identifiers to local process identifiers.

[0103] In this embodiment of the application, the general process identifier extracted in S1051 is first obtained, and the reverse mapping relationship table defined by the process identifier mapping rule on the target host is determined. Then, the general process identifier is used as an index to perform a matching query in the reverse mapping relationship table to locate the table entry corresponding to the general process identifier.

[0104] For example, continuing with the office document management scenario described earlier, the universal process identifier extracted by S1051 is Universal_Sync_003. The reverse mapping table stored on the target host is defined by process identifier mapping rules and is adapted to the Ubuntu 22.04 operating system. First, this universal process identifier is obtained to determine the corresponding reverse mapping table on the target host; then, Universal_Sync_003 is used as an index to perform a row-by-row matching query in the reverse mapping table to find the table entry whose universal process identifier column matches the index.

[0105] S1053. Obtain the local process identifier that is uniquely corresponding to the general process identifier and is valid in the second operating system from the reverse mapping table.

[0106] Specifically, after locating the reverse mapping table entry that matches the general process identifier in S1052, the unique identifier information corresponding to the general process identifier in the table entry is extracted. This identifier information is the local process identifier that is valid in the second operating system, thus completing the decoding from the general process identifier to the local process identifier.

[0107] For example, continuing the previous scenario, the universal process identifier extracted by S1051 is Universal_Sync_003. The reverse mapping table stored on the target host is defined by process identifier mapping rules, specifically adapted to the Ubuntu 22.04 operating system, as shown in Table 2 below:

[0108] Using Universal_Sync_003 as the index, the query is performed in the aforementioned reverse mapping table. After locating the corresponding entry, the second operating system local process identifier, CloudSync_Service_001, is extracted from the entry. This identifier is the local process identifier recognizable within the Ubuntu 22.04 operating system, used to locate the target cloud synchronization service process. The above example is merely one example of this application. In practical applications, the content of the reverse mapping table entries can be set according to actual process configuration requirements, and this application does not impose any limitations on this.

[0109] This application effectively solves the practical problem of target hosts being unable to recognize universal process identifiers and accurately locate target processes in heterogeneous system communication by combining the techniques of accurately extracting header information with preset offsets and implementing identifier conversion using a reverse mapping table. This combination of techniques achieves efficient and accurate decoding from universal identifiers to local identifiers, ensuring the interoperability and adaptability of process identifiers in heterogeneous environments, and breaking through the bottlenecks of cumbersome identifier conversion and inaccurate positioning in traditional heterogeneous communication.

[0110] S106. The payload area of ​​the transmission packet is deserialized to reconstruct the serialized data into the original communication data, and the original communication data is delivered to the target process specified by the local process identifier.

[0111] Deserialization, which includes local byte order restoration, data structure reconstruction, and checksum verification, is the reverse process of serialization. It restores the transmitted serialized data to the original communication data that the target host can directly process. The target memory space is a contiguous area in the target host's memory specifically allocated for storing the reconstructed original communication data. Pointers or handles are identifiers used to access this target memory space, allowing the target process to quickly locate and access the original communication data.

[0112] Optionally, step S106 may specifically include the following steps: S1061. Separate the data block and additional check value from the payload area of ​​the transmission packet.

[0113] In this step, the data block refers to the core data portion after byte order adjustment and padding byte insertion, without the attached checksum. It forms the basis for reconstructing the original communication data. Separation is the process of splitting the data block and checksum from the complete data in the payload area according to the rules for attaching checksums during serialization, ensuring accurate subsequent verification and validation.

[0114] Specifically, first, the complete data content of the transport packet payload area is determined; then, according to the checksum length and appending rules agreed upon during serialization, the checksum is appended to the end of the data block, and the splitting position of the data block and checksum is calculated; finally, the payload area data is split into two parts from the splitting position, the first half being the data block and the second half being the appended checksum. The core implementation logic is as follows: # Load Area Data Separation def separate_data_and_checksum(payload_data, checksum_length=2): # The checksum is appended to the end of the data block, and the split position is the payload data length minus the checksum length. split_pos = len(payload_data) - checksum_length if split_pos <= 0: raise ValueError("Load area data format error") data_block = payload_data[:split_pos] checksum = payload_data[split_pos:] return data_block, checksum The code above defines a splitting function that receives the complete data of the payload region and a preset check value length as input parameters. After calculating the splitting position, it splits the data into two parts: a data block and a check value, and returns the result. If the splitting position is unreasonable, an exception is thrown to ensure the accuracy of the splitting process.

[0115] For example, continuing with the office document management scenario mentioned earlier, the complete data of the transmission packet payload area is [0x46,0x69,0x6C,0x65,0x00,0x00,0x78,0x56,0x34,0x12,0x1A,0x2B], totaling 12 bytes. During serialization, the checksum length is agreed to be 2 bytes and appended to the end of the data block. The splitting position is calculated as 12-2=10. The payload data is split from this position, resulting in the first 10 bytes of data [0x46,0x69,0x6C,0x65,0x00,0x00,0x78,0x56,0x34,0x12], and the last 2 bytes of checksum [0x1A,0x2B].

[0116] S1062. Perform the same predetermined calculation process as in the serialization process on the data block to obtain a new calculated check value, and compare the new calculated check value with the separated check value.

[0117] Specifically, the data block separated in S1061 is first obtained; then the same predetermined calculation process as in the serialization process of S1033, namely the cyclic redundancy check algorithm, is executed to calculate a new calculated check value for the data block; finally, the new calculated check value is compared with the separated check value at the byte level to determine whether the two are consistent, thereby verifying whether the data block is complete and has not been tampered with during transmission.

[0118] For example, continuing the previous scenario, the data block separated in S1061 is [0x46, 0x69, 0x6C, 0x65, 0x00, 0x00, 0x78, 0x56, 0x34, 0x12]. The same cyclic redundancy check algorithm used during serialization is executed to calculate a new check value. First, the data block is shifted left by 16 bits. Then, the modulo value is obtained by taking the standard generator polynomial 0x8005. Finally, the left-shifted data block and the modulo value are XORed to obtain the newly calculated check value [0x1A, 0x2B]. The newly calculated check value is compared with the separated check value [0x1A, 0x2B]. The two bytes are completely identical, indicating that the data block has been transmitted intact and has not been tampered with.

[0119] S1063. If the comparison is consistent, allocate target memory space for the reconstructed original communication data and traverse the data block.

[0120] The size of the target memory space needs to be determined based on the estimated size of the original communication data to ensure that it can completely accommodate the reconstructed original communication data and avoid data storage overflow. Traversal refers to scanning the data block byte by byte or field by field to prepare for subsequent byte order restoration and data structure reorganization.

[0121] In this embodiment, firstly, under the premise of matching in S1062, the storage space required for the original communication data is estimated based on the size of the data block and the structural characteristics of the original communication data; then, the memory allocation interface of the target host is called to allocate a continuous memory space of the corresponding size as the target memory space; finally, the traversal program is started to scan the data block separated in S1061 field by field and record the starting position and length of each data field.

[0122] For example, continuing the previous scenario, after S1062 confirms the match, the structural characteristics of the data block [0x46,0x69,0x6C,0x65,0x00,0x00,0x78,0x56,0x34,0x12] are analyzed. It is known that the original communication data contains two fields: filename and file size, and the estimated required storage space is 8 bytes. The memory allocation interface is called to allocate 8 bytes of target memory space, starting at address 0x10000000. Subsequently, the data block is traversed, recording the filename field's starting position (0, length 4), padding bytes' starting position (4, length 2), and file size field's starting position (6, length 4).

[0123] S1064. For each multi-byte data field in the data block, perform a byte order adjustment that is the opposite of that during serialization, so as to restore it to the local byte order of the second operating system.

[0124] In this step, reverse byte order adjustment refers to the process of restoring multi-byte data fields that were adjusted to network byte order during serialization to the local byte order of the target host's second operating system. The core is to follow the reverse byte order logic from the serialization process to ensure that the data can be correctly parsed by the target host.

[0125] Specifically, firstly, based on the traversal results of S1063, all multi-byte data fields are filtered out from the data block; then, the local byte order type of the second operating system and the byte order adjustment rules during serialization are determined; finally, for each multi-byte data field, the byte order adjustment is performed in reverse order to restore it to a multi-byte data field that conforms to the local byte order.

[0126] For example, continuing the previous scenario, the second operating system is Ubuntu 22.04, whose local byte order is little-endian. Based on the traversal result of S1063, the multi-byte data field in the data block is the file size field, whose content in the data block is [0x78, 0x56, 0x34, 0x12], which has been adjusted to network byte order during serialization. Performing the reverse byte order adjustment as during serialization, the byte order of this field is reversed, resulting in [0x12, 0x34, 0x56, 0x78], restoring it to file size field data that conforms to the local byte order of Ubuntu 22.04.

[0127] S1065. Copy each data field, which has been restored to byte order, to the target memory space in sequence according to the original data structure layout, skipping all padding bytes, and complete the reconstruction of the original communication data.

[0128] Specifically, first, the restored data fields and the allocated target memory space are obtained; then, the structural layout of the original communication data is determined, that is, the order of the data fields; finally, according to the layout, the restored data fields are copied sequentially to the target memory space, skipping all the padding bytes traversed during the copying process, to ensure that the target memory space stores the original data structure without redundant padding bytes, thus completing the reconstruction of the original communication data.

[0129] For example, continuing the previous scenario, the fields restored in S1064 are the file name field [0x46, 0x69, 0x6C, 0x65] and the file size field [0x12, 0x34, 0x56, 0x78]. The original data structure layout is with the file name field first and the file size field second. The starting address of the target memory space allocated in S1063 is 0x10000000. The file name field is copied to the address segment 0x10000000-0x10000003 according to the layout, skipping the padding bytes [0x00, 0x00] in the data block, and the file size field is directly copied to the address segment 0x10000004-0x10000007. At this point, the target memory space stores the reconstructed original communication data, which contains [0x46,0x69,0x6C,0x65,0x12,0x34,0x56,0x78], and is completely consistent with the original communication data sent by the source host.

[0130] S1066. Pass a pointer or handle to the target memory space to the target process represented by the local process identifier.

[0131] The passing of pointers or handles is achieved through the inter-process communication interface provided by the target host operating system, ensuring that the target process can safely and quickly obtain the identification information pointing to the target memory space.

[0132] Specifically, first, the pointer or handle of the target memory space allocated by S1063 and the local process identifier obtained by S1053 are obtained; then, the target process corresponding to the local process identifier is located through the inter-process communication interface of the target host operating system; finally, the pointer or handle is passed to the target process, and the target process can access the original communication data in the target memory space through the pointer or handle to complete the data delivery.

[0133] For example, continuing the previous scenario, the target memory space pointer allocated in S1063 is 0x10000000, and the local process identifier obtained in S1053 is CloudSync_Service_001, corresponding to the target process being the cloud synchronization service process on the Ubuntu 22.04 operating system. Through the inter-process communication interface of the target host, the cloud synchronization service process is located, and the pointer 0x10000000 is passed to it. After receiving the pointer, the process can access the raw communication data in the address range 0x10000000-0x10000007 through this pointer, completing the delivery of office file synchronization data.

[0134] This application effectively solves the practical problems of serialized data being difficult to restore to original data, inaccurate data delivery positioning, and easy tampering of transmitted data in heterogeneous system communication by combining technologies such as data verification to ensure integrity, byte order reverse restoration to adapt to local systems, precise data structure reorganization, and precise process delivery. This combination of technologies achieves accurate reconstruction and secure delivery of serialized data to original communication data, breaking through the bottlenecks of poor deserialization adaptability and lack of data reliability in traditional heterogeneous communication.

[0135] Figure 3 This is a schematic diagram illustrating a specific implementation of a packaging system for inter-process communication between heterogeneous operating system hosts, provided in this application embodiment. (Refer to...) Figure 3 The system may include: The acquisition module 31 is used to acquire, on the source host, a process communication request issued by the source process, wherein the process communication request includes a target process identifier and communication data to be sent; The determination module 32 is used to identify the heterogeneity between the first operating system running on the source host and the second operating system running on the target host where the target process is located, and to determine the corresponding encapsulation protocol based on the heterogeneity. The encapsulation protocol includes data conversion specifications and process identifier mapping rules. The encoding module 33 is used to serialize the communication data according to the data conversion specification to generate serialized data, and to encode the target process identifier into a general process identifier according to the process identifier mapping rule. Sending module 34 is used to combine the general process identifier and the serialized data into a transmission packet, and send the transmission packet to the target host through the transmission control protocol network; The decoding module 35 is used to parse the header area of ​​the transmission packet on the target host to extract the general process identifier and operating system type information, and decode the general process identifier into a local process identifier of the target process under the second operating system based on the process identifier mapping rule. The reconstruction module 36 is used to deserialize the payload area of ​​the transmission packet to reconstruct the serialized data into the original communication data, and deliver the original communication data to the target process specified by the local process identifier.

[0136] The heterogeneous operating system host inter-process communication encapsulation system of this application embodiment is used to implement the aforementioned heterogeneous operating system host inter-process communication encapsulation method. Therefore, the specific implementation of the heterogeneous operating system host inter-process communication encapsulation system can be found in the embodiment section of the heterogeneous operating system host inter-process communication encapsulation method above. The specific implementation can be referred to the description of the corresponding embodiment, and will not be repeated here.

[0137] This application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the encapsulation method for inter-process communication between heterogeneous operating system hosts as described above.

[0138] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of any of the above-described encapsulation methods for inter-process communication between heterogeneous operating system hosts.

[0139] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory, random access memory, portable hard drives, magnetic disks, or optical disks.

[0140] Embodiments of the present invention also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in the above-described encapsulation method embodiments for inter-process communication between heterogeneous operating system hosts.

[0141] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0142] The above provides a detailed description of the encapsulation method and system for inter-process communication between heterogeneous operating system hosts provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A method for encapsulating inter-process communication between heterogeneous operating system hosts, characterized in that, include: On the source host, obtain the process communication request issued by the source process, the process communication request including the target process identifier and the communication data to be sent; The heterogeneity between the first operating system running on the source host and the second operating system running on the target host where the target process is located is identified, and a corresponding encapsulation protocol is determined based on the heterogeneity. The encapsulation protocol includes data conversion specifications and process identifier mapping rules. The communication data is serialized according to the data conversion specification to generate serialized data, and the target process identifier is encoded into a general process identifier according to the process identifier mapping rule. The general process identifier and the serialized data are combined into a transport packet, and the transport packet is sent to the target host through the Transmission Control Protocol network; On the target host, the header area of ​​the transmission packet is parsed to extract the general process identifier and operating system type information, and the general process identifier is decoded into a local process identifier for the target process under the second operating system based on the process identifier mapping rule; The payload area of ​​the transmitted packet is deserialized to reconstruct the serialized data into the original communication data, and the original communication data is delivered to the target process specified by the local process identifier; The step of identifying the heterogeneity between the first operating system running on the source host and the second operating system running on the target host where the target process resides, and determining the corresponding encapsulation protocol based on the heterogeneity, includes: The system obtains the first operating system type information of the source host; parses the network location information of the target host from the target process identifier; queries a preset configuration library that stores the mapping relationship between the network location of the storage host and the operating system type based on the network location information to obtain the second operating system type information of the target host; combines the first operating system type information and the second operating system type information to form an operating system heterogeneous combination pair; and uses the operating system heterogeneous combination pair as the search condition to find and determine the encapsulation protocol that uniquely corresponds to the operating system heterogeneous combination pair in the configuration library. The step of parsing the header region of the transmission packet on the target host to extract the generic process identifier and operating system type information, and decoding the generic process identifier into a local process identifier specifying the target process under the second operating system based on the process identifier mapping rule, includes: From the header region of the received transmission packet, data is read according to a predetermined offset and length, and the general process identifier and operating system type information are extracted respectively; using the general process identifier as an index, the reverse mapping table stored on the target host is queried, and the reverse mapping table is defined by the process identifier mapping rules; from the reverse mapping table, the local process identifier that uniquely corresponds to the general process identifier and is valid in the second operating system is obtained.

2. The method according to claim 1, characterized in that, The serialization process includes network byte order conversion, data structure alignment adjustment, checksum and appending; The steps of serializing the communication data according to the data conversion specification to generate serialized data, and encoding the target process identifier into a generic process identifier according to the process identifier mapping rule, include: Traverse each multi-byte data field within the communication data and adjust the byte order of each data field according to the byte order rules defined in the data conversion specification; Based on the memory alignment rules defined in the data conversion specification, calculate the number of padding bytes required between each data field, and insert the specified number of padding bytes at the corresponding positions; For the data block formed after byte order adjustment and padding byte insertion, a predetermined calculation process is performed to generate a check value, and the check value is appended to the end of the data block to form serialized data; Using the target process identifier as an index, search and obtain the general process identifier corresponding to the target process identifier in the Zhang mapping table defined by the process identifier mapping rule.

3. The method according to claim 1, characterized in that, The transmission packet includes a header area and a payload area. The header area is used to store the general process identifier and operating system type information, and the payload area is used to store the serialized data. The step of combining the generic process identifier and the serialized data into a transport packet and sending the transport packet to the target host via a Transmission Control Protocol (TCP) network includes: A memory buffer is created as the storage space for the transmission packet, and the memory buffer is divided into a header area and a payload area; Write the general process identifier into the predetermined process identifier field in the header area; Write the operating system type information of the target host into the predetermined system type field in the header area; The serialized data is copied completely to the payload area; The data content of the memory buffer is submitted to the network transmission interface of the source host to complete the transmission.

4. The method according to claim 1, characterized in that, The deserialization process includes local byte order restoration, data structure reconstruction, and checksum verification. The step of deserializing the payload region of the transmission packet to reconstruct the serialized data into original communication data, and delivering the original communication data to the target process specified by the local process identifier, includes: Data blocks and additional checksums are separated from the payload region of the transmitted packet; Perform the same predetermined calculation process as in the serialization process on the data block to obtain a new calculated check value, and compare the new calculated check value with the separated check value; If the comparison is consistent, allocate target memory space for the reconstructed original communication data and traverse the data blocks; For each multi-byte data field in the data block, perform a byte order adjustment that is the reverse of the serialization process to restore it to the local byte order of the second operating system; Each data field, after being restored to its original byte order, is copied sequentially into the target memory space according to the original data structure layout, skipping all padding bytes, thus completing the reconstruction of the original communication data; A pointer or handle to the target memory space is passed to the target process represented by the local process identifier.

5. The method according to claim 1, characterized in that, The step of searching and determining the encapsulation protocol uniquely corresponding to the heterogeneous combination of operating systems in the configuration library, using the heterogeneous combination of operating systems as the search criteria, includes: Access the configuration library, which contains multiple mapping entries. Each mapping entry consists of key-value pairs, where the key part stores an operating system heterogeneous combination pair and the value part stores an encapsulation protocol identifier. Using the heterogeneous combination of the operating system as the input key, the key portion of the configuration library is traversed by item-by-item comparison to find a mapping entry that is completely consistent with the input key. When a matching mapping entry is located in the configuration library, the corresponding encapsulation protocol identifier is extracted from the value portion of the mapping entry; Based on the encapsulation protocol identifier, query the additional protocol details library to obtain the complete encapsulation protocol content associated with the encapsulation protocol identifier. The complete encapsulation protocol content includes data conversion specifications and process identifier mapping rules.

6. A system for encapsulating inter-process communication between heterogeneous operating system hosts, used to execute the encapsulation method for inter-process communication between heterogeneous operating system hosts according to any one of claims 1 to 5, characterized in that, include: The acquisition module is used to acquire, on the source host, a process communication request issued by the source process, wherein the process communication request includes a target process identifier and communication data to be sent; The determination module is used to identify the heterogeneity between the first operating system running on the source host and the second operating system running on the target host where the target process is located, and to determine the corresponding encapsulation protocol based on the heterogeneity. The encapsulation protocol includes data conversion specifications and process identifier mapping rules. The encoding module is used to serialize the communication data according to the data conversion specification to generate serialized data, and to encode the target process identifier into a general process identifier according to the process identifier mapping rule. The sending module is used to combine the general process identifier and the serialized data into a transmission packet, and send the transmission packet to the target host through the transmission control protocol network; The decoding module is used on the target host to parse the header area of ​​the transmission packet to extract the general process identifier and operating system type information, and decode the general process identifier into a local process identifier of the target process under the second operating system based on the process identifier mapping rule. The reconstruction module is used to deserialize the payload area of ​​the transmission packet to reconstruct the serialized data into the original communication data, and deliver the original communication data to the target process specified by the local process identifier.

7. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, used to implement the encapsulation method for inter-process communication between heterogeneous operating system hosts as described in any one of claims 1 to 5 when executing the computer program.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, enables the encapsulation method for inter-process communication between heterogeneous operating system hosts as described in any one of claims 1 to 5.

Images