Encapsulation method and system for process communication between hosts of heterogeneous operating system

Abstract

The invention provides a packaging method and system for process communication between hosts of a heterogeneous operating system, and relates to the technical field of heterogeneous host communication.The method comprises the steps that a source host obtains a communication request, containing a target process identifier and communication data, of a source process, and the isomerism of the source host and a target host operating system is recognized; determining a corresponding encapsulation protocol containing a data conversion specification and a process identifier mapping rule; serializing communication data according to specifications, coding a target process identifier into a general process identifier according to rules, combining the target process identifier and the general process identifier into a transmission packet, and sending the transmission packet to a target host through a TCP network; and finally, analyzing the head of the transmission packet at the target host, extracting the general process identifier and the system type information, decoding to obtain a local process identifier and deserialized load area data, and delivering the data to the target process, so that standardized packaging and cross-platform data interaction of process communication between hosts of the heterogeneous operating system can be realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of heterogeneous host communication, and particularly relates to a packaging method and system for process communication between heterogeneous operating system hosts. BACKGROUND

[0002] The packaging method for process communication between heterogeneous operating system hosts is a core supporting technology for realizing process collaborative work in different system environments. The technology is widely applicable to distributed scenarios such as cloud computing, edge computing and Internet of Things, and provides communication guarantee for multi-platform resource integration and business collaboration, and has a very broad application prospect.

[0003] At present, in the existing packaging method for process communication between heterogeneous operating system hosts, a common packaging scheme based on general middleware is more common. The middleware client and server are respectively deployed on the source host and the target host to capture and process process communication requests, adopt a fixed serialization format to convert communication data, and locate the target process through a preset port mapping.

[0004] However, the middleware of the prior art needs to be customized and developed for different operating systems, and the fixed serialization format and port mapping method are difficult to adapt to various combinations of heterogeneous systems, which may cause data conversion failure or process positioning deviation, resulting in poor compatibility and reliability of cross-platform communication. Therefore, there is a technical problem of insufficient compatibility and reliability of process communication between heterogeneous operating system hosts in the prior art. SUMMARY

[0005] The present application aims to provide a packaging method and system for process communication between heterogeneous operating system hosts to solve the problem of insufficient compatibility and reliability of process communication between heterogeneous operating system hosts in the prior art.

[0006] To solve the above technical problems, in a first aspect, the present application provides a packaging method for process communication between heterogeneous operating system hosts, comprising: On the source host, a process communication request sent by a source process is obtained, the process communication request comprising a target process identifier and communication data to be sent; The heterogeneity between a first operating system running on the source host and a second operating system running on a target host where the target process is located is identified, and a corresponding packaging protocol is determined according to the heterogeneity, the packaging protocol comprising a data conversion specification and a process identifier mapping rule; 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; combining the universal process identifier and the serialized data into a transmission packet, and sending the transmission packet to the target host through a transmission control protocol network; On the target host, parsing a header region of the transmission packet to extract the universal process identifier and operating system type information, and decoding the universal process identifier into a local process identifier under the second operating system that specifies the target process based on the process identifier mapping rule; deserializing a payload region of the transmission packet to reconstruct the serialized data into original communication data, and delivering the original communication data to a 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 is located, and determining the corresponding encapsulation protocol according to the heterogeneity, comprises: obtaining first operating system type information of the source host; parsing network location information of the target host from the target process identifier; According to the network location information, query the pre-stored configuration library of host network location and operating system type mapping relationship to obtain the second operating system type information of the target host; Combining the first operating system type information and the second operating system type information to form an operating system heterogeneity combination pair; Taking the operating system heterogeneity combination pair as a retrieval condition, searching and determining the encapsulation protocol corresponding to the operating system heterogeneity combination pair in the configuration library.

[0008] Optionally, the serialization process includes network byte order conversion, data structure alignment adjustment and checksum addition; The step of serializing the communication data according to the data conversion specification to generate serialized data, and encoding the target process identifier into a universal process identifier according to the process identifier mapping rule, comprises: Traverse each multi-byte data field in the communication data, and adjust the byte arrangement order of each data field according to the byte order rule defined in the data conversion specification; According to the memory alignment rule defined in the data conversion specification, calculate the number of padding bytes required between each data field, and insert a specified number of padding bytes at the corresponding position; For the data block formed after the byte order adjustment and padding byte insertion, execute a predetermined calculation process to generate a checksum value, and append the checksum value to the end of the data block to form serialized data; The universal process identifier corresponding to the target process identifier is obtained by searching a Zhang mapping table defined by the process identifier mapping rule with the target process identifier as an index.

[0009] Optionally, the transmission packet includes a header region and a payload region, the header region is used to store the universal process identifier and operating system type information, and the payload region is used to store the serialized data. The step of combining the universal process identifier and the serialized data into a transmission packet and sending the transmission packet to the target host through a transmission control protocol network includes: A memory buffer is created as a storage space of the transmission packet, and the memory buffer is divided into a header region and a payload region. The universal process identifier is written into a predetermined process identifier field in the header region. The operating system type information of the target host is written into a predetermined system type field in the header region. The serialized data is completely copied to the payload region. Data content of the memory buffer is submitted to a network transmission interface of the source host to complete sending.

[0010] Optionally, the step of parsing the header region of the transmission packet to extract the universal process identifier and operating system type information on the target host and decoding the universal process identifier into a local process identifier of a target process under the second operating system based on the process identifier mapping rule includes: The universal process identifier and operating system type information are extracted by reading data from the header region of the received transmission packet according to a predetermined offset and length, respectively. The universal process identifier is used as an index to query a reverse mapping relationship table stored on the target host, and the reverse mapping relationship table is defined by the process identifier mapping rule. A local process identifier corresponding to the universal process identifier and valid in the second operating system is obtained from the reverse mapping relationship table.

[0011] Optionally, the deserialization processing includes local byte sequence restoration, data structure reorganization, and checksum verification. The step of performing deserialization processing on the payload region of the transmission packet to reconstruct the serialized data into original communication data and delivering the original communication data to a target process specified by the local process identifier includes: A data block and an additional checksum are separated from the payload region of the transmission packet. performing the same predetermined calculation process as in the serialization process on the data block to obtain a new calculated check value, and comparing the new calculated check value with the separated check value; in case of consistent comparison, allocating a target memory space for the reconstructed original communication data, and traversing the data block; for each multi-byte data field in the data block, performing byte order adjustment in the opposite direction as in serialization to restore the native byte order of the second operating system; copying each data field after byte order restoration to the target memory space in sequence according to the original data structure layout, skipping all padding bytes, and completing the reconstruction of the original communication data; passing a pointer or handle pointing to the target memory space to the target process identified by the local process.

