Strategy negotiation method, device and equipment of distributed system and storage medium

Abstract

The invention discloses a policy negotiation method and device for a distributed system, equipment and a storage medium, and the method comprises the steps: constructing a policy negotiation session, dividing to-be-interacted equipment information into a plurality of batches according to a preset message format, and packaging the to-be-interacted equipment information to obtain a plurality of policy negotiation messages; transmitting the plurality of negotiation messages to a target device node, and integrating a plurality of policy negotiation messages belonging to the same policy negotiation session to obtain a complete policy set to be negotiated; calling a state machine to process the to-be-negotiated strategy set, determining a corresponding strategy negotiation result, and returning a strategy response message; and storing a negotiation result in a main storage area and a standby storage area which are logically isolated according to the strategy response message. According to the invention, the to-be-interacted equipment information is divided into a plurality of batches to be packaged and transmitted, so that a traditional serial mode of one-by-one processing is changed, and the overall negotiation period is effectively shortened by improving the data throughput of single communication.

Description

Technical Field

[0001] This application relates to the field of strategy negotiation technology, and more specifically, to a strategy negotiation method, apparatus, device, and storage medium for a distributed system. Background Technology

[0002] In the fields of distributed computing and network communication, as system scale and complexity continue to increase, collaborative work among multiple device nodes has become the norm. To achieve efficient and orderly data interaction and task processing, nodes must reach an agreement on key parameters such as communication rules, resource allocation, and security policies; this process is called "policy negotiation." An effective policy negotiation mechanism is fundamental to ensuring the stable operation of distributed systems and achieving their intended functions, and is particularly important in industrial control, IoT, and edge computing scenarios that require high reliability and real-time performance.

[0003] Currently, the conventional approach to policy negotiation in distributed systems typically relies on a simple request-response pattern. Specifically, the device node initiating the negotiation encapsulates its local policy information into a message of a specific format and sends it to the target node over the network. The target node receives and parses the message, generates a response based on its content, and returns it. Both parties reach a local consensus based on the exchanged information and update their respective policy configurations accordingly. To achieve basic multi-policy processing, existing technologies often employ a sequential processing method, i.e., sending policy entries one by one, receiving confirmations for each entry, and directly overwriting the original policy storage area after negotiation is complete.

[0004] However, the aforementioned existing technologies have significant drawbacks. First, the method of negotiating policy one by one is inefficient when dealing with a large number of policies, resulting in severe accumulated network round-trip latency and an excessively long overall negotiation cycle, making it difficult to meet the needs of applications with high real-time requirements. Second, during the negotiation process, the replacement of old and new policies often adopts a direct overwrite approach, which can easily lead to brief but severe policy inconsistencies when distributed nodes are not synchronized in their policy updates, resulting in data packet loss or service interruption. Furthermore, the simple flow control logic is unable to effectively handle common anomalies in network transmission such as packet loss, out-of-order delivery, and timeouts, resulting in insufficient system robustness. Summary of the Invention

[0005] To address at least one deficiency or improvement need in the prior art, the present invention provides a policy negotiation method, apparatus, device, and storage medium for a distributed system, which solves the problems of low efficiency when processing a large number of policies, excessively long negotiation cycles, difficulty in meeting the real-time requirements of application scenarios, direct overwriting of old and new policies, and easy occurrence of brief but serious policy inconsistencies, leading to data packet loss or service interruption.

[0006] To achieve the above objectives, according to a first aspect of the present invention, a strategy negotiation method for a distributed system is provided, the method comprising: Construct a policy negotiation session, and encapsulate the information of the devices to be interacted with into multiple batches according to a preset message format to obtain multiple policy negotiation messages; Multiple negotiation messages are transmitted to the target device node, and multiple policy negotiation messages belonging to the same policy negotiation session are integrated to obtain a complete set of policies to be negotiated. The state machine is invoked to process the set of policies to be negotiated, determine the corresponding policy negotiation result, and return a policy response message. The negotiation results are stored in logically isolated primary and backup storage areas according to the strategy response message.

[0007] In one possible implementation, a policy negotiation session is constructed, and the information of the devices to be interacted with is divided into multiple batches and encapsulated according to a preset message format to obtain multiple policy negotiation messages, which also include: The maximum number of policy entries that a single policy negotiation message can carry is determined based on the maximum capacity of the network transmission unit. Based on the maximum number of policy entries, all policy entries corresponding to the information of devices to be interacted with are divided into several consecutive batches; Each batch is assigned a unique sequence number within this policy negotiation session, and this sequence number is encapsulated with the corresponding policy entry to obtain multiple policy negotiation messages.

[0008] In one possible implementation, multiple negotiation messages are transmitted to the target device node, and multiple policy negotiation messages belonging to the same policy negotiation session are integrated to obtain a complete set of policies to be negotiated, which also includes: Policy negotiation messages carrying sequence numbers are transmitted to the target device node in batches via the transmission network; The policy negotiation message is parsed, and the parsed policy entries are stored in the shared buffer. Retrieve policy entries from the shared buffer by sequence number and reassemble them into a complete set of policies to be negotiated.

[0009] In one possible implementation, the state machine is invoked to process the set of policies to be negotiated, determine the corresponding policy negotiation result, and return a policy response message. This also includes: The predefined states of a state machine include a set of states such as ready, negotiating, and waiting for a response. When the state machine is in the ready state, receiving the complete set of policies to be negotiated will trigger the state transition to the negotiation state and execute the policy matching logic. After the initial negotiation result is generated in the state during the negotiation, the state machine transitions to the waiting for response state and triggers the sending of the policy response message.

