A heterogeneous transmission interconnection system

Abstract

The present invention provides a heterogeneous transmission interconnection system, which modifies the transmission service interface implementation to achieve conversion between different transmission services, thereby supporting the interconnection between business data using different transmission services. Since only the transmission interface implementation logic is modified and additional processing is added, and the transmission service interface is not modified, it is transparent to the business system. The present invention realizes the heterogeneous system business interconnection and interoperability requirements required by many business systems. The present invention is transparent to the business layer, and the business does not need to make changes. At the same time, the business does not need to care about which transmission services are integrated in the bottom layer, nor does it need to encode for different transmission interfaces. The business system only needs to care about whether the data is sent out and whether it is received, and can focus more on the implementation of business logic, greatly reducing the workload of the business system.

Description

Technical Field

[0001] The present invention relates to the field of data transmission, and in particular to a heterogeneous transmission interconnection system. Background Art

[0002] With the rapid development of the internet, data has become increasingly important. One of the core aspects of business operations is the efficient flow of data. Cross-domain data transmission and sharing plays a vital role in a company's daily operations. Whether it's design drawings, videos, music, or datasets, the fast and secure transmission of this data is crucial for innovation, collaboration, and decision-making support. However, as data flows across different business systems, the following problems arise:

[0003] (1) The transmission methods used in different fields are different. Each field has its own independent transmission service and has developed a transmission method, transmission protocol and transmission interface that can adapt to the characteristics of this field. At the same time, the services within the domain are adapted to the domain transmission service and realize data transmission through the transmission service of this field. When cross-domain services need to communicate with each other, they cannot communicate directly because they use different transmission services. In this case, a transmission conversion service must be developed to convert the transmission protocols of the two fields to realize the intercommunication of business data.

[0004] (2) When businesses in multiple fields are interconnected, different transmission and conversion services are often developed at the same time, resulting in duplicate development and a waste of manpower and material resources.

[0005] (3) When businesses transmit data, they have many common requirements, including data reliability. Many businesses have these requirements, and different transmission services implement them independently. Therefore, if a transmission system can uniformly implement these capabilities, it can avoid having different transmission services implement these functions repeatedly. Summary of the Invention

[0006] Purpose of the invention: The technical problem to be solved by the present invention is to address the deficiencies of the existing technology and provide a heterogeneous transmission interconnection system that supports the interconnection of different transmission service business systems, including a central management subsystem, a domain management subsystem, an address mapping subsystem, a transmission interface subsystem, and a transmission scheduling subsystem.

[0007] The system divides the business system into different areas. Each area is called a sub-domain. A sub-domain represents a relatively independent system, usually an organization or unit. Each sub-domain independently manages the network facilities within the domain, including business IP address allocation and transmission services.

[0008] The central management subsystem is used to centrally manage all sub-domains. A sub-domain is represented by the structure area, and each sub-domain contains the attribute area_id, which represents the domain ID and is unique in the entire network. The central management subsystem is unique in the entire network. All sub-domains must initially register with the central management sub-system and obtain the registered domain ID information after successful registration. The central management sub-system monitors the transmission status of all sub-domains to ensure the validity of the sub-domain transmission service. Sub-domains can subscribe to the central management sub-system, and the central management sub-system will send the specified domain information to the requesting domain based on the subscription status, enabling business data intercommunication between sub-domains.

[0009] Each sub-domain is equipped with a sub-domain management subsystem, which is used to manage the business information of the domain and other sub-domains issued by the central management subsystem, including all business information of the domain and the address of the transmission scheduling subsystem of the domain. At the same time, the sub-domain management subsystem will subscribe to the central management subsystem to subscribe to the target sub-domain information. The sub-domain management subsystem can receive other sub-domain information issued by the central management subsystem, including business information and the address of the transmission scheduling subsystem.

[0010] An address mapping subsystem is set up in each sub-domain. The address mapping subsystem is used to implement the mapping function between the actual address and the virtual address of the service. Through address mapping, the information intercommunication capability between services using different transmission services is realized;

[0011] A transmission interface subsystem is set up in each sub-domain. The transmission interface subsystem is used to improve the underlying transmission service function: if the interoperable services use the same transmission service, the transmission service function processing flow remains unchanged; otherwise, the data interoperability between heterogeneous transmission services is completed through the transmission scheduling subsystem;

[0012] A transmission scheduling subsystem is set up in each sub-domain, which is responsible for the cross-domain transmission of business data; each sub-domain has one and only one transmission scheduling subsystem; the transmission scheduling subsystem receives data sent by the transmission interface subsystem within the domain and sends the data to the transmission scheduling subsystem of the destination domain; the transmission scheduling subsystem receives data sent by the transmission scheduling subsystems of other sub-domains and forwards the data to the transmission interface subsystem.

[0013] The central management subsystem includes a domain information registration management module, a domain status monitoring module and a domain information synchronization module;

[0014] The domain information registration management module is used to register, query, delete, update and cancel domain information; the domain manager registers the domain information to the central management subsystem, and the central management subsystem uses the long integer global_area_id to generate a domain global id, uses the data structure area to represent the domain information, and uses the structure app to represent the business information within the domain. The long integer global_area_id is initially 0; for all domains, a domain information queue map is established<area_id,area> all_areas, where all_areas is a hash table. The key in the hash table all_areas is the domain ID and the value is the domain information. all_areas stores the information of all domains registered in the central management subsystem. Each domain contains the domain ID, service information, and transmission scheduling subsystem address information. When a new domain is added to the central management subsystem, an area object is implemented for the domain and then added to all_areas. When a domain is deregistered from the central management subsystem, the area object corresponding to the domain is deleted from all_areas.

[0015] The registration of the domain information includes the following steps:

