A method, server and client for multi-client concurrent configuration

Abstract

The application relates to the technical field of client configuration, and provides a multi-client concurrent configuration method, a server and a client. The method comprises the following steps: a server receives a first negotiation message from a client, determines the locking capability of the client according to the first negotiation message; the server sends a second negotiation message to the client, so that the client determines the locking capability of the server according to the second negotiation message, and receives a locking message of the client according to the locking message sent by the server; the locking message is parsed to obtain parameters, and the candidate data area is locked and subsequently unlocked according to the parameters. The application expands the locking and unlocking operations defined by the protocol standard, so that the server and the client have the locking capability, the unlocking is performed according to the parameters, the problems that the candidate data area cannot be unlocked due to the fact that the software or the network fails, the client does not send the unlocking message or the unlocking message is not delivered to the server are avoided, and it is guaranteed that other clients can configure the equipment.

Description

Technical Field

[0001] This invention relates to the field of client configuration, and in particular to a method, server, and client for concurrent configuration of multiple clients. Background Technology

[0002] NETCONF (Network Configuration Protocol) is a network management configuration protocol. It establishes a session between the network manager or controller (NETCONF client) and the managed network device (NETCONF server). The client uses remote procedure calls (RPC) and a data protocol based on Extensible Markup Language (XML) to configure and manage the server.

[0003] The NETCONF protocol defines a series of datastores and operations for editing and saving configuration data. The relevant datastores and operations include:

[0004] Running data area <running>: Used to store the currently effective configuration data of the device; candidate data area <candidate>This is used to cache the configuration data currently being edited by the client. The configuration data in the candidate data area will not take effect immediately; it will be copied to the running data area and officially take effect only after the client performs a commit operation and the verification passes. (Edit configuration) <edit-config>Edit configuration data; the target can be the running data area or the candidate data area; submit. <commit>Submit the contents of the candidate data area to the running data area; lock. <lock>The client locks a specified data area. The target of the lock can be the running data area or the candidate data area. The locked data area cannot be modified by other clients; unlocking... <unlock>This operation unlocks a client that has locked a data area.

[0005] When managing network devices using the NETCONF protocol, to avoid data conflicts caused by multiple NETCONF clients configuring the server simultaneously, clients need to complete the configuration operation by following the steps of "locking the candidate data area - editing the candidate data area - committing the configuration - unlocking the candidate data area". Other clients cannot modify the contents of the data area until the client that has locked the data area unlocks it.

[0006] After a client successfully locks the configuration data area, due to software or network failures, the client fails to send an unlock message or the unlock message is not delivered to the server, resulting in the server's configuration data area being locked. In this case, other clients cannot configure the device.

[0007] In traditional human-machine interaction management methods, the aforementioned issues have little impact compared to human processing efficiency. However, in intelligent operation and maintenance scenarios such as the Industrial Internet, where machine-to-machine interaction is crucial, multiple network managers and controllers need to analyze network quality based on collected data on device performance, status, and alarms, and quickly adjust network parameters in real time. The aforementioned issues then severely impact network management efficiency.

[0008] Therefore, overcoming the shortcomings of the existing technology is an urgent problem to be solved in this technical field. Summary of the Invention

[0009] The problem to be solved by the embodiments of the present invention is how to solve the problem that after a client successfully locks the configuration data area, due to software or network failures, the client fails to send an unlock message or the unlock message is not delivered to the server, resulting in the server's configuration data area being locked and other clients being unable to configure the device.

[0010] The embodiments of the present invention adopt the following technical solutions:

[0011] In a first aspect, the present invention proposes a method for configuring concurrent multi-client configuration, comprising:

[0012] The server receives the first negotiation message from the client and determines the locking capability of the client based on the first negotiation message;

[0013] A second negotiation message is sent to the client so that the client can determine the locking capability of the server based on the second negotiation message, and then send a corresponding locking message according to the locking capability of the server.

[0014] The system receives a lock message from the client, parses the lock message to obtain parameters, and locks and subsequently unlocks the candidate data area based on the parameters.

[0015] Preferably, when the parameter indicates that the locking message is a message with locking timeout capability, the parameter further includes a timeout parameter, and the locking and subsequent unlocking of the candidate data area according to the parameter specifically includes:

[0016] Start the lock timer;

[0017] Obtain the timer value of the lock timer in real time;

[0018] If the timing value is greater than the timeout parameter, the candidate data area is unlocked;

[0019] If a configuration submission message is received from the client before the timeout expires, the configuration data is copied to the running data area, the candidate data area is unlocked, and the timer is stopped.

[0020] Preferably, when the parameter indicates that the locked message has the capability to unlock after submission, the step of locking and subsequently unlocking the candidate data area according to the parameter specifically includes:

[0021] Receive configuration data from the client and write the configuration data into the candidate data area;

[0022] After receiving the configuration submission message from the client, the configuration data is copied to the running data area. Once the configuration takes effect, the candidate data area is unlocked directly.

[0023] Preferably, the client includes at least a first client and a second client. When the parameters indicate that the locking message is a message with locking preemption capability, the parameters also include a priority parameter. The locking and subsequent unlocking of the candidate data area according to the parameters specifically includes:

[0024] The server parses the lock message from the first client, where the priority parameter is the first priority.

[0025] When the candidate data area is locked by the first client, the server receives a locking message from the second client, and the priority parameter is the second priority.

[0026] Determine the locking permissions for the candidate data area based on the first and second priorities;

[0027] If the first priority is not less than the second priority, the locking permission continues to belong to the first client, and a locking failure message is sent to the second client;

[0028] If the first priority is lower than the second priority, the server unlocks the candidate data area, transfers the locking permission to the second client, clears the configuration data not submitted by the first client, and sends a feedback message to the first client that the candidate data area has been preempted by another client.

[0029] Preferably, if the first priority is not less than the second priority, the locking permission continues to belong to the first client, and the process further includes:

[0030] Write the configuration data of the first client into the candidate data area;

[0031] After receiving the configuration submission message from the first client, the configuration data is copied to the runtime data area;

[0032] Upon receiving the unlock request message from the first client, the candidate data area is unlocked;

[0033] or,

[0034] When the parameters of the first client indicate that the locking message still has the ability to unlock after submission:

[0035] Write the configuration data of the first client into the candidate data area;

[0036] After receiving the configuration submission message from the first client, the configuration data is copied to the running data area. Once the configuration takes effect, the candidate data area is unlocked directly.

[0037] or,

[0038] When the parameters of the first client indicate that the locking message still has the capability to time out, the parameters also include a timeout parameter:

[0039] Start the lock timer;

[0040] Obtain the timer value of the lock timer in real time;

[0041] If the timing value is greater than the timeout parameter, the candidate data area is unlocked;

[0042] If the configuration submission message from the first client is received before the timeout expires, the configuration data is copied to the running data area, the candidate data area is unlocked, and the timer is stopped.

[0043] Preferably, the client includes at least a first client and a second client. When the candidate data area is locked by the first client, and the server receives a locking message from the second client, and the parameters indicate that the locking message has the capability to lock additional configurations, the parameters also contain the configuration data of the second client. The method for concurrent configuration of multiple clients further includes:

[0044] The configuration data of the second client is cached, and a message waiting for lock is sent to the second client;

[0045] After the first client unlocks the candidate data area, it is determined whether the configuration data of the second client conflicts with the latest configuration data in the candidate data area;

[0046] If a conflict exists, clear the cached configuration data and send a locking failure message to the second client;

[0047] If there is no conflict, the cached configuration data is stored in the candidate data area, the locking permission is transferred to the second client, and a message indicating successful locking is sent to the second client.

[0048] Preferably, the step of transferring the locking permission to the second client and sending a successful locking message to the second client further includes:

[0049] After receiving the configuration submission message from the second client, the configuration data is copied to the runtime data area;

[0050] Upon receiving the unlock request message from the second client, the candidate data area is unlocked;

[0051] or,

[0052] When the parameters of the second client indicate that the lock message still has the ability to unlock after submission, the step of transferring the lock permission to the second client and sending a lock success message to the second client further includes:

[0053] After receiving the configuration submission message from the second client, the configuration data is copied to the running data area. Once the configuration takes effect, the candidate data area is unlocked directly.

[0054] or,

[0055] When the parameters of the second client indicate that the locking message still has the capability to time out, the parameters also include a timeout parameter. The process of transferring locking authority to the second client and sending a successful locking message to the second client then further includes:

[0056] Start the lock timer;

[0057] Obtain the timer value of the lock timer in real time;

[0058] If the timing value is greater than the timeout parameter, the candidate data area is unlocked;

[0059] If a configuration submission message from the second client is received before the timeout, the configuration data is copied to the running data area, the candidate data area is unlocked, and the timer is stopped.

[0060] Secondly, the present invention also proposes a server-side application to the multi-client concurrent configuration method of the first aspect, wherein the server-side includes:

[0061] At least one processor;

[0062] At least one memory;

[0063] The at least one processor and the at least one memory are communicatively connected to each other. The at least one memory stores instructions that can be executed by the at least one processor. The instructions are executed by the at least one processor to enable the at least one processor to perform the multi-client concurrent configuration method of the first aspect.

[0064] Thirdly, this invention also proposes a method for configuring concurrent multi-client scenarios, including:

[0065] The client sends a first negotiation message to the server so that the server can determine the locking capability of the client based on the first negotiation message;

[0066] Receive a second negotiation message from the server, and determine the locking capability of the server based on the second negotiation message;

[0067] The client sends a lock message to the server, wherein the lock message carries parameters that the server supports, so that the server can lock and subsequently unlock the candidate data area according to the parameters.

[0068] Fourthly, the present invention also proposes a client for use in the multi-client concurrent configuration method of the third aspect, the client comprising:

[0069] At least one processor;

[0070] At least one memory;

[0071] In this embodiment, the at least one processor and the at least one memory are communicatively connected. The at least one memory stores instructions executable by the at least one processor. These instructions are executed by the at least one processor to enable the at least one processor to perform the multi-client concurrent configuration method of the third aspect. Compared with the prior art, the beneficial effects of the embodiments of the present invention are as follows:

[0072] This invention extends the locking and unlocking operations defined in the protocol standard, enabling both the server and client to have locking capabilities, thereby completing the negotiation of locking capabilities. The locking message carries parameters, which can be used to unlock the device. This avoids the problem that the server's configuration data area cannot be unlocked due to software or network failures, such as the client failing to send an unlock message or the unlock message not being delivered to the server. This ensures that other clients can configure the device.

[0073] Furthermore, this invention parses the client's locking message to obtain parameters, which indicate that the client sending the locking message has locking timeout capability, locking preemption capability, unlocking after submission capability, and locking with additional configuration capability. The locking timeout capability prevents a client from locking the data area for an extended period, thus preventing other clients from configuring the device. The locking preemption capability allows clients requiring urgent device operation to obtain priority access to the configuration data area lock, ensuring that urgent tasks are executed first. The unlocking after submission capability allows the server to automatically unlock the configuration data area after the client successfully submits the configuration, reducing the time overhead of waiting for unlock messages. The locking with additional configuration capability allows the client to attach configuration data to the locking message, reducing the number of message interactions. When the configuration data area is already locked, it reduces the time the client waits for the data area to unlock, and eliminates the need to repeatedly poll the configuration data area's locking status during the waiting process. Attached Figure Description

[0074] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0075] Figure 1 This is a flowchart illustrating a method for configuring multiple clients concurrently, as provided in an embodiment of the present invention.

[0076] Figure 2 This is a schematic diagram of the negotiation process between the server and the client in a multi-client concurrent configuration provided by an embodiment of the present invention;

