Two-stage submission method and device based on RESTCONF framework

Abstract

The invention relates to a two-stage submission method and device based on a RESTCONF framework, which realizes multi-user operation distinguishing, configuration temporary storage and submission and conflict detection by introducing the two-stage submission method into the RESTCONF framework and combining a command line interface identifier, a backup database and a JSON cache, effectively makes up the defect that the RESTCONF lacks NETCONF key functions, and improves the user experience. The flexibility and reliability of configuration management are improved, and modern network management requirements are met.

Description

Technical Field

[0001] The present invention belongs to the technical field of network configuration management, and in particular relates to a two-phase submission method and device based on a RESTCONF framework. Background Art

[0002] Traditional network devices widely use command-line interfaces (CLIs) to handle management and control commands. However, these lack a strict data structure, are prone to errors, and suffer from poor command compatibility. The NETCONF protocol addresses multi-vendor compatibility issues through XML and YANG data modeling, supporting features such as two-phase commit and data rollback. However, its complexity limits its application in lightweight scenarios. The RESTCONF protocol combines the simplicity of HTTP with the YANG model, supports the JSON format, and is well-suited for modern web integration and cloud platform management. It has been adopted in open source projects such as the SONiC white-box operating system. However, due to its use of short HTTP connections, RESTCONF lacks NETCONF's multiple data stores, two-phase commit, data rollback, and configuration locking features, making it ineffective at distinguishing multiple user operations or detecting configuration conflicts. Existing technologies use persistent SSH connections for user identification and data caching. However, the short nature of RESTCONF connections makes it difficult to track user operations, and single database operations can easily lead to multi-user configuration conflicts.

[0003] With enterprises' dual demands for lightweight northbound management interfaces for devices and support for traditional command lines, the RESTCONF framework needs to be modified to support two-phase commit, data rollback, and multi-user conflict detection, which has become a key issue in the current field of network configuration management. Summary of the Invention

[0004] The purpose of the present invention is to provide a two-phase submission method and device based on the RESTCONF framework to address the shortcomings of the existing technology in lacking multi-user operation distinction, configuration temporary storage and conflict management.

[0005] To achieve one of the above-mentioned objectives, an embodiment of the present invention provides a two-phase submission method based on the RESTCONF framework, the method comprising:

[0006] In response to the server receiving the RESTCONF configuration request sent by the client, the server parses and verifies the configuration data in the request, obtains the configuration data that passes the verification, and temporarily stores it in the backup database based on the command line interface identifier;

[0007] After receiving the commit command from the client, the server calls the script to flush the full data of the configuration database and merge it with the temporarily stored configuration data. The merged configuration data is obtained and multi-user conflict detection and verification are performed.

[0008] Based on the comprehensive results of conflict detection and verification, the server performs write or feedback operations on the merged configuration data to obtain the configuration update status or conflict information. If the verification passes, the merged configuration data is written to the configuration database and the relevant cache is cleared. If a conflict is detected, the conflict information is returned to the client.

[0009] The server returns an HTTP response to the client, displays the configuration temporary status or submission result in the response, and obtains a configuration result interface on which the user can continue to operate.

[0010] As a further improvement of an embodiment of the present invention, the method further includes, before the server receives the RESTCONF configuration request,

[0011] When the client logs in to the communication device via SSH, generating a unique command line interface identifier;

[0012] When the client constructs the RESTCONF configuration request, the command line interface identifier is carried in the HTTP request header of the request, and the configuration data is sent to the server to trigger the configuration data temporary storage operation.

[0013] As a further improvement of an embodiment of the present invention, the method further includes that the generation and carrying of the command line interface identifier includes:

[0014] When the client logs in through SSH, a unique command line interface identifier is generated by splicing the SSH session identifier and the user name, and the command line interface identifier is embedded in the user agent field of the HTTP request header of the RESTCONF configuration request to identify the source of the user operation;

[0015] When the client constructs the RESTCONF configuration request, user identification information is added to the URI path and the request body to adapt to the user data table structure in the YANG model extended by the server, thereby ensuring user attribution of the configuration data.

[0016] As a further improvement of an embodiment of the present invention, the method further includes: the configuration data temporary storage operation includes:

[0017] When the server parses and verifies the configuration data, the configuration data is verified for format and logic correctness through CVL;

[0018] If the verification fails, the server constructs an error message and returns it to the client via HTTP response, and terminates the configuration data temporary storage process;

[0019] If the verification passes, the server will temporarily store the configuration data in the backup database.

[0020] As a further improvement of an embodiment of the present invention, the method further includes that temporarily storing the configuration data in the backup database includes:

[0021] The server writes the verified configuration data into the backup database and marks it with the command line interface identifier to achieve user isolation, thereby obtaining the marked temporary configuration data;

[0022] The server records the operation metadata in a JSON cache file to support subsequent submission and conflict detection.

[0023] As a further improvement of an embodiment of the present invention, the method further includes that the configuration data submission and conflict detection operation includes:

