Method for correspondingly managing IPV4 and IPV6 addresses of same user of network dual stacks

Abstract

The invention discloses a corresponding management method for IPV4 and IPV6 addresses of the same user of network dual stacks, and relates to the technical field of network address management, network system nodes are divided into a main control node, a replica synchronization node and an edge cache node, a layered management architecture is constructed, hotspot users with frequent write-in are identified, a flow partitioning and path arbitration strategy is adopted, and the IPV4 and IPV6 addresses of the same user of the network dual stacks are correspondingly managed. The method comprises the following steps of: dynamically allocating an auxiliary book group, constructing a state deviation evaluation function, judging the consistency degree according to a version and hash information, selecting a corresponding synchronization strategy, fusing various mechanisms to form an execution layer consistency maintenance closed loop, and performing IPV4 and IPV6 address mapping relation management in a distributed environment. According to the management method, the stability, the accuracy and the reliability of the dual-stack user address mapping management system in a multi-source asynchronous operation environment are effectively enhanced by constructing a layered execution architecture which takes a main control node as a core, a copy synchronization node as a distribution guarantee and an edge cache node as a response terminal.

Description

Technical Field

[0001] The present invention relates to the technical field of network address management, and in particular to a method for managing the correspondence between IPv4 and IPv6 addresses of a same user in a dual-stack network. Background Art

[0002] Dual-Stack refers to the simultaneous deployment of IPV4 and IPV6 protocols in the same network environment to support the coexistence and smooth transition of the old and new protocols. In a dual-stack network, devices (such as user terminals or servers) are typically assigned an IPV4 address and an IPV6 address. This architecture facilitates the gradual transition to IPV6 while a large number of existing IPV4 networks still exist, and avoids network fragmentation. However, managing the correspondence between the IPV4 and IPV6 addresses owned by the same user in a dual-stack environment has become a key technical issue in network operation and maintenance, billing, security, and behavior tracing.

[0003] Traditional centralized or semi-centralized data synchronization methods are difficult to meet consistency requirements. In actual operation, the propagation of mapping information between multiple nodes is subject to significant latency, write conflicts, and state drift, which can easily lead to the following technical bottlenecks:

[0004] (1) The write pressure on the master node is concentrated, resulting in a decrease in processing capacity or even write blocking, low replica synchronization efficiency, and version drift causing a mismatch between historical records and real-time status;

[0005] (2) Edge nodes cannot respond to change requests in a timely manner, cache data becomes outdated, affecting user experience. Mapping information may be lost when network links jitter or some nodes fail, bringing security risks and user session interruptions.

[0006] (3) Due to the lack of dynamic control and deviation perception mechanisms, the system cannot proactively identify abnormal synchronization states and perform repairs, which affects system stability and maintainability.

[0007] Based on this, the present invention proposes a method for managing the correspondence between IPV4 and IPV6 addresses of the same user in a dual-stack network. By constructing a hierarchical execution architecture with the main control node as the core, the replica synchronization node as the distribution guarantee, and the edge cache node as the response terminal, the stability, accuracy and reliability of the dual-stack user address mapping management system in a multi-source asynchronous operation environment are effectively enhanced. Summary of the Invention

[0008] The purpose of the present invention is to provide a method for managing the corresponding IPv4 and IPv6 addresses of the same user of a dual-stack network, so as to solve the problems in the background technology.

[0009] In order to achieve the above object, the present invention provides the following technical solution: a method for managing the correspondence between the IPv4 and IPv6 addresses of the same user in a dual-stack network, the management method comprising the following steps:

[0010] S1: Divide the network system nodes into master control nodes, replica synchronization nodes, and edge cache nodes, which are used for core writing, replica synchronization, and edge response, respectively, to build a hierarchical management architecture;

[0011] S2: After the user accesses, the master control node establishes an IPv4 and IPv6 address binding relationship based on the authentication identifier, completes the writing and generates a synchronization log through a Raft-like consensus mechanism;

[0012] S3: Replica nodes use the improved Raft protocol, combining sliding windows with batch logs to transmit write records, achieving synchronous compression and latency reduction.

[0013] S4: The edge node asynchronously subscribes to the master control node change event and determines whether to refresh the local cache based on the version stamp;

[0014] S5: Regularly check the data consistency between network system nodes. If the deviation exceeds the limit, trigger patch synchronization or full snapshot recovery to synchronize the data.

[0015] S6: Identify hotspot users with frequent writes, implement traffic partitioning and path arbitration strategies, dynamically allocate replica groups, and reduce pressure on the master control node.

[0016] S7: Construct a state deviation evaluation function, determine the consistency level based on the version and hash information, and select the corresponding synchronization strategy to maintain logical consistency;

[0017] S8: The mechanisms of steps S2-S7 are integrated to form a closed loop for consistency maintenance at the execution layer, and manage the mapping relationship between IPv4 and IPv6 addresses in a distributed environment.

[0018] In a preferred embodiment, step S5: regularly checking the data consistency between network system nodes, and if the deviation exceeds the limit, triggering patch synchronization or full snapshot recovery to synchronize the data, includes the following steps:

[0019] The master control node provides a status summary for each verified node;

[0020] After receiving the state summary, the verified node calculates the consistency deviation and executes a repair strategy based on the calculation result. The execution of the repair strategy includes:

[0021] If the log lag is within the tolerance range, the master control node pushes an incremental patch package containing missing log entries and field difference information. The target nodes then restore the status and update the version stamp in sequence.

[0022] If the hash is abnormal or the log is broken, the master control node generates and pushes a full snapshot, and the target node clears the current state and loads the snapshot to restore the mapping data.

[0023] In a preferred embodiment, after receiving the state summary, the checked node calculates the consistency deviation:

[0024] If the log index lags behind the master control node by more than the set threshold, it is marked as version lag;

[0025] If the version stamp is significantly behind and the log record is missing, it is considered to be in a log-fragmented state;

[0026] If the hash values ​​do not match, it is determined that the state structure is abnormal;

[0027] If multiple rounds of verification fail consecutively, the node will be marked as an abnormal node.

[0028] In a preferred embodiment, step S6: identifying hotspot users with frequent writes, adopting traffic partitioning and path arbitration strategies, dynamically allocating replica groups, and reducing the pressure on the master control node, includes the following steps:

[0029] Collect the address binding relationship write operation frequency, continuous change number and consensus log entry trigger number of each user in real time, and calculate the hotspot score based on the set time window;

[0030] When the hotspot score exceeds a preset threshold, the user is marked as a hotspot user, a target replica group with low resource load is dynamically selected from multiple replica synchronization node groups, and a write mapping relationship between the user and the replica group is established;

[0031] During the write process, the master control node no longer participates in the log write consensus process, but receives the write summary or read-only confirmation package submitted by the target replica group;

[0032] The consensus weight, log buffer configuration and processing thread resources of each node in the replica group are dynamically adjusted according to the access intensity of the hotspot users and the load status of the replica group.

[0033] In a preferred embodiment, the write mapping relationship is constructed based on a consistent hash map or a load-aware routing table, and is used to direct subsequent binding relationship write requests of hotspot users to the target replica group;

[0034] The target replica group elects a local master node to perform write processing and complete subset consensus confirmation within the replica group.

[0035] In a preferred embodiment, step S7: constructing a state deviation evaluation function, judging the consistency level based on the version and hash information, and selecting a corresponding synchronization strategy to maintain logical consistency, includes the following steps:

[0036] The master control node periodically performs a state consistency evaluation on each replica node and calculates a consistency deviation score based on at least three types of indicators. The calculation method is:

[0037] The version offset, log entry gap, and hash inconsistency status are weighted separately to form a unified deviation score.

[0038] If the deviation score of a replica node exceeds the preset tolerance threshold, it will be marked as a deviation anomaly, and a compensation synchronization strategy will be selected based on the specific performance of various indicators:

[0039] If the log lag and version offset are at a low to medium level and the hashes are consistent, the lightweight patch synchronization strategy is selected to send the missing log entries and changed fields saved by the master control node to the replica nodes in the form of patches;