[0077] Figure 3 This is provided by the embodiments of the present invention. Figure 1 A schematic diagram of the first specific process for step 204 in the middle section;

[0078] Figure 4 This is a schematic diagram of the interaction flow of the first method for configuring multiple clients concurrently provided in an embodiment of the present invention;

[0079] Figure 5 This is provided by the embodiments of the present invention. Figure 1 A schematic diagram of the second specific process for step 204;

[0080] Figure 6 This is a schematic diagram of the first unlocking method for the candidate data area within a multi-client concurrent configuration provided by an embodiment of the present invention;

[0081] Figure 7 This is a schematic diagram of a second unlocking method for candidate data areas within a multi-client concurrent configuration provided by an embodiment of the present invention;

[0082] Figure 8 This is a flowchart illustrating a method for implementing a locking and preemption function between a server and a client within a multi-client concurrent configuration, as provided in an embodiment of the present invention.

[0083] Figure 9 This is provided by the embodiments of the present invention. Figure 1 A schematic diagram of the third specific process in step 204;

[0084] Figure 10 This is a schematic diagram of a method for unlocking after submission between the server and the client in a multi-client concurrent configuration provided by an embodiment of the present invention;

[0085] Figure 11 This is a flowchart illustrating a method for configuring multiple clients concurrently, with the server and client having a locking additional configuration, according to an embodiment of the present invention.

[0086] Figure 12 This is a flowchart illustrating a method for implementing a locked additional configuration function within a multi-client concurrent configuration, as provided in an embodiment of the present invention.

[0087] Figure 13 This is a flowchart of a method for configuring multiple clients concurrently, provided by an embodiment of the present invention.

[0088] Figure 14 This is a schematic diagram of the device provided in an embodiment of the present invention. Detailed Implementation

[0089] 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.

[0090] In the description of this invention, the terms "inner", "outer", "longitudinal", "lateral", "upper", "lower", "top", "bottom", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and do not require that this invention must be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting this invention.

[0091] In this invention, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0092] In this application, unless otherwise expressly specified and limited, the term "connection" should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral part; it can be a direct connection or an indirect connection through an intermediate medium. In addition, the term "coupled" can refer to a method of electrical connection for achieving signal transmission.

[0093] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0094] Example 1:

[0095] Embodiment 1 of the present invention provides a method for configuring concurrent multi-client configuration, such as... Figure 1 As shown, it includes:

[0096] Step 201: The server receives the first negotiation message from the client and determines the locking capability of the client based on the first negotiation message.

[0097] In this embodiment of the invention, both the server and client follow the NETCONF protocol. The client sends a first negotiation message to the server, announcing its supported locking capabilities. The locking capabilities of the client in this embodiment include: lock timeout capability, lock preemption capability, unlock after submission capability, and lock additional configuration capability.

[0098] To acquire the capabilities of locking timeout, locking preemption, unlocking after submission, and locking additional configuration, this invention extends the NETCONF protocol as follows:

[0099] Four new locking capabilities have been defined. Refer to the instructions in step 203 for the capability negotiation message format.

[0100] urn:fiberhome:yang:lock-timeout corresponds to the lock timeout capability;

[0101] urn:fiberhome:yang:lock-preemptive corresponds to the ability to lock and preempt.

[0102] urn:fiberhome:yang:unlock-after-committing corresponds to the ability to unlock after a commit;

[0103] urn:fiberhome:yang:lock-with-config corresponds to locking additional configuration capabilities;

[0104] Extended NETCONF <lock>Add the following node definitions to the RPC input parameters: timeout, priority, unlock-after-committing, and config.

[0105]

[0106]

[0107]

[0108] Step 202: Send a second negotiation message to the client so that the client can determine the locking capability of the server based on the second negotiation message, and then send a corresponding locking message according to the locking capability of the server.

[0109] In this embodiment of the invention, the server sends a second negotiation message to the client, announcing its own locking capabilities. These locking capabilities include: lock timeout capability, lock preemption capability, unlock after submission capability, and lock additional configuration capability. This embodiment establishes a session between the server and client via the NETCONF protocol, thereby negotiating the locking capabilities between them. After negotiation, the client can use the locking functions supported by both parties within the session. It is worth noting that there is no specific order requirement between steps 201 and 202 in this embodiment.

[0110] Step 203: Receive the lock message from the client, parse the lock message to obtain parameters, and lock and subsequently unlock the candidate data area according to the parameters.

[0111] By extending the locking capabilities of both the server and client in this embodiment of the invention, the locking message sent by the client will carry corresponding parameters. The server parses the locking message sent by the client and extracts the corresponding parameters, thereby recognizing the client's capability and unlocking the candidate data area. It is worth noting that the candidate data area in this embodiment can only be locked and configured by the client when it is unlocked. Once the candidate data area is locked by the current client, other clients must first unlock it before it can be locked and configured by other clients.

[0112] When this embodiment of the invention extends the locking and unlocking operations defined in the NETCONF protocol standard, it enables the client and server of this embodiment to have corresponding locking capabilities. An example of the message content and format for establishing a session between the server and client to complete the locking capability negotiation process is as follows: Figure 2 As shown, the details are as follows:

[0113]

[0114]

[0115] This invention extends the locking and unlocking operations defined in the protocol standard, enabling both the server and client to have locking capabilities, thereby completing the negotiation of locking capabilities. The unlock message carries parameters, which can be used to unlock the device. This avoids the problem that the server's configuration data area cannot be unlocked due to software or network failures, such as the client failing to send an unlock message or the unlock message not being delivered to the server. This ensures that other clients can configure the device.

[0116] Example 2:

[0117] Based on Embodiment 1, Embodiment 2 of this invention focuses on explaining how to solve the problem that other clients cannot configure the device when, in the case where the parameter package also includes a timeout parameter, the client fails to send an unlock message or the unlock message is not delivered to the server due to software or network failures after successfully locking the candidate data area.