[0016] Step a1: The domain management subsystem generates a unique ID for all services in the domain, and then sends the service ID information, service description information, and transmission scheduling subsystem IP address information to the central management subsystem;

[0017] Step a2: The central management subsystem constructs an area object, increments global_area_id by 1 to generate a sub-area id, populates apps with the service id and description information, fills trans_schedule_ip with the transmission scheduling subsystem IP address information, fills heart_send_time and heart_recv_time with the current time, and fills config_version with 1. The area object is added to all_areas.

[0018] Step a3: Notify the domain management subsystem of the successful registration;

[0019] Deleting the domain information includes the following steps:

[0020] Step b1: The central management subsystem deletes the corresponding area object from all_areas;

[0021] Step b2: Notify the domain information synchronization module of the central management subsystem of the domain information change;

[0022] The updating of the domain information includes the following steps:

[0023] Step c1: The domain management subsystem sends the area_id information, service id information, and transmission scheduling subsystem IP address information to the central management subsystem;

[0024] Step c2: The central management subsystem finds the area object corresponding to the sub-domain from all_areas according to area_id, updates the information, and then increases config_version by 1;

[0025] Step c3: Notify the domain information synchronization module of the domain information changes;

[0026] The domain status monitoring module regularly sends heartbeat request messages to the transmission scheduling subsystems of all domains and waits for responses; if no heartbeat response is received from the domain transmission scheduling subsystem within a certain period of time (usually 3 seconds, the domain failure time is configurable), the domain is determined to be failed;

[0027] The domain status monitoring module specifically performs the following steps:

[0028] Step d1: The central management subsystem traverses all_areas. For each area object, the central transmission scheduling subsystem sends a heartbeat message to each IP address of the transmission scheduling subsystem in the sub-domain, and updates the heart_send_time of the area object to the current time.

[0029] Step d2, receiving a heartbeat message: upon receiving the heartbeat message, update the heart_recv_time of the area object to the current time;

[0030] Step d3: compare heart_send_time and heart_recv_time. If the heartbeat message cannot be received within the specified time, set the status attribute of the domain to -1.

[0031] Step d4: If the central management subsystem receives the heartbeat message, the status attribute of the area object corresponding to the sub-domain is set to 1;

[0032] Step d1: If the status attribute of the area object changes, notify the area information synchronization module of the change in the area information;

[0033] The domain can subscribe to other domain information from the domain information synchronization module. The domain information synchronization module will send the subscribed domain information to the subscriber. When the domain business information changes, the domain information synchronization module will actively push the domain update information to the subscriber.<area_id,area*[]> sub_areas stores subscription information, hash table map<area_id,area*[]> The key of sub_areas is the subscribed area ID, and the value is the sub-area information of all subscribers who subscribe to this sub-area information;

[0034] The sub-domain can subscribe to other sub-domain information from the central management subsystem, specifically including the following steps:

[0035] Step e1: The central management subsystem receives a domain subscription request sent by a domain, where the domain subscription request includes the domain ID for which subscription is requested.

[0036] Step e2: The central management subsystem finds the corresponding area object in all_areas for the domain ID sent in the request;

[0037] In step e3, the central management subsystem searches for the key in sub_areas. If it is not found, it inserts a data item into sub_areas. The key is the ID of the subscribed sub-domain, and the value is the newly created area array. The area object found in all_areas is placed into the array. If the area array is found, the area object is added to the area array.

[0038] Step e4: Reply to the domain management subsystem that the domain subscription is successful, and send the subscribed domain information to the subscriber;

[0039] When synchronizing domain information, the domain information synchronization module will send the subscription domain information to the corresponding domain after receiving the notification sent by the domain information registration management. The modification and deletion of domain information and the change of domain status will trigger the domain information synchronization module to send domain update information to the domain subscribers. Domain update information includes domain update and deletion. For domain deletion, the central management subsystem will send the ID of the deleted domain to the subscriber; for domain update, the central management subsystem will send the area_id, apps, trans_schedule_ip, status, and config_version information to the subscriber.

[0040] The area object contains the following properties:

[0041] area_id: integer. Different sub-domains have different area_ids. area_id uniquely identifies a sub-domain.

[0042] app[]apps: all business information in the domain;

[0043] char*trans_schedule_ip: transmission scheduling subsystem ip;

[0044] status: transmission service status of the transmission scheduling subsystem;

[0045] send_time: heartbeat message sending timestamp;

[0046] recv_time: heartbeat message response timestamp;

[0047] config_version: is an integer, the configuration version number, starting from 1. Every time the business information of a domain changes, the version number increases by 1.

[0048] All business information app[]apps in the domain contains the following attributes:

[0049] int app_id: is an integer. An app_id uniquely identifies a service within a domain.

[0050] string app_desc: business description information.

[0051] The domain management subsystem provides the following functions:

[0052] Domain-specific service registration management: Use the structure local_app to represent domain-specific service information, and use the long integer global_app_id to generate the domain-specific service ID; the long integer global_app_id is initially 0; establish a queue map<int,app_local> local_apps; local_apps is a hash table, the key of the hash table local_apps is the business id, and the value is the local business information;

[0053] Synchronize domain information: use the queue sub_areas <area> Stores subscribed domain information; when the relevant domain information changes, it will receive the domain information pushed from the central management subsystem;

[0054] The domain-specific service registration management specifically includes the following steps:

[0055] Step f1, add 1 to global_app_id to obtain the business id;

[0056] Step f2: construct a local_app object based on the service ID, service IP address, and service description information, and add the local_app object to local_apps;

[0057] Step f3: Send the domain update information to the central management subsystem.

[0058] The local_app service information in the sub-domain includes the following attributes:

[0059] app_id: is an integer. An app_id uniquely identifies a service within a domain.

[0060] char*app_ip: the IP address of the server where the business is located;