[0040] If the hash check fails or the log is broken, the full snapshot replacement strategy is selected. The master control node generates a snapshot of the current state and transmits it to the target replica node for full state reconstruction.

[0041] In a preferred embodiment, the version stamp offset represents the difference between the state versions currently recorded by the master control node and the target replica node; the log entry gap represents the gap value of the consensus log index between the master control node and the target replica node; the state snapshot hash consistency represents whether the hash values ​​calculated by the master control node and the replica node for the binding relationship snapshot data structure are consistent.

[0042] In a preferred embodiment, step S2: after the user accesses, the main control node establishes an IPv4 and IPv6 address binding relationship based on the authentication identifier, completes writing and generates a synchronization log through a Raft-like consensus mechanism, including the following steps:

[0043] After the user access authentication is successful, the main control node receives the user authentication information reported by the access network element and extracts the authentication identification parameters as binding indexes, including but not limited to MAC address, IMSI number, PPPoEID or access interface identifier;

[0044] The master control node establishes a corresponding IPv4 and IPv6 address binding relationship based on the authentication identifier, and determines whether the binding is newly created or updated;

[0045] The master control node uses a Raft-like consensus mechanism to send the log entry to multiple replica synchronization nodes. The replica nodes write the log locally and return a confirmation response.

[0046] When the master control node receives confirmation from the number of replicas that meet the consensus conditions, it updates the submission index, performs the binding operation submission, and broadcasts the submission status to all replica nodes.

[0047] In a preferred embodiment, step S3: the replica node uses an improved Raft protocol, combined with a sliding window and batch log mode to transmit write records, to achieve synchronous compression and delay reduction, including the following steps:

[0048] After the master control node completes the user address binding change operation, it generates the corresponding log entry and adds it to the log aggregation queue;

[0049] In the log aggregation queue, multiple log entries are merged into batch log blocks when preset conditions are triggered. The trigger conditions include: the number of log entries reaches a preset threshold, the last synchronization time interval exceeds the upper limit, it is in an idle period, or the replica node requests log synchronization;

[0050] The master control node sends batches of log blocks to the replica synchronization node through a sliding window mechanism. The sliding window is used to limit the number of unconfirmed log blocks transmitted concurrently and dynamically release the window capacity based on the confirmation response of the replica node.

[0051] In a preferred embodiment, step S4: the edge node asynchronously subscribes to the master control node change event and determines whether to refresh the local cache based on the version stamp, including the following steps:

[0052] The edge cache node registers as an event subscription node with the main control node and specifies the event type and user range of interest;

[0053] After receiving the event message, the edge cache node extracts the user ID and searches for the corresponding binding record in the local cache. If no record exists, it pulls the complete binding data to build the initial cache; if the record exists, it performs a version stamp comparison:

[0054] When the local version stamp is smaller than the event version stamp, the data is considered outdated and enters the refresh process;

[0055] When the local version stamp is greater than or equal to the event version stamp, the update operation is skipped.

[0056] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0057] The present invention divides the network system nodes into main control nodes, replica synchronization nodes and edge cache nodes to build a hierarchical management architecture, regularly checks the data consistency between the network system nodes, and if the deviation exceeds the limit, triggers patch synchronization or full snapshot recovery to synchronize the data, identify hot users with frequent writes, adopts traffic partitioning and path arbitration strategies, dynamically allocates replica groups, reduces the pressure on the main control node, builds a state deviation evaluation function, judges the degree of consistency based on the version and hash information, and selects the corresponding synchronization strategy to maintain logical consistency, integrates multiple mechanisms to form an execution layer consistency maintenance closed loop, and manages the IPv4 and IPv6 address mapping relationship in a distributed environment. This management method effectively reduces the pressure on the synchronization link caused by high-frequency writes by constructing a hierarchical execution architecture with the main control node as the core, the replica synchronization node as the distribution guarantee, and the edge cache node as the response terminal, and enhances the stability, accuracy and reliability of the dual-stack user address mapping management system in a multi-source asynchronous operation environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments described in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0059] Figure 1 Flowchart of the management method of the present invention. DETAILED DESCRIPTION

[0060] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0061] Example 1: Please refer to Figure 1 As shown, this embodiment provides a method for managing the correspondence between the IPv4 and IPv6 addresses of the same user in a dual-stack network. The management method includes the following steps:

[0062] S1: Network system nodes are divided into three functional categories: master control nodes, replica synchronization nodes, and edge cache proxy nodes. The master control node is responsible for the core writing and distribution of IPv4 and IPv6 address mappings. Replica nodes maintain complete data copies to participate in consensus. Edge nodes handle high-frequency read requests, buffer writes, and support eventual consistency responses. This layered architecture balances strong consistency guarantees for central writes with high-performance read and write responses at the edge.

[0063] S2: After successful user access authentication, the master control node establishes an initial IPv4 and IPv6 address binding based on the access authentication identifier (such as MAC, IMSI, PPPoEID, etc.) and performs a write confirmation of the mapping change using a Raft-like consensus algorithm. After the write, a log entry is generated and pushed from the master control node to the replica nodes, achieving strong write consistency.

[0064] S3: To reduce the bandwidth consumption of synchronization links due to high-frequency changes, replica synchronization nodes use an improved Raft protocol, combined with a sliding window mechanism and batch log transmission strategy, to achieve log compression synchronization. During system idle periods, multiple address mapping change logs are aggregated and transmitted in unified packets, reducing synchronization frequency and transmission latency.

[0065] S4: Edge cache nodes subscribe to the master control node's change event channel and respond to address binding updates using asynchronous notifications and an event-driven mechanism. Each update carries a version stamp and a minimal change summary. Edge nodes compare the version stamps to determine whether to refresh their local cache, ensuring low-latency responses while avoiding frequent write operations.

[0066] S5: To prevent data deviations on edge or replica nodes due to disconnections, latency, and errors, the system periodically performs state consistency checks. If a deviation exceeds a set threshold, an incremental patch synchronization policy is automatically triggered. If the version gap is too large or the consistency assessment fails, the master control node initiates a full snapshot transfer for rapid rollback and recovery.

[0067] S6: The system monitors user write behavior and change frequency in real time, identifying "hotspot users" whose address bindings frequently change. For these users, a traffic partitioning arbitration mechanism is used to dynamically assign different replica groups as their primary write paths. The system also adjusts the weight of their consensus nodes to alleviate the concentrated write pressure on the master node and improve overall processing capacity.

[0068] S7: The system has a state deviation assessment function that regularly calculates consistency deviation scores based on metrics such as version stamps, log entries, and snapshot hashes between the master and replica nodes. If the deviation exceeds a set tolerance, the system automatically selects a "light patch synchronization" or "full snapshot replacement" strategy to ensure the logical consistency of the mapped data is not compromised.

[0069] S8: In a continuous system operation and multi-site deployment environment, the integrated mechanisms of steps S2-S7 form a complete execution-layer consistency maintenance closed loop. Combining strong master consistency, replica redundancy, edge tolerance, compression synchronization, event subscription, patch compensation, and deviation assessment strategies, this forms a dynamic and autonomous multi-source consistency assurance system, effectively supporting the real-time, highly available, and maintainable deployment of IPv4 and IPv6 dual-stack address associations in large-scale distributed scenarios.

[0070] This application divides the network system nodes into main control nodes, replica synchronization nodes and edge cache nodes to build a hierarchical management architecture, regularly checks the data consistency between the network system nodes, and if the deviation exceeds the limit, triggers patch synchronization or full snapshot recovery to synchronize the data, identify hot users with frequent writes, adopts traffic partitioning and path arbitration strategies, dynamically allocates replica groups, reduces the pressure on the main control node, builds a state deviation evaluation function, judges the degree of consistency based on the version and hash information, and selects the corresponding synchronization strategy to maintain logical consistency, integrates multiple mechanisms to form an execution layer consistency maintenance closed loop, and manages the mapping relationship between IPV4 and IPV6 in a distributed environment. This management method effectively reduces the pressure on the synchronization link caused by high-frequency writes by constructing a hierarchical execution architecture with the main control node as the core, the replica synchronization node as the distribution guarantee, and the edge cache node as the response terminal, and enhances the stability, accuracy and reliability of the dual-stack user address mapping management system in a multi-source asynchronous operation environment.