[0010] In one possible implementation, the state machine is invoked to process the set of policies to be negotiated, determine the corresponding policy negotiation result, and return a policy response message. This process also includes: The state machine starts a timer while waiting for a response; If a policy response message is received from the other end before the timer expires, the state machine transitions to the result integration state and determines the final policy negotiation result based on the response message. If the timer times out, the state machine transitions back to the negotiation state and triggers the retransmission mechanism.

[0011] In one possible implementation, the negotiation result is stored in logically isolated primary and backup storage areas according to the policy response message, and the implementation also includes: Write the determined set of negotiation results into the storage area currently designated as standby; After verifying that the write operation is correct, a storage area switching operation is performed, setting the standby storage area to the primary state and setting the original primary storage area to the standby state.

[0012] In one possible implementation, the storage area switching operation, which sets the standby storage area to the primary state and the original primary storage area to the standby state, further includes: Suspend read access requests to the policy storage area and swap the logical identifiers of the primary and standby storage areas; Resume read access requests to the policy storage area, and direct all policy query operations to the primary storage area after the identity swap.

[0013] According to a second aspect of the present invention, a policy negotiation apparatus for a distributed system is also provided, the method comprising: The information encapsulation module is configured to construct a policy negotiation session by dividing the device information to be interacted into multiple batches and encapsulating them according to a preset message format to obtain multiple policy negotiation messages. The policy integration module is configured to transmit multiple negotiation messages to the target device node and integrate multiple policy negotiation messages belonging to the same policy negotiation session to obtain a complete set of policies to be negotiated. The strategy negotiation module is configured to call the state machine to process the set of strategies to be negotiated, determine the corresponding strategy negotiation result, and return a strategy response message. The policy storage module is configured to store the negotiation results in logically isolated primary and backup storage areas based on the policy response message.

[0014] According to a third aspect of the present invention, a policy negotiation device for a distributed system is also provided, comprising at least one processing unit and at least one storage unit, wherein the storage unit stores a computer program, and when the computer program is executed by the processing unit, the processing unit performs the steps of any of the above-described policy negotiation methods for a distributed system.

[0015] According to a fourth aspect of the present invention, a storage medium is also provided, which stores a computer program executable by a policy negotiation device of a distributed system, wherein when the computer program is run on the policy negotiation device of the distributed system, the policy negotiation device of the distributed system performs the steps of any of the above-described policy negotiation methods of the distributed system.

[0016] In summary, compared with the prior art, the above-described technical solutions conceived by this invention can achieve the following beneficial effects: This invention provides a strategy negotiation method for distributed systems. By dividing the information of devices to be interacted with into multiple batches for encapsulation and transmission, the number of network communication rounds is reduced. A large number of fragmented strategy entries are integrated into a limited number of message exchanges to complete the negotiation. By increasing the data throughput of a single communication, the overall negotiation cycle is effectively shortened. A state machine is used to manage the negotiation process, introducing clear logical states and controlled state transitions into the strategy negotiation process. This enables precise responses to various events and the execution of corresponding processing logic. The introduction of the state machine standardizes and modularizes the complex negotiation process, improving controllability and predictability. Its embedded retransmission and other fault-tolerance mechanisms further enhance the robustness of the negotiation process in the face of network anomalies, avoiding the failure of the entire negotiation due to temporary faults. By establishing logically isolated primary and standby storage areas and updating policy results on this basis, the new negotiation results are written to the inactive standby storage area during the update. Subsequently, a switching operation is performed to convert it into the primary storage area. This ensures that at the moment of policy switching, there is always a complete and consistent set of policies available. This eliminates the policy inconsistency window caused by asynchronous policy updates or during the overwrite process, prevents data packet loss or service interruption, and improves service continuity during system updates. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating an embodiment of the strategy negotiation method for a distributed system provided by the present invention; Figure 2 Provided by the present invention Figure 1 A schematic flowchart of an embodiment of step S101; Figure 3 Provided by the present invention Figure 1 A schematic flowchart of an embodiment of step S102; Figure 4 A schematic diagram of the structure of an embodiment of the strategy negotiation device for a distributed system provided by the present invention; Figure 5 This is a schematic diagram of the structure of a policy negotiation device in a distributed system provided in an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the 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 merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0020] The terms "first," "second," "third," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0021] This invention provides a strategy negotiation method, apparatus, device, and storage medium for a distributed system, which will be described below.

[0022] Please see Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the strategy negotiation method for a distributed system provided by the present invention. In a specific embodiment of the present invention, a strategy negotiation method for a distributed system is disclosed, the method comprising: S101. Construct a policy negotiation session, and encapsulate the information of the device to be interacted into multiple batches according to the preset message format to obtain multiple policy negotiation messages. S102. Transmit multiple negotiation messages to the target device node and integrate multiple policy negotiation messages belonging to the same policy negotiation session to obtain a complete set of policies to be negotiated. S103. Call the state machine to process the set of policies to be negotiated, determine the corresponding policy negotiation result, and return the policy response message. S104. Based on the policy response message, store the negotiation results in logically isolated primary and backup storage areas.

[0023] In the above embodiments, policy negotiation between devices is a crucial step in ensuring communication security and data consistency in a distributed system. Traditional methods often employ a one-by-one negotiation approach for each policy, which is extremely inefficient when processing a large number of policies and can easily lead to prolonged data packet loss. Therefore, this method proposes a mechanism for constructing policy negotiation sessions, significantly improving negotiation efficiency by batch processing policy information.

[0024] In terms of implementation, a unified and flexible message format is first defined, which includes fields such as a message header, a policy entry count flag, specific policy information, and a checksum. The message header identifies the message type and version, while the policy entry count flag dynamically indicates the number of policies contained in the current message. When constructing a policy negotiation session, the policy configuration file is read, and the value of the policy entry count flag in the sent message is intelligently determined based on the number of policy entries in it.