[0012] Optionally, the step of searching and determining the encapsulation protocol uniquely corresponding to the operating system heterogeneous pair in the configuration library based on the operating system heterogeneous pair as the retrieval condition comprises: accessing the configuration library, the configuration library containing a plurality of mapping entries, each mapping entry being composed of a key-value pair, the key part storing an operating system heterogeneous pair, and the value part storing an encapsulation protocol identifier; taking the operating system heterogeneous pair as the input key, traversing the key part in the configuration library in a one-by-one comparison manner to find a mapping entry identical to the input key; when the matching mapping entry is located in the configuration library, extracting the corresponding encapsulation protocol identifier from the value part of the mapping entry; querying the additional protocol details library according to the encapsulation protocol identifier to obtain the complete encapsulation protocol content associated with the encapsulation protocol identifier, the complete encapsulation protocol content including data conversion specifications and process identification mapping rules.

[0013] In a second aspect, the application provides an encapsulation system for inter-process communication between heterogeneous operating system hosts, comprising: an obtaining module, configured to obtain, on a source host, a process communication request sent by a source process, the process communication request including a target process identification and communication data to be sent; a determining module, configured to identify the heterogeneity between a first operating system running on the source host and a second operating system running on a target host where the target process is located, and determine a corresponding encapsulation protocol according to the heterogeneity, the encapsulation protocol including data conversion specifications and process identification mapping rules; The encoding module is configured to serialize the communication data according to the data conversion specification to generate serialized data, and encode the target process identifier into a universal process identifier according to the process identifier mapping rule; The sending module is configured to combine the universal process identifier and the serialized data into a transmission packet, and send the transmission packet to the target host via a transmission control protocol network; The decoding module is configured to parse a header area of the transmission packet to extract the universal process identifier and operating system type information on the target host, and decode the universal 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 configured to deserialize a payload area of the transmission packet to reconstruct the serialized data into original communication data, and deliver the original communication data to the target process specified by the local process identifier.

[0014] In a third aspect, the present application provides an electronic device, comprising: a memory configured to store a computer program; a processor configured to implement the steps of the packaging method for inter-host process communication between heterogeneous operating systems according to the first aspect described above when executing the computer program.

[0015] In a fourth aspect, the present application provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program is executable by a processor to implement the steps of the packaging method for inter-host process communication between heterogeneous operating systems according to the first aspect described above.

[0016] The encapsulation method for inter-host process communication of heterogeneous operating systems provided by the application can obtain a process communication request sent by a source process and containing a target process identifier and communication data to be sent, can determine the communication object and core data, can accurately adapt to the differences between heterogeneous systems, and can ensure the pertinence of subsequent processing by identifying the heterogeneity of the operating systems of the source host and the target host and determining the encapsulation protocol containing data conversion specifications and process identifier mapping rules, can standardize the communication data and process identifier, eliminate the format differences between heterogeneous systems, and ensure the reliable transmission of standardized data, ensure the complete delivery of data by serializing the communication data according to the data conversion specifications to generate serialized data, encoding the target process identifier into a universal process identifier according to the process identifier mapping rules, combining the universal process identifier and the serialized data into a transmission packet, and sending the transmission packet to the target host through a TCP network, can accurately locate the target process, and can ensure the accuracy of the communication object by parsing the universal process identifier and the operating system type information in the header area of the transmission packet on the target host, decoding the local process identifier based on the process identifier mapping rules, can accurately restore and deliver the original data to the target process by reverse serializing the payload area of the transmission packet to reconstruct the original communication data and delivering the original communication data to the target process, and can complete the entire communication process.

[0017] Further, the first operating system type information of the source host is obtained, the network location information of the target host is parsed from the target process identifier, the second operating system type information of the target host is obtained from the network location information by querying a preset configuration library, the two types of operating system type information are combined to form an operating system heterogeneous combination pair, and finally the combination pair is used as a search condition to search and determine the unique corresponding encapsulation protocol in the configuration library. By accurately obtaining the operating system types of the source end and the target end and constructing a heterogeneous combination pair to match the unique encapsulation protocol, the encapsulation protocol can be automatically and accurately matched, the protocol matching efficiency and accuracy can be improved, the adaptation capability to heterogeneous systems can be further strengthened, and the smooth development of the subsequent communication process can be ensured. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions of the embodiments of the application or the prior art, the drawings needed to be used in the embodiments or the prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor.

[0019] Figure 1 A flowchart of an encapsulation method for inter-host process communication of heterogeneous operating systems provided by an embodiment of the application; Figure 2A specific implementation flowchart of a packaging method for inter-host process communication of heterogeneous operating systems provided by an embodiment of the present application is shown in the figure. Figure 3 A structural schematic diagram of a packaging system for inter-host process communication of heterogeneous operating systems provided by an embodiment of the present application is shown in the figure. DETAILED DESCRIPTION

[0020] In the inter-host process communication scenario of heterogeneous operating systems, the existing packaging scheme based on general middleware has obvious deficiencies: the middleware needs to be separately customized and developed for different operating systems, and uses fixed communication data conversion formats and process positioning methods, which are difficult to adapt to various combinations of heterogeneous systems. This will directly lead to two key problems, one is data conversion failure, and the other is target process positioning deviation, ultimately making cross-platform inter-process communication difficult to be stable and smooth, and compatibility and reliability are greatly discounted. The core of this problem is that the existing scheme does not handle the differences between heterogeneous systems, and there is an urgent need for a communication packaging scheme that can flexibly adapt to different heterogeneous systems.

[0021] To solve the above problems, the present application provides a packaging method for inter-host process communication of heterogeneous operating systems. The core idea is to first identify the operating system differences between the source host and the target host, and then match the corresponding exclusive packaging rules to achieve standardized processing and accurate conversion of communication data and process identifiers. Specifically, after the source host obtains a communication request, it first determines the heterogeneous type of the operating systems at both ends and determines the adaptive packaging protocol, converts the communication data into a standard format and the target process identifier into a universal identifier according to the protocol, and then sends the combination through the network; the target host converts the standard data and the universal identifier into a format recognizable by the local host in reverse, and accurately delivers it to the target process. This method eliminates the disadvantages of fixed formats and customized development of existing schemes, and solves the problems of insufficient compatibility and reliability in cross-platform communication in the prior art by adaptively adapting to the differences between heterogeneous systems and standardizing the key elements of communication, thereby ensuring smooth and stable process communication between hosts of different operating systems.