[0061] void*trans_addr: the business address used by the transmission service. Different transmission services use different business addresses.

[0062] string app_desc: business description information.

[0063] The address mapping subsystem provides the following functions:

[0064] Address mapping management: Create an array virtual_address[]map_address to store the mapping relationship between virtual addresses and real addresses; when adding address mapping, implement the virtual_address structure according to the mapped address and add the virtual_address structure to map_address; when deleting address mapping, delete the information from map_address.

[0065] The structure virtual_address in the array virtual_address[]map_address contains the following properties:

[0066] void*v_addr: virtual address, corresponding to the transport service address of this domain, which can be used by the transport service of this domain;

[0067] area_id: the domain ID to which the business belongs;

[0068] app_id: business ID.

[0069] The transmission interface subsystem includes a transmission sending module and a transmission receiving module;

[0070] The transmission sending module is used to send data sent to the heterogeneous transmission service to the transmission scheduling subsystem, and the data includes a compare function and a send_hook function;

[0071] The compare function is used to compare the destination address passed in by the source business with the virtual address of the address mapping subsystem. If they are the same, it returns 0; otherwise, it returns other values ​​1.

[0072] The send_hook function is used to determine whether the destination service address is another domain virtual address. If so, it sends the data to the transmission scheduling subsystem and returns 0, otherwise it returns 1. Then the send function needs to be modified. At the beginning of the send function, the send_hook function is called first, and the destination service address and service data transmission are passed to the send_hook function. When the function returns 0, it indicates that the send function can be completed. When the function returns other values, it indicates that the transmission service used by the destination service is the same as that of the current service, and the send function can continue processing.

[0073] The transmission receiving module includes a heterogeneous transmission data receiving process and a callback function recv_hook. The data receiving process receives service data sent from the transmission scheduling subsystem and calls the callback function recv_hook after receiving the service data. When recv_hook is called, it indicates that data sent by the service using heterogeneous transmission has been received. The heterogeneous transmission receiving process and the receiving function of the transmission service exist at the same time. The call of recv_hook indicates that data sent by the heterogeneous transmission service has been received, and the receiving function of the transmission service indicates that data sent by the same transmission service has been received.

[0074] The heterogeneous transmission data receiving process receives data sent from the transmission scheduling subsystem, including business data, source business virtual address, and destination business address; the heterogeneous transmission data receiving process calls the recv_hook callback function with the business data, source business virtual address, and destination business address as parameters.

[0075] The function signature of the send_hook function is: int send_hook(void*src_addr,void*dst_addr,char*data,int length,bool is_file); where * represents a pointer in C language, the parameter src_addr represents the source service address, dst_addr represents the virtual destination service address, data represents the service data, when is_file is true, data represents the file path to be sent, when is_file is false, data represents the service data, and length represents the length of the service data; the function returns 0 to indicate that the destination service uses heterogeneous transmission, and the transmission service sending function can end directly; the function returns 1 to indicate that the transmission service used by the destination service is the same as the current service, and the sending function of the underlying transmission service can continue to process;

[0076] The workflow of the send_hook function includes the following steps:

[0077] Step g1: Access the domain management subsystem, traverse local_apps, and for each local_app, call the compare function to compare src_addr with the trans_addr in the local_app. If they are equal, it means that the local_app structure corresponding to the sending service has been found. Otherwise, continue traversing. If not found, discard the message and the service is not registered. Otherwise, obtain the service ID of this service.

[0078] Step g2: Access the address mapping subsystem, traverse map_address, and for each virtual_address object, call the compare function, passing in the dst_addr parameter and the addr parameter of the virtual_address object. Check the comparison result. If it returns 0, it means that the corresponding service has been found, which involves heterogeneous transmission and needs to be processed by the transmission scheduling subsystem. The traversal ends and proceeds to the next step; otherwise, continue to traverse the next element of map_address; if no service matching the dst_addr parameter is found after traversing all elements of map_address, the send_hook function returns 1, and the transmission underlying function can continue processing.

[0079] Step g3: Send the area_id and app_id of the matching virtual_address object, along with the service id and service data, to the transmission scheduling subsystem;

[0080] The function pointer signature of the compare function is typedef int(*compare)(void*param1,void*param2). The compare function is an address comparison function used to compare whether two business addresses are the same address, where param1 represents a business address and param2 represents another business address to be compared. The compare function compares param1 and param2, and returns 0 if param1 and param2 are the same, otherwise it returns 1.

[0081] The function signature of recv_hook is void recv_hook(void*src_addr,void*dst_addr,char*data,int length,bool is_file), where the parameter src_addr represents the source business virtual address, dst_addr represents the destination business address, and data represents the business data. When is_file is true, data represents the receiving file path. When is_file is false, data represents the received business data, and length represents the length of the business data.

[0082] The transmission scheduling subsystem provides the following functions:

[0083] Receive data sent from other sub-domains, find the destination internal business according to the destination address, and send the data to the transmission interface subsystem where the business server is located.

[0084] Internally, it receives cross-domain transmission data sent by the transmission interface subsystem of the server where the business is located in the sub-domain, finds the transmission scheduling service in the destination domain, and sends the data to the destination transmission scheduling service;

[0085] The transmission scheduling subsystem includes a cross-domain transmission module, an internal transmission forwarding module and an external transmission distribution module;

[0086] The workflow of the transmission internal forwarding module includes:

[0087] Step h1: The cross-domain transmission module receives a cross-domain transmission message sent by the peer end, and parses the message to obtain the source sub-domain ID, source service ID, destination sub-domain ID, destination service ID, and service data;

[0088] Step h2: Check whether the destination domain ID is the local domain ID. If not, discard the message.

[0089] Step h3: Access the domain management subsystem and check whether the destination service ID exists in local_apps. If not, discard the message; otherwise, obtain local_app information, including the server IP and trans_addr of the destination service.