[0071] Example 2: S1: Network system nodes are divided into three functional categories: master control nodes, replica synchronization nodes, and edge cache proxy nodes. The master control node is responsible for the core writing and distribution of IPv4 and IPv6 address mappings, replica nodes maintain complete data copies to participate in consensus, and edge nodes handle high-frequency read requests and write buffering, supporting eventual consistency responses. This layered architecture balances strong consistency guarantees for central writes with high-performance read and write responses at the edge.

[0072] Network system nodes are divided into three functional categories: master control nodes, replica synchronization nodes, and edge cache proxy nodes. Master control nodes are responsible for the core writing and distribution of IPv4 and IPv6 address mappings, replica nodes maintain complete data copies to participate in consensus, and edge nodes handle high-frequency read requests, buffer writes, and support eventual consistency responses. This layered architecture balances strong consistency guarantees for central writes with high-performance read and write responses at the edge.

[0073] In a distributed network environment, to effectively manage the mapping between IPv4 and IPv6 addresses for the same user in a dual-stack architecture, the system first divides the overall system node functions into three tiers based on node responsibilities and network topology deployment characteristics: master control nodes (Master-Node), replica synchronization nodes (Replica-Node), and edge cache proxy nodes (Edge-Cache-Node). This structured design helps decouple data write consistency control from high-concurrency read access, improving the system's data consistency and service responsiveness in multi-site deployment environments.

[0074] The master control node assumes the most critical control and coordination functions in the system. It is responsible for receiving user authentication information reported by the access layer or authentication platform (such as AAA, RADIUS, DHCP), and based on this information, generates a corresponding binding relationship between the IPv4 address and the IPv6 address, establishing a dual-stack mapping record. This binding record is typically organized as a structured key-value pair, such as the structure <user ID → {IPv4 address, IPv6 address}>. When the master control node receives an address binding update request, it must serialize it and write it to the consensus log to ensure that operations in the system's multi-node environment can be serialized and support subsequent replication consistency.

[0075] Replica synchronization nodes are responsible for receiving synchronized log updates from the master control node in real time. Their primary function is to maintain data consistency across multiple backup nodes, enabling rapid recovery or takeover of mapping management tasks in the event of a master control node failure, migration, or load shift. After receiving a log entry, a replica node sequentially executes the binding change operations in the log and returns a confirmation signal to update the master node's submission status. The consensus mechanism typically uses the Raft protocol, where replica nodes collaborate with the master node and other replica nodes to reach a consensus vote (e.g., achieving majority confirmation) to ensure the consistency and integrity of log submissions.

[0076] Edge cache proxy nodes are deployed in areas close to access gateways or local business systems to handle high-frequency user address query requests and binding status updates, and are particularly suitable for edge data centers or edge routing scenarios. Their main responsibility is to cache the latest mapping status and quickly return query results, alleviating access pressure on central nodes. To maintain data accuracy, edge nodes typically monitor status updates of master or replica nodes in real time through event-driven or subscription mechanisms, while maintaining metadata such as version stamps, timestamps, or status summaries to determine whether the local cache is invalid and decide whether to trigger data refresh.

[0077] When an edge cache proxy node processes a query request, it usually uses a version stamp and timestamp along with a consistency digest to determine whether the current cache is still valid. The basic logic is as follows:

[0078] set up The current cache version number of the edge node, The latest version number currently released by the master control node, The last updated timestamp recorded for the edge node, is the current system time; is the maximum tolerated cache delay time, Current cache digest for edge nodes (e.g., hash digest); The digest value of the mapping corresponding to the master node.

[0079] The validity of the cache can be determined according to the following logic:

[0080] Version consistency determination: ; Time window tolerance judgment: ; Digest consistency check (optional): ; The final formula for judging whether the cache is valid is: ;

[0081] If the result is false, the edge node needs to initiate a data refresh or request an asynchronous update process.

[0082] The replica synchronization nodes use the Raft protocol to achieve strong consistency submission of the binding relationship log, and the core mechanism relies on the majority principle.

[0083] set up is the total number of replica synchronization nodes in the system; The number of replica nodes that currently confirm a log entry; The minimum number of commit quorums required by Raft. In Raft: , only when The log entry is considered to be in the "committed" state only when . If the system deploys a total of 5 replica synchronization nodes, then: Only when at least three replica nodes vote to confirm the log entry can the entry be considered officially submitted.

[0084] The dual stack address mapping relationship recorded by the main control node adopts the following structured key-value mapping method

[0085] , where: UID: user unique identifier (such as MAC address, user name or authentication ID); The IPv4 address assigned to the user; Assigned IPv6 address; is the current version number; The last updated timestamp; Maps a summary value to an address. Example:

[0086] This record indicates that the IPv4 and IPv6 addresses currently assigned to user 001122AABBCC are 192.168.1.100 and 2409:8A10:ABCD::1 respectively. The record version number is 15, the timestamp is 1720000000, and the digest value is hash.

[0087] When the edge node uses the eventual consistency mechanism, the system must ensure that cache synchronization is completed within a reasonable time window. The following formula can be used to evaluate synchronization reliability:

[0088] set up The average frequency of master node updates per unit time, The frequency of edge node detection and synchronization updates per unit time, Edge nodes at time The probability of not getting an update within . It can be approximately modeled as a Poisson process. If synchronization is an independent event, then: , if the edge node synchronizes once every 10 seconds (i.e. ), the probability of unsuccessful synchronization within 30 seconds is:

[0089] , that is, the probability of unsuccessful synchronization within 30 seconds is about 4.98%, indicating that the system has high synchronization reliability under the default delay tolerance window.

[0090] It's important to note that edge nodes don't directly participate in Raft consensus, but instead execute updates based on an eventual consistency model. This allows for brief data lags but ensures global logical consistency is achieved through master-driven synchronization and repair within a reasonable time window. For example, when an edge node receives a binding query request, it determines the data availability based on local cache hits and cache status flags. If the version is outdated or marked as invalid, it can choose to delay the response and pull the latest status, or respond with the old value first and then mark the update as asynchronous.

[0091] Furthermore, to avoid system fragmentation caused by node role division, nodes in the overall layered architecture communicate through a unified internal protocol interface. This protocol defines key elements such as log synchronization format, status notification structure, version verification method, and consistency maintenance strategy. Through the coordinated architecture of strong master consistency, multiple replica backups, and edge fault tolerance, stable and reliable address mapping management is achieved in scenarios with frequent dual-stack address changes, asynchronous propagation, and multi-source access.

[0092] For example, if a user terminal changes its IPv6 address within a short period of time due to a network switch, while its IPv4 address remains unchanged, in the hierarchical structure, the master node can immediately update the mapping relationship and send a synchronization log; the replica node can quickly confirm the update after receiving it; and the edge node can perceive the mapping change through event subscription and refresh the cached response. The entire process does not rely on a single node, thereby improving the robustness and resilience of the system. This layered strategy is the foundation of the subsequent execution layer consistency mechanism.

[0093] S2: After successful user access authentication, the master control node establishes an initial IPv4 and IPv6 address binding based on the access authentication identifier (such as MAC, IMSI, PPPoEID, etc.) and performs a write confirmation of the mapping change using a Raft-like consensus algorithm. After the write, a log entry is generated and pushed from the master control node to the replica nodes, achieving strong write consistency.

[0094] After successful user access authentication, the master control node establishes an initial IPv4 and IPv6 address binding based on the access authentication identifier (such as MAC, IMSI, PPPoEID, etc.) and performs a write confirmation of the mapping change using a Raft-like consensus algorithm. After the write, a log entry is generated and pushed from the master control node to the replica nodes, achieving strong write consistency.