[0022] In order for 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 only part of the embodiments of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0023] The core of the present application is to provide a packaging method for inter-host process communication of heterogeneous operating systems, and a flowchart of one specific embodiment of the method is shown in the figure. Figure 1 The method comprises: S101, obtaining, on a source host, a process communication request initiated by a source process.

[0024] The process communication request comprises a target process identifier and communication data to be sent. The source host is a computer device initiating the communication request. The target process identifier is used to uniquely determine a target process that needs to receive data. The communication data to be sent is various information, such as instructions, parameters, file fragments, etc., that the source process wants to deliver to the target process.

[0025] In a specific embodiment, 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 initiated by the source process, the fixed field of the request message is parsed, and the target process identifier and the communication data to be sent contained in the request are synchronously extracted. At the same time, the extracted information is preliminarily checked to ensure data integrity.

[0026] For example, assuming that the source host is an office computer running a Windows system, and a file synchronization process on it serves as the source process, which needs to deliver file update information to other hosts. The process communication monitoring module of the source host monitors the operation of the synchronization process in real time. When detecting that the file synchronization process initiates a communication request, the request message is immediately parsed, and the target process identifier CloudSync_Service_001 is extracted therefrom. The identifier corresponds to the cloud synchronization service process on the target host, and the communication data to be sent is extracted. These data contain the name of the updated file, the modification time, the data digest, and other information. Then, it is checked whether these information is missing or has format errors, and the data acquisition of this step is completed after confirming that there is no error.

[0027] S102, identifying the heterogeneity between a first operating system running on the source host and a second operating system running on a target host where the target process is located, and determining a corresponding encapsulation protocol according to the heterogeneity.

[0028] The encapsulation protocol comprises data conversion specifications and process identifier mapping rules, and is a rule set for adapting communication between heterogeneous operating systems. The heterogeneity refers to the differences in type, data format, process identifier rule, etc. between the operating systems running on the source host and the target host. The data conversion specification is used to define the format conversion standard of communication data between different operating systems, to ensure that the data can be correctly identified between heterogeneous systems. The process identifier mapping rule is used to establish the corresponding relationship of process identifiers under different operating systems, to realize accurate positioning of cross-system processes.

[0029] Optionally, as shown in Figure 2 The step S102 can specifically comprise the following steps: S1021, obtaining first operating system type information of the source host.

[0030] In the embodiments of the present application, the type identification information of the operating system is read by calling the system information interface of the source host operating system, and the identification information can directly represent the specific type of the operating system.

[0031] For example, assuming that the source host is a computer for file management in an office scenario, the system type identification is "Windows10_64bit" by calling the "Win32_OperatingSystem" interface of the Windows system, and thus the first operating system type information is determined to be the Windows 10 64-bit operating system. The above example is only an example of the present application, and in actual application, the system configuration file can also be read according to the requirements, and the present application does not limit this.

[0032] S1022, network location information of the target host is parsed from the target process identification.

[0033] In this step, the network location information is information for locating the specific location of the target host in the network, and usually contains IP address, port number and the like, which can realize accurate addressing of the target host.

[0034] Specifically, the target process identification is stored in the combination format of "network location information-process exclusive identification", and the network location information part is split from the target process identification according to the preset separator by string splitting technology. The splitting and parsing can be realized by the following core code: # Target process identification parsing def parse_target_process_id(target_process_id, separator='-'): # Split the identification according to the preset separator parts = target_process_id.split(separator, 1)# Only split once to avoid process exclusive identification containing separator if len(parts) == 2: return parts[0]# Return the network location information part else: raise ValueError("Target process identification format error") The above code realizes the parsing function of the target process identifier: by defining a parsing function, receiving the target process identifier and the preset delimiter as input parameters, and using a single segmentation strategy to split the target process identifier string, the possible interference of the delimiter in the process-specific identifier on the parsing result can be avoided. When two parts of content are obtained after splitting, the network location information of the first half is output. If the splitting result does not conform to the preset format, an exception is thrown to prompt that the identifier format is incorrect, thereby ensuring the accuracy and reliability of the parsing process.

[0035] In actual application, continuing the application scenario of the preceding office file management, it is assumed that the obtained target process identifier is “192.168.1.105:8080-CloudSync_Service_001” and the preset delimiter is “-”. The target process identifier is split by string segmentation technology to obtain the first half “192.168.1.105:8080”, wherein 192.168.1.105 is the IP address of the target host, 8080 is the communication port number, and the two together constitute the network location information of the target host. The above example is only an example of the present application, and other combination formats and delimiters can also be used in actual application, which is not limited in the present application.

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

[0037] Among them, the configuration library is a structured database established in advance, which is specially used to store the mapping relationship between host network location information and corresponding operating system type information, and can support quick retrieval of corresponding operating system type according to network location information.

[0038] In a specific embodiment, the target host network location information parsed is used as a retrieval keyword to query the configuration library using a precise matching retrieval algorithm. The configuration library stores a plurality of “network location information-operating system type” mapping entries, and the entries in the library are compared with the retrieval keyword one by one during retrieval. When a completely matched network location information entry is found, the operating system type information corresponding to the 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] The step S1025 can specifically include the following processes: accessing the configuration library, the configuration library containing a plurality of mapping entries, each mapping entry being composed of a key-value pair, the key part storing an operating system heterogeneous combination pair, and the value part storing an encapsulation protocol identifier; taking the operating system heterogeneous combination pair as an input key, traversing the key part in the configuration library in an item-by-item comparison manner to find a mapping entry completely consistent with the input key; when locating the matched mapping entry in the configuration library, extracting the corresponding encapsulation protocol identifier from the value part in the mapping entry; querying the additional protocol detail library according to the encapsulation protocol identifier to obtain complete encapsulation protocol content associated with the encapsulation protocol identifier, the complete encapsulation protocol content including data conversion specifications and process identification mapping rules.

[0046] The mapping entry is a basic data unit stored in the configuration library and is composed of a key-value pair, the key part being used for storing an operating system heterogeneous combination pair, and the value part being used for storing an encapsulation protocol identifier. The encapsulation protocol identifier is coding information used for uniquely identifying a certain encapsulation protocol, and the corresponding complete encapsulation protocol can be quickly located through the identifier. The protocol detail library is a database specially storing complete encapsulation protocol content, each encapsulation protocol being associated with a unique encapsulation protocol identifier and including corresponding data conversion specifications and process identification mapping rules.