[0024] After receiving the commit command, the server calls the Lua script to flush all the data in the configuration database to obtain the latest configuration status;

[0025] The server merges the latest configuration state with the temporarily stored configuration data marked by the command line interface identifier to obtain the merged configuration data and performs multi-user conflict detection and verification.

[0026] As a further improvement of an embodiment of the present invention, the method further includes that the conflict detection and verification includes:

[0027] Performing a CVL check on the merged configuration data by the server to detect whether there is a multi-user configuration conflict;

[0028] If the verification fails, the server constructs conflict information and returns it to the client via HTTP response;

[0029] If the verification is successful, the server writes the configuration data into the configuration database, clears the table entries marked with the command line interface identifier in the backup database and the operation records in the JSON cache file, and completes the configuration submission.

[0030] To achieve one of the above-mentioned objects of the invention, an embodiment of the present invention further provides a two-phase submission device based on the RESTCONF framework, the device comprising a request module, a verification module, an update module and a display module;

[0031] The request module is used to respond to the RESTCONF configuration request sent by the client received by the server, parse and verify the configuration data in the request, obtain the configuration data that passes the verification and temporarily store it in the backup database based on the command line interface identifier;

[0032] The verification module is used to call a script to flush the full data of the configuration database and merge it with the temporarily stored configuration data after the server receives the commit command sent by the client, obtain the merged configuration data, and perform multi-user conflict detection and verification;

[0033] The update module is used to perform a write or feedback operation on the merged configuration data through the server based on the comprehensive results of conflict detection and verification, obtain the configuration update status or conflict information, and write the merged configuration data to the configuration database and clear the relevant cache when the verification passes, and return the conflict information to the client when a conflict is detected;

[0034] The display module is used to return an HTTP response to the client through the server, display the configuration temporary storage status or submission result in the response, and obtain a configuration result interface on which the user can continue to operate.

[0035] In order to achieve one of the above-mentioned purposes of the invention, an embodiment of the present invention also provides an electronic device, including a memory and a processor, characterized in that the memory stores a computer program that can be run on the processor, and when the program is executed on the processor, the steps in the two-phase submission method based on the RESTCONF framework as described above are implemented.

[0036] To achieve one of the above-mentioned objects of the invention, an embodiment of the present invention further provides a storage medium, wherein the storage medium stores a computer program, and wherein when the computer program is executed by a processor, the steps in the two-phase submission method based on the RESTCONF framework are implemented as described above.

[0037] Compared with the prior art, the present invention provides a two-phase submission method and device based on the RESTCONF framework. By introducing the two-phase submission method into the RESTCONF framework and combining it with a command line interface identifier, a backup database, and a JSON cache, the present invention realizes multi-user operation differentiation, configuration temporary storage and submission, and conflict detection. This effectively makes up for the deficiency of RESTCONF in lacking the key functions of NETCONF, improves the flexibility and reliability of configuration management, and adapts to modern network management requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 This is an overall flow chart of the two-phase submission method based on the RESTCONF framework described in the present invention.

[0039] Figure 2 This is a flow chart for implementing the server-side two-phase commit of the two-phase commit method based on the RESTCONF framework described in the present invention.

[0040] Figure 3This is a schematic diagram of the effect of a user logging into a SONiC device in a two-phase commit mode using the two-phase commit method based on the RESTCONF framework described in the present invention.

[0041] Figure 4 This is a schematic diagram of the effect of viewing the stored information in the redis database using the two-phase commit method based on the RESTCONF framework described in the present invention.

[0042] Figure 5 This is a schematic diagram of submitting the current configuration using the two-phase submission method based on the RESTCONF framework described in the present invention.

[0043] Figure 6 This is a schematic diagram of the effect of submitting user configuration information from a backup database to a configuration database using the two-phase submission method based on the RESTCONF framework described in the present invention.

[0044] Figure 7 This is a schematic diagram of the effect of two users using admin as the login name to log in to the device command line interface at the same time using the two-phase submission method based on the RESTCONF framework of the present invention.

[0045] Figure 8 This is a schematic diagram of the effect of a user configuring apn-related commands in an interface with a command line interface identifier of admin0 according to the two-phase submission method based on the RESTCONF framework of the present invention.

[0046] Figure 9 It is a structural diagram of the two-phase submission device based on the RESTCONF framework described in the present invention. DETAILED DESCRIPTION

[0047] The present invention will be described in detail below with reference to the specific embodiments shown in the accompanying drawings. However, these embodiments do not limit the present invention, and any structural, methodological, or functional changes made by those skilled in the art based on these embodiments are all within the scope of protection of the present invention.

[0048] The embodiments of the present invention are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention and are not to be construed as limiting the present invention.

[0049] In the first embodiment of the present invention, the present invention provides a two-phase submission method based on the RESTCONF framework, such as Figure 1 As shown, the method includes,

[0050] S1: In response to the server receiving the RESTCONF configuration request sent by the client, the server parses and verifies the configuration data in the request, obtains the verified configuration data, and temporarily stores it in the backup database based on the command line interface identifier;