[0095] When a user successfully goes online through the network access authentication process (such as through PPPoE dial-up, DHCP request, 802.1x authentication, etc.), the access network element (such as BNG, BRAS, AGF, 5GC, etc.) will report the authentication success event to the control system. The main control node receives the event and extracts the authentication identification parameters that can be used to uniquely identify the user access session, such as the user's MAC address, IMSI number, PPPoE user name or access interface ID. The authentication identifier constitutes the logical index basis of the address binding relationship. In the data structure, it is usually implemented as a key (Key), and the IPV4 and IPV6 address pairs together constitute its value (Value), forming<User_ID→{IPV4,IPV6}> Structured binding relationship.

[0096] The master control node must ensure the consistency, uniqueness, and updatability of the binding relationship. Therefore, before processing each new binding write request, it must first check whether the same authentication identifier key exists. If a historical binding record exists and is different from the current IPV4 or IPV6 address, the system determines that the address has changed and enters the update process; otherwise, it enters the initial write process. Whether writing or updating, the master control node must convert the operation into a consensus log entry (LogEntry) and push it to the distributed consistency module.

[0097] To ensure the consistency and reliability of write operations in a multi-node system, this solution uses a consensus algorithm based on the Raft model. In the Raft framework, the master control node acts as the leader, responsible for generating log entries containing operation content and distributing them to all replica nodes (Followers). Log entries typically contain the following fields: log number (Index), term number (Term), operation type (write or update), user ID, IPv4 address, IPv6 address, operation timestamp, etc. The master control node sends AppendEntries requests to the replica nodes in parallel. The replica nodes persist the logs to their local buffers and return confirmation responses.

[0098] The master control node counts the number of responses returned and performs write confirmation judgment through the following processing logic:

[0099] Count the number of replica nodes N that have successfully written to the log; if N ≥ (Total_Replicas + 1) / 2 (that is, more than half of the nodes have completed log writing), the log entry is considered to have reached consensus; the commit index (Commit-Index) of the log entry is updated, and the binding relationship write operation is formally committed; the commit status is broadcast to all replica nodes, instructing them to switch from the "pre-write" state to the "formally committed" state; the write result is updated to the master node memory mapping table and change record pool, and the edge nodes or event channels are notified to refresh the cache.

[0100] After receiving the access authentication success event, the main control node generates the following structured mapping record based on the user authentication identifier: , where: UscrID: authentication identifier (such as MAC / IMSI / PPPoEID), IPV4: assigned IP / 4 address, IPV6: assigned IPV6 address, Bind time circle, Version number, used for real-time tracking. Example entry:

[0101]

[0102] Before processing a write request, the master node needs to determine whether there is a binding conflict, that is, whether it is an update or the first write. Addresses in historical binding records : The new address to be written. The judgment formula is: If Conflict=true, it indicates an update request and an update log entry needs to be generated; otherwise, it is the first write request.

[0103] The generated Raft log entries typically contain the following: ,The fields are described as follows: Index: log sequence number; Tcrm: current term number, OpType: operation type (write or update); UscrID: user identification: IPV4, IPV6: address content; Bind time circle.

[0104] The master control node sends AppendEntries requests to all replica nodes concurrently, and the replica nodes perform statistics after returning confirmation.

[0105] set up:

[0106] Returns the number of replica nodes that have been successfully confirmed; is the total number of replica nodes; : The minimum number of replicas required to reach consensus. The Raft consensus judgment formula is: If true, it is considered that the current log entry has reached consensus. The master node will: update CommitIndex; broadcast the commit status; refresh the mapping table and cache queue; and notify the edge node to synchronize or refresh the local cache. When the system deploys 5 replica nodes: , so only 3 nodes need to confirm for the submission to be successful.

[0107] In actual implementation, to improve Raft protocol processing efficiency, an asynchronous callback mechanism can be used to control parallel confirmations. A log index buffer pool with a priority queue can also be used to accelerate the order of log submission. When write pressure increases or log backlogs become significant, the master node can also optimize compression by adjusting log batch size and delaying the write confirmation time window.

[0108] For example, user A accesses the network using a mobile terminal with IMSI 460011234567890. After authentication, the assigned IPv4 address is 100.64.23.5, and the IPv6 address is 2409:8a45:1234:5678::2. The master node generates the following structured log entry and writes it to the local cache and log file: Index: 153245, Term: 27, Operation: UPDATE, User_ID: 460011234567890, IPv4: 100.64.23.5, IPv6: 2409:8a45:1234:5678::2, Timestamp: 2025-08-01 10:52:14. This log entry is then synchronized to the other replica nodes and committed. Once more than half of the copies have been confirmed, the master node writes the user's IPV4 and IPV6 mapping information into the execution layer as the official status, and sends a version stamp notification event to the edge cache node.

[0109] Through the above mechanism, it can be ensured that under the network dual-stack architecture, even if the mapping relationship changes frequently, the system can still achieve atomic writing, strong consistency confirmation and recoverable submission of key binding data in a distributed environment, providing data foundation and operational basis for subsequent edge response, read cache refresh and consistency maintenance.

[0110] S3: To reduce the bandwidth consumption of synchronization links due to high-frequency changes, replica synchronization nodes use an improved Raft protocol, combined with a sliding window mechanism and batch log transmission strategy, to achieve log compression synchronization. During system idle periods, multiple address mapping change logs are aggregated and transmitted in unified packets, reducing synchronization frequency and transmission latency.

[0111] To reduce the bandwidth consumption of synchronization links due to high-frequency changes, replica synchronization nodes use an improved Raft protocol, combined with a sliding window mechanism and batch log transmission strategy, to achieve log compression synchronization. During system idle periods, multiple address mapping change logs are aggregated and transmitted in unified packets, reducing synchronization frequency and transmission latency.

[0112] In a dual-stack environment, the binding relationship between a user's IPv4 and IPv6 addresses is highly dynamic and time-sensitive. This is especially true in scenarios where mobile networks, virtual dial-up, and large-scale access devices frequently go online and offline, and binding information changes frequently. If each change were synchronized to all replica nodes as a single log entry, this would increase link overhead, reduce system throughput, increase confirmation latency, and even interfere with the stability of the consensus process. To address this issue, this step proposes an improved Raft log compression synchronization mechanism that combines log aggregation and a sliding window, improving synchronization efficiency from two dimensions: replica synchronization granularity and sending timing.

[0113] After the master control node completes the binding change write and generates the log entry, the system does not immediately transmit each log entry individually to the replica node. Instead, it uses the Log Aggregation Queue to collect and cache multiple log entries within a short time window to form a batch log block. The batch transmission logic dynamically determines the transmission timing based on the system operation status and is usually triggered when any of the following conditions are met:

[0114] The number of log entries in the current log aggregation queue reaches the set threshold; the maximum sending interval has exceeded since the last log synchronization; the system detects that the network link or processor is currently idle; a pull request from a replica node is received (for example, a follower actively requests logs because the follower status is lagging behind).

[0115] The log aggregation queue is implemented as a FIFO structure, combined with a batch packet generator to form a transmission unit. Each log block carries unified header information, including the start index, end index, log entry count, batch version number, and checksum, to facilitate fast unpacking and integrity verification by replica nodes.

[0116] In terms of transmission control, a sliding window synchronization mechanism (Sliding-Window-Replication-Control) is introduced to limit the number of concurrent unconfirmed log blocks and dynamically adjust the transmission rhythm. The core logic of the sliding window is as follows:

[0117] The window size W is defined, indicating that at any given time, a maximum of W unconfirmed log blocks are allowed to be in the sending state simultaneously. Each time the master node sends a log block, the window slides forward one grid. When an acknowledgment response (ACK) is received from a replica node, indicating that the log block has been persisted, the window releases a grid space. If the window is full, the master node suspends sending new log blocks and waits for the ACK response to free up space.