[0025] If there are many policy entries, they are divided into multiple batches. Each batch contains several policy entries and is encapsulated into an independent policy negotiation message. It's understandable that the batching strategy is not a simple fixed-quantity division, but rather dynamically adjusted based on the complexity of the policy information and network transmission efficiency. This ensures that the message size of each batch is moderate, fully utilizing network bandwidth while avoiding transmission failures due to excessively large messages.

[0026] In addition, to enhance the anti-interference capability of the messages, each message is appended with a checksum field, which is used by the receiver to verify the integrity and accuracy of the message. Through this batch-based message encapsulation method with a verification mechanism, policy negotiation, which originally required multiple interactions, can now be completed efficiently in a small number of batches, thus improving negotiation efficiency.

[0027] During the transmission phase, this method ensures that multiple batches of messages arrive at the target device node accurately and in an orderly manner, and are integrated into a complete set of policies to be negotiated. To this end, this method introduces a message transmission and integration mechanism based on session ID.

[0028] Each policy negotiation session is assigned a unique session ID upon creation. This ID serves as an implicit identifier for the message and is contained within the internal structure of each policy negotiation message (although it does not appear directly in the message data, it is associated with the message header or other metadata). After receiving a message, the target device node first categorizes multiple messages belonging to the same policy negotiation session based on the session identifier information in the message header (or the session ID obtained by parsing the internal structure of the message).

[0029] To efficiently process these messages, the target device nodes employ advanced data structures such as ring buffers for message caching and sorting. The ring buffer can dynamically adjust its size to accommodate varying message storage needs, while providing efficient insertion and deletion operations to ensure that messages are quickly integrated into a complete set of negotiable policies in the order they were sent.

[0030] Furthermore, to address uncertainties and delays in network transmission, target device nodes can implement timeout retransmission and message deduplication mechanisms. If a batch of messages is not received within a specified time, the node will proactively request the sender to retransmit; if duplicate messages are received, deduplication will be performed using the message sequence number or other unique identifier to ensure that the integrated policy set is complete and error-free.

[0031] State machines, as a powerful process control mechanism, are used in this method to precisely manage the entire lifecycle of policy negotiation. By defining the various states, events, transition conditions, and actions of the state machine, fine-grained control over the policy negotiation process can be achieved. Specifically, multiple states of the state machine are defined according to the needs and scenarios of policy negotiation. Simultaneously, events that trigger state transitions are defined, such as message received events, message processing completion events, and timeout events. During processing, if errors or abnormal situations are encountered, such as incorrect message format or incomplete policy information, the state machine can immediately transition to the error handling state and execute corresponding recovery or rollback actions.

[0032] After all policy information has been processed, the corresponding policy negotiation result is generated according to preset algorithms and rules (such as priority sorting, conflict resolution strategies, etc.). Finally, the negotiation result is encapsulated into a policy response message, with the corresponding message header and verification information set, and returned to the sending device node via the original path. Through this state machine management approach, the policy negotiation process is strictly controlled and optimized, ensuring that each step is executed according to preset logic and conditions, thus improving the reliability and predictability of the process.

[0033] The primary and secondary storage areas can be physically different regions of the same storage device (isolated by partitions or file systems), or they can be different storage devices (e.g., primary storage on an SSD and secondary storage on an HDD). Logically, they are completely isolated to ensure that data in the primary storage area is not affected or overwritten by data in the secondary storage area.

[0034] When the negotiation period arrives, the new negotiation result is first written to the standby storage area. A checksum and error detection mechanism ensures data integrity and accuracy. Once confirmed, atomic operations (such as file system-level renaming or linking) are used to switch the data in the standby storage area to the primary storage area. Simultaneously, the standby storage area is cleared or updated for future use. This primary / standby switching mechanism avoids data inconsistencies that could arise from directly overwriting data in the primary storage area. Even in the event of system failures or power outages during the data switching process, at least one complete copy of the data is guaranteed, thus improving data reliability and availability.

[0035] Furthermore, to enhance data security, data in the primary and backup storage areas can be backed up and verified periodically. Backup data can be stored on remote servers or cloud storage to prevent data loss due to damage to local storage devices. Through a multi-layered data protection mechanism, the persistence and security of policy negotiation results are ensured.

[0036] Compared with existing technologies, this embodiment provides a distributed system policy negotiation method that reduces the number of network communication rounds by dividing the information of devices to be interacted with into multiple batches for encapsulation and transmission. It integrates a large number of fragmented policy entries into a limited number of message exchanges to complete the negotiation, effectively shortening the overall negotiation cycle by increasing the data throughput of a single communication. A state machine is used to manage the negotiation process, introducing clear logical states and controlled state transitions, enabling precise responses to various events and execution of corresponding processing logic. The introduction of the state machine standardizes and modularizes the complex negotiation process, improving controllability and predictability. Its embedded retransmission and other fault-tolerance mechanisms further enhance the robustness of the negotiation process in the face of network anomalies, avoiding the failure of the entire negotiation due to temporary faults. By establishing logically isolated primary and standby storage areas and updating policy results on this basis, the new negotiation results are written to the inactive standby storage area during the update. Subsequently, a switching operation is performed to convert it into the primary storage area. This ensures that at the moment of policy switching, there is always a complete and consistent set of policies available. This eliminates the policy inconsistency window caused by asynchronous policy updates or during the overwrite process, prevents data packet loss or service interruption, and improves service continuity during system updates.

[0037] Please see Figure 2 , Figure 2 Provided by the present invention Figure 1 A flowchart illustrating an embodiment of step S101 is provided. In some embodiments of the present invention, a policy negotiation session is constructed, and the information of the device to be interacted with is divided into multiple batches and encapsulated according to a preset message format to obtain multiple policy negotiation messages. The process also includes: S201. Determine the maximum number of policy entries that a single policy negotiation message can carry based on the maximum capacity of the network transmission unit. S202. Based on the maximum number of policy entries, divide all policy entries corresponding to the information of devices to be interacted into several consecutive batches. S203. Assign a unique sequence number to each batch within this policy negotiation session, and encapsulate the sequence number with the corresponding policy entry to obtain multiple policy negotiation messages.