[0051] S2: After receiving the commit command from the client, the server calls a script to flush the full data of the configuration database and merge it with the temporarily stored configuration data. The merged configuration data is then detected and verified for multi-user conflicts.

[0052] S3: Based on the combined results of conflict detection and verification, the server performs a write or feedback operation on the merged configuration data to obtain the configuration update status or conflict information. If the verification passes, the merged configuration data is written to the configuration database and the relevant cache is cleared. If a conflict is detected, the conflict information is returned to the client.

[0053] S4: The server returns an HTTP response to the client, displays the configuration temporary status or submission result in the response, and obtains a configuration result interface on which the user can continue to operate.

[0054] In a specific embodiment of the present invention, before the server receives the RESTCONF configuration request, the method further includes:

[0055] When the client logs in to the communication device via SSH, generating a unique command line interface identifier;

[0056] When the client constructs the RESTCONF configuration request, the command line interface identifier is carried in the HTTP request header of the request, and the configuration data is sent to the server to trigger the configuration data temporary storage operation.

[0057] It should be noted that before the server receives a RESTCONF configuration request, the client performs the following preparatory operations to ensure traceability of configuration data and user isolation:

[0058] The client logs in to the communication device using the SSH protocol to access the command line interface (CLI). During the login process, the system generates a unique CLI identifier based on the SSH session ID and the login username. This identifier is formed by concatenating the SSH session ID and username. For example, the username "admin" and the session ID "0" are concatenated to generate the identifier "admin0." This identifier uniquely identifies the user's operation window, ensuring that configuration actions by different users can be distinguished in multi-user scenarios, laying the foundation for subsequent two-phase commit and multi-user conflict detection.

[0059] Furthermore, when constructing a RESTCONF configuration request, the client embeds the generated command-line interface identifier in the User-Agent field of the HTTP request header to identify the source of the user operation. RESTCONF configuration requests are based on HTTP methods (such as POST, PUT, PATCH, etc.). Their URI path and request body are constructed according to the server-extended YANG model and contain user identification information. For example, for ACL configuration, the client constructs the URI path: / restconf / data / sonic-user-acl:sonic-user-acl / USER_ACL_TABLE / USER_ACL_TABLE_LIST={usr_name},{acl_name}, and the request body contains the user identifier and configuration parameters. By carrying the command-line interface identifier in the request, the client ensures that the server can identify the source of the operation and associate it with the correct user data table.

[0060] After constructing the request, the client sends the configuration data to the server via HTTP, triggering the server's temporary storage of the configuration data. Upon receiving the request, the server parses the User-Agent field in the HTTP request header to extract the command-line interface identifier. Based on the URI path and the user identification information in the request body, the server temporarily stores the configuration data in a backup database, providing a data foundation for subsequent verification and submission operations.

[0061] In a specific embodiment of the present invention, the command line interface identifier is generated and carried as follows:

[0062] When the client logs in through SSH, a unique command line interface identifier is generated by splicing the SSH session identifier and the user name, and the command line interface identifier is embedded in the user agent field of the HTTP request header of the RESTCONF configuration request to identify the source of the user operation;

[0063] When the client constructs the RESTCONF configuration request, user identification information is added to the URI path and the request body to adapt to the user data table structure in the YANG model extended by the server, thereby ensuring user attribution of the configuration data.

[0064] It should be noted that the generation and carrying process of the command line interface identifier includes the following detailed steps to ensure the traceability of user operations and the correct transmission of configuration data in the RESTCONF framework:

[0065] When a client logs in to a communication device using the SSH protocol, the system generates a unique command-line interface identifier (CLI) to identify the user's operation window. This identifier is formed by concatenating the SSH session identifier and the login username. For example, if the username is "admin" and the SSH session identifier is "0," the identifier "admin0" is generated. The uniqueness of this identifier ensures that the server can accurately distinguish configuration operations from different users in multi-user concurrent scenarios, providing a basis for two-phase commit and multi-user conflict detection. After generation, the client embeds this CLI identifier in the User-Agent field of the HTTP request header of the RESTCONF configuration request to identify the source of the operation. For example, when sending a POST, PUT, or PATCH request, the User-Agent field is set to "admin0," allowing the server to identify the specific user by parsing the request header.

[0066] Furthermore, when constructing a RESTCONF configuration request, the client designs the URI path and request body based on the server's extended YANG model, ensuring that user identification information is included to match the server's user data table structure. For example, for ACL configuration, the client constructs the URI path: / restconf / data / sonic-user-acl:sonic-user-acl / USER_ACL_TABLE / USER_ACL_TABLE_LIST={usr_name},{acl_name}, where usr_name corresponds to the command-line interface identifier and acl_name is the name of the configured ACL table. The request body also contains user identification information, for example, {"sonic-user-acl:USER_ACL_TABLE_LIST": [{"usr_name": "admin0", "acl_name": "test"}]}. By including user identification information in the URI and request body, the client ensures that the configuration data corresponds to the user data table defined in the server's YANG model, thereby implementing user-attributed configuration data. After receiving the request, the server parses the URI path and the usr_name field in the request body, associates the configuration data with a specific user, and stores it in the backup database to support subsequent staging and submission operations.

