Heterogeneous transmission interconnection system

Abstract

The invention provides a heterogeneous transmission interconnection system, which modifies transmission service interface implementation and realizes conversion of different transmission services, thereby supporting interconnection and intercommunication among business data using different transmission services. Only transmission interface implementation logic is modified, additional processing is added, and a transmission service interface is not modified, so that the method is transparent to a service system. According to the invention, the business interconnection and intercommunication requirements of the heterogeneous system required by many business systems are met. According to the invention, the service layer is transparent, the service does not need to be changed, the service does not need to concern which transmission services are integrated at the bottom layer and does not need to encode different transmission interfaces, and a service system only needs to concern whether data are sent out and received, so that the realization of service logic can be more focused; and the workload of a service system is greatly reduced.

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 of enterprise operations is the efficient circulation of data. Cross-domain data transmission and sharing plays a vital role in the daily operation of enterprises. Whether it is design drawings, videos, music or data sets, the fast and secure transmission of these data is crucial for enterprise innovation, collaboration and decision support. However, with the circulation of data between business systems in different fields, the following problems have emerged:

[0003] (1) The transmission methods used in different fields are different. Each field has its own independent transmission service and has developed transmission methods, transmission protocols, and transmission interfaces that can adapt to the characteristics of this field. At the same time, the services within this field are adapted to the transmission service within the field and data transmission is achieved through the transmission service in this field. When cross-field 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 achieve business data intercommunication.