[0118] When the parameter indicates that the locking message is a message with locking timeout capability, the parameter includes a timeout period parameter. The process of locking and subsequently unlocking the candidate data area based on the parameter is as follows: Figure 3 As shown, it specifically includes:

[0119] Step 301: Start the lock timer.

[0120] In this embodiment of the invention, after the client and server complete the locking capability negotiation, if both the client and server have locking timeout capabilities, the locking timeout function can be implemented. The client sends a locking message to the server, requesting the server to lock the candidate data area, and the locking message carries a timeout parameter. After receiving the client's locking message, the server locks and subsequently unlocks the candidate data by parsing the obtained timeout parameter; when the server obtains the timeout parameter, it starts the locking timer. It is understood that the timeout parameter in this embodiment of the invention is actually a set time value (for example, the timeout parameter is set to 10000 milliseconds), which can be set according to actual conditions.

[0121] Step 302: Obtain the timing value of the lock timer in real time.

[0122] In this embodiment of the invention, the lock timer can be understood as a device that monitors time. By acquiring the real-time timing value of the lock timer and comparing it with the timeout parameter, it is possible to determine whether the client has timed out from the start of the lock timer until the server finishes processing the client's edited and submitted configuration. The timing value in this embodiment of the invention represents the real-time time value monitored by the lock timer.

[0123] Step 303: If the timing value is greater than the timeout parameter, then the candidate data area is unlocked.

[0124] When the timer value is greater than the timeout parameter, it indicates that the client configuration process has timed out, meaning that the client did not send an unlock message before the lock timer expired. In this case, the server unlocks the candidate data area.

[0125] Step 304: If the client submits a configuration message before the timeout expires, copy the configuration data to the running data area, unlock the candidate data area, and stop the timer.

[0126] In this embodiment of the invention, the timeout refers to the lock timer timeout. If a configuration submission message is received from the client before the timeout, it indicates that the client completed the editing and submission of the configuration before the lock timer timed out, and the server unlocked the candidate data area. During this process, the server can unlock the candidate data area in at least two ways: First, the server receives the configuration submission message from the client, processes the client's configuration submission, and sends feedback to the client. Then, the client sends an unlock message, and the server unlocks the candidate data area based on the client's unlock message, finally stopping the lock timer. Second, the server receives the configuration submission message from the client, copies the corresponding configuration data to the running data area for execution, the configuration takes effect, then unlocks the candidate data area, and finally stops the lock timer. This method requires that both the server and the client support the ability to unlock after submission.

[0127] The following details the process of implementing the lock timeout function between the server and the client in this embodiment of the invention. After the client and server complete the lock capability negotiation, if both the client and the server support the lock timeout capability, then it can be implemented as follows: Figure 4 As shown, this implements the lock timeout function.

[0128] Step 401: The client sends a message to the server requesting to lock the candidate data area. The lock message carries a timeout parameter, the specific format and example of which are as follows:

[0129]

[0130] Step 402: After receiving the lock message, the server locks the candidate data area and starts a lock timer with a timeout of 10,000 milliseconds.

[0131] Steps 403-406 are the normal unlocking process, which means that the client completes the editing and submission of configuration operations before the lock timer expires and actively sends an unlock message.

[0132] Step 403: The client sends a message, edits the candidate data area, and submits the configuration.

[0133] Step 404: The server processes the client's editing and submission of configurations.

[0134] Step 405: The client sends an unlock message.

[0135] Step 406: The server unlocks the candidate data area and stops the locking timer.

[0136] Steps 407-410 constitute the timeout unlocking process, meaning that if the client does not send an unlock message before the lock timer expires, the server will automatically unlock the device.

[0137] Step 407: The client sends a message, edits the candidate data area, and submits the configuration.

[0138] Step 408: The server processes the client's editing and submission of configurations.

[0139] Step 409: The lock timer times out, the server unlocks the lock, and clears any uncommitted configuration data.

[0140] Step 410: The server sends a message to the client, notifying that the lock has been released due to a timeout.

[0141] Embodiment 2 of this invention extends the locking and unlocking operations defined in the NETCONF protocol standard, enabling both the client and server sides to support locking capabilities with timeouts. Locking timeouts prevent a single client from locking a candidate data area for an extended period, thus preventing other clients from configuring the device.

[0142] Example 3:

[0143] Based on Embodiment 1, Embodiment 3 of the present invention focuses on explaining how to solve the problem when the parameters indicate that the locking message is a message with locking preemption capability, and the parameters also include priority parameters. This problem arises because a client needs to urgently modify the device configuration in order to eliminate device failure or avoid network anomalies, but at this time another client has locked the configuration data area and is performing a low-priority operation, causing the urgent task required by the former to be unable to be completed in time.

[0144] The client in this embodiment of the invention includes at least a first client and a second client. When the parameters indicate that the locking message is a message with locking preemption capability, the parameters also include a priority parameter. The locking and subsequent unlocking of the candidate data area are performed according to the parameters, such as... Figure 5 As shown, it specifically includes:

[0145] Step 501: The server parses the lock message from the first client, where the priority parameter is the first priority.

[0146] In this embodiment of the invention, after the client (including at least a first client and a second client) and the server complete the locking capability negotiation, if both the client and the server support the locking preemption capability, the locking preemption capability can be realized. The client sends a locking message to the server, requesting the server to lock the candidate data area, and the locking message carries a priority parameter. The server parses the locking message sent by the first client, and based on the priority parameter carried in the locking message, it can know the first priority corresponding to the first client.

[0147] Step 502: When the candidate data area is locked by the first client, the server receives a locking message from the second client, where the priority parameter is the second priority.

[0148] The server locks the candidate data area based on the lock message sent by the first client. If, while the candidate data area is locked and before the first client completes its configuration, the server receives a lock message from a second client, it parses the lock message sent by the second client to obtain the second priority corresponding to the second client. It is worth noting that, in this embodiment of the invention, before implementing the locking preemption capability, the priorities of all clients need to be set in advance, and the client can carry its corresponding locking priority when sending a lock message.