[0067] In a specific implementation scenario of the present invention, taking the ACL service as an example, the YANG data definition format corresponding to the immediate-effective mode without two-phase commit is as follows:

[0068] container sonic-acl {

[0069] container ACL_TABLE {

[0070] sonic-ext:db-name "CLI_DB";

[0071] list ACL_TABLE_LIST {

[0072] key "acl_name";}

[0073] leaf acl_name {

[0074] type string;

[0075] }

[0076] }

[0077] }

[0078] }

[0079] The YANG data definition format corresponding to the newly added two-phase commit mode is as follows:

[0080] container sonic-user-acl {

[0081] container USER_ACL_TABLE {

[0082] sonic-ext:db-name "USER_CLI_DB";

[0083] list USER_ACL_TABLE_LIST {

[0084] key "usr_name acl_name";

[0085] leaf usr_name {

[0086] type string;

[0087] }

[0088] leaf acl_name {

[0089] type string;

[0090] }

[0091] }

[0092] }

[0093] }

[0094] By comparison, the advantages of the two-phase commit mode provided by the present invention are as follows: First, to avoid conflicts with YANG files in normal mode, the "user" or "USER" field is inserted into the container node name in the YANG data format; Second, the database index name "USER_CLI_DB" in the two-phase mode is distinguished from the immediate-effective mode. When a user enters an ACL-related command in the two-phase mode, the data is first temporarily stored in the "USER_CLI_DB" database; Third, a key item "usr_name" is added to the LIST table, corresponding to the user command line interface identifier. After the user enters the ACL-related command, the operation data is temporarily stored in the backup database represented by "USER_CLI_DB", and the key contains the login window identifier as a tag. After the user enters the "commit" command to submit the current window operation, the server can merge the table marked with "usr_name" with the table in the configuration database "CLI_DB".

[0095] Corresponding to the newly added YANG data format, the REST API input content structure for the immediate-effective mode and two-phase commit mode is as follows:

[0096] keypath = cc.Path(' / restconf / data / sonic-acl:sonic-acl / ACL_TABLE / ACL_TABLE_LIST={acl_name}', acl_name=args[1])

[0097] body = {

[0098] "sonic-acl:ACL_TABLE_LIST": [{

[0099] "acl_name": args[1]

[0100] }]

[0101] }

[0102] aa.patch(keypath, body )

[0103] keypath = cc.Path(' / restconf / data / sonic-user-acl:sonic-user-acl / USER_ACL_TABLE / USER_ACL_TABLE_LIST={usr_name},{acl_name}', usr_name=args[0], acl_name=args[1])

[0104] body = {

[0105] "sonic-user-acl:USER_ACL_TABLE_LIST": [{

[0106] "usr_name": args[0],

[0107] "acl_name": args[1],

[0108] }]

[0109] }

[0110] aa.patch(keypath, body, user_agent=args[0])

[0111] The above Python code is an example of calling YANG data. The keypath variable represents the URI for accessing the YANG data node, and the body variable represents the data content to be delivered. By comparing the names of several URI nodes, it can be seen that the URI in immediate mode accesses the ACL data table defined by the YANG data in normal mode, while the URI in two-phase mode accesses the ACL data table defined by the YANG data in two-phase mode. The two-phase commit mode requires the user command line interface identifier (user_name) to be included in the URI and the delivered data. This is the value represented by the "usr_name" field. When calling the REST API interface in immediate mode, such as when sending data in a patch, the keypath and body parameters are passed in. The two-phase commit mode requires the user_agent parameter to be passed in for mode determination on the server side.

[0112] In a specific embodiment of the present invention, the configuration data temporary storage operation is specifically as follows:

[0113] When the server parses and verifies the configuration data, the configuration data is verified for format and logic correctness through CVL;

[0114] If the verification fails, the server constructs an error message and returns it to the client via HTTP response, and terminates the configuration data temporary storage process;

[0115] If the verification passes, the server will temporarily store the configuration data in the backup database.

[0116] It should be noted that the configuration data temporary storage operation includes the following detailed steps to ensure the correctness of the configuration data and the implementation of user isolation in the RESTCONF framework:

[0117] After receiving a RESTCONF configuration request from a client, the server first parses and validates the configuration data in the request. This parsing process involves extracting the user-agent field in the HTTP request header to obtain the command-line interface identifier, and parsing the user identification information and configuration parameters in the URI path and request body. The server then verifies the format and logical correctness of the configuration data using CVL. CVL verifies that the data structure conforms to the YANG model definition and checks that the data satisfies logical constraints, such as parameter consistency in ACL configuration. If the verification fails, the server constructs an error message that clearly indicates the reason for the verification failure (such as a format error or logical conflict) and returns it to the client via an HTTP response, terminating the temporary storage process for the configuration data to prevent invalid data from entering the backup database.