[0038] In the above embodiments, the maximum number of policy entries that a single message can carry must first be determined based on the maximum capacity (MTU) of the network transmission unit. If too many policies are transmitted at once, they may be split due to exceeding the MTU, increasing the risk of transmission failure and reassembly delay; if too few are transmitted, messages need to be sent frequently, reducing negotiation efficiency. Therefore, it is necessary to first obtain the minimum MTU value of the current network (such as the minimum value when the device is connected to multiple networks) and then estimate the space occupied by a single policy.

[0039] Each message needs to include fixed fields such as session identifier, version number, and verification information (approximately 30-50 bytes), as well as the specific rules for each policy (such as source / destination address, port, etc.; complex rules may occupy 30 bytes, while simple rules occupy approximately 10 bytes). A small amount of blank bytes should also be reserved to support future rule upgrades. Subtracting the fixed portion and reserved space from the MTU value, and then dividing by the average space occupied by a single policy, yields the maximum number of policies a single message can carry (rounded to the nearest integer). For example, with an MTU of 1500 bytes, if the fixed portion occupies 50 bytes, the reserved portion 20 bytes, and the average size of a single policy is 20 bytes, then a single message can carry a maximum of 71 policies.

[0040] After determining the single message capacity, all policy entries to be negotiated (which may number in the hundreds or thousands) need to be divided into consecutive batches. First, count the total number of policies. If the total number is 0, the negotiation is terminated. Then, divide the total number of policies by the maximum single message capacity and round up to get the total number of batches (e.g., 1000 policies require 15 batches if each batch contains 71 policies). Finally, allocate policies sequentially starting from the first policy. After each batch is filled to the maximum capacity, the remaining policies are added to the next batch. At the same time, the original order of policies within the batch must be maintained (e.g., sorted by device priority or rule logic) to avoid disrupting rule dependencies due to batching.

[0041] Finally, a unique sequence number must be assigned to each batch and encapsulated into a complete message. At the start of the negotiation session, a counter is initialized (e.g., starting from 0), and the counter increments by 1 for each batch assigned, ensuring that the sequence numbers are consecutive and non-repeating. The message structure must include a message header (containing session identifier, total number of batches, current batch number, and checksum information), a message body (all policy entries for the current batch, arranged in a preset format), and a checksum (calculating CRC and other check values ​​for the message header and message body as a whole, used by the receiver to verify data integrity). Combining these three elements in sequence forms the final policy negotiation message. The receiver can reassemble the policy entries in the correct order according to the sequence number and use the checksum to detect whether batches are lost or tampered with during transmission.

[0042] Please see Figure 3 , Figure 3 Provided by the present invention Figure 1 A flowchart illustrating an embodiment of step S102 is provided. In some embodiments of the present invention, multiple negotiation messages are transmitted to the target device node, and multiple policy negotiation messages belonging to the same policy negotiation session are integrated to obtain a complete set of policies to be negotiated. The process also includes: S301. Transmit policy negotiation messages carrying serial numbers to the target device node in batches through the transmission network; S302. Parse the policy negotiation message and store the parsed policy entries in the shared buffer; S303. Retrieve policy entries from the shared buffer according to their sequence numbers and reassemble them into a complete set of policies to be negotiated.

[0043] In the above embodiments, policy negotiation messages carrying sequence numbers need to be sent to the target device node in batches via a transmission network. The transmission network may be wired Ethernet, wireless LAN, or a hybrid link. Different networks have different bandwidths, latency, and reliability. Therefore, it is necessary to select an appropriate transmission protocol (such as TCP to ensure reliability or UDP to pursue low latency) according to the actual network conditions. At the same time, it is necessary to ensure that the messages are sent in batch order to avoid batch disorder due to network jitter. For example, if a batch of messages arrives late due to network congestion, the receiver may not be able to correctly reassemble subsequent policies because it did not receive that batch. Therefore, the sender needs to record the sequence numbers of the sent batches and retransmit them if no acknowledgment is received within a timeout period. The receiver needs to return an acknowledgment response for each batch of messages to form a closed-loop transmission mechanism.

[0044] When the target device node receives the policy negotiation message, it needs to parse it and store the policy entries in the shared buffer. The parsing process first verifies the integrity of the message; if the verification fails, the message is discarded and a retransmission is requested. If the verification passes, the session identifier, batch number, and total batch count are extracted from the message header to confirm that the message belongs to the current negotiation session and has not been received repeatedly. Then, the policy entries in the message body are parsed, and the specific rules (such as source IP, destination port, action type, etc.) of each policy are extracted according to a preset format (such as key-value pairs of "field name=value" or binary encoding). These policy entries, along with their corresponding batch number, sequence number, and other information, are stored in the shared buffer. The shared buffer must use a thread-safe data structure, supporting multi-threaded concurrent read and write operations to ensure efficient collaboration between the sender and receiver.

[0045] Finally, policy entries need to be retrieved from the shared buffer according to their sequence numbers and reassembled into a complete set of policies to be negotiated. The reassembly process first filters out all policy entries belonging to the current negotiation session based on the session identifier, then sorts them by batch number and sequence number to ensure the policy entries are strictly arranged in the order they were sent. If a batch number is missing, reassembly must be paused and the sender requested to retransmit the missing batch until all batches are received completely. After reassembly, the policy set needs to be logically validated. For example, it checks for conflicting rules (such as allowing and denying the same port on the same device simultaneously), dependent rules (such as a rule requiring another rule as a prerequisite), or invalid values ​​(such as incorrect IP address formats). If problems are found, they need to be marked and reported back to the sender for correction. The final complete set of policies to be negotiated will serve as the basis for subsequent negotiations, ensuring that both parties can conduct fair and accurate negotiations based on the same policy benchmark.