[0149] Step 503: Determine the locking permissions of the candidate data area based on the first priority and the second priority.

[0150] The embodiments of the present invention determine the locking permission of the candidate data area by comparing the first priority and the second priority.

[0151] Step 504: If the first priority is not less than the second priority, the locking permission continues to belong to the first client, and a locking failure message is sent to the second client.

[0152] If the first priority is greater than or equal to the second priority, it means that the first client's priority is higher than or equal to the second client's priority. The locking permission for the candidate data area still belongs to the first client. At this time, the server determines that the second client has failed to lock and sends a locking failure message to the second client.

[0153] Step 505: If the first priority is lower than the second priority, the server unlocks the candidate data area, transfers the locking permission to the second client, clears the configuration data not submitted by the first client, and sends a feedback message to the first client that the candidate data area has been preempted by another client.

[0154] If the first priority is lower than the second priority, it means that the first client's priority is lower than the second client's priority. The server determines that the second client has successfully locked the candidate data area, unlocks the candidate data area, transfers the locking permission to the second client, clears the configuration data of the first client, and sends a feedback message to the first client that the candidate data area has been preempted by the second client. Then, based on the second client's locking message, the server locks the candidate data area and executes the configuration process for the second client.

[0155] If the first priority is not less than the second priority, the locking permission continues to belong to the first client. This is followed by an unlocking process for the candidate data area, which can be done in two ways: Figure 6 As shown, the first unlocking method for the candidate data area is as follows:

[0156] Step 601: Write the configuration data of the first client into the candidate data area.

[0157] Step 602: After receiving the configuration submission message from the first client, copy the configuration data to the runtime data area.

[0158] Step 603: After receiving the unlock request message from the first client, unlock the candidate data area.

[0159] For the candidate data area, a second unlocking method is also included. The parameters indicate that when the locked message still has the ability to unlock after submission, if the first priority is not less than the second priority, the locking permission continues to belong to the first client. This further includes, for example... Figure 7 As shown, specifically:

[0160] Step 701: Write the configuration data of the first client into the candidate data area;

[0161] Step 702: After receiving the configuration submission message from the first client, copy the configuration data to the running data area. After the configuration takes effect, directly unlock the candidate data area.

[0162] The first and second unlocking methods for the candidate data area have been described in detail in step 304 of embodiment 2 of the present invention, and will not be repeated here.

[0163] The following details the process of implementing the locking and preemption function between the server and the client in this embodiment of the invention. After the client and server complete the locking capability negotiation, if both the server and the client support the locking and preemption capability, then it can be performed as follows: Figure 8 As shown, this implements the locking and preemption function.

[0164] Step 801: The first client sends a message to the server to lock the candidate data area with a locking priority of X. Here, we will use X=10 as an example for explanation. The message content and format are shown in the following example:

[0165]

[0166]

[0167] Step 802: The server locks the candidate data area.

[0168] Step 803: The second client sends a message to the server to lock the candidate data area with a locking priority of Y. Here, Y is 8 as an example for explanation.

[0169] Step 804: Since the locking priority of the second client is lower than that of the first client, the server determines that the second client's locking has failed.

[0170] In step 805, the server sends a message to the second client, notifying that the lock failed and the data area has been locked by another client.

[0171] Step 806: The second client sends a message to the server to lock the candidate data area with a locking priority of Z. Here, Z is 15 as an example for explanation.

[0172] Step 807: Since the second client's locking priority is higher than that of the first client, the server determines that the second client has successfully locked the data, transfers the locking permission of the candidate data area to the second client, and clears the configuration data that the first client has not submitted.

[0173] Step 808: The server sends a message to the second client, notifying it that the lock was successful.

[0174] Step 809: The server sends a message to the first client, notifying it that the lock has been released due to a higher-priority client preempting the lock.

[0175] Embodiment 3 of this invention extends the locking and unlocking operations defined in the NETCONF protocol standard, enabling both the client and server sides of this embodiment to support lock preemption capabilities. Through lock preemption, clients requiring urgent device operation are allowed to obtain priority access to the configuration data area, ensuring that urgent tasks are executed first.

[0176] Example 4:

[0177] Based on Embodiment 1, Embodiment 3 of the present invention focuses on how to solve the problem that when the parameters indicate that the locked message has the ability to unlock after submission, other clients cannot edit the candidate data area and do not know when it will be unlocked, so they need to repeatedly try the locking operation, which in turn generates additional waiting time and processing overhead.

[0178] In this embodiment of the invention, after the client and server complete the locking capability negotiation, if both the client and server support the post-commit unlock capability, the post-commit unlock function can be implemented. The client sends a locking message to the server, and the server parses the locking message to obtain the corresponding parameters. When the parameters indicate that the locking message has the post-commit unlock capability, the candidate data area is locked and subsequently unlocked according to the parameters. Figure 9 As shown, it specifically includes:

[0179] Step 901: Receive configuration data from the client and write the configuration data into the candidate data area.

[0180] The server receives configuration data from the client and writes the configuration into the candidate data area.

[0181] Step 902: After receiving the configuration submission message from the client, copy the configuration data to the running data area. After the configuration takes effect, directly unlock the candidate data area.

[0182] After receiving the configuration submission message from the client, the server copies the configuration data to the runtime data area, the configuration takes effect, the candidate configuration area is unlocked directly, and the server sends a message to the client to notify the client that the candidate data area has been unlocked.

[0183] The following details the process by which the server and client implement the "unlock after submission" function in this embodiment of the invention. After the client and server complete the negotiation on locking capabilities, if both the client and server support the "unlock after submission" capability, then the process can proceed as follows: Figure 10 As shown, this implements the function of unlocking after submission.

[0184] Step 1001: The client sends a message to the server to lock the candidate data area. The lock message carries an unlock parameter after submission. The message content and format are shown in the following example:

[0185]