[0118] This sliding control mechanism effectively avoids network congestion and overload, and allows the master node to perceive network latency and confirmation rate in real time. By calculating the mean and rate of change of the log confirmation interval, the master node can dynamically adjust the window size W, achieving adaptive adjustment to different network conditions.

[0119] For example, in a high-concurrency scenario, the master node can set the window size to 10. Whenever 10 log blocks are sent concurrently, the master node will pause sending and wait for at least 5 replica nodes to confirm success before continuing. When the link is stable and the replica performance is high, the window size can be automatically expanded to 20, further improving the synchronization throughput.

[0120] After receiving the batch log blocks, the replica node verifies the log index continuity and hash summary accuracy in turn. After confirming that they are correct, it writes the log blocks to the local buffer and returns an acknowledgment message (ACK). It then applies them to the local state machine one by one according to the log sequence to update the local IPV4 and IPV6 mapping replica status.

[0121] A typical application scenario of this mechanism is: if 100 users update their IPv6 addresses due to network fluctuations within one minute, the system compresses these updates into about 5 log blocks, each log block contains 20 binding records, and synchronization is completed through only 5 transmissions, which greatly reduces communication and processing overhead compared to the traditional 100 single synchronizations.

[0122] In summary, this step effectively reduces the frequency of log entry transmission through the log aggregation mechanism, and realizes dynamic adjustment and rhythm control of synchronization bandwidth through the sliding window control strategy. At the same time, it greatly improves the replica synchronization efficiency and system responsiveness while ensuring log integrity, providing key high-performance log synchronization support capabilities for building a large-scale distributed IPV4 / IPV6 binding mapping system.

[0123] S4: Edge cache nodes subscribe to the master control node's change event channel and respond to address binding updates using asynchronous notifications and an event-driven mechanism. Each update carries a version stamp and a minimal change summary. Edge nodes compare the version stamps to determine whether to refresh their local cache, ensuring low-latency responses while avoiding frequent write operations.

[0124] Edge cache nodes subscribe to the master control node's change event channel and respond to address binding updates using asynchronous notifications and an event-driven mechanism. Each update carries a version stamp and a minimal change summary. Edge nodes compare the version stamps to determine whether to refresh their local cache, ensuring low-latency responses while avoiding frequent write operations.

[0125] In a distributed address mapping system, edge cache nodes are primarily used to improve the response speed of read access, especially in the face of high-concurrency, short-cycle IPv4 and IPv6 mapping query requests (such as user status queries from edge gateways, address mapping resolution during NAT conversion, etc.). Their performance and cache effectiveness directly affect the overall system throughput and user experience. However, if edge nodes frequently pull data from the main control node or perform invalid cache refresh operations, it will not only bring network bandwidth load, but may also cause state jitter and data inconsistency. Therefore, this step proposes an event-driven asynchronous subscription mechanism, combined with version stamp comparison and difference summary recognition, to achieve efficient perception of address binding changes by edge nodes and minimize updates.

[0126] First, during system initialization, each edge cache node registers as an event subscriber with the master control node, specifying the event types to listen for (e.g., IPv4 / IPv6 address changes, binding additions / deletions, etc.) and the user ID range of interest (e.g., users in the local access zone). The master control node maintains an asynchronous change event channel (Change-Event-Channel) for each event category, which can push change messages based on message queues (e.g., Kafka, RabbitMQ) or lightweight subscription mechanisms (e.g., gRPC streams, WebSocket persistent connections).

[0127] When the main control node completes the update operation of a certain IPV4 and IPV6 address binding relationship, it will generate a change event message. The event message contains at least the following fields: user unique identifier (such as IMSI, MAC, PPPoEID), operation type (bind / update / release), version stamp (VersionToken), timestamp, minimum change summary (DiffSummary), etc. The version stamp is used to describe the logical version of the current binding state. It is recommended to use a composite hash value (such as a hash of the user ID and timestamp) or a monotonically increasing number (such as a log index) to ensure comparability and uniqueness; the minimum change summary is used for compressed transmission and only contains the fields that actually changed in the mapping, such as the comparison between the original IPV6 address and the new address, rather than the full structure. After the edge node receives the change event, it enters the following processing flow:

[0128] Extract the user ID and version stamp from the event message; check whether there is a cache record for the corresponding user in the local cache; if no cache record exists, it is considered as the first load, and the latest data is pulled and stored locally; if a record exists, perform version comparison: if the local version stamp is less than the event version stamp, it means that the data is outdated and enters the refresh process; if the local version stamp is greater than or equal to the event version stamp, no refresh is required and the update process is skipped; after entering the refresh process, use the minimum change summary to perform field-level overwrite updates, replacing only the changed address fields rather than rewriting the entire cache object; update the version stamp of the local cache object and record the change event processing status (such as adding a status log or triggering an update callback).

[0129] Through this mechanism, edge nodes can effectively avoid invalid write operations and excessive refreshes, reducing the frequency of pull requests to the master node. They can also fine-tune updates at the granularity level, updating only the fields that actually change (e.g., only the IPv6 address changes, while the IPv4 remains unchanged). This strategy is particularly effective in reducing system load when system resources are limited or link bandwidth is tight, ensuring overall system performance, consistency, and stability.

[0130] For example, if a user's IPv6 address changes due to network reselection, while their IPv4 address remains unchanged, the master node generates a change event with a version stamp of "V202508011045" and sets the change summary to {IPv6: "old address" → "new address"}. The edge node compares the locally cached version to "V202508011042," which is lower than the current version. Therefore, it can overwrite and update only the IPv6 field, without having to rewrite or retrieve all binding information.

[0131] In summary, the edge response mechanism based on asynchronous subscription and version stamp comparison not only significantly improves the accuracy and efficiency of data updates, but also provides a highly controllable edge consistency guarantee capability for large-scale distributed dual-stack address mapping systems, with strong engineering adaptability and scalability.

[0132] S5: To prevent data deviations on edge or replica nodes due to disconnections, latency, and errors, the system periodically performs state consistency checks. If a deviation exceeds a set threshold, an incremental patch synchronization policy is automatically triggered. If the version gap is too large or the consistency assessment fails, the master control node initiates a full snapshot transfer for rapid rollback and recovery.

[0133] To prevent data deviations at edge or replica nodes due to disconnections, latency, or errors, the system periodically performs state consistency checks. If a deviation exceeds a set threshold, an incremental patch synchronization policy is automatically triggered. If the version gap is too large or the consistency assessment fails, the master control node initiates a full snapshot transfer for rapid rollback and recovery.

[0134] In a distributed address mapping management system, various factors, such as network instability, node load fluctuations, physical link interruptions, or abnormal system restarts, can cause state information on edge cache nodes and replica synchronization nodes to deviate from that of the master control node. This can lead to query errors in user address binding relationships, state rollbacks, and even consistency violations. To improve the long-term stability and data consistency of the system, this step designs a periodic state consistency check mechanism. This mechanism, combined with incremental patch synchronization and full snapshot recovery strategies, provides a hierarchical repair capability for varying degrees of deviation.

[0135] The system uses a unified state consistency check scheduler, which performs state consistency checks across all active replica nodes and edge nodes at fixed intervals (e.g., every 10 minutes, every hour) or dynamically scheduled conditions (e.g., increasing change frequency, increasing abnormal events). During verification, each node pulls a lightweight summary (StateDigest) from the master control node. This summary contains: the index number of the latest commit log; the current state version stamp; a hash digest value (typically generated by sorting the binding table fields and then performing a hash); the timestamp of the last verification; and the node status label (e.g., healthy, delayed, or partially lost).

[0136] After receiving the summary information, the node compares the local state and performs consistency judgment according to the following logic:

[0137] Log index comparison: If the local log index lags behind the master node by more than a set threshold (for example, 50 log entries), the node is initially judged to be in a "version lagging" state and enters the incremental patch evaluation phase;

[0138] Version stamp comparison: If the state version number recorded by the node is lower than the master node version number, and the corresponding log content is missing or discontinuous, it is judged as "possible link break or data loss" and snapshot synchronization is given priority;