[0046] In some embodiments of the present invention, the process of calling a state machine to process the set of policies to be negotiated, determining the corresponding policy negotiation result, and returning a policy response message further includes: The predefined states of a state machine include a set of states such as ready, negotiating, and waiting for a response. When the state machine is in the ready state, receiving the complete set of policies to be negotiated will trigger the state transition to the negotiation state and execute the policy matching logic. After the initial negotiation result is generated in the state during the negotiation, the state machine transitions to the waiting for response state and triggers the sending of the policy response message.

[0047] In the above embodiments, the core design of the state machine is based on a predefined set of states: a ready state (initial state, indicating that the system is ready to receive policy input), a negotiating state (executing core logic such as policy matching and conflict detection), and a waiting-for-response state (a preliminary result has been generated, awaiting confirmation or supplementary information from the other party). These three states are transitioned in an orderly manner through event triggering, ensuring the rigor of the negotiation process. For example, the state machine starts in the ready state by default. If a complete set of policies to be negotiated is received at this time, the data integrity is verified. After successful verification, the state transitions to the negotiating state, and a transition timestamp is recorded to monitor timeouts.

[0048] Once the state machine enters the negotiation state, it will immediately execute the policy matching logic. Based on the policy type, it will call the corresponding matching algorithm (such as rule-based exact matching or feature-based fuzzy matching) to compare the policy entries of the sender and receiver pairwise and identify conflicting, redundant, or complementary rules.

[0049] During the matching process, a conflict list needs to be dynamically maintained, recording all rule pairs that need to be negotiated and their context information. If a key rule is found to be missing during the matching process, the state machine will temporarily mark it as a partial negotiation state and generate a supplementary request event, continuing processing after receiving the complete rule. After the matching is completed, a preliminary negotiation result is generated based on the preset negotiation strategy (such as priority rules, time weights, or manually configured conflict resolution strategies). This result can be a merged unified strategy set, a phased execution plan, or pending items requiring manual intervention. At this time, the state machine will transition to a waiting response state and trigger the encapsulation of a strategy response message.

[0050] While awaiting a response, the preliminary negotiation results are encoded into a policy response message using a standardized format. The message header must include the original session identifier, result type, timestamp, and digital signature; the message body describes the negotiation results in blocks according to policy type, such as marking conflicting rules as resolved or pending confirmation, and marking redundant rules as merged. Detailed change logs and subsequent operation suggestions must also be attached. After encapsulation, the message is sent to the sender via a transport layer protocol (such as TCP or reliable UDP).

[0051] If no confirmation is received from the other party within a preset time, the state machine will automatically retransmit the response message. After a timeout, the session will be marked as a negotiation failure and related resources will be cleaned up. If confirmation is received and the result is completely successful, the state machine will transition back to the ready state, waiting for the next negotiation. If the result is partially successful, it needs to re-enter the negotiation state based on the supplementary information provided by the other party, forming a closed-loop processing flow. The entire state machine ensures the reliability, traceability, and efficiency of policy negotiation through clear state definitions, event-driven transition mechanisms, and strict error handling.

[0052] In some embodiments of the present invention, a state machine is invoked to process the set of policies to be negotiated, determine the corresponding policy negotiation result, and return a policy response message. This process further includes: The state machine starts a timer while waiting for a response; If a policy response message is received from the other end before the timer expires, the state machine transitions to the result integration state and determines the final policy negotiation result based on the response message. If the timer times out, the state machine transitions back to the negotiation state and triggers the retransmission mechanism.

[0053] In the above embodiments, after the policy response message is encapsulated and sent, the state machine enters a waiting-for-response state. At this time, a dynamically configured timer is started synchronously. The duration of this timer is not a fixed value, but is calculated based on the current network environment (such as round-trip latency obtained through ICMP probes and the average response time in historical negotiation records), the performance of the peer device (such as the processing capability score extracted from device metadata), and the complexity of the policy (such as the number of rules in the policy set to be negotiated and the computing resources required for conflict detection). For example, if the network latency is less than 50ms and there are fewer than 10 policy entries, the timer may be set to 2 seconds; if there is network jitter or the policy contains complex regular expression matching, the duration will be extended to 8 seconds to ensure that the peer has sufficient time to complete the response processing. After the timer is started, the state machine will mark the current session as active negotiation and temporarily occupy some system resources to monitor the timer status and the receiving port to avoid response message loss or processing delay due to resource contention.

[0054] If the state machine successfully receives the policy response message from the peer via the transport layer protocol before the timer expires, it immediately triggers a multi-level verification process. First, it verifies whether the session identifier in the message header completely matches the current negotiation session to prevent misprocessing messages from other parallel sessions; second, it verifies the digital signature or HMAC checksum to ensure that the message has not been tampered with during transmission; finally, it parses the key fields in the message body to extract the peer's feedback information on the preliminary negotiation results.

[0055] After successful verification, the state machine will transition to the result integration state. In this state, the preset integration rule engine is invoked to synthesize the responses from both parties and generate the final strategy negotiation result: if the other party fully accepts the preliminary result, the preliminary result is marked as successful and a confirmation message containing the final strategy set is generated; if the other party proposes partial modifications, it needs to be re-evaluated according to the conflict resolution strategy (such as manual intervention, preset priority rules, or weighted voting algorithm) to generate a revised result; if the other party completely rejects the solution and there is no alternative, the negotiation is marked as failed and the detailed reasons are recorded.