[0090] Step h4, access the address mapping subsystem, traverse map_address, and for each virtual_address object, match the source domain id and source service id in the message with the area_id and app_id of the virtual_address object. If no matching object is found, discard the message; otherwise, obtain the v_addr attribute of the matching object.

[0091] Step h5, send the service data, trans_addr and v_addr together to the data interface subsystem of the destination IP;

[0092] The workflow of the transmission external distribution module includes:

[0093] Step i1: The transmission scheduling subsystem receives the service data to be forwarded, as well as the source service ID, destination service ID, and destination domain ID, sent by the service transmission service calling the send_hook function.

[0094] Step i2: search for the corresponding sub-area in sub_areas according to the destination domain ID. If no discarded message is found, obtain the destination sub-area transmission scheduling subsystem IP address.

[0095] Step i3: Construct a cross-domain transmission message, including the local domain ID, source service ID, destination service ID, destination domain ID, and service data;

[0096] Step i4: call the cross-domain transmission module to send the cross-domain transmission message to the transmission scheduling subsystem of the destination sub-domain.

[0097] The beneficial effects of the present invention are as follows: the heterogeneous transmission interconnection system of the present invention supports interoperability between services using different transmission services by virtualizing service addresses. Because the underlying transmission interface is not modified, the heterogeneous protocol conversion process is transparent to the service, and the service can achieve interoperability with other services using different transmission services without making any changes. BRIEF DESCRIPTION OF THE DRAWINGS

[0098] The present invention will be further described below in conjunction with the accompanying drawings and specific embodiments, and the above and / or other advantages of the present invention will become more apparent.

[0099] Figure 1 It is a schematic diagram of the overall structure of the heterogeneous transmission interconnection system.

[0100] Figure 2 This is a structural diagram of the central management subsystem.

[0101] Figure 3 This is a structural diagram of the domain management subsystem.

[0102] Figure 4 This is a structural diagram of the address mapping subsystem.

[0103] Figure 5 It is a flow chart of the sending module of the transmission interface subsystem.

[0104] Figure 6 It is a flow chart of the receiving module of the transmission interface subsystem.

[0105] Figure 7 It is a structural diagram of the transmission scheduling subsystem.

[0106] Figure 8 It is a flow chart of the external distribution module of the transmission scheduling subsystem.

[0107] Figure 9 It is a flow chart of the internal forwarding module of the transmission scheduling subsystem. DETAILED DESCRIPTION

[0108] like Figure 1 As shown, this embodiment provides a heterogeneous transmission interconnection system. To implement this system, the following subsystems need to be implemented:

[0109] The central management subsystem supports centralized management of all domains. It consists of three parts: the domain information registration and management module, the domain status monitoring module, and the domain information synchronization module. The domain information registration and management module is responsible for registering, updating, and deregistering domain information. The domain status monitoring module is responsible for monitoring the network status of all domains and ensuring the validity of domain communication links through a heartbeat mechanism. The domain information synchronization module synchronizes domain information through a domain subscription and distribution mechanism.

[0110] A domain management subsystem is built in each domain to manage the business information of that domain. Simultaneously, the domain management subsystem subscribes to the central management subsystem for the target domain information. This allows the domain management subsystem to receive domain information issued by the central management subsystem.

[0111] An address mapping subsystem is built in each sub-domain to implement the mapping function between the actual address and virtual address of the services in this sub-domain. Through address mapping, information intercommunication between services using different transmission services is achieved.

[0112] A transmission interface subsystem is constructed in each subdomain, including a transmission sending module and a transmission receiving module. The transmission sending module includes a compare function and a send_hook function. The compare function is used to compare the destination address passed in by the source service with the virtual address of the address mapping subsystem. The send_hook function is used to send data sent to the heterogeneous transmission service to the transmission scheduling subsystem. The transmission receiving module includes a heterogeneous transmission data receiving process and a callback function recv_hook. The data receiving process receives service data sent from the transmission scheduling subsystem. After receiving the service data, the callback function recv_hook is called to complete the reception of the heterogeneous transmission service data.

[0113] Build a transmission scheduling subsystem to handle cross-domain transmission of service data. Each sub-domain has only one transmission scheduling subsystem. The transmission scheduling subsystem receives data from the interface encapsulation subsystem within the domain and sends it to the transmission scheduling subsystem in the destination domain. It also receives data from transmission scheduling subsystems in other sub-domains and forwards it to the destination service.

[0114] like Figure 2 As shown in the figure, to build the central management subsystem, three modules need to be implemented: domain information registration management module, domain subscription distribution module and domain status monitoring module.

[0115] The domain information registration management module maintains the global global_area_id number and hash table map<area_id,area> all_areas. global_area_id assigns a domain id to the newly generated domain. The key of all_areas is the domain id, and the value is the domain information. All_areas stores all registered domain information. The domain management subsystem of each domain reports the business information within the domain to the domain information registration management module. The reported information includes domain registration information, domain modification information, and domain deletion information. Upon receiving domain registration information, the domain registration information module adds 1 to global_area_id as the domain id of the new domain, then constructs an area object, adds the area object to all_areas, and 3. Notifies the domain management subsystem of successful registration. Upon receiving domain modification information, the domain information registration management module finds the domain area object from all_areas, updates the object content, adds 1 to the config_version attribute of the area object, and then notifies the domain subscription and distribution module that there is a domain attribute update. When receiving the domain deletion information, the domain information registration management module deletes the area object from all_areas and then notifies the domain subscription distribution module that the domain has been deleted.