[0139] Hash value verification failure: If the state hash values ​​generated by the master node and the current node for the same user set are inconsistent, it indicates that there is a field-level offset or structural damage, and a strong consistency verification process needs to be initiated;

[0140] Exceeding the limit for consecutive verification failures: If a node shows inconsistencies in multiple consecutive verifications, the system will mark it as an "abnormal node" and enter the snapshot reset process.

[0141] Based on the above judgment results, the system selects the corresponding repair path. The processing logic is as follows:

[0142] Incremental-Patch-Sync: This method is suitable for scenarios where log latency is minimal and the data structure is intact, but some fields or entries are out of sync. The master node constructs a patch package containing all missing log entries and pushes it to the target node. The target node then applies the logs in order to restore the state. The patch package contains the log index, operation type, field differences, and checksum. After application, a new version stamp is generated and the status flag is updated. This method is suitable for scenarios with broken log indexes, abnormal status fields, severe hash conflicts, or unrecoverable node state. The master node generates a snapshot file of the current full state, including all user bindings, version stamps, system flags, and complete index information. The target node clears its local state, loads the snapshot, and restores to the latest state, then participates in the normal synchronization process. Checksum verification and resuming transfers are supported during snapshot transfer to ensure data integrity.

[0143] For example, a replica node lost update records from log index 8601 to 8650 due to a disk error. Its status version was "V202507311245," while the master node's current status was "V202508011030." During periodic verification, this was identified as a "version lag + log fragmentation" state. The system determined that the incremental patch could not be fully restored and instead pushed the latest snapshot package, "snapshot-V202508011030." After the target node was loaded, it reset its status table and restored synchronization capabilities.

[0144] To further enhance robustness, the system can also configure differentiated verification strategies based on node type. For example, replica nodes employ strict consistency verification standards, performing log and hash comparisons at all times; edge cache nodes focus on version stamp comparisons and latency assessments, allowing for short-term deviations but requiring regular forced refreshes. Furthermore, all verification records are stored in the system log for auditing and anomaly analysis.

[0145] By designing sophisticated state deviation identification logic and hierarchical repair paths, we balance data integrity and recovery capabilities while ensuring synchronization efficiency, effectively solving the problem of distributed state drift caused by unstable communication or system failures, and providing a key self-healing mechanism for the long-term stable operation of the dual-stack address mapping system.

[0146] S6: The system monitors user write behavior and change frequency in real time, identifying "hotspot users" whose address bindings frequently change. For these users, a traffic partitioning arbitration mechanism is used to dynamically assign different replica groups as their primary write paths. The system also adjusts the weight of their consensus nodes to alleviate the concentrated write pressure on the master node and improve overall processing capacity.

[0147] The system monitors user write behavior and change frequency in real time, identifying "hotspot users" whose address bindings frequently change. For these users, a traffic partitioning arbitration mechanism is used to dynamically assign different replica groups as their primary write paths. The system also adjusts the weight of their consensus nodes to alleviate the pressure of concentrated writes on the master node and improve overall processing capabilities.

[0148] In the dual-stack address mapping management system, the write operation of the user address binding relationship is characterized by low frequency and stability in most cases. However, some users may trigger high-frequency binding write or update operations in a short period of time due to frequent network switching, IP rebinding, abnormal terminal behavior or special business needs. If such "hot users" are uniformly handled by a single master node and a fixed replica group, it will cause resource concentration, write queue delays, and even blockage and failure of the consensus mechanism, seriously affecting the scalability and load balancing capabilities of the system. To this end, the system introduces a hotspot identification and traffic partition arbitration mechanism to dynamically migrate loads and reconstruct write paths for high-write users, thereby achieving elastic regulation of distributed processing pressure.

[0149] First, the system builds a user write behavior monitoring module to collect real-time metrics such as the frequency of write requests per user per unit time, the number of consecutive changes, and the number of consensus log entries triggered. This data is aggregated and statistically analyzed by time window (e.g., the last 5 minutes, 30 minutes, or 2 hours). When a user's hotspot score exceeds the preset HOT_THRESHOLD threshold, the system marks them as a hotspot user and triggers the write path arbitration logic. The arbitration module selects replica groups with high resource idleness from the current replica topology and constructs a "user-replica group" write mapping table. This mapping table can be implemented using consistent hashing or a load-aware routing table to ensure a dynamic, low-conflict, and highly balanced mapping relationship between hotspot users and replica resources.

[0150] Once the arbitration adjustment is completed, the master control node will route the hotspot user's write operations to the newly assigned replica group. The elected local master node within the group will be responsible for processing the writes and participating in the subset consensus process. To ensure that the master node can still grasp the global state, each local write still needs to submit a read-only copy or status summary to the master node to maintain the coordination of the logical master and the consistency root. The system can also dynamically adjust the consensus weight parameters of the nodes within the replica group to improve their write priority and processing capabilities, such as increasing the size of their log replication thread pool, cache reserved space, or the lower limit of the response timeout.

[0151] Due to signal fluctuations on a 5G mobile network, a certain terminal experienced frequent IPv6 address changes, with binding updates occurring every 10 seconds. The system detected that the user had initiated 60 binding change requests within 10 minutes, resulting in a hotspot score of 102, exceeding the set threshold of 90. The arbitration module selected replica group R3 (containing nodes N7, N8, and N9) as the new write path, assigning a write weight of 1.5. N7 within replica group R3 served as the temporary write coordination node, responsible for handling log aggregation and status confirmation. The master node only received summary confirmation packets and periodically aggregated log indexes. This strategy successfully shifted write pressure from the primary node to the edge replica domain, improving the system's overall concurrency and reducing write latency.

[0152] This mechanism enables dynamic routing and load migration of write paths, preventing concentrated write traffic impacts on physical or logical structures. Furthermore, by assessing hotspot levels, dynamically selecting groups, and adjusting weights, the system implements a collaborative processing strategy of "distribution on demand, real-time regulation," ensuring high-performance, high-elasticity, and scalable execution for IPv4 and IPv6 mapping write requests in complex access environments. This mechanism also provides a sound data distribution foundation for subsequent data consistency maintenance (such as state snapshot synchronization and edge cache updates).

[0153] S7: The system is designed with a state deviation evaluation function that regularly calculates the consistency deviation score based on indicators such as version stamps, log entries, and snapshot hashes between the master node and each replica node. Once the deviation exceeds the set tolerance, the "light patch synchronization" or "full snapshot replacement" strategy can be automatically selected to ensure that the logical consistency of the mapped data is not destroyed. The system is designed with a state deviation evaluation function that regularly calculates the consistency deviation score based on indicators such as version stamps, log entries, and snapshot hashes between the master node and each replica node. Once the deviation exceeds the set tolerance, the "light patch synchronization" or "full snapshot replacement" strategy can be automatically selected to ensure that the logical consistency of the mapped data is not destroyed.

[0154] In an IPv4 and IPv6 address mapping management system for large-scale multi-node deployments, to ensure that network-wide mapping data maintains logical consistency during dynamic updates, the state consistency between master and replica nodes must be periodically evaluated and quantified. Due to factors such as asynchronous network transmission, node load fluctuations, and log propagation delays, replica states may experience varying degrees of lag, offset, or field inconsistency. Therefore, this step proposes designing and running a state-divergence evaluation function to accurately measure the degree of synchronization consistency of replica nodes relative to the master node, and based on this, determine whether to trigger compensation operations and what synchronization strategy to adopt.

[0155] The evaluation dimensions of this function include but are not limited to the following three indicators:

[0156] Version stamp offset (version_drift): the difference between the version identifiers of the data structure or snapshot currently maintained by the master node and the replica node;

[0157] Log entry gap (log_gap): The gap between the last log index value of the replica node and the master node in the consensus log sequence;