[0118] Furthermore, if the CVL verification passes, the server will temporarily store the verified configuration data in the backup database. During the storage process, the server uses the command line interface identifier as a tag to write the configuration data to the user data table in the backup database to achieve data isolation in multi-user scenarios. For example, for ACL configuration, the table item stored by the server contains a "type" attribute value of "L3" and is associated with the command line interface identifier. At the same time, the server records the metadata of the operation to a JSON cache file to track the user's configuration operations and support subsequent submission and conflict detection. This temporary storage operation ensures that the configuration data can be safely stored before submission and provides a data basis for multi-user conflict detection.

[0119] In a specific embodiment of the present invention, the configuration data is temporarily stored in the backup database, specifically,

[0120] The server writes the verified configuration data into the backup database and marks it with the command line interface identifier to achieve user isolation, thereby obtaining the marked temporary configuration data;

[0121] The server records the operation metadata in a JSON cache file to support subsequent submission and conflict detection.

[0122] It should be noted that the operation of temporarily storing configuration data in the backup database includes the following detailed steps to ensure the secure storage of configuration data in the RESTCONF framework, user isolation, and support for subsequent submission and conflict detection:

[0123] After the server confirms the format and logical correctness of the configuration data through CVL verification, it writes the verified configuration data to the backup database. During the writing process, the server uses the command line interface identifier as an index tag to store the configuration data in the user data table of the backup database to achieve data isolation in multi-user scenarios. For example, for ACL configuration, the table entry stored by the server contains the attribute "type" with a value of "L3" and is associated with a specific user through the command line interface identifier "admin0". This marking mechanism ensures that the configuration data of different users does not interfere with each other in the backup database, and the resulting temporarily stored configuration data after marking provides accurate user attribution information for subsequent submission operations.

[0124] Furthermore, the server records the operation metadata related to the configuration data in a JSON cache file to support subsequent two-phase commit and multi-user conflict detection. Operation metadata includes RedisKey, attribute value, CVL operation type (such as create or modify), and data table name. These metadata are stored in JSON format and record each user's configuration behavior in the order of operations, such as recording the operation details of ACL table creation or attribute modification. The JSON cache file provides the server with an operation history, which facilitates sequential traversal of the operation records when receiving the "commit" command, merging with the data in the configuration database and performing conflict detection. This recording mechanism ensures the traceability of configuration data and provides support for configuration consistency verification in multi-user concurrent scenarios.

[0125] In a specific implementation scenario of the present invention, Figure 2 As shown, the server-side two-phase commit implementation process is as follows:

[0126] 1. The user logs in to the command line interface in two-phase commit mode via SSH and adds configuration commands to the command line. The client then sends an HTTP request to the server.

[0127] 2. After receiving the request, the server first determines whether the configuration command is a "commit" command.

[0128] 3. If it is not a "commit" command, determine whether there is cache information marked with the command line interface identifier in the backup database.

[0129] 4. If no cached information exists, the Lua script is triggered to flush the data in the configuration database (ConfigDB) to the backup database and mark it with the command line interface identifier. If cached information exists, the CVL check is performed on the configuration data sent by the client.

[0130] 5. If the CVL check fails, construct the CVL failure information, send an HTTP response, and reply the result to the client; if the CVL check succeeds, send the client configuration data to the backup database, and record the successful backup database operation in the json file marked with the command line interface identifier, and finally send an HTTP response to the client.

[0131] 6. If the server receives the request and determines that the configuration command is a "commit" command, it triggers the Lua script to flush the data in ConfigDB to the backup database and merge it with the table entry marked with the command line interface identifier.

[0132] 7. After the merge is completed, the server reads the JSON file marked with the command line interface identifier, traverses each operation record from top to bottom in sequence, and generates configuration data.

[0133] 8. Perform CVL verification on the configuration data generated by each operation record.

[0134] 9. If the CVL check fails, construct a multi-user configuration conflict detection message and send an http response to the client.

[0135] 10. If the CVL verification succeeds, all the configuration data recorded in the json file is merged into the configuration database ConfigDB, and the json file cache and all entries marked with the command line interface identifier in the backup database are cleared. Finally, an http response is sent to the client.

[0136] In a specific embodiment of the present invention, the configuration data submission and conflict detection operation is specifically as follows:

[0137] After receiving the commit command, the server calls the Lua script to flush all the data in the configuration database to obtain the latest configuration status;

[0138] The server merges the latest configuration state with the temporarily stored configuration data marked by the command line interface identifier to obtain the merged configuration data and performs multi-user conflict detection and verification.

[0139] It should be noted that the configuration data submission and conflict detection operation includes the following detailed steps to ensure that the second phase of the two-phase commit in the RESTCONF framework can accurately merge configuration data and detect potential conflicts in multi-user scenarios:

[0140] After receiving the commit command from the client, the server triggers the second phase of the two-phase commit. First, the server calls a Lua script to flush all data in the configuration database, copying the latest configuration status to the backup database. This flushing operation is intended to obtain the latest configuration data submitted by other users in the configuration database, ensuring that subsequent merge and verification processes are based on the current global configuration status. For example, if other users have submitted ACL configurations or app-group length configurations, the flushing operation will update this data to the backup database, providing a complete data foundation for conflict detection.