[0116] The domain-specific subscription distribution module maintains a global map<area_id,area*[]> The sub_areas object, the key is the subscribed domain id, and the value is the domain set of all subscribers who subscribe to this domain information. The domain subscription distribution module includes the domain subscription process and the domain information notification process. Upon receiving the domain subscription request sent by the domain management subsystem, the domain subscription distribution module updates the subscription information in sub_areas, and then sends the subscribed domain information to the subscriber. Upon receiving the domain information change sent by the domain information registration management module, the changed domain id is used as the key to find the subscriber area array from sub_areas. For domain updates, the updated domain information is sent to each subscriber. For domain deletions, the domain deletion information is sent to each subscriber, and then the object is deleted from sub_areas.

[0117] The domain status monitoring module includes a heartbeat sending and receiving process and a status judgment process. The heartbeat sending and receiving process periodically traverses all_areas, sending heartbeat messages to each domain and updating the area object's heart_send_time. After receiving the heartbeat message response sent by the domain, the area object's heart_recv_time is updated. The status judgment process traverses all_areas and compares the heart_send_time and heart_recv_time of each area object. If the heart_recv_time is less than the heart_send_time and the difference reaches the threshold, the area object's status attribute is set to -1; otherwise, it is set to 1. When the area object's status attribute changes, the domain subscription and distribution module is notified.

[0118] like Figure 3 As shown in the figure, to build a domain management subsystem, two modules need to be implemented: the local domain business management module and the domain subscription module.

[0119] The domain business management module maintains the global global_app_id and hash table map<app_id,local_app> local_apps. global_app_id generates a unique business identifier for each business. local_apps stores local business information. When a new local business is added, the business management module of this domain first adds 1 to the global_app_id to obtain the business id, and then constructs the local_app object based on the business id, business IP address and other business information, adds the object to local_apps, and finally notifies the central management subsystem of the domain business information change. Business modifications are limited to business description information and business IP. The business management module of this domain modifies the corresponding local_app object in local_apps, and then notifies the central management subsystem of the domain business information change. For business deletion, the business management module of this domain deletes the corresponding local_app object in local_apps, and then notifies the central management subsystem of the domain business information change.

[0120] The domain subscription module maintains the global sub_areas <area> An object that stores all subscribed domain information. When subscribing to a domain, the domain subscription module constructs an empty area object, sends a domain subscription request to the central management subsystem, fills the area object with the received response information, and adds the area object to sub_areas. When canceling a domain subscription, a domain unsubscription request is sent to the central management subsystem, and then the area object is deleted from sub_areas. The domain subscription module receives the domain update information sent by the central management subsystem. Upon receipt, it compares the config_version in the domain update information with the config_version of the corresponding area object in sub_areas. If the two are the same, no update is required. Otherwise, the received response information is updated to the area object.

[0121] like Figure 4As shown, the address mapping subsystem is constructed, gradually exposing the global virtual_address[]map_address array to store all address mappings. Each virtual_address represents the virtual address corresponding to the local domain of another sub-domain service. The void*addr in virtual_address corresponds to a locally allocated virtual address that can be recognized by the local service, the area_id corresponds to the sub-domain ID of the external service, and the app_id corresponds to the service ID of the external service. When adding an address mapping, the virtual_address structure is implemented according to the mapped address and added to the map_address. When deleting an address mapping, the information is deleted from the map_address.

[0122] To build a transmission interface subsystem, it is necessary to implement the transmission sending module and the transmission receiving module.

[0123] like Figure 5 As shown, the transmission sending module is implemented. First, the underlying transmission service needs to implement the compare function and the send_hook function. The compare function is used to compare whether the addresses are the same. The send_hook function traverses the map_address and compares the input destination business virtual address and the address in the map_address array one by one through the compare function. If a match is found, it means that the destination business belongs to other sub-domains, so the area_id and app_id of the matching virtual_address object are sent to the transmission scheduling subsystem together with the business id and business data, and then 0 is returned, otherwise 1 is returned. Then the sending function of the transmission service is modified. When the business calls the sending function provided by the transmission service, the sending function packages the destination address into void*addr, and calls the send_hook function together with the source address information and business data as parameters. If 0 is returned, it means that the sending process is over, and the sending function returns directly, otherwise the sending function continues to process.

[0124] like Figure 6 As shown, to implement the transmission and reception module, it is necessary to additionally implement the heterogeneous transmission and reception process. For the reception of homogeneous business data, there is no change from before. For the reception of heterogeneous business data, it is necessary to receive data from the transmission scheduling subsystem, including business data, source business virtual address and destination business address, and then call the recv_hook function. The recv_hook function is implemented by the transmission service and returns the business data to the business. The recv_hook function and the transmission service's own receiving function exist at the same time. The recv_hook callback function represents the receipt of data sent using the heterogeneous transmission service business, and the transmission service's own receiving function represents the receipt of data sent using the homogeneous transmission service.

[0125] like Figure 7 As shown in the figure, building a transmission scheduling subsystem requires the implementation of an external distribution module, an internal forwarding module, and a cross-domain transmission module. Cross-domain transmission enables the transmission of data between different sub-domains. The external distribution module receives data sent by the intra-domain transmission interface subsystem, including the source service ID, destination area ID, destination service ID, and service data, and sends the data to the cross-domain transmission module. The cross-domain transmission module sends the data to the destination domain transmission scheduling subsystem. The internal forwarding module receives data sent by other sub-domain transmission scheduling subsystems, including the source service ID, source area ID, destination service ID, destination area ID, and service data. The internal forwarding module forwards the data to the transmission interface subsystem of the server where the destination service is located.

[0126] like Figure 8 As shown, the external distribution module receives service data to be forwarded from the send_hook function of the local domain transmission interface subsystem, including the service data, source service ID, destination service ID, and destination domain ID. The external distribution module searches for the destination domain transmission scheduling subsystem address based on the destination domain. If the address is not found, the message is invalid and discarded. Otherwise, it constructs a cross-domain transmission message, including the local domain ID, source service ID, destination service ID, destination domain ID, and service data, and sends the data to the cross-domain transmission module for transmission.