[0158] State snapshot hash consistency (hash_match): Calculates a digest hash value for the current state mapping table contents and checks its consistency with the master node's hash. The three metrics above are mapped to a unified deviation scoring model, calculated as: score = weight_v * normalize(version_drift) + weight_l * normalize(log_gap) + weight_h * (1-hash_match). The normalize(...) function normalizes the raw values ​​to the range of 0 to 1. weight_v, weight_l, and weight_h are the weighting coefficients for version drift, log lag, and hash inconsistency, respectively. The resulting score represents the consistency deviation score, with higher values ​​indicating more inconsistent node states.

[0159] The system sets a consistency tolerance threshold for each replica node (for example, the default value is 0.6). After each execution of the above function, if the node score exceeds the threshold, it will be marked as "deviation abnormal" and a repair strategy will be automatically selected. The repair strategy selection logic is as follows:

[0160] If the version offset and log gap are both at a low to medium level and hash consistency still exists, the system prioritizes the lightweight patch synchronization strategy (Incremental-Patch). That is, the master node only sends the missing log entries and key field update values ​​to the replica node, and the replica node applies the repair patch in sequence to restore state consistency.

[0161] If the hash is inconsistent, or the log is broken or the version is seriously lagging (such as the loss of multiple key log segments), the system will initiate the full snapshot replacement strategy (Snapshot-Replace). The master node will generate the latest full state snapshot and send it to the replica node in its entirety. The replica node will clear the current state and overwrite the snapshot content.

[0162] For example, the current version stamp of a replica node is V10201, the master node is V10215, the log gap is 12, and the status hash comparison fails. The calculation results are as follows: version_drift=14, log_gap=12, hash_match=0.

[0163] If the weight configuration is: version weight 0.4, log weight 0.4, hash weight 0.2, and the normalized score is 0.93 (exceeding the tolerance threshold of 0.6), the system determines that a full snapshot replacement is required and triggers the corresponding synchronization module to fully reconstruct the replica state.

[0164] In addition, to ensure performance and security, status deviation evaluation can be scheduled according to role priority. For example, the master node performs high-frequency evaluation on key replica nodes (such as followers participating in voting) and low-frequency or lazy evaluation on edge auxiliary nodes. Some replica nodes can reduce the burden on the master by actively reporting their own status summaries.

[0165] In summary, this step can dynamically perceive the state drift risk in the distributed system by constructing a deviation assessment function that quantifies multi-dimensional indicators and performs normalized weighted aggregation, and select the corresponding synchronization strategy according to the severity, thereby achieving efficient consistency recovery without relying on global resynchronization, providing refined and integrated state health monitoring and maintenance capabilities for large-scale dual-stack address mapping systems.

[0166] S8: In a continuous system operation and multi-site deployment environment, the integrated mechanisms of steps S2-S7 form a complete execution-layer consistency maintenance closed loop. Combining strong master consistency, replica redundancy, edge tolerance, compression synchronization, event subscription, patch compensation, and deviation assessment strategies, this forms a dynamic and autonomous multi-source consistency assurance system, effectively supporting the real-time, highly available, and maintainable deployment of IPv4 and IPv6 dual-stack address associations in large-scale distributed scenarios.

[0167] In an environment of continuous system operation and multi-site deployment, the integrated mechanisms of steps S2–S7 form a complete closed loop for execution-layer consistency maintenance. Combining strong master consistency, replica redundancy, edge tolerance, compression synchronization, event subscription, patch compensation, and deviation assessment strategies, this forms a dynamic, autonomous, multi-source consistency assurance system, effectively supporting the real-time, highly available, and maintainable deployment of IPv4 and IPv6 dual-stack address associations in large-scale distributed scenarios.

[0168] This step serves as the finishing touch to the consistency maintenance of the entire system's execution layer logic. Its core goal is to build a mapping relationship consistency closed-loop mechanism that operates stably over the long term, has strong self-repair capabilities, and offers efficient cross-domain collaboration. Based on S2 to S7, the system has implemented various functional modules, from master control writes to edge responses, and from log synchronization to state deviation repair. However, in large-scale and multi-region deployment environments, truly achieving stable and controllable data consistency guarantees requires not only that each step operate independently and stably, but also that they be integrated into a dynamic and autonomous consistency maintenance closed-loop system through a unified strategy and scheduling mechanism.

[0169] The implementation of a closed loop relies on the system's precise control over the entire write and distribution lifecycle. First, the master node guarantees strongly consistent writes based on a Raft-like protocol (S2), ensuring that every change to the IPv4 / IPv6 address binding relationship is globally ordered and replicable. Second, replica nodes use an improved compression synchronization mechanism to update logs using a sliding window and batch transmission method (S3), improving throughput while ensuring accurate data dissemination. Finally, through the event subscription and version-driven mechanism of edge cache nodes (S4), rapid feedback and change awareness are achieved for high-frequency read operations, avoiding redundant writes and access blockage. The system then regularly performs consistency checks on node states (S5), accurately identifying deviations by comparing log indexes, version stamps, hash digests, and other indicators. Based on the deviation level, the system then repairs the deviation using multi-level synchronization methods such as incremental patches or snapshot reconstruction. Furthermore, a user-level write heat recognition mechanism (S6) is introduced to automatically identify hot users and reconstruct their write paths and replica resource allocation to avoid write congestion. Finally, a state deviation evaluation function (S7) regularly calculates the global deviation level and dynamically controls the synchronization rhythm, thus closing the write-synchronization-evaluation-repair control chain.

[0170] The operation of this closed-loop mechanism involves the real-time linkage of multiple internal subsystems. For example, at the control and scheduling layer, the system designs a "synchronization scheduling engine (SyncScheduler)" that continuously monitors the status metadata reported by various nodes (such as latency indicators, version updates, data hit rates, etc.) and controls synchronization priorities and paths:

[0171] During the scheduling process, the system dynamically allocates processing resources, limits the frequency of low-value synchronization tasks, and prioritizes data consistency along critical paths. Furthermore, a two-way healthy channel is established between the master and replica nodes through an asynchronous link + confirmation feedback mechanism. This ensures that if synchronization failures, version drift, or abnormal network latency occur, the system can quickly respond, flag the fault, and trigger a fault-tolerant repair process.

[0172] At the operational level, the closed-loop mechanism also supports visual display of system consistency status and automatic alarms. If the deviation rate continues to rise or a node fails multiple rounds of verification, the system will prompt administrator intervention through alarm channels (such as Syslog, Prometheus alerts, and visualization panels). Detailed diagnostic information will also be generated, including the discrepancy log segment, the ID of the out-of-sync node, and repair suggestions.

[0173] For example, in a nationwide carrier network, data center nodes distributed across different regions each maintain edge caching and replica writing tasks. When network jitter and edge node cache lag occur in a certain region, the master node, through an evaluation function, discovers a serious deviation in its state hash value and triggers a full snapshot push. However, if a replica node in another region experiences only three log delays, it automatically employs an incremental patch strategy for rapid repair. This entire process requires no human intervention; the system automatically schedules and tracks the state recovery process based on the policy function, achieving a truly closed-loop consistency maintenance system in a multi-source, multi-node environment.

[0174] In summary, S8 defines not only a simple execution logic encapsulation, but also aggregates the capabilities of each module into an evolvable, fault-tolerant, and consistency-enhanced dynamic governance framework through logical linkage and policy-driven methods. It can continuously support the accurate management and stable distribution of IPV4 and IPV6 address binding relationships under large-scale user concurrency, high-frequency data changes, and complex network environments. It is the key mechanism core to support the dual-stack evolution of future Internet basic services and the improvement of operational governance capabilities.

[0175] Throughout this specification, references to terms such as "one embodiment," "example," or "specific example" indicate that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of the present invention. In this specification, schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0176] The preferred embodiments of the present invention disclosed above are intended only to help illustrate the present invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the present invention to specific embodiments. Obviously, many modifications and variations are possible based on the contents of this specification. These embodiments are selected and described in detail in this specification to better explain the principles and practical applications of the present invention, thereby enabling those skilled in the art to better understand and utilize the present invention. The present invention is limited only by the claims and their full scope and equivalents.

Claims