[0047] Specifically, first, the configuration library containing a plurality of mapping entries composed of key-value pairs is accessed. The operating system heterogeneous combination pair composed of S1024 is taken as an input key, the key part in the configuration library is traversed in an item-by-item comparison manner to find a mapping entry completely consistent with the input key, and the core implementation logic is as follows: # Configuration library retrieval matching def find_matching_protocol(config_lib, os_heterogeneous_pair): # Traverse the configuration library key-value pair for pair, proto_id in config_lib.items(): if pair == os_heterogeneous_pair: return proto_id# Return the matching encapsulation protocol identifier return None# No match returns empty The above code realizes the retrieval matching function of the configuration library: by defining a retrieval function, receiving the configuration library and the operating system heterogeneous combination pair to be retrieved as input parameters, wherein the configuration library is stored in a dictionary structure, the key is the operating system heterogeneous combination pair, and the value is the corresponding encapsulation protocol identifier. By iterating through the key-value pairs in the configuration library, item-by-item matching is performed, and when a key that is completely consistent with the input heterogeneous combination pair is found, the corresponding encapsulation protocol identifier is output. If no matching item is found, an empty value is returned, ensuring the simplicity and efficiency of the retrieval logic. Subsequently, the extracted encapsulation protocol identifier is used as a retrieval keyword to query the additional protocol detail library to obtain the complete encapsulation protocol content associated with the identifier.

[0048] In another specific embodiment, to improve retrieval efficiency, an index structure of the key part can be established in the configuration library, and the operating system heterogeneous combination pair is associated with the index address. During retrieval, the input key corresponding index address is first located through the index structure, and then the corresponding mapping entry is directly obtained according to the index address. The process of extracting the encapsulation protocol identifier and querying the protocol detail library is consistent with the previous embodiment.

[0049] In actual application, continuing the office file management scenario described above, the operating system heterogeneous combination pair is known as "Windows 10 64bit-Ubuntu 22.04". The configuration library is accessed, and part of the mapping entries contained in the configuration library are as follows: Windows 10 64bit-Ubuntu 22.04-Protocal_003, Windows 10 64bit-macOS Ventura-Protocal_005, Linux CentOS 7-Ubuntu 22.04-Protocal_008. The "Windows 10 64bit-Ubuntu 22.04" is used as the input key to compare the key part in the library item by item, and after the matching entry is found, the encapsulation protocol identifier in the value part is extracted as Protocal_003. Then the protocol detail library is queried, and the complete encapsulation protocol content corresponding to Protocal_003 in the library contains: the data conversion specification is "convert the UTF-16 encoded data of the Windows system to the UTF-8 encoded data of the Ubuntu system", and the process identifier mapping rule is "one-to-one mapping of the process ID of the Windows system and the process name of the Ubuntu system". The above example is only an example of the present application, and in actual application, the entry content of the configuration library and the protocol detail library can be set according to the actual heterogeneous system combination demand, which is not limited by the present application.

[0050] The application realizes automatic and accurate matching of encapsulation protocols by accurately obtaining the source end and target end operating system types, constructing a heterogeneous combination, and matching a dedicated encapsulation protocol, effectively solving the problem of insufficient flexibility in adapting heterogeneous systems with encapsulation protocols in the prior art. This technical combination can complete heterogeneous identification and protocol matching without human intervention, improving the efficiency of communication configuration between heterogeneous operating system hosts, while ensuring accurate adaptation of encapsulation protocols and heterogeneous system combinations.

[0051] S103, serializing the communication data according to the data conversion specification to generate serialized data, and encoding the target process identifier into a universal process identifier according to the process identifier mapping rule.

[0052] The serialization process includes network byte sequence conversion, data structure alignment adjustment, and checksum addition, which is a process of converting communication data to be transmitted between heterogeneous systems into a unified format, ensuring that the data can be correctly transmitted and parsed between different operating system hosts. The universal process identifier is a process identifier that meets the cross-system communication standard and can be recognized by different operating system hosts, used to implement uniform positioning of processes in a heterogeneous environment.

[0053] Optionally, step S103 can specifically include the following steps: S1031, traversing each multi-byte data field in the communication data, and adjusting the byte arrangement order of each data field according to the byte sequence rule defined in the data conversion specification.

[0054] In this step, multi-byte data fields refer to data units composed of two or more bytes, such as file size, modification timestamp, etc. The network byte sequence rule is a unified byte arrangement standard agreed upon in heterogeneous system communication, used to eliminate parsing deviations caused by byte sequence differences between different operating system hosts.

[0055] Specifically, first, traverse all multi-byte data fields in the communication data to identify the original byte sequence of each field; then, according to the network byte sequence rule defined in the data conversion specification, adjust the byte arrangement order of the fields whose original byte sequence does not conform to the rule, to obtain multi-byte data fields that conform to the unified standard.

[0056] Exemplarily, continuing the foregoing office document management scenario, it is assumed that the communication data contains a multi-byte data field of file size, whose original value is 0x12345678, the byte sequence is [0x12, 0x34, 0x56, 0x78], and the source host operating system adopts little-endian byte sequence. The network byte sequence rule defined in the data conversion specification is big-endian byte sequence. The original byte sequence of the field does not conform to the rule by traversing, and the byte sequence is adjusted to [0x78, 0x56, 0x34, 0x12] after adjustment, and the corresponding value is still 0x12345678 but the byte arrangement conforms to the unified standard.

[0057] S1032, according to the memory alignment rule defined in the data conversion specification, the number of padding bytes required between each data field is calculated, and a specified number of padding bytes are inserted at the corresponding position.

[0058] The memory alignment rule is a rule set for ensuring that data is correctly stored and read in the memory of different operating system hosts, which specifies the starting address offset requirement of different types of data fields in the memory. The padding byte is an invalid byte inserted between the data fields, which avoids data parsing errors caused by differences in memory alignment methods of different systems.

[0059] In the embodiment of the application, first, the memory alignment length corresponding to each data field is determined according to the memory alignment rule in the data conversion specification; then, the difference between the current starting address of each data field and the starting address conforming to the alignment rule is calculated, which 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 rule.

[0060] In actual application, continuing the foregoing scenario, it is assumed that the memory alignment rule defined in the data conversion specification is "alignment by 4 bytes", that is, the starting address of the data field needs to be an integer multiple of 4. The communication data after S1031 adjustment contains two continuous fields, the first field is the file name, the string type, the length is 3 bytes, the starting address is 0, and the second field is the file size, the 4-byte integer type. The number of padding bytes required for the second field is calculated: the end address of the first field is 2, the next integer multiple of 4 address is 4, the difference is 2, and therefore 2 padding bytes need to be inserted. After inserting 2 0x00 padding bytes between the file name field and the file size field, the starting address of the file size field becomes 4, which conforms to the memory alignment rule. The above example is only one example of the application, and the number of padding bytes can be calculated according to different memory alignment rules in actual application, which is not limited by the application.