[0141] Furthermore, the server merges the latest configuration status obtained by back-flushing with the temporary configuration data marked with the command line interface identifier in the backup database to generate the merged configuration data. Specifically, the server reads the table entry associated with the user identifier in the backup database, and combines it with the operation metadata recorded in the JSON cache file to integrate the temporary data with the full data of the configuration database in the order of operation. For example, for ACL configuration, the server merges the temporary "type:L3" attribute with the existing ACL table in the configuration database. After the merge, the server performs CVL verification on the merged configuration data to detect whether there is a multi-user configuration conflict. For example, if multiple users modify a shared resource at the same time, the CVL verification will identify a conflict and generate a verification failure result. The verification process ensures that the merged configuration data complies with the logical constraints and device configuration rules of the YANG model, thereby ensuring the consistency and reliability of the configuration. This merge and verification operation provides the data basis for the final submission or conflict feedback.

[0142] In a specific embodiment of the present invention, conflict detection and verification are specifically as follows:

[0143] Performing a CVL check on the merged configuration data by the server to detect whether there is a multi-user configuration conflict;

[0144] If the verification fails, the server constructs conflict information and returns it to the client via HTTP response;

[0145] If the verification is successful, the server writes the configuration data into the configuration database, clears the table entries marked with the command line interface identifier in the backup database and the operation records in the JSON cache file, and completes the configuration submission.

[0146] It should be noted that the conflict detection and verification operation includes the following detailed steps to ensure that the second phase of the two-phase commit in the RESTCONF framework can accurately verify the consistency of the configuration data and complete the commit or feedback conflict information:

[0147] After the server completes the configuration data merge, it performs a CVL check on the merged configuration data to detect any multi-user configuration conflicts. The merged configuration data contains the temporary configuration data marked with the command line interface identifier in the backup database and the latest configuration status submitted by other users in the configuration database. The CVL check is based on the server-side extended YANG model to verify the format and logical correctness of the merged data and check whether the configuration constraints of the device are met. For example, in a multi-user scenario, if user "admin0" attempts to submit a configuration with an app-group length of 30, and another user "admin1" has submitted a configuration with a length of 10, the CVL check will detect that the total length of the two exceeds the length limit, thereby identifying a configuration conflict. This verification process ensures the consistency and compatibility of configuration data in multi-user concurrent scenarios.

[0148] Furthermore, if the CVL check fails, the server constructs detailed conflict information, clearly indicating the cause of the conflict, such as "app-group length exceeds the limit" or "ACL table configuration is incompatible with existing data." The conflict information is returned to the client via an HTTP response, informing the user of the specific reason for the configuration failure, and terminating the submission process. The temporary data in the backup database is retained so that the user can modify and resubmit it. If the CVL check succeeds, it indicates that the merged configuration data has no conflicts and complies with the constraints of the YANG model. The server writes the configuration data into the configuration database. For example, for ACL configuration, the server writes attributes such as "type: L3" to the corresponding table entries in ConfigDB. Subsequently, the server clears the table entries marked with the command line interface identifier in the backup database and the relevant operation metadata recorded in the JSON cache file to release storage resources and avoid redundant data. After completing the above operations, the server returns a confirmation message of successful submission to the client via an HTTP response, thereby completing the entire two-stage submission process.

[0149] In a specific implementation scenario of the present invention, an example of a single-user configuration scenario involves steps 1, 2, 3, 4, 6, 7, 8, and 10 of the server-side two-phase commit implementation process.

[0150] An example of a user issuing an ACL configuration is as follows: Figure 3As shown in the figure, a user logs in to the SONiC device in two-phase commit mode. The login username is admin, and the SSH session ID is 0. Therefore, the command line interface identifier is admin0, and the table entries marked with admin0 in the backup database are cleared. The user then enters "configure terminal" to enter the configuration view, enters "acl test" to create an ACL table named "test", enters the ACL configuration view, and enters "type l3" to modify the "type" attribute of the current ACL table. Both the "acl test" and "type l3" commands trigger the client to send configuration data to the backup database. The "acl test" command, as the first command entered on this interface, triggers the data sending command. The server triggers the Lua script to flush the data in ConfigDB to the backup database.

[0151] Before the admin0 user sends the configuration, the server has no configuration data cache. When the first command is sent, the database is triggered to flush accurately to identify the admin0 operation. The cache configuration of the admin0 user can be queried in the backup database on the 15th, such as Figure 4 As shown in the figure, to view the Redis database storage information and verify whether the delivered configuration data is consistent with expectations, first enter "redis-cli" in the system shell interface to access the Redis database, enter "SELECT 15" to switch to database 15, which is the backup database, and enter "keys *ACL*" to list all table entries containing the "ACL" field in the table name. An ACL table entry named "test" configured by the command line interface identifier "admin0" is found: "USER_ACL_TABLE|admin0|test". "hgetall USER_ACL_TABLE|admin0|test" command is used to view the properties of the table entry, and it can be seen that the "type" attribute is indeed the previously configured "L3".