1. A method for managing the correspondence between IPV4 and IPV6 addresses of a single user in a dual-stack network, characterized by: The management method comprises the following steps: S1: Divide the network system nodes into master control nodes, replica synchronization nodes, and edge cache nodes, which are used for core writing, replica synchronization, and edge response, respectively, to build a hierarchical management architecture; S2: After the user accesses, the master control node establishes an IPv4 and IPv6 address binding relationship based on the authentication identifier, completes the writing and generates a synchronization log through a Raft-like consensus mechanism; S3: Replica nodes use the improved Raft protocol, combining sliding windows with batch logs to transmit write records, achieving synchronous compression and latency reduction. S4: The edge node asynchronously subscribes to the master control node change event and determines whether to refresh the local cache based on the version stamp; S5: Regularly check the data consistency between network system nodes. If the deviation exceeds the limit, trigger patch synchronization or full snapshot recovery to synchronize the data. S6: Identify hotspot users with frequent writes, implement traffic partitioning and path arbitration strategies, dynamically allocate replica groups, and reduce pressure on the master control node. S7: Construct a state deviation evaluation function, determine the consistency level based on the version and hash information, and select the corresponding synchronization strategy to maintain logical consistency; S8: The mechanisms of steps S2-S7 are integrated to form a closed loop for consistency maintenance at the execution layer, and manage the mapping relationship between IPv4 and IPv6 addresses in a distributed environment.

2. The method for managing the correspondence between IPv4 and IPv6 addresses of a single user in a dual-stack network according to claim 1, wherein: Step S5: Regularly check the data consistency between network system nodes. If the deviation exceeds the limit, trigger patch synchronization or full snapshot recovery to synchronize the data, including the following steps: The master control node provides a status summary for each verified node; After receiving the state summary, the verified node calculates the consistency deviation and executes a repair strategy based on the calculation result. The execution of the repair strategy includes: If the log lag is within the tolerance range, the master control node pushes an incremental patch package containing missing log entries and field difference information. The target nodes then restore the status and update the version stamp in sequence. If the hash is abnormal or the log is broken, the master control node generates and pushes a full snapshot, and the target node clears the current state and loads the snapshot to restore the mapping data.

3. The method for managing the correspondence between the IPv4 and IPv6 addresses of the same user of a dual-stack network according to claim 2, wherein: After receiving the state summary, the verified node calculates the consistency deviation: If the log index lags behind the master control node by more than the set threshold, it is marked as version lag; If the version stamp is significantly behind and the log record is missing, it is considered to be in a log-fragmented state; If the hash values ​​do not match, it is determined that the state structure is abnormal; If multiple rounds of verification fail consecutively, the node will be marked as an abnormal node.

4. The method for managing the correspondence between the IPv4 and IPv6 addresses of the same user of a dual-stack network according to claim 3, wherein: Step S6: Identify hotspot users with frequent writes, adopt traffic partitioning and path arbitration strategies, dynamically allocate replica groups, and reduce the pressure on the main control node. This includes the following steps: Collect the address binding relationship write operation frequency, continuous change number and consensus log entry trigger number of each user in real time, and calculate the hotspot score based on the set time window; When the hotspot score exceeds a preset threshold, the user is marked as a hotspot user, a target replica group with low resource load is dynamically selected from multiple replica synchronization node groups, and a write mapping relationship between the user and the replica group is established; During the write process, the master control node no longer participates in the log write consensus process, but receives the write summary or read-only confirmation package submitted by the target replica group; The consensus weight, log buffer configuration and processing thread resources of each node in the replica group are dynamically adjusted according to the access intensity of the hotspot users and the load status of the replica group.

5. The method for managing the correspondence between IPV4 and IPV6 addresses of the same user of a dual-stack network according to claim 4, characterized in that: The write mapping relationship is constructed based on a consistent hash map or a load-aware routing table, and is used to direct subsequent binding relationship write requests of hotspot users to the target replica group; The target replica group elects a local master node to perform write processing and complete subset consensus confirmation within the replica group.

6. The method for managing the correspondence between IPv4 and IPv6 addresses of a single user in a dual-stack network according to claim 1, wherein: Step S7: Construct a state deviation evaluation function, determine the consistency level based on the version and hash information, and select the corresponding synchronization strategy to maintain logical consistency, including the following steps: The master control node periodically performs a state consistency evaluation on each replica node and calculates a consistency deviation score based on at least three types of indicators. The calculation method is: The version offset, log entry gap, and hash inconsistency status are weighted separately to form a unified deviation score. If the deviation score of a replica node exceeds the preset tolerance threshold, it will be marked as a deviation anomaly, and a compensation synchronization strategy will be selected based on the specific performance of various indicators: If the log lag and version offset are at a low to medium level and the hashes are consistent, the lightweight patch synchronization strategy is selected to send the missing log entries and changed fields saved by the master control node to the replica nodes in the form of patches; If the hash check fails or the log is broken, the full snapshot replacement strategy is selected. The master control node generates a snapshot of the current state and transmits it to the target replica node for full state reconstruction.

7. The method for managing the correspondence between IPv4 and IPv6 addresses of a single user in a dual-stack network according to claim 6, wherein: The version stamp offset represents the difference between the state versions currently recorded by the master control node and the target replica node; the log entry gap represents the gap value of the consensus log index between the master control node and the target replica node; the state snapshot hash consistency represents whether the hash values ​​calculated by the master control node and the replica node for the binding relationship snapshot data structure are consistent.

8. The method for managing the correspondence between IPv4 and IPv6 addresses of a same user in a dual-stack network according to any one of claims 1 to 7, characterized in that: Step S2: After the user accesses, the master control node establishes an IPv4 and IPv6 address binding relationship based on the authentication identifier, completes writing and generates a synchronization log through a Raft-like consensus mechanism, including the following steps: After the user access authentication is successful, the main control node receives the user authentication information reported by the access network element and extracts the authentication identification parameters as binding indexes, including but not limited to MAC address, IMSI number, PPPoEID or access interface identifier; The master control node establishes a corresponding IPv4 and IPv6 address binding relationship based on the authentication identifier, and determines whether the binding is newly created or updated; The master control node uses a Raft-like consensus mechanism to send the log entry to multiple replica synchronization nodes. The replica nodes write the log locally and return a confirmation response. When the master control node receives confirmation from the number of replicas that meet the consensus conditions, it updates the submission index, performs the binding operation submission, and broadcasts the submission status to all replica nodes.

9. The method for managing the correspondence between IPv4 and IPv6 addresses of a single user in a dual-stack network according to claim 8, wherein: Step S3: The replica node uses the improved Raft protocol, combined with sliding windows and batch logs to transmit write records, to achieve synchronous compression and latency reduction, including the following steps: After the master control node completes the user address binding change operation, it generates the corresponding log entry and adds it to the log aggregation queue; In the log aggregation queue, multiple log entries are merged into batches of log blocks when preset conditions are triggered. Trigger conditions include: the number of log entries reaches a preset threshold, the last synchronization interval exceeds the upper limit, the idle period occurs, or a replica node requests log synchronization. The master control node sends batches of log blocks to the replica synchronization node through a sliding window mechanism. The sliding window is used to limit the number of unconfirmed log blocks transmitted concurrently and dynamically release the window capacity based on the confirmation response of the replica node.

10. The method for managing the correspondence between IPv4 and IPv6 addresses of the same user of a dual-stack network according to claim 9, characterized in that: Step S4: The edge node asynchronously subscribes to the master control node change event and determines whether to refresh the local cache based on the version stamp, including the following steps: The edge cache node registers as an event subscription node with the main control node and specifies the event type and user range of interest; After receiving the event message, the edge cache node extracts the user ID and searches for the corresponding binding record in the local cache. If no record exists, it pulls the complete binding data to build the initial cache; if the record exists, it performs a version stamp comparison: When the local version stamp is smaller than the event version stamp, the data is considered outdated and enters the refresh process; When the local version stamp is greater than or equal to the event version stamp, the update operation is skipped.

Images