[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 resources.

[0005] (3) When data is transmitted between services, there are many common requirements, including data transmission reliability. Many services have such requirements, and different transmission services have implemented such requirements. Therefore, if there is a transmission system that 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 provide a heterogeneous transmission interconnection system to support 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 according to the scope. Each scope is called a sub-domain. A sub-domain represents a relatively independent system, usually an organization, unit, etc. 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; sub-domains are represented by the structure area, and each sub-domain contains the attribute area_id, which represents the sub-domain id, and area_id is unique in the entire network; the central management subsystem is unique in the entire network; all sub-domains must be registered with the central management subsystem at the beginning, and after successful registration, the registered sub-domain id information can be obtained; the central management subsystem will monitor the transmission status of all sub-domains to ensure that the sub-domain transmission service is valid; sub-domains can subscribe to the central management subsystem, and the central management subsystem will send the specified sub-domain information to the requesting sub-domain according to the subscription status, so that business data can be interoperable between sub-domains;

[0009] A sub-domain management subsystem is set in each sub-domain, and the sub-domain management subsystem 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 in each sub-domain, and the address mapping subsystem is used to realize 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 in each sub-domain, and the transmission interface subsystem is used to improve the underlying transmission service function: if the intercommunication services use the same transmission service, the transmission service function processing flow remains unchanged; otherwise, the data intercommunication between heterogeneous transmission services is completed through the transmission scheduling subsystem;

[0012] A transmission scheduling subsystem is set up in each sub-domain, and the transmission scheduling subsystem 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 sub-domain information registration management module, a sub-domain status monitoring module and a sub-domain information synchronization module;

[0014] The sub-domain information registration management module is used for registering, querying, deleting, updating and canceling sub-domain information; the sub-domain manager registers the sub-domain information to the central management subsystem, and the central management subsystem generates a sub-domain global id with the long integer global_area_id, represents the sub-domain information with the data structure area, and represents the service information in the sub-domain with the structure app. The long integer global_area_id is initially 0; for all sub-domains, a sub-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 all the domain information registered in the central management subsystem; each domain contains the domain id, business 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 the area object is 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 sub-domain management subsystem generates a unique ID for all services in the sub-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, adds 1 to global_area_id, generates a sub-domain id, fills 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, fills config_version with 1, and adds the area object to all_areas;

[0018] Step a3, notifying the domain management subsystem of 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, notifying the domain information synchronization module of the central management subsystem that the domain information has changed;

[0022] The updating of the domain information comprises 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, notifying the domain information synchronization module that the domain information has changed;

[0026] The sub-domain status monitoring module periodically sends a heartbeat request message to the transmission scheduling subsystem of all sub-domains and waits for a response; if no heartbeat response sent by the sub-domain transmission scheduling subsystem is received within a certain period of time (generally 3 seconds, the sub-domain failure time is configurable), the sub-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 sub-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, the area information synchronization module is notified of the change in the area information;

[0033] The sub-domain can subscribe to other sub-domain information from the sub-domain information synchronization module. The sub-domain information synchronization module will send the sub-domain information to the subscriber. When the sub-domain business information changes, the sub-domain information synchronization module will actively push the sub-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, which specifically includes 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 of the domain for which subscription is requested;

[0036] Step e2, the central management subsystem finds the corresponding area object in all_areas for the sub-domain ID sent by the request;

[0037] Step e3, the central management subsystem searches for the key in sub_areas. If it is not found, it inserts a piece of data into sub_areas. The key is the subscribed sub-domain ID, and the value is the newly created area array. It puts the area object found in all_areas into the array. If the area array is found, it adds the area object into the area array.

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

[0039] When synchronizing domain information, after receiving the notification sent by the domain information registration management, the domain information synchronization module will send the subscription domain information to the corresponding domain; 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 subscriber. The 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 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 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 in 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 the service information in the domain, 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 queue sub_areas <area> Store subscribed domain information; when the relevant domain information changes, it will receive the domain information pushed by 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 according to 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 server ip 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 attributes:

[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 service 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, the data is sent to the transmission scheduling subsystem and 0 is returned, otherwise 1 is returned. Then the sending function needs to be modified. At the beginning of the sending 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 means that the sending function can be terminated. When the function returns other values, it means that the transmission service used by the destination service is the same as that of the current service, and the sending function can continue to process.

[0073] The transmission receiving module includes a heterogeneous transmission data receiving process and a callback function recv_hook. The data receiving process receives the 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 the 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 the data sent by the heterogeneous transmission service has been received, and the receiving function of the transmission service indicates that the 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 using 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, 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 service data length; function return 0 indicates that the destination service uses heterogeneous transmission, and the transmission service sending function can end directly; function return 1 indicates 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 and trans_addr in local_app. If they are equal, it means that the local_app structure corresponding to the sending service is found, otherwise continue to traverse; 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, call the compare function for each virtual_address object, pass 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 is found, which involves heterogeneous transmission and needs to be processed by the transmission scheduling subsystem, the traversal ends, and enters 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, sending the area_id and app_id of the matched virtual_address object together 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 service virtual address, dst_addr represents the destination service address, data represents the service data, when is_file is true, data represents the receiving file path, when is_file is false, data represents the received service data, and length represents the service data length;

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

[0083] Receive data sent by 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 service is located in the sub-domain, finds the transmission scheduling service of 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 working process of the transmission internal forwarding module includes:

[0087] Step h1, the cross-domain transmission module receives the 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, 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 where the destination service is located;

[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 the corresponding sub-domain in sub_areas according to the destination domain ID, if no discarded message is found, otherwise obtain the destination sub-domain transmission scheduling subsystem IP;

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

[0096] Step i4, calling 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 interconnection and intercommunication between services using different transmission services by virtualizing the service address. Since the underlying transmission interface is not modified, the heterogeneous protocol conversion process is transparent to the service, and the service can achieve intercommunication with other services using different transmission services without making any changes. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0100] Figure 2 It is a schematic diagram of the structure of the central management subsystem.

[0101] Figure 3 It is a schematic diagram of the domain management subsystem structure.

[0102] Figure 4 It is a schematic diagram of the address mapping subsystem structure.

[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 schematic diagram of the transmission scheduling subsystem structure.

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

[0107] Fig. 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 the system, the following subsystems need to be implemented:

[0109] The central management subsystem supports unified and centralized management of all sub-domains. It includes three parts: sub-domain information registration management module, sub-domain status monitoring module, and sub-domain information synchronization module. The sub-domain information registration management module is used to register, update, and cancel sub-domain information. The sub-domain status monitoring module is responsible for monitoring the network status of all sub-domains and ensuring the validity of the sub-domain communication link through the heartbeat mechanism. The sub-domain information synchronization module realizes sub-domain information synchronization through the sub-domain subscription distribution mechanism.

[0110] A sub-domain management subsystem is built in each sub-domain to manage the business information 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. In this way, the sub-domain management subsystem can receive the sub-domain information issued by the central management subsystem.

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

[0112] A transmission interface subsystem is constructed in each sub-domain, 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, and the send_hook function is used to send the 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 the service data sent from the transmission scheduling subsystem, and calls the callback function recv_hook after receiving the service data to complete the reception of the heterogeneous transmission service data.

[0113] Construct a transmission scheduling subsystem to be responsible for the cross-domain transmission of business data. There is only one transmission scheduling subsystem in a sub-domain. On the one hand, the transmission scheduling subsystem receives data sent by the interface encapsulation subsystem in the domain and sends the data to the transmission scheduling subsystem in the destination domain. On the other hand, the transmission scheduling subsystem receives data sent by transmission scheduling subsystems in other sub-domains and forwards the data to the destination business.

[0114] like Figure 2 As shown, to build the central management subsystem, three modules need to be implemented, namely, the domain information registration management module, the domain subscription distribution module and the 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, and adds the area object to all_areas. 3. Notify 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 distribution module that there is a domain attribute update. When receiving the sub-domain deletion information, the sub-domain information registration management module deletes the area object from all_areas, and then notifies the sub-domain subscription distribution module that the sub-domain has been deleted.

[0116] The domain-specific subscription distribution module maintains a global map<area_id,area*[]> 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. When 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. When 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 deletion, 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, sends heartbeat messages to each domain, and updates the heart_send_time of the area object. After receiving the heartbeat message response sent by the domain, the heart_recv_time of the area object is updated. The status judgment process traverses all_areas, and for each area object, compares heart_send_time and heart_recv_time. If heart_recv_time is less than heart_send_time and the difference reaches the threshold, the status attribute of the area object is set to -1, otherwise it is set to 1. When the status attribute of the area object changes, the domain subscription distribution module is notified.

[0118] like Figure 3 As shown, 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, then constructs a 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 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, and the global virtual_address[]map_address array is gradually exposed to store all address mappings. Each virtual_address represents a 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, area_id corresponds to the sub-domain id to which the external service belongs, and app_id corresponds to the service id of the external service. When adding address mapping, the virtual_address structure is implemented according to the mapped address and added to map_address. When deleting address mapping, the information is deleted from map_address.

[0122] To build the 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 service 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 service 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 service id and service data, and then 0 is returned, otherwise 1 is returned. Then the sending function of the transmission service is modified. When the service 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 service 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 business.

[0125] like Figure 7 As shown, to build a transmission scheduling subsystem, it is necessary to implement an external distribution module, an internal forwarding module, and a cross-domain transmission module. Cross-domain transmission realizes the transmission of data in different sub-domains. The external distribution module receives data sent by the intra-domain transmission interface subsystem, including the source service id, the destination area id, the destination service id, and service data, and sends the data to the cross-domain transmission module, which 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, the source area id, the destination service id, the destination area id, and service data, and 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 the service data to be forwarded sent by the send_hook function of the local transmission interface subsystem, including 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 according to the destination domain. If it is not found, it means that the message is invalid and the message is discarded. Otherwise, a cross-domain transmission message is constructed, including the local domain ID, source service ID, destination service ID, destination domain ID, and service data, and the data is sent to the cross-domain transmission module to complete the data transmission.

[0127] like Fig. 9 As shown, the internal forwarding module receives the cross-domain transmission message sent by the opposite end, and parses the source domain ID, source service ID, destination domain ID, destination service ID, and service data. First, check whether the destination domain of the message is the current domain. If not, discard the invalid message. Then check whether the current domain contains the destination service ID. If not, discard the invalid message. Then, find the source service virtual address and the destination service address based on the source service ID and the destination service ID, and finally send the service data together with the two addresses to the transmission interface subsystem.

[0128] This embodiment is illustrated with a specific example. 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 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 about the communication protocol, modify its own transmission software and business software, and finally achieve intercommunication. When it is necessary to intercommunicate with a new business system, it is necessary to modify its own business system many 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, and 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. There are many methods and ways to implement the technical solution. The above is only a preferred implementation of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be considered as the protection scope of the present invention. All components not specified in this embodiment can be implemented by 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 system divides the business system according to the scope, each scope 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; sub-domains are represented by the structure area, and each sub-domain contains the attribute area_id, which represents the sub-domain id, and area_id is unique in the entire network; the central management subsystem is unique in the entire network; all sub-domains must be registered with the central management subsystem at the beginning, and after successful registration, the registered sub-domain id information can be obtained; the central management subsystem will monitor the transmission status of all sub-domains to ensure that the sub-domain transmission service is valid; sub-domains can subscribe to the central management subsystem, and the central management subsystem will send the specified sub-domain information to the requesting sub-domain according to the subscription status, so that business data can be interoperable between sub-domains; A sub-domain management subsystem is set in each sub-domain, and the sub-domain management subsystem 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 in each sub-domain, and the address mapping subsystem is used to realize 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 in each sub-domain, and the transmission interface subsystem is used to improve the underlying transmission service function: if the intercommunication services use the same transmission service, the transmission service function processing flow remains unchanged; otherwise, the data intercommunication between heterogeneous transmission services is completed through the transmission scheduling subsystem; A transmission scheduling subsystem is set up in each sub-domain, and the transmission scheduling subsystem 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, characterized in that The central management subsystem includes a sub-domain information registration management module, a sub-domain status monitoring module and a sub-domain information synchronization module; The sub-domain information registration management module is used for registering, querying, deleting, updating and canceling sub-domain information; the sub-domain manager registers the sub-domain information to the central management subsystem, and the central management subsystem generates a sub-domain global id with the long integer global_area_id, represents the sub-domain information with the data structure area, and represents the service information in the sub-domain with the structure app. The long integer global_area_id is initially 0; for all sub-domains, a sub-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 all the domain information registered in the central management subsystem; each domain contains the domain id, business 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 the area object is 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 sub-domain management subsystem generates a unique ID for all services in the sub-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, adds 1 to global_area_id, generates a sub-domain id, fills 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, fills config_version with 1, and adds the area object to all_areas; Step a3, notifying the domain management subsystem of 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, notifying the domain information synchronization module of the central management subsystem that the domain information has changed; The updating of the domain information comprises 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, notifying the domain information synchronization module that the domain information has changed; The sub-domain status monitoring module periodically sends a heartbeat request message to the transmission scheduling subsystem of all sub-domains and waits for a response; 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 sub-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, the area information synchronization module is notified of the change in the area information; The sub-domain can subscribe to other sub-domain information from the sub-domain information synchronization module. The sub-domain information synchronization module will send the sub-domain information to the subscriber. When the sub-domain business information changes, the sub-domain information synchronization module will actively push the sub-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, which specifically includes 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 of the domain for which subscription is requested; Step e2, the central management subsystem finds the corresponding area object in all_areas for the sub-domain ID sent by the request; Step e3, the central management subsystem searches for the key in sub_areas. If it is not found, it inserts a piece of data into sub_areas. The key is the subscribed sub-domain ID, and the value is the newly created area array. It puts the area object found in all_areas into the array. If the area array is found, it adds the area object into the area array. Step e4, replying to the domain management subsystem that the domain subscription is successful, and sending the subscribed domain information to the subscriber; When synchronizing domain information, after receiving the notification sent by the domain information registration management, the domain information synchronization module will send the subscription domain information to the corresponding domain; 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 subscriber. The 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 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 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 in 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 the service information in the domain, 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> Store subscribed domain information; when the relevant domain information changes, it will receive the domain information pushed by 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 according to 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 server ip 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 attributes: 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 service 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, the data is sent to the transmission scheduling subsystem and 0 is returned, otherwise 1 is returned. Then the sending function needs to be modified. At the beginning of the sending 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 means that the sending function can be terminated. When the function returns other values, it means that the transmission service used by the destination service is the same as that of the current service, and the sending function can continue to process. The transmission receiving module includes a heterogeneous transmission data receiving process and a callback function recv_hook. The data receiving process receives the 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 the 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 the data sent by the heterogeneous transmission service has been received, and the receiving function of the transmission service indicates that the 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: int send_hook (void *src_addr, void *dst_addr, char *data, int length, bool is_file); where * represents a pointer in C language, 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 service data length; function return 0 indicates that the destination service uses heterogeneous transmission, and the transmission service sending function can end directly; function return 1 indicates 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 and trans_addr in local_app. If they are equal, it means that the local_app structure corresponding to the sending service is found, otherwise continue to traverse; 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, call the compare function for each virtual_address object, pass 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 is found, which involves heterogeneous transmission and needs to be processed by the transmission scheduling subsystem, the traversal ends, and enters 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, sending the area_id and app_id of the matched virtual_address object together 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 service virtual address, dst_addr represents the destination service address, data represents the service data, when is_file is true, data represents the receiving file path, when is_file is false, data represents the received service data, and length represents the service data length; The transmission scheduling subsystem provides the following functions: Receive data sent by 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 service is located in the sub-domain, finds the transmission scheduling service of 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 working process of the transmission internal forwarding module includes: Step h1, the cross-domain transmission module receives the 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, 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 where the destination service is located; 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 the corresponding sub-domain in sub_areas according to the destination domain ID, if no discarded message is found, otherwise obtain the destination sub-domain transmission scheduling subsystem IP; Step i3, construct a cross-domain transmission message, including the sub-domain ID, source service ID, destination service ID, destination domain ID and service data; Step i4, calling the cross-domain transmission module to send the cross-domain transmission message to the transmission scheduling subsystem of the destination sub-domain.

Images