[0061] S1033, performing a predetermined calculation process on the data block formed after the byte sequence adjustment and the padding byte insertion to generate a check value, and appending the check value to the end of the data block to form serialized data.

[0062] In this step, the check value is a data value obtained by a predetermined calculation process for verifying data integrity, which will change if the data is lost or tampered with during transmission. The serialized data is a unified format data block formed after byte sequence adjustment, memory alignment adjustment and check value appending, which can be directly used for network transmission between heterogeneous systems.

[0063] Specifically, first, the data block after the byte sequence adjustment of S1031 and the padding byte insertion of S1032 is obtained; then, a cyclic redundancy check algorithm is used as a predetermined calculation process to calculate the 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 algorithm is to first left shift the above data block by 16 bits, 16 being the order of the standard generator polynomial 0x8005, then take the modulus of the left shifted data block with the standard generator polynomial to get the modulus value, and finally XOR the left shifted data block with the modulus value. The operation result is the check value. The XOR operation is used to realize the logical judgment of binary bits, the left shift operation is used to shift the data bits as a whole, and the modulus operation is used to get the remainder of the division of the data block by the generator polynomial.

[0065] By way of example, continuing the office file management scenario, the data block after the byte sequence adjustment of S1031 and the padding byte insertion of S1032 is [0x46, 0x69, 0x6C, 0x65, 0x00, 0x00, 0x78, 0x56, 0x34, 0x12], of which 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. The cyclic redundancy check algorithm is used to calculate the check value. First, the data block is left shifted by 16 bits, then the modulus of the standard generator polynomial 0x8005 is taken to get the modulus value, and finally the left shifted data block is XORed with the modulus value to generate the check value 0x1A2B. The check value 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, taking the target process identifier as an index, searching and obtaining the universal 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 a specific carrier of a process identification mapping rule, and stores a correspondence relationship between a local process identification and a universal process identification under different operating systems, and can support fast query with the local process identification as an index, and realizes accurate mapping of the local identification and the universal identification.

[0068] In the embodiment of the application, first, a mapping table defined by a process identification mapping rule is determined, the mapping table containing a key-value pair of a local process identification corresponding to an operating system of a target host and a universal process identification; then, the target process identification obtained in S101 is taken as an index to search in the mapping table; when a matching key is found, the corresponding value is extracted, and the value is the universal process identification corresponding to the target process identification.

[0069] Exemplarily, continuing the preceding office file management scenario, the target process identification obtained in S101 is CloudSync_Service_001. The process identification mapping rule used in this step corresponds to a preset mapping table, and the mapping table is specially adapted to the mapping requirement of the local process identification and the universal process identification of the target host Ubuntu 22.04 operating system, and the specific content is shown in Table 1 as follows:

[0070] When searching, CloudSync_Service_001 is taken as an index to perform a matching query in the above mapping table, and after a corresponding key-value pair is found, the value part Universal_Sync_003 is extracted, and the value is the universal process identification that can be recognized across systems. The above example is only one example of the application, and the content of the key-value pair of the mapping table can be set according to the actual process configuration requirement in actual application, and the application does not limit this.

[0071] The technical combination of the application effectively solves the real problems of incompatible data transmission formats between heterogeneous operating system hosts, process identification intercommunication and data transmission errors. The technical combination realizes cross-system adaptation and integrity protection of communication data, and achieves unified identification of process identification, and breaks through the bottleneck of complicated format adaptation and poor reliability in traditional heterogeneous communication.

[0072] S104, combining the universal process identification and the serialized data into a transmission packet, and sending the transmission packet to the target host through a transmission control protocol network.

[0073] The transport packet is a standardized data unit for network transmission, including a header region and a payload region. The header region is used to store general process identification and operating system type information for quick analysis and positioning by the target host after receiving; the payload region is used to store serialized data, which is the core effective data of transmission. The transport control protocol network is a network environment that uses the transport control protocol for data transmission, has the characteristics of reliable transmission and sequential delivery, and can ensure that the transport packet is delivered to the target host completely and accurately.

[0074] Optionally, step S104 can specifically include the following steps: S1041, creating a memory buffer as a storage space for the transport packet.

[0075] In this step, the memory buffer is a continuous storage space opened in the source host memory, which is used to temporarily store the transport packet data to be combined, avoiding data storage disorder. The header region and the payload region are divided according to the structure requirements of the transport packet. The size and starting address of each region are preset fixed values, ensuring the standardization of data writing and reading.

[0076] Specifically, first, the total storage space size required by the header region and the payload region is calculated according to the preset transport packet structure parameters; then the memory allocation interface of the source host is called to open a continuous memory space of corresponding size as the memory buffer; finally, the memory buffer is divided into the header region and the payload region according to the preset division rule, 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: # Transport packet memory buffer creation and division def create_transport_buffer(header_size=64, payload_size=None): # Calculate the total buffer size (header fixed at 64 bytes, payload size determined by serialized data) total_size = header_size + payload_size if payload_size else header_size + 1024# Default payload buffer size is 1024 bytes # Open the memory buffer buffer = bytearray(total_size) # Divide the header region and the payload region (header starting address 0, payload starting address is 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 above code defines a creation function, receives preset header region size and payload region size as parameters, calculates the total buffer size, then allocates a corresponding byte array as a buffer, and divides the two regions according to the rule that the start address of the header region is 0 and the start address of the payload region is the header size. Finally, the complete buffer and the two partitions are returned to provide a structured storage space for subsequent data writing.

[0077] For example, continuing the office file management scenario, the preset transmission packet header region size is 64 bytes, and the serialized data size generated by S103 is 12 bytes, so the payload region size needs to be at least 12 bytes. By calling the above function, the total buffer size is calculated to be 64+12=76 bytes. After allocating a 76-byte memory buffer, the first 64 bytes are divided into the header region with a start address of 0-63, and the last 12 bytes are divided into the payload region with a start address of 64-75.

[0078] S1042, write the universal process identifier into the predetermined process identifier field in the header region.

[0079] The predetermined process identifier field is a fixed byte segment in the header region that is specifically used to store the universal process identifier, and the start offset and the number of occupied bytes are both preset values, which ensures that the target host can accurately extract the universal process identifier.