[0186] Step 1002: The server locks the candidate data area.

[0187] Step 1003: The client sends a message to the server to edit the candidate data area.

[0188] Step 1004: The server writes the configuration data into the candidate data area.

[0189] Step 1005: The client sends a message to the server to submit the configuration.

[0190] Step 1006: The server copies the configuration data to the running data area, and the configuration takes effect.

[0191] Step 1007: The server automatically unlocks the candidate data area.

[0192] Step 1008: The server sends a message to the client, notifying them that the candidate data area has been unlocked.

[0193] Embodiment 4 of this invention extends the locking and unlocking operations defined in the NETCONF protocol standard, enabling both the client and server sides of this embodiment to support the locking capability of unlocking after submission. This unlock-after-submission feature allows the server to automatically unlock the candidate data area after the client successfully submits the configuration, thereby reducing the time overhead of waiting for unlock messages and improving efficiency.

[0194] Example 5:

[0195] Based on Embodiment 1, Embodiment 5 of the present invention extends the locking and unlocking operations defined in the NETCONF protocol standard, enabling both the client and server sides of the present invention to support the locking capability of locking additional configurations. This solves the problem that even if multiple clients have different configuration data to be edited and there are no syntax or business-level conflicts in the configuration data area, the configuration operations can still only be executed serially, resulting in low efficiency.

[0196] The client in this embodiment of the invention includes at least a first client and a second client. When the candidate data area is locked by the first client, and the server receives a locking message from the second client, and the parameters indicate that the locking message has additional configuration capabilities, the parameters also contain the configuration data of the second client, such as... Figure 11 As shown, the method for configuring concurrent multi-client configuration also includes:

[0197] Step 1101: Cache the configuration data of the second client and send a message to the second client to wait for lock.

[0198] The server parses the lock message from the second client to obtain the second client's configuration data. The second client's configuration data is contained in the lock message it sent, specifically as described in step 1205, "Lock Message". <config> and< / config> The content between the tags. In this embodiment of the invention, the second client sends a lock message to the server. The server receives the lock message and parses it. The lock message contains the second client's configuration data. By parsing the lock message, the server can obtain the second client's configuration data.

[0199] After the server obtains the configuration data from the second client, it caches the configuration data on the server and sends a message to the client stating that the configuration is cached and awaiting locking. It's worth noting that since the first client is currently occupying the candidate data area and configuring it, and has not yet released its lock on the candidate data area, the server caches the second client's configuration data internally, not in the candidate data area.

[0200] Step 1102: After the first client unlocks the candidate data area, determine whether the configuration data of the second client conflicts with the latest configuration data in the candidate data area.

[0201] Since the first client has already edited the candidate data area during its configuration process, after the first client unlocks the candidate data area, a conflict verification is performed on the second client's configuration data to determine whether there is a conflict between the second client's configuration data and the latest configuration data in the candidate data area. If a conflict exists, even after the first client unlocks the candidate data area, the second client may still be unable to perform normal configuration. For example, suppose that during the first client's configuration process, file A needs to be deleted, but the second client needs file A to complete the normal configuration. After the first client unlocks the candidate data area, the candidate data area now contains the latest configuration data, i.e., the first client's configuration data has already been written into it, and file A has been deleted. When the cached configuration data of the second client needs to be stored in the candidate data area, the lack of file A causes a conflict, preventing the cached configuration data of the second client from being stored in the candidate data area.

[0202] Step 1103: If a conflict exists, clear the cached configuration data and send a lock failure message to the second client.

[0203] When a conflict occurs, the server clears the cached configuration data and sends a locking failure message to the second client, informing the second client that the locking has failed.

[0204] Step 1104: If there is no conflict, store the cached configuration data in the candidate data area, transfer the locking permission to the second client, and send a message to the second client indicating successful locking.

[0205] If no conflict exists, the cached configuration file is stored in the candidate data area, the locking permission is transferred to the second client, and a locking success message is sent to the second client. In this embodiment of the invention, during the configuration process on the first client, the configuration data cached by the second client is stored in the server (not in the candidate data area) in advance. After the first client unlocks the candidate data area, it performs conflict checking on the cached configuration data. If no conflict exists, the cached data is directly stored in the candidate data area, thus saving the time of writing the configuration data to the candidate data area one by one.

[0206] The following details the process by which the server and client implement the locking additional configuration function in this embodiment of the invention. After the client and server complete the locking capability negotiation, if both the server and client support the locking additional configuration capability, then it can be done as follows: Figure 12 As shown, this implements the function of locking additional configurations.

[0207] Step 1201: The first client sends a message to the server to lock the candidate data area.

[0208] Step 1202: The server locks the candidate data area.

[0209] Step 1203: The first client sends a message to the server to edit and submit the configuration.

[0210] Step 1204: The server processes the first client's edit and submit configuration operations.

[0211] Step 1205: The second client sends a message to the server to lock the candidate data area. The lock message includes configuration data. Example of message content and format:

[0212]

[0213] Step 1206: The server caches the configuration data of the second client.

[0214] Step 1207: The server sends a message to the second client, notifying it that the configuration data has been cached and is waiting to be locked.

[0215] Step 1208: The first client sends a message to the server to unlock the candidate data area.

[0216] Step 1209: The server unlocks the candidate data area and checks whether the configuration data of the cached second client conflicts with the latest configuration data.

[0217] Steps 1210-1211 are the lock failure process.

[0218] Step 1210: Data conflict, locking failed, server clears cached configuration data.

[0219] Step 1211: The server sends a message to the client, notifying it that the lock failed.

[0220] Steps 1212-1216 constitute the successful lock process.

[0221] In step 1212, with no data conflict, the server transfers the candidate data area permissions to the second client and writes the cached configuration data from step 1207 into the candidate data area.

[0222] Step 1213: The server sends a message to the second client, notifying it that the lock was successful.

[0223] Step 1214: The second client sends a message to the server to submit the configuration.