[0056] After integration, the final result is encoded into a standardized message and returned to the peer through the original transmission path. Temporary resources of this negotiation (such as shared buffers, timer instances, session logs, etc.) are cleaned up, and the global policy status table is updated (such as marking the session as "completed" or "requires manual review").

[0057] If a valid response message is not received from the other end before the timer expires, the state machine will determine that there is a transmission error or that the other end has timed out, triggering a multi-stage retransmission mechanism. First, all non-critical operations in the current session are suspended to avoid data corruption due to inconsistent states. Then, the retransmission counter is checked (initially set to 0). If the maximum retransmission threshold (usually configured to 3 times) has not been reached, the previously sent policy response message is repackaged and retransmitted through the original transmission channel. At the same time, the retransmission parameters are dynamically adjusted according to network quality: if the first timeout is due to network congestion, the sending rate is reduced and the congestion control algorithm is enabled; if it is due to processing delays at the other end, the duration of subsequent timers is extended.

[0058] If no response is received after the number of retransmissions reaches the threshold, the state machine will be forced to transition back to the negotiation state and the session will be marked as abnormally terminated. At the same time, a multi-dimensional alarm log (recording session identifier, timeout, number of retransmissions, network status snapshot, etc.) will be generated and pushed to the operation and maintenance monitoring platform. In the negotiation state, two processing methods can be selected according to the configuration.

[0059] For non-critical policy negotiations (such as log collection rules), the negotiation process is restarted; for core security policy negotiations (such as firewall rule updates), the negotiation is paused and a manual intervention process is triggered to ensure that critical business operations are not affected. Through the synergy of dynamic timers and intelligent retransmission mechanisms, the state machine effectively addresses network unreliability, peer performance differences, and uncertainties in complex business scenarios while ensuring negotiation efficiency, thus achieving high availability and maintainability of policy negotiation.

[0060] In some embodiments of the present invention, storing the negotiation result in a logically isolated primary storage area and a backup storage area according to the policy response message further includes: Write the determined set of negotiation results into the storage area currently designated as standby; After verifying that the write operation is correct, a storage area switching operation is performed, setting the standby storage area to the primary state and setting the original primary storage area to the standby state.

[0061] In the above embodiments, after parsing the policy response message and confirming the final negotiation result, the dual-storage area write and dynamic switching process is initiated to ensure high availability and fault tolerance of the policy data. First, based on the current health status of the storage area and the preset load balancing strategy (such as round-robin or minimum load priority), a logically isolated primary or backup storage area is selected as the backup target for this write operation. For example, if the current disk utilization of the primary storage area exceeds 85% or the I / O latency exceeds a preset threshold (such as 50ms), the backup storage area is selected as the write target to avoid putting additional pressure on the primary area.

[0062] After selecting a target, the negotiation result set is encoded in a standardized format (such as JSON or binary protocol) and sent to the physical device of the backup storage area simultaneously through a dual-channel write mechanism. The primary channel uses a specific transmission protocol (such as TCP or iSCSI) to ensure that the data arrives completely, while the secondary channel provides redundancy through checksum comparison or fast retransmission mechanism (such as QUIC protocol) to prevent data loss due to single-channel failure.

[0063] During the write process, a multi-level verification mechanism is employed to ensure data integrity. At the transport layer, the complete arrival of each data packet is verified using TCP sequence numbers and ACK confirmation mechanisms. At the storage layer, the backup storage area immediately calculates a checksum upon receiving the data and compares it with the checksum calculated by the sender; if they do not match, retransmission is triggered. At the application layer, the written data is parsed and key fields are verified; if any anomalies are found (such as rule conflicts or format errors), the write process is interrupted and an alarm log is generated. Only after all verifications pass is the write status flag updated in the metadata table of the backup storage area, and audit information such as the write timestamp, operator, and verification results recorded.

[0064] After verifying that the write operation is correct, a storage area switch operation is performed. A distributed lock mechanism (such as a distributed lock based on Zookeeper or etcd) is used to ensure that no other process modifies the storage area state at the same time during the switch to avoid state inconsistency. Then, the storage management interface (such as the LUN switch API of the storage array or the master-slave switch command of the database) is called to update the status of the standby storage area from standby to master.

[0065] Simultaneously, the storage area mapping relationship in the global configuration center is updated to ensure that all service nodes can obtain the latest primary storage area address in real time. After the switchover is completed, a status change notification is sent to the original primary storage area, and its status is marked as downgraded from primary to standby. At the same time, a data synchronization task is triggered (such as through rsync or database replication tools) to reverse synchronize the newly written data to the original primary storage area, maintaining data consistency between the two storage areas. During the synchronization process, an incremental synchronization strategy (transmitting only the difference data) is adopted to reduce bandwidth consumption, and a breakpoint resume mechanism is used to deal with abnormal situations such as network interruptions.

[0066] To verify the effectiveness of the switchover, a health check is performed immediately after the switchover is complete. A query request is sent to the new primary storage area to verify data readability. Simultaneously, a fault scenario is simulated (such as disconnecting the network connection of the new primary storage area) to check whether the standby storage area (i.e., the original primary area) can automatically take over the service, ensuring disaster recovery capabilities. If the check passes, a switchover success log is generated and pushed to the operations and maintenance platform; if it fails, it automatically rolls back to the state before the switchover (resetting the original primary area as primary) and triggers a high-level alarm to notify the administrator for intervention. This ensures seamless storage area switching while guaranteeing data security, ensuring the continuous availability of policy negotiation results and business continuity.

[0067] In some embodiments of the present invention, performing a storage area switching operation, setting the standby storage area to a primary state, and setting the original primary storage area to a standby state, further includes: Suspend read access requests to the policy storage area and swap the logical identifiers of the primary and standby storage areas; Resume read access requests to the policy storage area, and direct all policy query operations to the primary storage area after the identity swap.