[0080] In the embodiment of the application, the universal process identifier obtained by S1034 and the preset start offset and the number of occupied bytes of the predetermined process identifier field in the header region are first obtained. Then, the universal process identifier is converted into a byte format that meets the field requirements. Finally, the converted universal process identifier byte data is written into the predetermined process identifier field of the header region according to the preset start offset, completing the storage of the universal process identifier.

[0081] In actual application, continuing the scenario described above, the universal process identifier obtained by S1034 is Universal_Sync_003, and its corresponding byte format is 0x556E6976657273616C5F53796E635F303033. The start offset of the predetermined process identifier field in the header region is 8, and the number of occupied bytes is 18. The byte data of the above universal process identifier is written from the position of 0+8=8 of the start address of the header region, occupying 18 bytes of space continuously, completing the writing of the universal process identifier.

[0082] S1043, write the operating system type information of the target host into a predetermined system type field in the header region.

[0083] The predetermined system type field is a fixed byte segment in the header region specially used for storing the operating system type information of the target host, and the starting offset and the occupied byte number are also preset values, which are used for the target host to quickly identify the corresponding parsing rule of the operating system.

[0084] Specifically, first, the operating system type information obtained in S1023 and the preset starting offset and the occupied byte number of the predetermined system type field in the header region are obtained; the operating system type information is converted into a byte format meeting the field requirement; then, the converted byte data is written into the predetermined system type field of the header region according to the preset starting offset. Since the field and the predetermined process identification field in S1042 are both located in the header region, and the preset offsets are different, no data writing conflict occurs.

[0085] Exemplarily, continuing the foregoing scenario, the operating system type information of the target host obtained in S1023 is Ubuntu22.04, and the corresponding byte format is 0x5562756E74752032322E3034. The preset starting offset of the predetermined system type field in the header region is 32, and the occupied byte number is 12. The byte data of the operating system type information is written from the position of the starting address 0+32=32 of the header region, and occupies 12 byte spaces continuously. At this time, in the header region, bytes 8-25 are the general process identification, and bytes 32-43 are the operating system type information, and the fields do not interfere with each other.

[0086] S1044, copy the serialized data completely to the payload region.

[0087] In the embodiment of the application, first, the serialized data generated in S1033 and the starting address of the payload region divided in S1041 are obtained; then, a data copy interface is called to copy the serialized data in byte order to the payload region completely, the starting address of the copy is the preset starting address of the payload region, and the copy length is consistent with the byte length of the serialized data, so that the serialized data is stored in the payload region completely and without loss.

[0088] In another specific embodiment, if the size of the serialized data exceeds the preset initial size of the payload region, the memory reallocation interface can be called to expand the payload region space first, and then the data is copied, so as to avoid data overflow.

[0089] Exemplarily, continuing the foregoing scenario, the serialized data generated by S1033 is [0x46, 0x69, 0x6C, 0x65, 0x00, 0x00, 0x78, 0x56, 0x34, 0x12, 0x1A, 0x2B], a total of 12 bytes. The start address of the payload region divided by S1041 is 64, and the data copying interface is called to copy the above-mentioned 12 bytes of serialized data in sequence and completely from address 64 to the payload region. After completion, the 64-75 bytes stored in the payload region are the complete serialized data.

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

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

[0092] Specifically, first, the complete memory buffer created is obtained, including all data of the header region and the payload region, and the network location information of the target host; then the network transmission interface of the source host is called, the data content of the memory buffer is taken as the transmission data, and the network location information of the target host is taken as the transmission destination parameter to pass into the interface; after receiving the parameters, the network transmission interface encapsulates the data into a transmission control protocol data packet and sends it to the target host through the transmission control protocol network, completing the entire transmission packet sending process.

[0093] Exemplarily, continuing the foregoing scenario, the memory buffer created by S1041 contains 64 bytes of header data and 12 bytes of payload data, a total of 76 bytes of data content; the network location information of the target host is 192.168.1.105:8080. The network transmission interface of the source host is called, and 76 bytes of buffer data and the network location information of the target host are passed in. The interface encapsulates the data into a transmission control protocol data packet and sends it to the 8080 port of 192.168.1.105 through the office network.

[0094] The present application effectively solves the real problems of data transmission format confusion, core information loss and poor transmission reliability in heterogeneous system communication through the technical combination of structured transmission packet construction, accurate partition writing and reliable protocol transmission. The technical combination realizes the standardized encapsulation and ordered storage of transmission data, and relies on the transmission control protocol to guarantee the complete delivery of data, breaking through the bottleneck of non-standard transmission packet construction and data error in traditional heterogeneous communication.

[0095] S105, parsing a header region of the transport package to extract the universal process identifier and operating system type information on the target host, and decoding the universal process identifier into a local process identifier of the target process under the second operating system based on the process identifier mapping rule.

[0096] Wherein, decoding is the process of converting the universal process identifier universally applicable across systems into a local process identifier recognizable by the second operating system of the target host, and the core is to realize the reverse conversion of the identifier by relying on the corresponding relationship established by the process identifier mapping rule. The local process identifier is the identification information used to uniquely identify the target process in the second operating system.

[0097] Optionally, step S105 can specifically include the following steps: S1051, reading data from the header region of the received transport package according to a predetermined offset and length, and extracting the universal process identifier and operating system type information, respectively.

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

[0099] Specifically, first, the transport package is received on the target host, and the starting address of the header region of the transport package is located; then, according to the predetermined offset and length agreed in advance, the storage positions of the universal process identifier field and the operating system type information field in the header region are located respectively; finally, data of a specified length is read from the corresponding positions to complete the extraction of the universal process identifier and the operating system type information.

[0100] Illustratively, continuing the previous office document management scenario, after the target host receives the transport package, it determines that the starting address of the header region is 0. The header is configured in advance as follows: the universal process identifier field offset is 8, and the length is 18; the operating system type information field offset is 32, and the length is 12. According to the configuration calculation, the starting address of the universal process identifier field is 0+8=8, 8-25 bytes of data are read, a total of 18 bytes, and after decoding, Universal_Sync_003 is obtained; the starting address of the operating system type information field is 0+32=32, 32-43 bytes of data are read, a total of 12 bytes, and after decoding, Ubuntu 22.04 is obtained.

[0101] S1052, querying the reverse mapping relationship table stored on the target host with the universal process identifier as an index, the reverse mapping relationship table being defined by the process identifier mapping rule.

[0102] The reverse mapping relationship table is a specific carrier of the process identifier mapping rule on the target host, and stores the correspondence between the universal process identifier and the local process identifier of the second operating system. The reverse mapping relationship table is specially used for conversion and query of the universal process identifier to the local process identifier.