[0224] Step 1215: The server processes the configuration submission operation.

[0225] Step 1216: The second client sends a message to the server to unlock the candidate data area.

[0226] Embodiment 5 of this invention extends the locking and unlocking operations defined in the NETCONF protocol standard, enabling both the client and server sides of this embodiment to support the locking capability of attaching configuration data to the lock message. This allows the client to attach configuration data to the lock message, reducing the number of message interactions. If the candidate data area is already locked by the first client, the data in the second client is cached. After the first client unlocks the candidate data area, it performs conflict checking on the cached configuration data. If there is no conflict, the cached data is directly stored in the candidate data area, thus saving the time of writing configuration data to the candidate data area one by one, and eliminating the need to repeatedly poll the configuration data area's locking status during the waiting process.

[0227] This embodiment of the invention describes transferring locking permissions to a second client and sending a successful locking message to the second client. It then further includes transferring locking permissions to the second client and unlocking the candidate data area based on the locking message sent by the second client. When the second client acquires locking permissions for the candidate data area, the unlocking of the candidate data area specifically includes the following three methods: First, after receiving a configuration submission message from the second client, the configuration data is copied to the running data area; after receiving an unlock request message from the second client, the candidate data area is unlocked. Second, both the second client and the server have a lock function that unlocks after submission; the second client's lock message carries parameters for unlocking after submission; after transferring locking permissions to the second client and sending a successful locking message, the second client submits a configuration message, copies the configuration data to the running data area, and then unlocks the candidate data area. After the lock expires, the candidate data area is unlocked directly. Alternatively, both the client and the server have the locking capability to unlock after a timeout. The second client's lock message carries a timeout parameter. After transferring the locking permission to the second client and sending a successful lock message, the server parses the received lock message, obtains the timeout parameter, and starts a lock timer. The server then obtains the lock timer's timing value in real time. If the timing value is greater than the timeout parameter, the candidate data area is unlocked. If a configuration submission message from the second client is received before the timeout, the configuration data is copied to the running data area, the candidate data area is unlocked, and the timer is stopped.

[0228] Example 6:

[0229] Embodiment 6 of the present invention also proposes a method for configuring concurrent multi-client configuration, such as... Figure 13 As shown, it includes:

[0230] Step 1301: The client sends a first negotiation message to the server so that the server can determine the locking capability of the client based on the first negotiation message.

[0231] Step 1302: Receive the second negotiation message sent from the server, and determine the locking capability of the server based on the second negotiation message.

[0232] Step 1303: The client sends a lock message to the server, wherein the lock message carries parameters that the server can support, so that the server can lock and subsequently unlock the candidate data area according to the parameters.

[0233] In Embodiment 6 of this invention, steps 1301-1303 are basically the same as in Embodiment 1, except that the execution subject in Embodiment 1 is the server, while in Embodiment 6 of this invention, the execution subject is the client. This invention extends the locking and unlocking operations defined in the extended protocol standard, enabling both the server and client to have locking capabilities, thereby completing the negotiation of locking capabilities. Parameters are carried in the unlock message, allowing unlocking based on these parameters. This avoids the problem where the server's configuration data area lock cannot be released due to software or network failures, such as the client failing to send an unlock message or the unlock message not being delivered to the server, ensuring that other clients can configure the device.

[0234] Furthermore, this invention parses the client's lock message to obtain parameters, which indicate that the client sending the lock message has lock timeout capability, lock preemption capability, commit-and-unlock capability, and lock-and-attach-configuration capability. The lock timeout capability prevents a client from locking the data area for an extended period, thus preventing other clients from configuring the device. The lock preemption capability allows clients requiring urgent device operation to obtain priority access to the configuration data area lock, ensuring that urgent tasks are executed first. The commit-and-unlock capability allows the server to automatically unlock the configuration data area after the client successfully submits the configuration, reducing the time overhead of waiting for unlock messages. The lock-and-attach-configuration capability allows the client to attach configuration data to the lock message, reducing the number of message interactions. When the configuration data area is already locked, it reduces the time the client waits for the data area to unlock, and eliminates the need to repeatedly poll the configuration data area lock status during the waiting process.

[0235] Example 7:

[0236] like Figure 14 The diagram shown is a schematic representation of the architecture of a device according to an embodiment of the present invention. The device of this embodiment includes one or more processors 21 and a memory 22. Figure 14 Take a processor 21 as an example.

[0237] Processor 21 and memory 22 can be connected via a bus or other means. Figure 14 Taking the example of a connection between China and Israel via a bus.

[0238] Memory 22, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs and non-volatile computer-executable programs. Processor 21 executes a method for multi-client concurrent configuration by running the non-volatile software programs and instructions stored in memory 22.

[0239] When the processor executes the method for configuring multiple clients concurrently as in Examples 1-5, the device is a server; when the processor executes the method for configuring multiple clients concurrently as in Example 6, the device is a client.

[0240] Memory 22 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 22 may optionally include memory remotely located relative to processor 21, which can be connected to processor 21 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0241] The program instructions / modules are stored in the memory 22. When executed by one or more processors 21, they execute the multi-client concurrent configuration method in embodiments 1-5 or the multi-client concurrent configuration method in embodiment 6. For example, they execute the methods described above. Figure 1-12 The steps shown.

[0242] The above description is only 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 protection scope of the present invention.< / lock> < / unlock> < / lock> < / commit> < / candidate> < / running>

Claims

1. A method for configuring concurrent multi-client configuration, characterized in that, include: The server receives the first negotiation message from the client and determines the locking capability of the client based on the first negotiation message; A second negotiation message is sent to the client so that the client can determine the locking capability of the server based on the second negotiation message, and then send a corresponding locking message according to the locking capability of the server. Receive a lock message from the client, parse the lock message to obtain parameters, and lock and subsequently unlock the candidate data area according to the parameters; When the parameter indicates that the locking message is a message with locking timeout capability, the parameter also includes a timeout parameter. The locking and subsequent unlocking of the candidate data area according to the parameter specifically includes: starting a locking timer; obtaining the timing value of the locking timer in real time; if the timing value is greater than the timeout parameter, then unlocking the candidate data area; if a configuration submission message from the client is received before the timeout, then copying the configuration data to the running data area, unlocking the candidate data area, and stopping the timer.