[0127] like Figure 9 As shown, the internal forwarding module receives a cross-domain transmission message from the peer end and parses it to determine the source domain ID, source service ID, destination domain ID, destination service ID, and service data. It first checks whether the message's destination domain is the local domain. If not, the invalid message is discarded. It then checks whether the local domain contains the destination service ID. If not, the invalid message is discarded. The source service virtual address and destination service address are then determined based on the source and destination service IDs. Finally, the service data, along with the two addresses, is sent to the transmission interface subsystem.

[0128] This embodiment is illustrated with a specific example. Suppose there are three enterprises, namely Enterprise 1, Enterprise 2 and Enterprise 3. Each enterprise has its own independent business system. Each enterprise uses its own transmission software and has its own independent transmission interface and transmission protocol. Now the business systems of the three enterprises need to communicate with each other. According to the current practice, each enterprise needs to communicate with the other enterprise on the communication protocol, modify its own transmission software and business software, and finally achieve intercommunication. When intercommunication with a new business system is required, it is necessary to modify its own business system multiple times. Through the system of this embodiment, a global public central management subsystem is established, and each enterprise corresponds to a sub-domain and registers with the central management subsystem. Each enterprise sub-domain implements the transmission interface subsystem and makes adaptive modifications in its own transmission interface to achieve intercommunication with each other. When a new business system is added later, only a new sub-domain is added. The existing business system does not need to make any changes to achieve intercommunication with the newly added business system.

[0129] The present invention provides a heterogeneous transmission interconnection system. Numerous methods and approaches exist for implementing this technical solution. The foregoing merely represents a preferred embodiment of the present invention. It should be noted that those skilled in the art may make various improvements and modifications without departing from the principles of the present invention, and such improvements and modifications are also within the scope of protection of the present invention. Any components not specified in this embodiment may be implemented using existing technologies.

Claims

1. A heterogeneous transmission interconnection system, characterized in that: It includes central management subsystem, domain management subsystem, address mapping subsystem, transmission interface subsystem and transmission scheduling subsystem; The heterogeneous transmission interconnection system divides the business system into ranges, each range is called a sub-domain, and a sub-domain represents a relatively independent system; each sub-domain independently manages the network facilities within the domain, including business IP address allocation and transmission services; The central management subsystem is used to centrally manage all sub-domains. A sub-domain is represented by the structure area, and each sub-domain contains the attribute area_id, which represents the domain ID and is unique in the entire network. The central management subsystem is unique in the entire network. All sub-domains must initially register with the central management sub-system and obtain the registered domain ID information after successful registration. The central management sub-system monitors the transmission status of all sub-domains to ensure the validity of the sub-domain transmission service. Sub-domains can subscribe to the central management sub-system, and the central management sub-system will send the specified domain information to the requesting domain based on the subscription status, enabling business data intercommunication between sub-domains. Each sub-domain is equipped with a sub-domain management subsystem, which is used to manage the business information of the domain and other sub-domains issued by the central management subsystem, including all business information of the domain and the address of the transmission scheduling subsystem of the domain. At the same time, the sub-domain management subsystem will subscribe to the central management subsystem to subscribe to the target sub-domain information. The sub-domain management subsystem can receive other sub-domain information issued by the central management subsystem, including business information and the address of the transmission scheduling subsystem. An address mapping subsystem is set up in each sub-domain. The address mapping subsystem is used to implement the mapping function between the actual address and the virtual address of the service. Through address mapping, the information intercommunication capability between services using different transmission services is realized; A transmission interface subsystem is set up in each sub-domain. The transmission interface subsystem is used to improve the underlying transmission service function: if the interoperable services use the same transmission service, the transmission service function processing flow remains unchanged; otherwise, the data interoperability between heterogeneous transmission services is completed through the transmission scheduling subsystem; A transmission scheduling subsystem is set up in each sub-domain, which is responsible for the cross-domain transmission of business data; each sub-domain has one and only one transmission scheduling subsystem; the transmission scheduling subsystem receives data sent by the transmission interface subsystem within the domain and sends the data to the transmission scheduling subsystem of the destination domain; the transmission scheduling subsystem receives data sent by the transmission scheduling subsystems of other sub-domains and forwards the data to the transmission interface subsystem.

