Multi-copy Association Relationship Tracking and Synchronization Method and Device
Through the distributed breadth-first search algorithm and access control strategy, the data replica association tracking problem in cross-domain and cross-system scenarios is solved, precise positioning and secure synchronization update of cross-domain data replicas are realized, and the security and efficiency of data sharing are improved.
Patent Information
- Application Number
- CN202211244689.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-10-12
- Publication Date
- 2025-08-01
- Estimated Expiration
- 2042-10-12
AI Technical Summary
It is difficult for the prior art to effectively maintain and track the association relationship of data copies in cross-domain and cross-system scenarios, especially in the process of data sharing, it is difficult to ensure that a specific version of the copy files are only accessed by specific users, and synchronous updates of cross-domain circulation are difficult to achieve.
The distributed breadth-first search algorithm and access control policy are adopted to realize the positioning and synchronous update of cross-domain replicas through replica association tables and network topology diagrams. Sticky Policy (SP) technology is used to bind access control policies to ensure replica security.
It realizes precise positioning of data copies and synchronous updates in cross-domain and cross-system scenarios, reduces communication overhead, improves query efficiency and security, and meets the subjective needs of users.
Smart Images

Figure CN115630031B_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the field of data security, and more specifically, relates to a method and device for tracking and synchronizing multi-copy association relationships. Background Art
[0002] In recent years, the state has attached great importance to the dividends of data opening and sharing, and actively promoted the aggregation, integration, and in-depth utilization of massive data across regions, layers, and departments to promote economic development and improve people's livelihood. However, high-value data such as user private data and enterprise core business data contains a large amount of privacy information. While these privacy / secret data are aggregated and shared, their ownership and management rights are separated, and shared data are wantonly retained as copies and transferred without authorization in the background, which brings huge risks of privacy leakage and threats of interest damage, becoming the main obstacle to the large-scale promotion of data sharing. Therefore, it is urgent to study how to effectively control the flow of multi-copies of shared data while realizing data sharing.
[0003] Existing solutions mainly track the multi-copy association relationships of data through a copy catalog to lay a foundation for data flow control. The essence of a copy catalog is a data structure that associates copy files with source files to enable the traceability of copies. Among them, the copy catalog includes two parts: relationship construction and mechanism implementation. (1) Construction of copy association relationships: When users share data and create copies, they store copy information and information about copy holders and add this information to the copy catalog. (2) Mechanism implementation: Based on the copy catalog, a mechanism with copy association relationships as the core is designed to expand the controllable scope of files and realize the flow control of copy files. Some research uses a copy association relationship table to track the flow status of copies in a distributed system and implements a deletion mechanism on this basis. At the same time, some scholars have proposed a multi-copy association model and deletion feedback mechanism for data, which can meet the needs of data multi-copy association and deletion caused by operations such as sharing, transferring, or downloading by authorized users or storage service providers.
[0004] The limitations of existing solutions are mainly manifested in:
[0005] (1) Existing work almost only focuses on the maintenance of in-domain copy association relationships, and the flow scope of copies is limited within a local area network, without considering scenarios of cross-system storage and cross-domain propagation of copies. However, in actual scenarios, when data is shared by a service provider to another party, in most cases, the two parties are not in the same local area network, and the maintenance scheme of in-domain association relationships is obviously not applicable to the situation where copies are transferred across domains. Existing work is difficult to solve the maintenance and tracking of association relationships during the cross-domain and cross-system flow of multi-copies.
[0006] (2) Most existing solutions ignore the in-domain and cross-domain replica transfer and the synchronous update of their associated relationships, making it difficult to support the cross-domain transfer control of replicas. The specific manifestations are as follows: How to ensure that a specific replica of a specific version can only be accessed by specific authorized users during the transfer and synchronization process, while other users cannot access it. Summary of the Invention
[0007] In view of the above defects or improvement requirements of the prior art, the present invention provides a method for tracking and synchronizing multi-replica association relationships, aiming to achieve accurate positioning and synchronous update of associated relationships for replica files of specific versions during the data sharing process in cross-domain and cross-system scenarios, thereby solving the control problem during the cross-domain and cross-system transfer process of data. In the present invention, nodes are divided into file-holding nodes and replica-holding nodes. The file-holding node derives a replica flow graph from the replica association relationship table, and uses a distributed breadth-first search algorithm to determine the location of the replica-holding node; sends a query notice to the replica-holding node, and obtains the location of the file of a specific version in the network based on the notice feedback and tracks the replica association relationship. On this basis, the synchronization mechanism uses an access control policy to generate a permission verification challenge, determines the synchronization scope according to the challenge result, and while updating the replica within the scope, performs consistency verification of the associated relationship. When sharing files, the access control policy is bound to the replica file by means of the Sticky Policy (SP) technology to ensure the security of the replica.
[0008] To achieve the above object, according to one aspect of the present invention, a method for tracking and synchronizing multi-replica association relationships is provided, including the following steps:
[0009] (1) Establishment of associated relationship: All participating parties record when sharing files: file identifier, IP of the file holder, IP of the replica source, number of stored replicas, IP of the replica sharer, file version information, where the file identifier is unique; add this information to the replica association relationship table;
[0010] (2) Replica tracking: The file-holding node sends a positioning notice T to all other nodes in the graph according to the replica flow graph derived from the replica association relationship table. After receiving the notice, the nodes give feedback on the notice and transfer the positioning notice according to the local replica flow graph; except for the file-holding node and the nodes that have not shared files, each node performs the feedback and transfer operations, and the file-holding node constructs a network topology graph based on the notice feedback.
[0011] (3) Tracking of associated relationship: After obtaining the network topology graph, the file-holding node sends a version query notice V to all other nodes in the topology graph. After receiving it, the nodes return a feedback VR, and the file-holding node expands the network topology graph into a version topology graph according to VR.
[0012] (4)Synchronous notification and permission verification: After the file holding node updates the file, it synchronizes the distributed copies across domains. The file holding node generates a permission verification challenge based on the characteristics of the synchronization nodes, constructs a synchronous notification, and each node performs permission verification and puts the verification result into the feedback information. The file holding node determines the synchronization scope according to the feedback;
[0013] (5)Scope synchronization and consistency check: After the synchronization scope is determined, the file holding node generates an access control policy to ensure that the copy can only be accessed by nodes within the synchronization scope. The access control policy is bound to the copy file using the SP technology and sent to the nodes within the synchronization scope together.
[0014] In one embodiment of the present invention, the step (1) includes the following sub-steps:
[0015] (1.1)Addition of copy association relationship table: The information recorded when sharing the file: file identifier Fid, file holder's IP SourceAddress, copy source's IP DirectAddress, number of stored copies N, copy sharer's IP ShareAddress: file version version is used as an entry in the copy association relationship table, and a new relationship record is created in the copy association relationship table;
[0016] (1.2)Export of copy flow graph: When each node shares or updates a file with the file identifier Fid, it exports a copy flow graph according to the copy association relationship table: G = (V, E), where V = {its own IP} ∪ {copy sharer's IP}; E = {(its own IP, copy sharer's IP)}.
[0017] In one embodiment of the present invention, in the step (1.2), for a node with multiple copy sharers, the copy flow graph is a tree with its own IP as the root and a height of 2.
[0018] In one embodiment of the present invention, the step (2) includes the following sub-steps:
[0019] (2.1)Location notification: The file holding node constructs a location notification T according to the copy flow graph, where T = {IP = file holding node's IP, id = Fid, jumps = 0, seq = seq'+1, type = location}, where IP is the file holder's IP, id is the unique file identifier Fid, jumps represents the number of hops the message has experienced, seq represents the sequence number of this location notification, and seq' represents the sequence number of the previous location notification, and type represents the notification type;
[0020] (2.2) Notification Feedback: After a node receives the location notification T, it checks whether it stores or shares the located file copy according to the replica association relationship table, and returns the location notification feedback TR, where TR = {id, jumps, seq, type, DirectAddress, SelfAddress, ShareAddress}. Here, id, jumps, seq, and type are all the information in the location notification T, DirectAddress is the IP of the replica source, SelfAddress is its own IP, and ShareAddress is the IP of the replica sharer. If only the located copy is stored, ShareAddress = -1;
[0021] (2.3) Notification Transmission: The node transmits the replica location notification T' to other nodes in the graph according to its own replica flow graph, where T' = {IP = the IP of the file holder, id = Fid, jumps = jumps' + 1, seq = seq, type = location}, and jumps' is the jumps value in the location notification T received by this node;
[0022] (2.4) Feedback Verification and Network Topology Graph Construction: The file holder node starts from jumps = 0 according to the received location notification feedback, and verifies the consistency of DirectAddress, SelfAddress, and ShareAddress in the feedback layer by layer until all feedbacks are verified.
[0023] In an embodiment of the present invention, the specific implementation of the feedback verification and network topology graph construction in step (2.4) is as follows:
[0024] For the feedback TR0 with jumps = 0 and the feedback TR1 with jumps = 1, the DirectAddress in TR0 is the IP of the file holder node, and the ShareAddress in TR0 is the SelfAddress in TR1. Only when this consistency relationship is met can the verification pass. For each feedback notification, if the verification passes, a node with IP as SelfAddress and an edge of (SelfAddrss, ShareAddress) are added to the network topology graph, otherwise not.
[0025] In an embodiment of the present invention, step (3) includes the following sub-steps:
[0026] Version Query Notification in Version (3.1): The file - holding node sends a version query notification V to all nodes in the network topology graph. Its structure is similar to the location notification in step (2.1), with the difference being the value of the parameter type representing the notification type. For the location notification, type = location; for the version query notification, type = query.
[0027] Notification Feedback in (3.2): Each node gives feedback VR on the received version query notification. VR = {id, jumps, seq, type, version}, where version represents the current copy version.
[0028] Version Topology Graph Construction in (3.3): After the file - holding node receives the file versions returned by all nodes, it adds the version attribute to the nodes in the network topology graph obtained in (2) to obtain the version topology graph. The file - holding node realizes the tracking of copies and their associated relationships through the version topology graph.
[0029] In one embodiment of the present invention, step (4) includes the following sub - steps:
[0030] Permission Verification Challenge Generation in (4.1): Regarding the access control policy as a function F, inputting the user profile and data profile, and outputting a permission verification challenge. The result of the permission verification challenge is associated with the user and is unique.
[0031] Synchronous Notification in (4.2): The file - holding node sends a synchronous notification U to all nodes in the version topology graph. U = {IP = IP of the file - holding party, id = Fid, seq = seq'+1, type = synchronous, Verification}, where IP, id, seq have the same meaning as in the location notification T, and Verification represents the permission verification challenge generated in (4.1).
[0032] Permission Verification and Feedback in (4.3): After each node receives the synchronous notification U, it responds to the permission verification challenge therein and returns the result in UR to the file - holding node. UR = {id, seq, type, VerifyResult}, where VerifyResult is the result of the permission verification challenge response.
[0033] Determining the Synchronization Range in (4.4): The file - holding node compares the VerifyResult in the received UR with the local permission calculation result to determine whether the node has the qualification for synchronization, and then determines the synchronization range.
[0034] In one embodiment of the present invention, step (5) includes the following sub - steps:
[0035] (5.1)Access control policy generation: The access control policy is regarded as function F here. For nodes within the synchronization scope, F(user profile, data profile) = True. The function verifies the user profile and data profile input by the node to determine whether the node has access rights;
[0036] (5.2)File scope synchronization: The file holding node sends a copy bound with the access control policy to the nodes within the synchronization scope;
[0037] (5.3)Consistency check: After the file update is completed, the file synchronization node sends UV1 to its parent node; after the copy is sent, the file holding node sends UV2 to the parent node of the file synchronization node.
[0038] (5.4)Association relationship scope synchronization: The parent nodes of all file synchronization nodes verify UV1 and UV2. If the verification passes, they update the table entry and return success Suc to the file holding node; otherwise, they return error Err.
[0039] In one embodiment of the present invention, in the step (5.3): UV1 = {IP = file holder's IP, id = Fid, UpdateAddress, version}; UV2 = {IP = file holder's IP, id = Fid, UpdateAddress, version}; where UpdateAddress represents the IP of the node that updates the file, and version represents the file version.
[0040] According to another aspect of the present invention, there is also provided a multi-copy association relationship tracking synchronization device, including at least one processor and a memory. The at least one processor and the memory are connected through a data bus. The memory stores instructions executable by the at least one processor. After being executed by the processor, the instructions are used to complete the multi-copy association relationship tracking synchronization method.
[0041] Generally speaking, compared with the prior art through the above technical solutions conceived by the present invention, the following beneficial effects are achieved:
[0042] (1)Efficient query and strong scalability: The present invention uses a graph-based association relationship model instead of a tree-based association relationship model, considers different versions of the same file during the copy propagation process, and improves the copy directory without affecting the query efficiency. While helping users establish inter-domain copy association relationships, it retains the possibility of interconnecting the intra-domain copy association relationship solutions to achieve intra-domain and inter-domain copy association relationship tracking.
[0043] (2) Low communication overhead: Based on distributed breadth-first search and replica tracking of the replica directory, the topology map of the entire network is stored distributively in each node, avoiding the single point of failure problem. The distributed breadth-first search algorithm balances the computing load to each node with non-zero out-degree, reducing the requirements of each node for computing and load capacity, improving the replica location efficiency while reducing the single point communication overhead.
[0044] (3) Provide subjective regulation function: While providing replica association relationship tracking, the parameters in the notification can be adjusted according to the subjective needs of users to track the location and status of specific files of specific versions.
[0045] (4) Secure and accurate: On the premise of not affecting the performance of the multi-replica association relationship tracking method, the SP technology is integrated to ensure data security, the access control policy is used to enhance the reliability of cross-domain transfer control within the domain, and the synchronization mechanism is implemented to ensure the accuracy of the association relationship. BRIEF DESCRIPTION OF THE DRAWINGS
[0046] Figure 1 is the flowchart of the multi-replica association relationship tracking and synchronization method in the embodiment of the present invention;
[0047] Figure 2 is the schematic diagram of replica tracking in the embodiment of the present invention;
[0048] Figure 3 is the schematic diagram of association relationship tracking in the embodiment of the present invention;
[0049] Figure 4 is the schematic diagram of synchronization notification and permission verification in the embodiment of the present invention;
[0050] Figure 5 is the schematic diagram of range synchronization and consistency check in the embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION
[0051] In order to make the objectives, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention. In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.
[0052] The following first explains and describes the technical terms of the present invention:
[0053] Replica association relationship table: The specific manifestation form of the replica directory in the present invention. When users share data and create replicas, the replica information, replica holders and other information are stored in this table.
[0054] Network topology graph: A directed graph constructed with IPs as nodes and sharing relationships as edges. Among them, the in-degree of the file holder is 0, and the out-degree of the copy holder node without shared copies is 0.
[0055] Version topology graph: A knowledge graph constructed by adding file version attributes to each node based on the network topology graph.
[0056] Range synchronization: It includes file synchronization of copies and synchronous update of all associated relationships in the entire copy sharing network.
[0057] Permission verification challenge: A challenge generated by receiving the input of the user profile and the data profile. This challenge verifies the user's permissions, and the challenge generator verifies the permissions of the challenge responder through the response result.
[0058] SP technology: Using cryptographic technology to bind access control policies to data and transfer them along with the data.
[0059] As Figure 1 shown, the multi-copy associated relationship tracking and synchronization method of the present invention includes the following steps:
[0060] (1) Establishment of associated relationships. All participating parties record the following information when sharing files: file identifier, IP of the file holder, IP of the copy source, number of stored copies, IP of the copy sharer, file version information, where the file identifier is unique. Adding this information to the copy associated relationship table includes the following steps:
[0061] (1.1) Addition to the copy associated relationship table. The information recorded when sharing files: file identifier Fid, IP of the file holder SourceAddress, IP of the copy source DirectAddress, number of stored copies N, IP of the copy sharer ShareAddress, and file version version are used as the table entries of the copy associated relationship table, and a new relationship record is created in the copy associated relationship table.
[0062] (1.2) Export of the copy flow graph. When each node performs operations such as sharing and updating a file with the file identifier Fid, the copy flow graph can be exported according to the copy associated relationship table:
[0063] G = (V, E), V = {own IP} ∪ {IP of the copy sharer};
[0064] E = {(own IP, IP of the copy sharer)};
[0065] For a node with multiple copy sharers, the copy flow graph is actually a tree with its own IP as the root and a height of 2.
[0066] (2) Replica Tracing. The file-holding node sends a location notification T to all other nodes in the graph according to the replica flow graph derived from the replica association table. After receiving the notification, the nodes give feedback on the notification and pass the location notification according to the local replica flow graph. Except for the file-holding node and the nodes that have not shared the file, each node performs the feedback and passing operations. After waiting for the timeout period or receiving the notification feedback with jumps = 16, the file-holding node constructs a network topology graph based on the notification feedback, as Figure 2 shown, which includes the following steps:
[0067] (2.1) Location Notification. The file-holding node constructs a location notification T according to the replica flow graph.
[0068] T = {IP = IP of the file-holding node, id = Fid, jumps = 0, seq = seq’ + 1, type = location}
[0069] where IP is the IP of the file holder, id is the unique file identifier Fid, jumps represents the number of hops the message has experienced, seq represents the sequence number of this location notification (seq’ represents the sequence number of the previous location notification), and type represents the notification type.
[0070] (2.2) Notification Feedback. After receiving the location notification T, the node checks whether it stores or shares the located file replica according to the replica association table and returns a location notification feedback TR.
[0071] TR = {id, jumps, seq, type, DirectAddress, SelfAddress, ShareAddress}
[0072] where id, jumps, seq, and type are all the information in the location notification T, DirectAddress is the IP of the replica source, SelfAddress is its own IP, ShareAddress is the IP of the replica sharer. If only the located replica is stored, ShareAddress = -1.
[0073] (2.3) Notification Passing. The node passes the replica location notification T’ to other nodes in the graph according to its own replica flow graph.
[0074] T’ = {IP = IP of the file holder, id = Fid, jumps = jumps’ + 1, seq = seq, type = location}
[0075] where jumps’ is the jumps value in the location notification T received by this node, and the other values are the same as those in T.
[0076] (2.4) Feedback verification and network topology graph construction. The file-holding node verifies the consistency of DirectAddress, SelfAddress, and ShareAddress in the feedback starting from jumps = 0 according to the received location notification feedback, layer by layer downward until all feedbacks are verified. For the feedback TR0 with jumps = 0 and the feedback TR1 with jumps = 1, the DirectAddress in TR0 is the IP of the file-holding node, and the ShareAddress in TR0 is the SelfAddress in TR1. Only when this consistency relationship is met can the verification pass. For each feedback notification, if the verification passes, add a node with IP as SelfAddress and an edge of (DirectAddress, SelfAddress) to the network topology graph; otherwise, do not add.
[0077] (3) Association relationship tracking. After obtaining the network topology graph, the file-holding node sends a version query notification V to all other nodes in the topology graph. After receiving it, the nodes return a feedback VR. The file-holding node expands the network topology graph into a version topology graph according to VR, as Figure 3 shown, including the following steps:
[0078] (3.1) Version query notification. The file-holding node sends a version query notification V to all nodes in the network topology graph. Its construction is similar to the location notification in step (2.1), with the difference being the value of the parameter type representing the notification type. For the location notification, type = location, and for the version query notification, type = query.
[0079] (3.2) Notification feedback. Each node gives feedback on the received version query notification.
[0080] VR = {id, jumps, seq, type, version}, where version represents the current copy version.
[0081] (3.3) Version topology graph construction. After receiving the file versions returned by all nodes, the file-holding node adds the version attribute to the nodes in the network topology graph obtained in (2) to obtain the version topology graph, which is essentially a knowledge graph. The file-holding node realizes the tracking of the copy and its association relationship through the version topology graph.
[0082] (4) Synchronization notification and permission verification. After the file-holding node updates the file, it performs cross-domain range synchronization on the distributed copies. The file-holding node generates a permission verification challenge according to the synchronization node characteristics and constructs a synchronization notification. Each node performs permission verification and puts the verification result into the feedback information. The file-holding node determines the synchronization range according to the feedback, as Figure 4As shown, it includes the following steps:
[0083] (4.1) Permission verification challenge generation. Regarding the access control policy as a function F, with the input of user profile and data profile (user profile and data profile are structures in permission control), it outputs a permission verification challenge. The permission verification challenge result is associated with the user and is unique.
[0084] (4.2) Synchronization notification. The file holding node sends a synchronization notification U to all nodes in the version topology graph.
[0085] U = {IP = IP of the file holder, id = Fid, seq = seq'+1, type = synchronous, Verification}, where IP, id, and seq have the same meaning as the location notification T, and Verification represents the permission verification challenge generated in (4.1).
[0086] (4.3) Permission verification and feedback. After each node receives the synchronization notification U, it responds to the permission verification challenge in it and puts the result into UR and returns it to the file holding node.
[0087] UR = {id, seq, type, VerifyResult}, where VerifyResult is the result of the permission verification challenge response.
[0088] (4.4) Determine the synchronization scope. The file holding node compares the VerifyResult in the received UR with the local permission calculation result to determine whether the node has the synchronization qualification, and then determines the synchronization scope.
[0089] (5) Scope synchronization and consistency check. After the file holding node determines the synchronization scope, it generates an access control policy to ensure that the replica can only be accessed by nodes within the synchronization scope. Using the SP technology, the access control policy is bound to the replica file and sent to the nodes within the synchronization scope, as Figure 5 shown, it includes the following steps:
[0090] (5.1) Access control policy generation. The access control policy can be regarded as a function F. For nodes within the synchronization scope, F(user profile, data profile) = True, otherwise it is False. The function verifies the user profile and data profile input by the node to determine whether the node has access permission.
[0091] (5.2) File scope synchronization. The file holding node sends the replica bound with the access control policy to the nodes within the synchronization scope.
[0092] (5.3) Consistency check. After the file update is completed, the file synchronization node sends UV1 to its parent node; after the replica sending is completed, the file holding node sends UV2 to the parent node of the file synchronization node.
[0093] UV1 = {IP = IP of the file holder, id = Fid, UpdateAddress, version}
[0094] UV2 = {IP = IP of the file holder, id = Fid, UpdateAddress, version}
[0095] Among them, IP and id are the same as those in the previous text. UpdateAddress represents the IP of the node that updates the file, and version represents the file version.
[0096] (5.4) Association relationship range synchronization. The parent nodes of all file synchronization nodes verify UV1 and UV2. If the verification passes, the table entries are updated and a success Suc is returned to the file holding node; otherwise, an error Err is returned.
[0097] Further, the present invention also provides a multi-replica association relationship tracking and synchronization device, including at least one processor and a memory. The at least one processor and the memory are connected through a data bus. The memory stores instructions executable by the at least one processor. After the instructions are executed by the processor, they are used to complete the multi-replica association relationship tracking and synchronization method.
[0098] Those skilled in the art can easily understand that the above is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent replacements, and improvements made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims
1. A multi-copy association relationship tracking and synchronization method, characterized in that, It includes the following steps: (1) Association relationship establishment: When all participating parties share files, they record: file identifier, file holder's IP, source IP of the copy, number of stored copies, IP of the copy sharer, file version information, where the file identifier is unique; add this information to the copy association relationship table; (2) Copy tracking: The file holding node sends a location notification T to all other nodes in the graph according to the copy flow graph derived from the copy association relationship table. After receiving the notification, the nodes give feedback and transfer the location notification according to the local copy flow graph; except for the file holding node and the nodes that have not shared the file, each node performs the feedback and transfer operations, and the file holding node constructs a network topology graph based on the notification feedback; (3) Association relationship tracking: After obtaining the network topology graph, the file holding node sends a version query notification V to all other nodes in the topology graph. After receiving it, the nodes return a feedback VR, and the file holding node expands the network topology graph into a version topology graph according to VR; (4) Synchronization notification and permission verification: After the file holding node updates the file, it performs cross-domain range synchronization on the distributed copies. The file holding node generates a permission verification challenge according to the characteristics of the synchronization nodes, constructs a synchronization notification, and each node performs permission verification and puts the verification result into the feedback information. The file holding node determines the synchronization range according to the feedback; (5) Range synchronization and consistency check: After the synchronization range is determined, the file holding node generates an access control policy to ensure that the copy can only be accessed by the nodes within the synchronization range, and uses the SP (Sticky Policy) technology to bind the access control policy to the copy file and send it to the nodes within the synchronization range together.
2. The multi-copy correlation relationship tracking and synchronization method according to claim 1, wherein The step (1) includes the following sub-steps: (1.1) Adding to the copy association relationship table: Take the information recorded when sharing the file: file identifier Fid, file holder's IP SourceAddress, source IP of the copy DirectAddress, number of stored copies N, IP of the copy sharer ShareAddress: file version version as an entry in the copy association relationship table, and create a new relationship record in the copy association relationship table; (1.2) Exporting the copy flow graph: When each node shares or updates a file with the file identifier Fid, it exports the copy flow graph according to the copy association relationship table: G = (V, E), V = {its own IP} ∪ {IP of the copy sharer}; E = {(its own IP, IP of the copy sharer)}.
3. The multi-copy association relationship tracking and synchronization method according to claim 2, characterized in that, In the step (1.2), for a node with multiple copy sharers, the copy flow graph is a tree with its own IP as the root and a height of 2.
4. The multi-copy association relationship tracking and synchronization method according to claim 1 or 2, characterized in that The step (2) includes the following sub-steps: (2.1) Location Notification: The file - holding node constructs a location notification T according to the replica flow graph. T = {IP = IP of the file - holding node, id = Fid, jumps = 0, seq = seq’ + 1, type = location}, where IP is the IP of the file holder, id is the unique file identifier Fid, jumps represents the number of hops the message has experienced, seq represents the sequence number of this location notification, seq’ represents the sequence number of the previous location notification, and type represents the notification type. (2.2) Notification Feedback: After receiving the location notification T, the node checks whether it stores or shares the located file replica according to the replica association relation table, and returns a location notification feedback TR. TR = {id, jumps, seq, type, DirectAddress, SelfAddress, ShareAddress}, where id, jumps, seq, type are all the information in the location notification T, DirectAddress is the IP of the replica source, SelfAddress is its own IP, ShareAddress is the IP of the replica sharer. If it only stores the located replica, ShareAddress = - 1. (2.3) Notification Transmission: The node transmits the replica location notification T’ to other nodes in the graph according to its own replica flow graph. T’ = {IP = IP of the file holder, id = Fid, jumps = jumps’ + 1, seq = seq, type = location}, where jumps’ is the value of jumps in the location notification T received by this node. (2.4) Feedback Verification and Network Topology Graph Construction: The file - holding node verifies the consistency of DirectAddress, SelfAddress, and ShareAddress in the feedback starting from jumps = 0 according to the received location notification feedback, layer by layer until all feedbacks are verified.
5. The multi-copy association relationship tracking and synchronization method according to claim 4, characterized in that The specific implementation of feedback verification and network topology graph construction in step (2.4) is as follows: For the feedback TR0 with jumps = 0 and the feedback TR1 with jumps = 1, the DirectAddress in TR0 is the IP of the file - holding node, and the ShareAddress in TR0 is the SelfAddress in TR1. Only when this consistency relationship is met can the verification pass. For each feedback notification, if the verification passes, a node with IP as SelfAddress and an edge of (SelfAddrss, ShareAddress) are added to the network topology graph; otherwise, they are not added.
6. The multi-copy association relationship tracking and synchronization method according to claim 4, characterized in that, Step (3) includes the following sub - steps: Version query notification (3.1): The file - holding node sends a version query notification V to all nodes in the network topology graph. Its structure is similar to the location notification in step (2.1), with the difference being the value of the parameter type representing the notification type. For the location notification, type = location, and for the version query notification, type = query; Notification feedback (3.2): Each node gives feedback VR on the received version query notification. VR = {id, jumps, seq, type, version}, where version represents the current replica version; Version topology graph construction (3.3): After the file - holding node receives the file versions returned by all nodes, it adds the version attribute to the nodes in the network topology graph obtained in (2) to obtain the version topology graph. The file - holding node uses the version topology graph to track the replicas and their associated relationships.
7. The multi-copy association relationship tracking and synchronization method according to claim 1 or 2, characterized in that The said step (4) includes the following sub - steps: Permission verification challenge generation (4.1): Regard the access control policy as a function F. Input the user profile and data profile, and output a permission verification challenge. The result of the permission verification challenge is associated with the user and is unique; Synchronization notification (4.2): The file - holding node sends a synchronization notification U to all nodes in the version topology graph; U = {IP = file - holding party's IP, id = Fid, seq = seq'+ 1, type = synchronous, Verification}, where IP = file - holding node's IP, id = Fid, seq = seq'+ 1, and Verification represents the permission verification challenge generated in (4.1); Permission verification and feedback (4.3): After each node receives the synchronization notification U, it responds to the permission verification challenge in it and puts the result into UR and returns it to the file - holding node. UR = {id, seq, type, VerifyResult}, where VerifyResult is the result of the permission verification challenge response; Determine the synchronization scope (4.4): The file - holding node compares the VerifyResult in the received UR with the local permission calculation result to determine whether the node has the synchronization qualification and further determine the synchronization scope.
8. The multi-copy association relationship tracking and synchronization method according to claim 1 or 2, characterized in that, The said step (5) includes the following sub - steps: Access control policy generation (5.1): The access control policy is regarded as a function F here. For the nodes within the synchronization scope, F(user profile, data profile)=True. The function verifies the input user profile and data profile of the node to determine whether the node has access permission; File - range synchronization (5.2): The file - holding node sends the replicas bound with the access control policy to the nodes within the synchronization scope; Consistency check (5.3): After the file update is completed, the file synchronization node sends UV1 to its parent node; after the replica is sent, the file - holding node sends UV2 to the parent node of the file synchronization node; (5.4) Association relationship range synchronization: The parent nodes of all file synchronization nodes verify UV1 and UV2. If the verification passes, update the table entry and return success Suc to the file holding node; otherwise, return error Err.
9. The multi-copy association relationship tracking and synchronization method according to claim 8, characterized in that, In the step (5.3): UV1 = {IP = file holder's IP, id = Fid, UpdateAddress, version}; UV2 = {IP = file holder's IP, id = Fid, UpdateAddress, version}; where Fid is the unique file identifier, UpdateAddress represents the IP of the node that updates the file, and version represents the file version.
10. A multi-copy association relationship tracking and synchronization device, characterized in that: It includes at least one processor and a memory. The at least one processor and the memory are connected through a data bus. The memory stores instructions that can be executed by the at least one processor. After being executed by the processor, the instructions are used to complete the multi-copy association relationship tracking and synchronization method described in any one of claims 1-9.
Citation Information
Patent Citations
Safety protection method based on big data processing platform
CN105553940A
Cognitive synchronization of digital files
US20210209065A1