[0068] In the above embodiments, when performing a storage area switching operation, in order to ensure data consistency and service continuity, firstly, all read access requests to the policy storage area are temporarily suspended through a global traffic control module (such as traffic interception based on service mesh or request routing rules of API gateway) to avoid query results errors due to data inconsistency between the old and new primary storage areas during the switching process; during the suspension period, a preset maintenance response is returned to the client that initiated the query request, and key information such as the suspension start time, the affected client identifier, and the request type are recorded to facilitate subsequent auditing and troubleshooting.

[0069] At the same time, the storage management interface is called to perform the logical identifier swap operation between the primary and standby storage areas. This not only updates the internal configuration of the storage device (such as changing the volume identifier of the primary area from "primary" to "secondary" and the standby area from "secondary" to "primary"), but also synchronously modifies the storage area mapping relationship in the global configuration center (such as updating the value of the key "active_storage" from the original primary area address to the new primary area address), ensuring that all service nodes that depend on this configuration can obtain the latest storage area status in real time.

[0070] After the logical identifier swap is completed, the data synchronization and verification phase begins. A dual-channel verification mechanism ensures the data integrity of the new primary storage area (formerly the backup area): On one hand, critical data (such as the latest written policy rules and configuration change records) is read from the new primary area and compared with the backup data cached in the original primary area before the switch. If differences are found, an automatic repair process is triggered, resynchronizing the differing data from the original primary area or rolling back the switch operation. On the other hand, the metadata of the new primary area (such as file system status and database transaction logs) is checked to ensure it is in a healthy state (e.g., no uncommitted transactions, no disk errors). If any anomalies are found, it is marked as a switch risk and the administrator is notified for intervention. Only when all verifications pass is the switch operation considered safe at the data level.

[0071] Subsequently, read access requests to the policy storage area were gradually restored, and query requests for critical business functions (such as real-time policy issuance and security event handling) were allowed through the traffic control module to ensure the availability of core functions. Then, requests for non-critical business functions (such as historical policy queries and report generation) were gradually allowed to avoid the pressure on the new primary storage area caused by sudden traffic surges.

[0072] During the recovery process, all policy query operations will automatically be directed to the new primary storage area after the identifier swap, achieved through a dynamic routing mechanism. Before initiating a query, the service node first reads the current active_storage address from the global configuration center and routes the request to the storage device corresponding to that address. If the configuration center fails to update in time due to network latency, the service node will trigger a local cache refresh process to ensure correct routing. Simultaneously, query performance after recovery is monitored. If a performance degradation is detected (such as response time exceeding a threshold or throughput falling below a baseline), load balancing adjustments are triggered to ensure a good user experience.

[0073] To verify the switching effect, an end-to-end test was performed after access was restored to simulate a real business scenario and check whether the new primary storage area could correctly process requests and return expected results. Simultaneously, system logs were monitored to confirm the absence of error records. If the test passed, a successful switchover report was generated, recording the switchover time, data verification results, performance metrics, etc., and pushed to the operations and maintenance platform. If it failed, the system automatically rolled back to the state before the switchover and triggered a high-level alarm to notify the administrator to investigate the problem. This approach ensured data security and consistency while achieving a seamless transition during storage area switching, guaranteeing the continuous high availability of the policy service.

[0074] To better implement the strategy negotiation method for distributed systems in this invention embodiment, based on the strategy negotiation method for distributed systems, please refer to the corresponding documentation. Figure 4 , Figure 4 This is a schematic diagram of an embodiment of the policy negotiation device for a distributed system provided by the present invention. The embodiment of the present invention provides a policy negotiation device 400 for a distributed system, comprising: The information encapsulation module 410 is configured to construct a policy negotiation session, and encapsulate the device information to be interacted into multiple batches according to a preset message format to obtain multiple policy negotiation messages. The policy integration module 420 is configured to transmit multiple negotiation messages to the target device node and integrate multiple policy negotiation messages belonging to the same policy negotiation session to obtain a complete set of policies to be negotiated. The strategy negotiation module 430 is configured to call the state machine to process the set of strategies to be negotiated, determine the corresponding strategy negotiation result, and return a strategy response message. The policy storage module 440 is configured to store the negotiation results in logically isolated primary and backup storage areas based on the policy response message.

[0075] It should be noted that the device 400 provided in the above embodiments can implement the technical solutions described in the above method embodiments. The specific implementation principles of the above modules or units can be found in the corresponding content in the above method embodiments, and will not be repeated here.

[0076] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a policy negotiation device for a distributed system provided in an embodiment of the present invention. Based on the above-described policy negotiation method for a distributed system, the present invention also provides a policy negotiation device for a distributed system, which can be a computing device such as a mobile terminal, desktop computer, laptop, handheld computer, or server. The policy negotiation device 500 for the distributed system includes a processor 510, a memory 520, and a display 530. Figure 5Only a portion of the components of the policy negotiation device for the distributed system are shown; however, it should be understood that implementation of all shown components is not required, and more or fewer components may be implemented instead.

[0077] In some embodiments, the memory 520 may be an internal storage unit of the policy negotiation device 500 of the distributed system, such as a hard disk or memory of the policy negotiation device 500. In other embodiments, the memory 520 may be an external storage device of the policy negotiation device 500 of the distributed system, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the policy negotiation device 500 of the distributed system. Further, the memory 520 may include both internal storage units and external storage devices of the policy negotiation device 500 of the distributed system. The memory 520 is used to store application software and various types of data installed on the policy negotiation device 500 of the distributed system, such as program code installed on the policy negotiation device 500 of the distributed system. The memory 520 may also be used to temporarily store data that has been output or will be output. In one embodiment, the memory 520 stores a policy negotiation program 540 of the distributed system, which can be executed by the processor 510 to implement the policy negotiation method of the distributed system in the various embodiments of this application.