2. The system according to claim 1, wherein: The central management subsystem includes a domain information registration management module, a domain status monitoring module and a domain information synchronization module; The domain information registration management module is used to register, query, delete, update and cancel domain information; the domain manager registers the domain information to the central management subsystem, and the central management subsystem uses the long integer global_area_id to generate a domain global id, uses the data structure area to represent the domain information, and uses the structure app to represent the business information within the domain. The long integer global_area_id is initially 0; for all domains, a domain information queue map is established<area_id,area> all_areas, where all_areas is a hash table. The key in the hash table all_areas is the domain ID and the value is the domain information. all_areas stores the information of all domains registered in the central management subsystem. Each domain contains the domain ID, service information, and transmission scheduling subsystem address information. When a new domain is added to the central management subsystem, an area object is implemented for the domain and then added to all_areas. When a domain is deregistered from the central management subsystem, the area object corresponding to the domain is deleted from all_areas. The registration of the domain information includes the following steps: Step a1: The domain management subsystem generates a unique ID for all services in the domain, and then sends the service ID information, service description information, and transmission scheduling subsystem IP address information to the central management subsystem; Step a2: The central management subsystem constructs an area object, increments global_area_id by 1 to generate a sub-area id, populates apps with the service id and description information, fills trans_schedule_ip with the transmission scheduling subsystem IP address information, fills heart_send_time and heart_recv_time with the current time, and fills config_version with 1. The area object is added to all_areas. Step a3: Notify the domain management subsystem of the successful registration; Deleting the domain information includes the following steps: Step b1: The central management subsystem deletes the corresponding area object from all_areas; Step b2: Notify the domain information synchronization module of the central management subsystem of the domain information change; The updating of the domain information includes the following steps: Step c1: The domain management subsystem sends the area_id information, service id information, and transmission scheduling subsystem IP address information to the central management subsystem; Step c2: The central management subsystem finds the area object corresponding to the sub-domain from all_areas according to area_id, updates the information, and then increases config_version by 1; Step c3: Notify the domain information synchronization module of the domain information changes; The sub-domain status monitoring module regularly sends heartbeat request messages to the transmission scheduling subsystems of all sub-domains and waits for responses; if no heartbeat response is received from the sub-domain transmission scheduling subsystem within a certain period of time, the sub-domain is determined to be invalid; The domain status monitoring module specifically performs the following steps: Step d1: The central management subsystem traverses all_areas. For each area object, the central transmission scheduling subsystem sends a heartbeat message to each IP address of the transmission scheduling subsystem in the sub-domain, and updates the heart_send_time of the area object to the current time. Step d2, receiving a heartbeat message: upon receiving the heartbeat message, update the heart_recv_time of the area object to the current time; Step d3: compare heart_send_time and heart_recv_time. If the heartbeat message cannot be received within the specified time, set the status attribute of the domain to -1. Step d4: If the central management subsystem receives the heartbeat message, the status attribute of the area object corresponding to the sub-domain is set to 1; Step d1: If the status attribute of the area object changes, notify the area information synchronization module of the change in the area information; The domain can subscribe to other domain information from the domain information synchronization module. The domain information synchronization module will send the subscribed domain information to the subscriber. When the domain business information changes, the domain information synchronization module will actively push the domain update information to the subscriber.<area_id,area*[]> sub_areas stores subscription information, hash table map<area_id,area*[]> The key of sub_areas is the subscribed area ID, and the value is the sub-area information of all subscribers who subscribe to this sub-area information; The sub-domain can subscribe to other sub-domain information from the central management subsystem, specifically including the following steps: Step e1: The central management subsystem receives a domain subscription request sent by a domain, where the domain subscription request includes the domain ID for which subscription is requested. Step e2: The central management subsystem finds the corresponding area object in all_areas for the domain ID sent in the request; In step e3, the central management subsystem searches for the key in sub_areas. If it is not found, it inserts a data item into sub_areas. The key is the ID of the subscribed sub-domain, and the value is the newly created area array. The area object found in all_areas is placed into the array. If the area array is found, the area object is added to the area array. Step e4: Reply to the domain management subsystem that the domain subscription is successful, and send the subscribed domain information to the subscriber; When synchronizing domain information, the domain information synchronization module will send the subscription domain information to the corresponding domain after receiving the notification sent by the domain information registration management. The modification and deletion of domain information and the change of domain status will trigger the domain information synchronization module to send domain update information to the domain subscribers. Domain update information includes domain update and deletion. For domain deletion, the central management subsystem will send the ID of the deleted domain to the subscriber; for domain update, the central management subsystem will send the area_id, apps, trans_schedule_ip, status, and config_version information to the subscriber.

3. The system according to claim 2, characterized in that The area object contains the following properties: area_id: integer. Different sub-domains have different area_ids. area_id uniquely identifies a sub-domain. app[]apps: all business information in the domain; char*trans_schedule_ip: transmission scheduling subsystem ip; status: transmission service status of the transmission scheduling subsystem; send_time: heartbeat message sending timestamp; recv_time: heartbeat message response timestamp; config_version: is an integer, the configuration version number, starting from 1. Every time the business information of a domain changes, the version number increases by 1.

4. The system according to claim 3, characterized in that All business information app[]apps in the domain contains the following attributes: int app_id: is an integer. An app_id uniquely identifies a service within a domain. string app_desc: business description information.

5. The system according to claim 4, characterized in that The domain management subsystem provides the following functions: Domain-specific service registration management: Use the structure local_app to represent domain-specific service information, and use the long integer global_app_id to generate the domain-specific service ID; the long integer global_app_id is initially 0; establish a queue map<int,app_local> local_apps; local_apps is a hash table, the key of the hash table local_apps is the business id, and the value is the local business information; Synchronize domain information: use the queue sub_areas <area> Stores subscribed domain information; when the relevant domain information changes, it will receive the domain information pushed from the central management subsystem; The domain-specific service registration management specifically includes the following steps: Step f1, add 1 to global_app_id to obtain the business id; Step f2: construct a local_app object based on the service ID, service IP address, and service description information, and add the local_app object to local_apps; Step f3: Send the domain update information to the central management subsystem.

6. The system according to claim 5, characterized in that The local_app service information in the sub-domain includes the following attributes: app_id: is an integer. An app_id uniquely identifies a service within a domain. char*app_ip: the IP address of the server where the business is located; void*trans_addr: the business address used by the transmission service. Different transmission services use different business addresses. string app_desc: business description information.

7. The system according to claim 6, characterized in that The address mapping subsystem provides the following functions: Address mapping management: Create an array virtual_address[]map_address to store the mapping relationship between virtual addresses and real addresses; when adding address mapping, implement the virtual_address structure according to the mapped address and add the virtual_address structure to map_address; when deleting address mapping, delete the information from map_address.

8. The system according to claim 7, characterized in that The structure virtual_address in the array virtual_address[]map_address contains the following properties: void*v_addr: virtual address, corresponding to the transport service address of this domain, which can be used by the transport service of this domain; area_id: the domain ID to which the business belongs; app_id: business ID.