[0152] After the data dependency check of the current command line configuration of the admin0 user passes, a two-stage commit is performed, such as Figure 5 As shown, the user continues to enter the "commit" command to commit the current configuration.

[0153] After submitting the configuration, the configuration of the admin0 user in database 15 is cleared, and all cached configurations are successfully submitted to database 4. Figure 6 As shown in FIG. 1 , after the user submits the configuration, the previously configured ACL-related table entry information in the backup database, namely database No. 15, is cleared, and the ACL-related configuration information can be found in database No. 4, namely the configuration database.

[0154] In a specific implementation scenario of the present invention, an example of a multi-user configuration scenario involves steps 1, 2, 3, 4, 6, 7, 8, 9, and 10 of the two-stage submission implementation process on the server side. Multiple users log in to configure at the same time, and the user configuration data submitted later conflicts with the user configuration data submitted earlier. The test server can identify the conflict in the verification after the "commit" command and feedback it to the command line interface.

[0155] Both users admin0 and admin1 are configured at the same time.

[0156] User admin1 configures the app-group length and submits it, such as Figure 7 As shown in the figure, two users both use the login name admin to log in to the device command line interface at the same time. One of the users has an SSH session ID of 1 and a command line interface identifier of admin1. On this interface, the user configures APN-related commands and submits them successfully.

[0157] The admin0 user configures the second app-group length. Since the total length of all app-groups cannot exceed 32 as defined in the template, the admin0 user will report a configuration conflict error when submitting the request. Multi-user conflict detection takes effect. For example, Figure 8 In the example shown, a user configured APN-related commands in the CLI interface with the identifier admin0. After running the command "apn-id template tmplt1 length 64 user-group 32 app-group 32" on admin0, the configuration was successfully submitted. However, after entering the command "app-group index 1 length 30" and submitting the command, a conflict occurred, causing the configuration to fail.

[0158] Because the configuration of "app-group index 2 length 10" has been submitted to the configuration database on the admin1 interface, and the admin1-related table entries in the backup database are not synchronized with the submission of admin0, when "app-group index 1 length 30" is entered on the admin0 interface, it can pass the CVL verification and be sent to the backup database. However, when "commit" is entered on the admin0 interface to submit, the server will be triggered to flush the latest configuration database data to the backup database. When the configuration command "app-group index 1 length 30" is verified again, a conflict error is reported.

[0159] In the second embodiment of the present invention, the present invention provides a two-phase submission device based on the RESTCONF framework, such as Figure 3 As shown, the device includes a request module 1, a verification module 2, an update module 3 and a display module 4;

[0160] The request module 1 is used to respond to the RESTCONF configuration request sent by the client received by the server, parse and verify the configuration data in the request, obtain the configuration data that passes the verification and temporarily store it in the backup database based on the command line interface identifier;

[0161] The verification module 2 is used to call a script to flush the full data of the configuration database and merge it with the temporarily stored configuration data after the server receives the commit command sent by the client, obtain the merged configuration data, and perform multi-user conflict detection and verification;

[0162] The update module 3 is used to perform a write or feedback operation on the merged configuration data through the server based on the comprehensive results of conflict detection and verification, obtain the configuration update status or conflict information, and write the merged configuration data into the configuration database and clear the relevant cache when the verification passes, and return the conflict information to the client when a conflict is detected;

[0163] The display module 4 is used to return an HTTP response to the client through the server, display the configuration temporary status or submission result in the response, and obtain a configuration result interface on which the user can continue to operate.

[0164] In a third embodiment of the present invention, the present invention provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the program is executed on the processor, the steps in the two-phase submission method based on the RESTCONF framework as described above are implemented.

[0165] In a fourth embodiment of the present invention, the present invention provides a storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the two-phase submission method based on the RESTCONF framework described above.

[0166] In summary, the present invention provides a two-phase submission method and device based on the RESTCONF framework. By introducing the two-phase submission method into the RESTCONF framework and combining it with a command line interface identifier, a backup database, and a JSON cache, the method and device achieve multi-user operation differentiation, configuration temporary storage and submission, and conflict detection. This effectively compensates for the lack of NETCONF's key functions in RESTCONF, improves the flexibility and reliability of configuration management, and adapts to modern network management requirements.

[0167] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working process of the modules described above can refer to the corresponding process in the aforementioned method implementation, and will not be repeated here.

[0168] Modules described as separate components may or may not be physically separate, and components shown as modules may or may not be physical modules, i.e., they may be located in one place or distributed across multiple network modules. Some or all of these modules may be selected to achieve the purpose of this embodiment according to actual needs.

[0169] In addition, the functional modules in each embodiment of the present application may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into a single module. The above-mentioned integrated modules may be implemented in the form of hardware or in the form of hardware plus software functional modules.