[0078] In some embodiments, processor 510 may be a central processing unit (CPU), a microprocessor, or other data processing chip, used to run program code stored in memory 520 or process data, such as executing a strategy negotiation method for a distributed system.

[0079] In some embodiments, display 530 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. Display 530 is used to display information from the policy negotiation device 500 of the distributed system and to display a visual user interface. Components 510-530 of the policy negotiation device 500 of the distributed system communicate with each other via a system bus.

[0080] In one embodiment, when the processor 510 executes the distributed system policy negotiation program 540 in the memory 520, the steps in the distributed system policy negotiation method described above are implemented.

[0081] This embodiment also provides a computer-readable storage medium storing a policy negotiation program for a distributed system, which, when executed by a processor, performs the following steps: Construct a policy negotiation session, and encapsulate the information of the devices to be interacted with into multiple batches according to a preset message format to obtain multiple policy negotiation messages; Multiple negotiation messages are transmitted to the target device node, and multiple policy negotiation messages belonging to the same policy negotiation session are integrated to obtain a complete set of policies to be negotiated. The state machine is invoked to process the set of policies to be negotiated, determine the corresponding policy negotiation result, and return a policy response message. The negotiation results are stored in logically isolated primary and backup storage areas according to the strategy response message.

[0082] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method. The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, DVDs, CD-ROMs, microdrives, as well as magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), or any type of medium or device suitable for storing instructions and / or data.

[0083] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0084] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0085] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between devices or units may be electrical or other forms.

[0086] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0087] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0088] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0089] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0090] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of embodiments of this disclosure upon considering the specification and practicing the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described herein. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

[0091] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0092] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for policy negotiation of a distributed system, characterized in that, The method comprises: constructing a policy negotiation session, dividing device information to be interacted into multiple batches according to a preset message format, encapsulating to obtain multiple policy negotiation messages; transmitting the multiple negotiation messages to a target device node, and integrating multiple policy negotiation messages belonging to the same policy negotiation session to obtain a complete policy set to be negotiated; calling a state machine to process the policy set to be negotiated, determining a corresponding policy negotiation result, and returning a policy response message; storing the negotiation result in a primary storage area and a backup storage area which are logically isolated according to the policy response message.

2. The policy negotiation method of a distributed system according to claim 1, wherein, The method further comprises: determining a maximum number of policy entries that can be carried by a single policy negotiation message according to a maximum capacity of a network transmission unit; dividing policy entries corresponding to all device information to be interacted into a plurality of continuous batches based on the maximum number of policy entries; allocating a sequence number unique in the current policy negotiation session to each batch, and encapsulating the sequence number and the corresponding policy entries to obtain multiple policy negotiation messages.

3. The policy negotiation method of a distributed system according to claim 2, wherein, The method further comprises: transmitting the policy negotiation messages carrying the sequence numbers to the target device node in batches through a transmission network; analyzing the policy negotiation messages, and storing the analyzed policy entries in a shared buffer; taking out the policy entries according to the sequence numbers from the shared buffer, and recombining the policy entries into a complete policy set to be negotiated.

4. The policy negotiation method of a distributed system according to claim 1, wherein, The method further comprises: the state machine predefines a state set including a ready state, a negotiation state, and a waiting response state; when the state machine is in the ready state, an event of receiving the complete policy set to be negotiated triggers state migration to the negotiation state, and policy matching logic is executed; after generating a preliminary negotiation result in the negotiation state, the state machine migrates to the waiting response state, and triggers sending of the policy response message.

5. The policy negotiation method of a distributed system according to claim 4, wherein, The method further comprises: the state machine starts a timer in the waiting response state; if the policy response message of the opposite end is received before the timer expires, the state machine migrates to a result integration state, and determines a final policy negotiation result according to the response message; if the timer expires, the state machine migrates back to the negotiation state, and triggers a retransmission mechanism.

6. The policy negotiation method of a distributed system according to claim 1, wherein, The method further comprises: writing the determined negotiation result set to a storage area currently designated as a backup state. After the check write operation is completed correctly, a storage area switching operation is performed to set the standby storage area as a master state and set the original master storage area as a standby state.

7. The policy negotiation method of a distributed system according to claim 6, wherein, The storage area switching operation, which sets the standby storage area as a master state and sets the original master storage area as a standby state, further includes: suspending read access requests to the policy storage area, and exchanging the logical identifiers of the master storage area and the standby storage area; resuming read access requests to the policy storage area, and directing all policy query operations to the master storage area after the exchange of the logical identifiers.

8. A policy negotiation apparatus of a distributed system, characterized by comprising: The method includes: an information encapsulation module configured to construct a policy negotiation session, encapsulate device information to be interacted in batches according to a preset message format, and obtain multiple policy negotiation messages; a policy integration module configured to transmit the multiple negotiation messages to a target device node, and integrate multiple policy negotiation messages belonging to the same policy negotiation session to obtain a complete set of policies to be negotiated; a policy negotiation module configured to call a state machine to process the set of policies to be negotiated, determine a corresponding policy negotiation result, and return a policy response message; a policy storage module configured to store the negotiation result in a master storage area and a standby storage area which are logically isolated according to the policy response message.

9. A policy negotiation device of a distributed system, characterized by The computer program is stored in the at least one storage unit and is executable by the at least one processing unit, and when the computer program is executed by the at least one processing unit, the at least one processing unit is caused to perform the steps of the policy negotiation method of the distributed system according to any one of claims 1 to 7.

10. A storage medium, characterized by The computer program is stored in the at least one storage unit and is executable by the at least one processing unit, and when the computer program is executed by the at least one processing unit, the at least one processing unit is caused to perform the steps of the policy negotiation method of the distributed system according to any one of claims 1 to 7.

Images