[0103] In the embodiment of the application, the universal process identifier extracted in S1051 is acquired first, and a reverse mapping relationship table defined by the process identifier mapping rule on the target host is determined; then the universal process identifier is used as an index to perform matching query in the reverse mapping relationship table, and the table item corresponding to the universal process identifier is located.

[0104] By way of example, continuing the office document management scenario described above, the universal process identifier extracted in S1051 is Universal_Sync_003, and the reverse mapping relationship table stored on the target host is defined by the process identifier mapping rule and is adapted to the Ubuntu 22.04 operating system. First, the universal process identifier is acquired to determine the corresponding reverse mapping relationship table on the target host; then Universal_Sync_003 is used as an index to perform line-by-line matching query in the reverse mapping relationship table, and the table item in which the universal process identifier column is consistent with the index is searched.

[0105] S1053, acquiring, from the reverse mapping relationship table, a local process identifier corresponding to the universal process identifier uniquely and effective in the second operating system.

[0106] Specifically, after the reverse mapping relationship table item matching the universal process identifier is located in S1052, the identification information corresponding to the universal process identifier uniquely in the table item is extracted, and the identification information is the local process identifier effective in the second operating system, and the decoding of the universal process identifier to the local process identifier is completed.

[0107] By way of example, continuing the scenario described above, the universal process identifier extracted in S1051 is Universal_Sync_003. The reverse mapping relationship table stored on the target host is defined by the process identifier mapping rule and is specially adapted to the Ubuntu 22.04 operating system, and the specific content is shown in Table 2 as follows:

[0108] The second operating system local process identifier CloudSync_Service_001 in the table item is extracted after locating the corresponding table item in the reverse mapping relationship table indexed by Universal_Sync_003. The identifier is the local process identifier that can be recognized in the Ubuntu 22.04 operating system and is used to locate the target cloud synchronization service process. The above example is only an example of the present application, and the content of the table item of the reverse mapping relationship table can be set according to the actual process configuration requirements, which is not limited in the present application.

[0109] The technical combination of the present application realizes accurate extraction of header information by pre-setting an offset and identification conversion by a reverse mapping table, effectively solving the practical problems that the target host cannot recognize the universal process identifier and cannot accurately locate the target process in heterogeneous system communication. The technical combination realizes efficient and accurate decoding of universal identifier to local identifier, ensures the intercommunication and adaptation of process identifiers in a heterogeneous environment, and breaks through the bottleneck of cumbersome identification conversion and inaccurate positioning in traditional heterogeneous communication.

[0110] S106, performing deserialization processing on the payload area of the transmission packet to reconstruct the serialized data into original communication data, and delivering the original communication data to a target process specified by the local process identifier.

[0111] The deserialization processing includes local byte sequence restoration, data structure reorganization and checksum verification, which is the inverse process of serialization processing, and is used to restore the serialized data to the original communication data that can be directly processed by the target host. The target memory space is a continuous space specially used to store the original communication data after reconstruction in the target host memory. The pointer or handle is identification information used to point to the target memory space, which can quickly locate and access the original communication data by the target process.

[0112] Optionally, step S106 can specifically include the following steps: S1061, separating the data block and the additional checksum from the payload area of the transmission packet.

[0113] In this step, the data block refers to the core data part after byte sequence adjustment and padding byte insertion, without the addition of the checksum, which is the basis for reconstructing the original communication data. The separation is a process of separating the data block and the checksum from the complete data in the payload area according to the addition rule of the checksum during serialization, which ensures that the subsequent checksum and verification can be accurately performed.

[0114] Specifically, first, the complete data content of the transmission packet payload area is determined; then, according to the agreed checksum length and additional rules during serialization, the checksum is added at the end of the data block, and the split position of the data block and the checksum is calculated; finally, the payload area data is split into two parts from the split position, the first half is the data block, and the second half is the additional checksum. The core implementation logic is as follows: # Payload area data separation def separate_data_and_checksum(payload_data, checksum_length=2): # The checksum is added at the end of the data block, and the split position is the length of the payload data minus the length of the checksum split_pos = len(payload_data) - checksum_length if split_pos<= 0: raise ValueError("Payload area data format error") data_block = payload_data[:split_pos] checksum = payload_data[split_pos:] return data_block, checksum The above code defines a separation function, receives the complete data of the payload area and the preset checksum length as input parameters, calculates the split position, and then splits the data into a data block and a checksum and returns it. If the split position is not reasonable, an exception is thrown to ensure the accuracy of the separation process.

[0115] For example, continuing the previous office file management scenario, the complete data of the transmission packet payload area is [0x46, 0x69, 0x6C, 0x65, 0x00, 0x00, 0x78, 0x56, 0x34, 0x12, 0x1A, 0x2B], a total of 12 bytes. The checksum length is agreed to be 2 bytes during serialization, and is added at the end of the data block. The split position is calculated as 12-2=10. The payload data is split from this position to obtain a data block of the first 10 bytes [0x46, 0x69, 0x6C, 0x65, 0x00, 0x00, 0x78, 0x56, 0x34, 0x12] and a checksum of the last 2 bytes [0x1A, 0x2B].

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

[0117] Specifically, first, the separated data block is acquired S1061; then, the same predetermined calculation process as in the serialization process S1033, i.e., the cyclic redundancy check algorithm, is performed to calculate the new calculation check value from the data block; finally, the new calculation check value is compared with the separated check value at the byte level to determine whether they are consistent, thereby verifying whether the data block is complete and has not been tampered with in the transmission process.

[0118] By way of example, continuing the foregoing scenario, the separated data block S1061 is [0x46, 0x69, 0x6C, 0x65, 0x00, 0x00, 0x78, 0x56, 0x34, 0x12]. The same cyclic redundancy check algorithm as in the serialization process is performed to calculate the new check value, the data block is first shifted left by 16 bits, then the modulus is obtained by taking the modulus of the standard generator polynomial 0x8005, and finally the left-shifted data block is XORed with the modulus to obtain the new calculation check value [0x1A, 0x2B]. The new calculation check value is compared with the separated check value [0x1A, 0x2B], and the two bytes are completely consistent, indicating that the data block is complete and has not been tampered with in the transmission process.

[0119] S1063, in the case of consistent comparison, a target memory space is allocated for the reconstructed original communication data, and the data block is traversed.

[0120] The size of the target memory space needs to be determined according to the estimated size of the original communication data to ensure that the reconstructed original communication data can be completely accommodated, avoiding data storage overflow. Traversal refers to scanning the data block byte by byte or field by field to prepare for subsequent byte sequence restoration and data structure reorganization.