[0170] The above-mentioned integrated modules implemented in the form of software functional modules can be stored in a computer-readable storage medium. The above-mentioned software functional modules are stored in a storage medium and include a number of instructions for causing a computer system (which may be a personal computer, server, or network system, etc.) or a processor to execute some of the steps of the methods described in various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a mobile hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0171] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application.

Claims

1. A two-phase commit method based on the RESTCONF framework, characterized by: include, In response to the server receiving the RESTCONF configuration request sent by the client, the server parses and verifies the configuration data in the request, obtains the configuration data that passes the verification, and temporarily stores it in the backup database based on the command line interface identifier; After receiving the commit command from the client, the server calls the script to flush the full data of the configuration database and merge it with the temporarily stored configuration data. The merged configuration data is obtained and multi-user conflict detection and verification are performed. Based on the comprehensive results of conflict detection and verification, the server performs write or feedback operations on the merged configuration data to obtain the configuration update status or conflict information. If the verification passes, the merged configuration data is written to the configuration database and the relevant cache is cleared. If a conflict is detected, the conflict information is returned to the client. The server returns an HTTP response to the client, displays the configuration temporary status or submission result in the response, and obtains a configuration result interface on which the user can continue to operate.

2. The two-phase commit method based on the RESTCONF framework according to claim 1, characterized in that: Before the server receives the RESTCONF configuration request, it also includes: When the client logs in to the communication device via SSH, generating a unique command line interface identifier; When the client constructs the RESTCONF configuration request, the command line interface identifier is carried in the HTTP request header of the request, and the configuration data is sent to the server to trigger the configuration data temporary storage operation.

3. The two-phase commit method based on the RESTCONF framework according to claim 2, characterized in that: The generation and carrying of the command line interface identifier includes: When the client logs in through SSH, a unique command line interface identifier is generated by splicing the SSH session identifier and the user name, and the command line interface identifier is embedded in the user agent field of the HTTP request header of the RESTCONF configuration request to identify the source of the user operation; When the client constructs the RESTCONF configuration request, user identification information is added to the URI path and the request body to adapt to the user data table structure in the YANG model extended by the server, thereby ensuring user attribution of the configuration data.

4. The two-phase commit method based on the RESTCONF framework according to claim 2, characterized in that: The configuration data temporary storage operation includes: When the server parses and verifies the configuration data, the configuration data is verified for format and logic correctness through CVL; If the verification fails, the server constructs an error message and returns it to the client via HTTP response, and terminates the configuration data temporary storage process; If the verification passes, the server will temporarily store the configuration data in the backup database.

5. The two-phase commit method based on the RESTCONF framework according to claim 4 is characterized in that: The temporarily storing the configuration data in the backup database includes: The server writes the verified configuration data into the backup database and marks it with the command line interface identifier to achieve user isolation, thereby obtaining the marked temporary configuration data; The server records the operation metadata in a JSON cache file to support subsequent submission and conflict detection.

6. The two-phase commit method based on the RESTCONF framework according to claim 5, characterized in that: The configuration data submission and conflict detection operations include: After receiving the commit command, the server calls the Lua script to flush all the data in the configuration database to obtain the latest configuration status; The server merges the latest configuration state with the temporarily stored configuration data marked by the command line interface identifier to obtain the merged configuration data and performs multi-user conflict detection and verification.

7. The two-phase commit method based on the RESTCONF framework according to claim 6, characterized in that: The conflict detection and verification includes: Performing a CVL check on the merged configuration data by the server to detect whether there is a multi-user configuration conflict; If the verification fails, the server constructs conflict information and returns it to the client via HTTP response; If the verification is successful, the server writes the configuration data into the configuration database, clears the table entries marked with the command line interface identifier in the backup database and the operation records in the JSON cache file, and completes the configuration submission.

8. A two-phase commit device based on the RESTCONF framework, characterized by: It includes a request module, a verification module, an update module and a display module; The request module is used to respond to the RESTCONF configuration request sent by the client received by the server, parse and verify the configuration data in the request, obtain the configuration data that passes the verification and temporarily store it in the backup database based on the command line interface identifier; The verification module is used to call a script to flush the full data of the configuration database and merge it with the temporarily stored configuration data after the server receives the commit command sent by the client, obtain the merged configuration data, and perform multi-user conflict detection and verification; The update module is used to perform a write or feedback operation on the merged configuration data through the server based on the comprehensive results of conflict detection and verification, obtain the configuration update status or conflict information, and write the merged configuration data to the configuration database and clear the relevant cache when the verification passes, and return the conflict information to the client when a conflict is detected; The display module is used to return an HTTP response to the client through the server, display the configuration temporary storage status or submission result in the response, and obtain a configuration result interface on which the user can continue to operate.

9. An electronic device comprising a memory and a processor, characterized in that: The memory stores a computer program that can be run on the processor, and when the program is executed on the processor, the steps of the two-phase submission method based on the RESTCONF framework according to any one of claims 1 to 7 are implemented.

10. A storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the two-phase submission method based on the RESTCONF framework as described in any one of claims 1 to 7 are implemented.

Images