9. The system according to claim 8, characterized in that The transmission interface subsystem includes a transmission sending module and a transmission receiving module; The transmission sending module is used to send data sent to the heterogeneous transmission service to the transmission scheduling subsystem, and the data includes a compare function and a send_hook function; The compare function is used to compare the destination address passed in by the source business with the virtual address of the address mapping subsystem. If they are the same, it returns 0; otherwise, it returns other values ​​1. The send_hook function is used to determine whether the destination service address is another domain virtual address. If so, it sends the data to the transmission scheduling subsystem and returns 0, otherwise it returns 1. Then the send function needs to be modified. At the beginning of the send function, the send_hook function is called first, and the destination service address and service data transmission are passed to the send_hook function. When the function returns 0, it indicates that the send function can be completed. When the function returns other values, it indicates that the transmission service used by the destination service is the same as that of the current service, and the send function can continue processing. The transmission receiving module includes a heterogeneous transmission data receiving process and a callback function recv_hook. The data receiving process receives service data sent from the transmission scheduling subsystem and calls the callback function recv_hook after receiving the service data. When recv_hook is called, it indicates that data sent by the service using heterogeneous transmission has been received. The heterogeneous transmission receiving process and the receiving function of the transmission service exist at the same time. The call of recv_hook indicates that data sent by the heterogeneous transmission service has been received, and the receiving function of the transmission service indicates that data sent by the same transmission service has been received. The heterogeneous transmission data receiving process receives data sent from the transmission scheduling subsystem, including service data, source service virtual address, and destination service address; The heterogeneous transmission data receiving process calls the recv_hook callback function with the service data, source service virtual address, and destination service address as parameters.

10. The system according to claim 9, characterized in that The function signature of the send_hook function is: intsend_hook(void*src_addr,void*dst_addr,char*data,int length,bool is_file); where * represents a pointer in C language, the parameter src_addr represents the source service address, dst_addr represents the virtual destination service address, data represents the service data, when is_file is true, data represents the file path to be sent, when is_file is false, data represents the service data, and length represents the length of the service data; the function returns 0 to indicate that the destination service uses heterogeneous transmission, and the transmission service sending function can end directly; the function returns 1 to indicate that the transmission service used by the destination service is the same as the current service, and the sending function of the underlying transmission service can continue to process; The workflow of the send_hook function includes the following steps: Step g1: Access the domain management subsystem, traverse local_apps, and for each local_app, call the compare function to compare src_addr with the trans_addr in the local_app. If they are equal, it means that the local_app structure corresponding to the sending service has been found. Otherwise, continue traversing. If not found, discard the message and the service is not registered. Otherwise, obtain the service ID of this service. Step g2: Access the address mapping subsystem, traverse map_address, and for each virtual_address object, call the compare function, passing in the dst_addr parameter and the addr parameter of the virtual_address object. Check the comparison result. If it returns 0, it means that the corresponding service has been found, which involves heterogeneous transmission and needs to be processed by the transmission scheduling subsystem. The traversal ends and proceeds to the next step; otherwise, continue to traverse the next element of map_address; if no service matching the dst_addr parameter is found after traversing all elements of map_address, the send_hook function returns 1, and the transmission underlying function can continue processing. Step g3: Send the area_id and app_id of the matching virtual_address object, along with the service id and service data, to the transmission scheduling subsystem; The function pointer signature of the compare function is typedef int(*compare)(void*param1,void*param2). The compare function is an address comparison function used to compare whether two business addresses are the same address, where param1 represents a business address and param2 represents another business address to be compared. The compare function compares param1 and param2, and returns 0 if param1 and param2 are the same, otherwise it returns 1. The function signature of recv_hook is void recv_hook(void*src_addr,void*dst_addr,char*data,int length,bool is_file), where the parameter src_addr represents the source business virtual address, dst_addr represents the destination business address, and data represents the business data. When is_file is true, data represents the receiving file path. When is_file is false, data represents the received business data, and length represents the length of the business data. The transmission scheduling subsystem provides the following functions: Receive data sent from other sub-domains, find the destination internal business according to the destination address, and send the data to the transmission interface subsystem where the business server is located; Internally, it receives cross-domain transmission data sent by the transmission interface subsystem of the server where the business is located in the sub-domain, finds the transmission scheduling service in the destination domain, and sends the data to the destination transmission scheduling service; The transmission scheduling subsystem includes a cross-domain transmission module, an internal transmission forwarding module and an external transmission distribution module; The workflow of the transmission internal forwarding module includes: Step h1: The cross-domain transmission module receives a cross-domain transmission message sent by the peer end, and parses the message to obtain the source sub-domain ID, source service ID, destination sub-domain ID, destination service ID, and service data; Step h2: Check whether the destination domain ID is the local domain ID. If not, discard the message. Step h3: Access the domain management subsystem and check whether the destination service ID exists in local_apps. If not, discard the message; otherwise, obtain local_app information, including the server IP and trans_addr of the destination service. Step h4: Access the address mapping subsystem, traverse map_address, and for each virtual_address object, match the source domain ID and source service ID in the message with the area_id and app_id of the virtual_address object. If no matching object is found, discard the message; otherwise, obtain the v_addr attribute of the matching object. Step h5, send the service data, trans_addr and v_addr together to the data interface subsystem of the destination IP; The workflow of the transmission external distribution module includes: Step i1: The transmission scheduling subsystem receives the service data to be forwarded, as well as the source service ID, destination service ID, and destination domain ID, sent by the service transmission service calling the send_hook function. Step i2: search for the corresponding sub-area in sub_areas according to the destination domain ID. If no discarded message is found, obtain the destination sub-area transmission scheduling subsystem IP address. Step i3: Construct a cross-domain transmission message, including the local domain ID, source service ID, destination service ID, destination domain ID, and service data; Step i4: call the cross-domain transmission module to send the cross-domain transmission message to the transmission scheduling subsystem of the destination sub-domain.

Images