[0121] In the embodiments of the present application, first, under the premise of consistent comparison S1062, the storage space required by the original communication data is estimated according to 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 open 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 S1061 field by field, and the starting position and length of each data field are recorded.

[0122] Exemplarily, continuing the previous scenario, after the comparison in S1062 is consistent, the structural features 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, a file name and a 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, and the starting address is 0x10000000. Then the data block is traversed, and the file name field starting position 0, length 4, padding byte starting position 4, length 2, and file size field starting position 6, length 4 are recorded.

[0123] S1064, for each multi-byte data field in the data block, perform byte order adjustment opposite to that during serialization to restore the native byte order of the second operating system.

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

[0125] Specifically, first, based on the traversal result of S1063, all multi-byte data fields are filtered out from the data block; then the native byte order type of the second operating system and the byte order adjustment rule during serialization are determined; finally, for each multi-byte data field, the byte order adjustment opposite to that during serialization is performed to restore it to a multi-byte data field conforming to the native byte order.

[0126] Exemplarily, continuing the previous scenario, the second operating system is Ubuntu 22.04, and its native 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, and its content in the data block is [0x78, 0x56, 0x34, 0x12], which has been adjusted to network byte order during serialization. Perform byte order adjustment opposite to that during serialization to reverse the byte order of the field to get [0x12, 0x34, 0x56, 0x78], and restore it to the file size field data conforming to the native byte order of Ubuntu 22.04.

[0127] S1065, copy each data field after byte order restoration to the target memory space in sequence according to the original data structure layout, skip 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 structure layout of the original communication data, i.e., the arrangement order of the data fields, is determined; finally, the restored data fields are copied into the target memory space according to the layout, and all padding bytes traversed in the copying process are skipped, so that the original data structure without redundant padding bytes is stored in the target memory space, and the reconstruction of the original communication data is completed.

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

[0130] S1066, a pointer or handle pointing to the target memory space is passed to the target process represented by the local process identifier.

[0131] The passing of the pointer or handle is implemented through the inter-process communication interface provided by the target host operating system, so as to ensure 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 found and 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, and the data delivery is completed.

[0133] Exemplarily, continuing the foregoing scenario, the target memory space pointer allocated by S1063 is 0x10000000, and the local process identifier obtained by S1053 is CloudSync_Service_001, and the corresponding target process is 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 the process. After the process receives the pointer, the original communication data in the 0x10000000-0x10000007 address segment can be accessed through the pointer, and the delivery of the office file synchronization data is completed.

[0134] The technical combination of guaranteeing integrity through data verification, reversing byte sequence to adapt to the local system, accurately recombining data structure, and accurately delivering process, effectively solves the practical problems that serialized data is difficult to restore to original data, data delivery is not accurate, and transmitted data is easy to tamper in heterogeneous system communication. The technical combination realizes accurate reconstruction and safe delivery of serialized data to original communication data, and breaks through the bottleneck of poor deserialization adaptability and no data reliability guarantee in traditional heterogeneous communication.

[0135] Figure 3 A specific implementation structure diagram of a packaging system for inter-process communication between heterogeneous operating system hosts provided by an embodiment of the present application is shown in Figure 3 The system can include: An acquisition module 31 is configured to acquire, on a source host, a process communication request sent by a source process, the process communication request including a target process identifier and communication data to be sent. A determination module 32 is configured to identify the heterogeneity between a first operating system running on the source host and a second operating system running on a target host where the target process is located, and determine a corresponding packaging protocol according to the heterogeneity, the packaging protocol including data conversion specifications and process identifier mapping rules. An encoding module 33 is configured to serialize the communication data according to the data conversion specifications to generate serialized data, and encode the target process identifier into a universal process identifier according to the process identifier mapping rules. A sending module 34 is configured to combine the universal process identifier and the serialized data into a transmission packet, and send the transmission packet to the target host through a transmission control protocol network. A decoding module 35 is configured to parse the header area of the transmission packet to extract the universal process identifier and operating system type information on the target host, and decode the universal process identifier into a local process identifier under the second operating system that specifies the target process based on the process identifier mapping rules. A reconstruction module 36 is configured to deserialize the payload region of the transport packet to reconstruct the serialized data into original communication data, and deliver the original communication data to a target process specified by the local process identifier.

[0136] The encapsulation system for inter-process communication between hosts of heterogeneous operating systems according to the embodiments of the present application is used to implement the encapsulation method for inter-process communication between hosts of heterogeneous operating systems as described above, and the specific embodiments of the encapsulation system for inter-process communication between hosts of heterogeneous operating systems can be found in the foregoing embodiments of the encapsulation method for inter-process communication between hosts of heterogeneous operating systems. The specific embodiments can be described with reference to the corresponding embodiments, and will not be described here again.

[0137] The present application also provides an electronic device, comprising: a memory configured to store a computer program; and a processor configured to implement the steps of the encapsulation method for inter-process communication between hosts of heterogeneous operating systems when executing the computer program.

[0138] The present application also provides a computer readable storage medium having a computer program stored thereon, wherein the computer program is configured to implement the steps of the encapsulation method for inter-process communication between hosts of heterogeneous operating systems when executed by a processor.

[0139] In an exemplary embodiment, the computer readable storage medium can include, but is not limited to, a U disk, a read-only memory, a random access memory, a mobile hard disk, a magnetic disk or an optical disk, and various media capable of storing computer programs.

[0140] The embodiments of the present application also provide a computer program product, wherein the computer program product comprises a computer program, and the computer program is configured to implement the steps of the encapsulation method for inter-process communication between hosts of heterogeneous operating systems when executed by a processor.

[0141] Those skilled in the art can further appreciate that the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be realized in electronic hardware, computer software or a combination of both. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of the examples have been described in general terms in the foregoing description. Whether the functions are performed 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 implementation should not be considered beyond the scope of the present application.

[0142] The above describes in detail the encapsulation method and system for inter-process communication between heterogeneous operating system hosts provided by the present application. The principles and implementation modes of the present application are described by using specific examples in this paper, and the above description of the examples is only used to help understand the method of the present application and its core idea. It should be pointed out that, for those skilled in the art, some improvements and modifications can be made to the present application without departing from the principles of the present application, and these improvements and modifications also fall within the protection scope of the present 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.

2. The method according to claim 1, characterized in that, 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.

3. 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.

4. 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.

5. The method according to claim 1, characterized in that, 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.

6. 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.

7. The method according to claim 2, 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.

8. A packaging system for inter-process communication between heterogeneous operating system hosts, 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.

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

10. 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 7.

Images