2. The method for configuring multiple clients concurrently according to claim 1, characterized in that, When the parameter indicates that the locked message has the capability to unlock after submission, the locking and subsequent unlocking of the candidate data area according to the parameter specifically includes: Receive configuration data from the client and write the configuration data into the candidate data area; After receiving the configuration submission message from the client, the configuration data is copied to the running data area. Once the configuration takes effect, the candidate data area is unlocked directly.

3. The method for configuring multiple clients concurrently according to claim 1, characterized in that, The client includes at least a first client and a second client. When the parameters indicate that the locking message is a message with locking preemption capability, the parameters also include a priority parameter. The locking and subsequent unlocking of the candidate data area according to the parameters specifically includes: The server parses the lock message from the first client, where the priority parameter is the first priority. When the candidate data area is locked by the first client, the server receives a locking message from the second client, and the priority parameter is the second priority. Determine the locking permissions for the candidate data area based on the first and second priorities; If the first priority is not less than the second priority, the locking permission continues to belong to the first client, and a locking failure message is sent to the second client; If the first priority is lower than the second priority, the server unlocks the candidate data area, transfers the locking permission to the second client, clears the configuration data not submitted by the first client, and sends a feedback message to the first client that the candidate data area has been preempted by another client.

4. The method for configuring multiple clients concurrently according to claim 3, characterized in that, If the first priority is not less than the second priority, the locking permission continues to belong to the first client, and the following further includes: Write the configuration data of the first client into the candidate data area; After receiving the configuration submission message from the first client, the configuration data is copied to the runtime data area; Upon receiving the unlock request message from the first client, the candidate data area is unlocked; or, When the parameters of the first client indicate that the locking message still has the ability to unlock after submission: Write the configuration data of the first client into the candidate data area; After receiving the configuration submission message from the first client, the configuration data is copied to the running data area. Once the configuration takes effect, the candidate data area is unlocked directly. or, When the parameters of the first client indicate that the locking message still has the capability to time out, the parameters also include a timeout parameter: Start the lock timer; Obtain the timer value of the lock timer in real time; If the timing value is greater than the timeout parameter, the candidate data area is unlocked; If the configuration submission message from the first client is received before the timeout expires, the configuration data is copied to the running data area, the candidate data area is unlocked, and the timer is stopped.

5. The method for configuring multiple clients concurrently according to claim 1, characterized in that, The client includes at least a first client and a second client. When the candidate data area is locked by the first client, and the server receives a locking message from the second client, and the parameters indicate that the locking message has the capability to add configuration information, the parameters also contain the configuration data of the second client. The method for concurrent configuration by multiple clients further includes: The configuration data of the second client is cached, and a message waiting for lock is sent to the second client; After the first client unlocks the candidate data area, it is determined whether the configuration data of the second client conflicts with the latest configuration data in the candidate data area; If a conflict exists, clear the cached configuration data and send a locking failure message to the second client; If there is no conflict, the cached configuration data is stored in the candidate data area, the locking permission is transferred to the second client, and a message indicating successful locking is sent to the second client.

6. The method for configuring multiple clients concurrently according to claim 5, characterized in that, The process of transferring locking permissions to the second client and sending a successful locking message to the second client further includes: After receiving the configuration submission message from the second client, the configuration data is copied to the runtime data area; Upon receiving the unlock request message from the second client, the candidate data area is unlocked; or, When the parameters of the second client indicate that the lock message still has the ability to unlock after submission, the step of transferring the lock permission to the second client and sending a lock success message to the second client further includes: After receiving the configuration submission message from the second client, the configuration data is copied to the running data area. Once the configuration takes effect, the candidate data area is unlocked directly. or, When the parameters of the second client indicate that the locking message still has the capability to time out, the parameters also include a timeout parameter. The process of transferring locking authority to the second client and sending a successful locking message to the second client then further includes: Start the lock timer; Obtain the timer value of the lock timer in real time; If the timing value is greater than the timeout parameter, the candidate data area is unlocked; If a configuration submission message from the second client is received before the timeout, the configuration data is copied to the running data area, the candidate data area is unlocked, and the timer is stopped.

7. A server-side component, characterized in that, include: At least one processor; At least one memory; The at least one processor and the at least one memory are communicatively connected to each other. The at least one memory stores instructions that can be executed by the at least one processor. The instructions are executed by the at least one processor to enable the at least one processor to perform the multi-client concurrent configuration method according to any one of claims 1-6.

8. A method for configuring concurrent multi-client configuration, characterized in that, include: The client sends a first negotiation message to the server so that the server can determine the locking capability of the client based on the first negotiation message; Receive a second negotiation message from the server, and determine the locking capability of the server based on the second negotiation message; The client sends a lock message to the server, wherein the lock message carries parameters that the server can support, so that the server can lock and subsequently unlock the candidate data area according to the parameters; When the parameter indicates that the locking message is a message with locking timeout capability, the parameter also includes a timeout parameter. The locking and subsequent unlocking of the candidate data area according to the parameter specifically includes: starting a locking timer; obtaining the timing value of the locking timer in real time; if the timing value is greater than the timeout parameter, then unlocking the candidate data area; if a configuration submission message from the client is received before the timeout, then copying the configuration data to the running data area, unlocking the candidate data area, and stopping the timer.

9. A client, characterized in that, include: At least one processor; At least one memory; The at least one processor and the at least one memory are communicatively connected to each other. The at least one memory stores instructions that can be executed by the at least one processor. The instructions are executed by the at least one processor to enable the at least one processor to perform the multi-client concurrent configuration method of claim 8.

Images