CN114640579A - Method, device and system for managing network device - Google Patents

Method, device and system for managing network device Download PDF

Info

Publication number
CN114640579A
CN114640579A CN202011378969.4A CN202011378969A CN114640579A CN 114640579 A CN114640579 A CN 114640579A CN 202011378969 A CN202011378969 A CN 202011378969A CN 114640579 A CN114640579 A CN 114640579A
Authority
CN
China
Prior art keywords
request
server
target
task
rpc
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202011378969.4A
Other languages
Chinese (zh)
Inventor
黎楚熙
戴新宁
陈锐
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202011378969.4A priority Critical patent/CN114640579A/en
Priority to PCT/CN2021/133533 priority patent/WO2022111635A1/en
Publication of CN114640579A publication Critical patent/CN114640579A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding

Abstract

The application discloses a method, equipment and a system for managing network equipment, which are used for reducing waste of network resources. The method comprises the following steps: and in the process that the server side executes the task corresponding to the first RPC request, the server side receives a target request sent by the first client side. The target request comprises a first identification, the first identification indicates that the server side preferentially executes a task corresponding to the target request, the target request comprises a second identification of the first RPC request, and the target request indicates that the server side interrupts the task corresponding to the first RPC request according to the second identification.

Description

Method, device and system for managing network device
Technical Field
The embodiment of the application relates to the technical field of communication, in particular to a method, equipment and a system for managing network equipment.
Background
A network configuration protocol (NETCONF) is a network protocol that implements network configuration for managing network devices. The NETCONF network system comprises a client and a server, and the client and the server can mutually transmit configuration data, state data and Remote Procedure Call (RPC). The client can add, modify or delete the configuration of the network device through the NETCONF, and can also obtain the configuration and the state information of the network device.
In the related art, when a user needs to preferentially execute a new request task, the user needs to wait for the server to start executing the new request task after finishing processing the task being executed, so that the time for processing an emergency task or a priority task is greatly increased, and the waste of network resources is increased.
Disclosure of Invention
The application provides a method, equipment and a system for managing network equipment, which can realize the priority processing of tasks needing priority processing or emergency tasks so as to reduce the waste of network resources.
In a first aspect, a method for managing a network device is provided, where in a process that a server executes a task corresponding to a first Remote Procedure Call (RPC) request, the server receives a target request sent by a first client connected to the server, where the target request includes a first identifier indicating that the server should preferentially execute the task corresponding to the target request, that is, indicating that the task priority of the target request is higher, and the target request includes a second identifier of the first RPC request, and the server may determine the first RPC request or the task corresponding to the first RPC request according to the second identifier, where the target request indicates that the server interrupts the task corresponding to the executing first RPC request.
The interruption of the task corresponding to the first RPC request being executed by the server may be understood as the termination of the execution of the task corresponding to the first RPC request by the server and the priority execution of the task corresponding to the target request. The task corresponding to the target request may be a cancel-get instruction, which is used to instruct the server to interrupt the specified task being executed.
In the embodiment of the application, after the server receives the target request sent by the client, the server can interrupt the task corresponding to the first RPC request being executed by the server according to the target request, so that the server can preferentially execute the task needing priority processing or emergency processing, and the waste of network resources of the server is reduced.
When the client indicates the server to interrupt the task corresponding to the first RPC request, often a task requiring priority processing or emergency is sent to the server, the client can indicate the server to execute the task corresponding to the second RPC request by sending the second RPC request, the task corresponding to the second RPC request is the task requiring priority processing or emergency, and the task requiring priority processing or emergency can be carried by the target request, which is specifically described below:
in one possible implementation, the target request further includes a target task, and the method further includes: the server interrupts the task corresponding to the first RPC request which is being executed by the server according to the target request, and executes the target task corresponding to the target request according to the target request, wherein the target task can be a task which needs to be processed preferentially or is urgent. In one possible implementation, the target task does not include a task corresponding to the first RPC request that instructs the server to interrupt. Optionally, the target task does not include a task corresponding to the first RPC request indicated to be interrupted, and the target task may be an RPC task corresponding to another RPC request different from the task corresponding to the first RPC request.
In the implementation mode, the target request also comprises a target task, the server side can interrupt the task corresponding to the first RPC request and execute the target task, and the server side does not need to wait for executing the target task after executing the task corresponding to the first RPC request, so that the execution efficiency of the target task is improved; and the target request also comprises a target task, and the client can send the target request comprising the task corresponding to the first RPC request interrupted by the server and the target task to the server, so that the waste of network resources is reduced.
In addition, in a possible implementation manner of the first aspect, after the server receives the target request sent by the first client, the method further includes: the server receives a second RPC request sent by a second client, wherein the second RPC request indicates the server to execute a task corresponding to the second RPC request; correspondingly, the server executes the task corresponding to the second RPC request. In a possible implementation manner, the first client and the second client may be the same client or different clients.
In the method, the server executes the task corresponding to the second RPC request after interrupting the task corresponding to the first RPC request, and the server does not need to wait for the execution of the task corresponding to the first RPC request to execute the task corresponding to the second RPC request, so that the task corresponding to the second RPC request is preferentially executed, and the waste of network resources of the server is reduced.
In a possible implementation manner, the interrupting, by the server, the task corresponding to the first RPC request according to the target request includes: and if the server determines that the task being executed by the server is the task corresponding to the first RPC request according to the second identifier of the first RPC request, the server interrupts the task corresponding to the first RPC being executed.
In the method, a scheme is provided for the server to interrupt the task corresponding to the first RPC request according to the target request.
In a possible implementation manner, the server-side interrupting the task being executed includes: the server stops executing the executing task; or stopping executing the executing task and putting the task identifier of the task corresponding to the first RPC request into the task list of the server side.
In a possible implementation manner, the server side arranges tasks that need to be executed but are not executed in a task list according to a preset rule, and all tasks in the task list have one-to-one corresponding identifiers. The step that the server side interrupts the task corresponding to the first RPC request according to the target request comprises the following steps: the server determines a task corresponding to the first RPC request in a task list according to the second identifier, wherein the task list comprises tasks which are not executed by the server; and the server side deletes the task corresponding to the first RPC request in the task list.
In this possible implementation manner, a scheme is specifically provided in which when the server interrupts the task corresponding to the first RPC request according to the target request, the task corresponding to the first RPC request is not yet executed, so that the realizability of the scheme is improved.
In a possible implementation manner, the request sent by the client to the server includes not only the RPC request but also the configuration data acquisition request and the status data acquisition request.
In a second aspect, a method for managing a network device is provided, the method comprising: the method comprises the steps that a first client sends a target request to a server in the process of executing a task corresponding to a first Remote Procedure Call (RPC) request, wherein the target request comprises a first identifier, the first identifier indicates that the server preferentially executes the task corresponding to the target request, the target request comprises a second identifier, and the target request indicates that the server interrupts the task corresponding to the first RPC request which is being executed by the server.
In the possible implementation manner, the client can send the target request after sending the first RPC request, so that the server interrupts the task corresponding to the first RPC request, and the client can interrupt the task executed by the server, thereby reducing the waste of network resources of the server.
In a possible implementation manner, the target request further instructs the server to execute a target task corresponding to the target request.
In the possible implementation manner, the target request further includes a target task, and the first client may send the target request including the task indicating the server to interrupt the first RPC request and the target task to the server, without separately sending, which reduces waste of network resources.
In a third aspect, a method for managing network devices is provided, where the method specifically includes: and the second client sends a second RPC request to the server, and the second RPC request indicates the server to execute a task corresponding to the second RPC request.
In a possible implementation manner, in this embodiment, the client that sends the second RPC request and the client that sends the target request are the same client.
In a fourth aspect, an apparatus is provided that includes means for performing the method for managing a network device provided in the first aspect or any one of the possible implementations of the first aspect, for example, the apparatus includes: the receiving unit is used for receiving a target request sent by a first client, the target request comprises a first identifier, the first identifier indicates that the server preferentially executes a task corresponding to the target request, the target request comprises a second identifier of the first RPC request, and the target request indicates that the server interrupts the task corresponding to the first RPC request being executed by the server.
In a fifth aspect, an apparatus is provided, which includes means for performing the method for managing a network device provided in the second aspect or any one of the possible implementation manners of the second aspect, and for example, the apparatus includes: the sending unit is used for sending a target request to a server, wherein the target request comprises a first identifier, the first identifier indicates that the server preferentially executes a task corresponding to the target request, the target request comprises a second identifier of the first RPC request, and the target request indicates that the server interrupts the task corresponding to the first RPC request being executed by the server.
In a sixth aspect, a client is provided, which includes: and the sending unit is used for sending a second RPC request to the server, and the second RPC request indicates the server to execute a task corresponding to the second RPC request.
The client has the functionality to implement the method of the third aspect or any one of the possible implementations of the third aspect. The functions may be implemented by hardware or by software programs. The hardware or software includes one or more modules corresponding to the above functions, such as: and a sending unit.
In a seventh aspect, a server side is provided, where the server side includes at least one processor, a memory, a communication interface, and computer executable instructions stored in the memory and executable on the processor, and when the computer executable instructions are executed by the processor, the processor performs the method according to the first aspect or any one of the possible implementation manners of the first aspect.
In an eighth aspect, a first client is provided, the first client comprising at least one processor, a memory, a communication interface, and computer executable instructions stored in the memory and executable on the processor, wherein when the computer executable instructions are executed by the processor, the processor performs the method according to any one of the possible implementation manners of the second aspect or the second aspect.
In a ninth aspect, there is provided a second client comprising at least one processor, a memory, a communication interface, and computer executable instructions stored in the memory and executable on the processor, wherein when the computer executable instructions are executed by the processor, the processor performs the method according to any one of the possible implementations of the third aspect or the third aspect.
A tenth aspect provides a computer-readable storage medium storing one or more computer-executable instructions that, when executed by a device, cause the device to perform the method of the first aspect or any one of the possible implementations of the first aspect.
In an eleventh aspect, there is provided a computer readable storage medium storing one or more computer executable instructions, which when executed by a device, cause the device to perform the method of any one of the possible implementations of the second aspect as described above.
In a twelfth aspect, there is provided a computer-readable storage medium storing one or more computer-executable instructions that, when executed by a device, cause the device to perform the method of any one of the possible implementations of the third aspect or the third aspect as described above.
In a thirteenth aspect, a system is provided, which includes a client and a server. The server in the system may perform the method of the first aspect or any one of the possible implementation manners of the first aspect. The client in the system may perform the method of the second aspect or any one of the possible implementations of the second aspect.
In a fourteenth aspect, a computer program (product) is provided, the computer program (product) comprising: computer program code for causing a computer to perform the method of the first aspect or any of the possible implementations of the first aspect, or the second aspect or any of the possible implementations of the second aspect, or the third aspect, when the computer program code is run by a computer.
Drawings
Fig. 1 is a schematic view of a NETCONF network system;
FIG. 2 is a schematic flow chart of a related art;
fig. 3 is a schematic flowchart of a method for managing network devices in an embodiment of the present application;
fig. 4 is a flowchart illustrating a method for managing network devices according to an embodiment of the present application;
fig. 5 is a flowchart illustrating a method for managing network devices according to an embodiment of the present application;
fig. 6 is a schematic structural diagram of a server in an embodiment of the present application;
FIG. 7 is a schematic structural diagram of a client according to an embodiment of the present application;
FIG. 8 is a schematic structural diagram of a client according to an embodiment of the present application;
fig. 9 is a schematic structural diagram of a server in an embodiment of the present application;
FIG. 10 is a schematic structural diagram of a client according to an embodiment of the present application;
FIG. 11 is a schematic structural diagram of a client according to an embodiment of the present application;
fig. 12 is a schematic structural diagram of a NETCONF network system in the embodiment of the present application.
Detailed Description
The terms "first," "second," and the like in the description and in the claims of the present application and in the above-described drawings are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It will be appreciated that the data so used may be interchanged under appropriate circumstances such that the embodiments described herein may be practiced otherwise than as specifically illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
Referring to fig. 1, a network configuration protocol (NETCONF) is a network protocol for managing network configuration of network devices. The NETCONF network system comprises a client and a server, wherein one server can be connected with a plurality of clients, and the client and the server can mutually transmit configuration data, state data and Remote Procedure Call (RPC). The client can add, modify or delete the configuration of the network device of the server through the NETCONF protocol, and can acquire the configuration and state information of the network device of the server.
Referring to fig. 2, in the related art, when a client performs a new message query, a task being executed by a server cannot be interrupted. For the interactive client, the client can send a new second RPC request, and the server can process the task in the second RPC request only after processing the task in the first RPC request.
Based on the NETCONF network system, the following describes a method for managing network devices in the embodiment of the present application:
referring to fig. 3, in the embodiment of the present application, in a process of executing a task corresponding to a first RPC request at a server, when a client needs that the server preferentially executes a second RPC request, a first client sends a target request with a first identifier to the server, and correspondingly, the server receives the target request with the first identifier sent by the first client, where the target request includes a second identifier of the first RPC request, the target request indicates that the server interrupts the task corresponding to the first RPC request being executed at the server, and the first identifier indicates that the server preferentially processes the target request, that is, when the server recognizes that the target request has the first identifier, the server interrupts the task corresponding to the first RPC request according to the second identifier.
In the embodiment of the application, after the server interrupts the task corresponding to the first RPC request according to the target request, the server may execute the target task corresponding to the target request, and may also execute the task corresponding to the second RPC sent by the second client. The following are described separately:
after the server interrupts the task corresponding to the first RPC request according to the target request, the server executes the task corresponding to the second RPC sent by the second client.
Referring to fig. 4, a process of a method for managing a network device in an embodiment of the present application includes:
401. the first client sends a target request to the server.
In the process that the server executes the task corresponding to the first Remote Procedure Call (RPC) request, the first client sends a target request to the server, correspondingly, the server receives the target request sent by the client, the target request indicates the server to interrupt the task corresponding to the first RPC request executed by the server, and the target request comprises the second identifier of the first RPC request.
Specifically, the target request carries a priority identifier, i.e. a first identifier, where the first identifier is used to indicate that the target request is a packet that needs to be processed preferentially, and the server is required to process the target request preferentially after receiving the target request; the target request also includes a second identification of the first RPC request. For example, the procedure of one embodiment of the target request is as follows:
+---x cancel-get
+----input
|+---w message-id uint32
the target request comprises a cancel-get instruction, wherein the cancel-get instruction is used for instructing the server to interrupt a specified task which is executed by the server; a user can enable a client to send a preset shortcut instruction to a server in a mode of inputting the instruction at a first client; the message-id in the instruction indicates a specified request message, and the message-id comprises a second identifier of the first RPC request.
The procedure of another embodiment of the target request is as follows:
<rpc urg＝”true”message-id＝”101”
Xmlns＝”urn:ietf:params:ns:netconf:base:1.0”>
<cancel-get Xmlns＝”urn:huawei:yang:huawei-netconf”>
<message-id>100</message-id>
</cancel-get>
</rpc>
the target request comprises a cancel-get instruction, wherein the cancel-get instruction is used for instructing the server to interrupt a specified task which is executed by the server; the user may input a preset shortcut instruction at the client, so that the first client sends the instruction to the server, for example, the shortcut instruction may be Ctrl + c. The urg mark is a priority mark, namely a first mark, and is used for indicating that the command is an emergency command with priority higher than that of a conventional command, and the server side should preferentially process the message after receiving the command, namely preferentially execute a task corresponding to the target request; for example, the server may set the query instruction and the notification instruction to the regular instruction with low priority, and set the interrupt instruction to the regular instruction with high priority. The message-id in the instruction indicates a task corresponding to an assigned request message, and the identifier of the message is "101", that is, the second identifier of the first RPC request is 101. After receiving the instruction, the server preferentially executes a task corresponding to the message with the interrupt message-id of 101.
402. And the server interrupts the task corresponding to the first RPC request according to the target request.
And the server side interrupts the task corresponding to the first RPC request which is executed by the server side according to the second identifier of the first RPC request in the target request.
Specifically, when the server receives the target request, the server preferentially processes the target request according to the first identifier of the target request. The server side determines whether the second identifier is the same as the identifier of the currently executed task according to the second identifier of the first RPC request in the target request, and if so, interrupts the currently executed task; if the two identifiers are different, traversing the task of the server end, determining whether the identifier of the task which is the same as the second identifier in the target request exists, and if so, deleting the task; if not, the target request is discarded.
403. And the second client sends a second RPC request to the server.
The client sends a second RPC request to the server, and correspondingly, the server receives the second RPC request sent by the client, the second RPC request instructs the server to execute a task corresponding to the second RPC request, and the task corresponding to the second RPC request in this embodiment is a task that needs priority processing or is urgent.
404. And the server executes the task corresponding to the second RPC request.
And the server executes the task corresponding to the second RPC request according to the second RPC request.
In the embodiment of the present application, the request corresponding to the task being executed by the server and the request sent to the server by the second client are RPC requests, and actually, the request may also be configuration data acquisition requests, status data acquisition requests, and other messages, which is not limited herein.
In the embodiment of the present application, the server side implements interruption of the task corresponding to the first RPC request by deleting the identifier of the task corresponding to the first RPC request in the task list of the server side or stopping execution of the task being executed, in addition, the server side may not delete the task corresponding to the first RPC request and place the task in the corresponding waiting processing area of the server side, and there are various methods for the server side to implement interruption of the task corresponding to the first RPC request, which are not limited herein.
In the embodiment of the present application, the server side implements message concurrence for a single session of a single client in a manner of a main thread and a working thread, and in addition, the server side may also implement message concurrence for a single session of a single client in a manner of a concurrence mechanism based on a blocking technique, a concurrence mechanism based on a timestamp mechanism, a concurrence mechanism based on validity confirmation, and the like, which is not limited herein.
In the embodiment of the present application, the client that sends the second RPC request to the server is the second client, and the client that sends the target request to the server is the first client.
In this embodiment, the target request instructs the server to interrupt the task corresponding to the first RPC request, and the target request may also instruct the server to execute the task corresponding to the target request, which is described below:
and secondly, after the server interrupts the task corresponding to the first RPC request according to the target request, the server executes the target task corresponding to the target request.
Referring to fig. 5, another flow of the method for managing a network device in the embodiment of the present application includes:
501. the first client sends a target request to the server.
In the process that the server executes the task corresponding to the first Remote Procedure Call (RPC) request, the first client sends a target request to the server, correspondingly, the server receives the target request sent by the client, the target request indicates the server to interrupt the task corresponding to the first RPC request executed by the server, and the target request comprises the second identifier of the first RPC request. The target request further indicates the server to execute a target task corresponding to the target request, in this embodiment, the target task does not include a task indicating to interrupt the first RPC request, and the target task may be a task corresponding to another RPC request different from the task corresponding to the first RPC request.
Specifically, the target request has a priority identifier, i.e. a first identifier, where the first identifier is used to indicate that the target request is an emergency message, and the server needs to preferentially process the target request after receiving the target request; the target request also includes a second identification of the first RPC request. For example, the procedure of one embodiment of the target request is as follows:
+---x cancel-get
+----input
|+---w message-id uint32
the target request comprises a cancel-get instruction, wherein the cancel-get instruction is used for instructing the server to interrupt a specified task which is executed by the server; a user can enable a client to send a preset shortcut instruction to a server in a mode of inputting the instruction at a first client; the message-id in the instruction indicates a specified request message, and the message-id comprises a second identifier of the first RPC request.
The procedure of another embodiment of the target request is as follows:
<rpc urg＝”true”message-id＝”101”
Xmlns＝”urn:ietf:params:ns:netconf:base:1.0”>
<cancel-get Xmlns＝”urn:huawei:yang:huawei-netconf”>
<message-id>100</message-id>
</cancel-get>
</rpc>
the target request comprises a cancel-get instruction, wherein the cancel-get instruction is used for instructing the server to interrupt a specified task which is executed by the server; the user may input a preset shortcut instruction at the client, so that the first client sends the instruction to the server, for example, the shortcut instruction may be Ctrl + c. The urg identifier may be a priority identifier, i.e., a first identifier, configured to indicate that the instruction is an emergency instruction with a priority higher than that of a conventional instruction, and after receiving the instruction, the server side should preferentially process the packet, i.e., preferentially execute a task corresponding to the target request; for example, the server may set the query instruction and the notification instruction to the regular instruction with low priority, and set the interrupt instruction to the regular instruction with high priority. The message-id in the instruction indicates a task corresponding to a specified request message, and the identifier of the message is "101", that is, the second identifier of the first RPC request is 101. After receiving the instruction, the server preferentially executes a task corresponding to the message with the interrupt message-id of 101.
502. And the server interrupts the task corresponding to the first RPC request according to the target request.
In the embodiment of the present application, step 504 is similar to step 402 in fig. 4, and details thereof are not repeated here again
503. And the server executes the target task corresponding to the target request.
And the server executes the target task corresponding to the target request according to the target request. In one possible implementation, the target task does not include a cancel-get instruction, and the target task is a task corresponding to another RPC request different from the task corresponding to the first RPC request.
In the embodiment of the present application, the request message corresponding to the task being executed by the server is an RPC request, and may actually be a configuration data acquisition request, a status data acquisition request, and other messages, which is not limited herein.
In the embodiment of the application, the server side interrupts the task corresponding to the first RPC request by deleting the identifier of the task corresponding to the first RPC request in the task list of the server side or by interrupting the task being executed, in addition, the server side may not delete the task corresponding to the first RPC request and place the task in the corresponding waiting processing area of the server side, and there are various methods for the server side to specifically interrupt the task corresponding to the first RPC request, which are not limited herein.
In the embodiment of the present application, the server side implements message concurrency for a single session of a single client in a manner of a main thread and a working thread, and in addition, the server side may also implement message concurrency for a single session of a single client in a manner of a concurrency mechanism based on a lockout technique, a concurrency mechanism based on a timestamp mechanism, a concurrency mechanism based on validity confirmation, and the like, which is not limited herein specifically.
Referring to fig. 6, a server 600 provided in this embodiment of the present application, which may be the server in fig. 4 or fig. 5, is described below, where the server 600 includes:
a receiving unit 601, configured to receive a target request sent by a first client, where the target request includes a first identifier, where the first identifier indicates that the server preferentially executes a task corresponding to the target request, the target request includes a second identifier of the first RPC request, and the target request indicates that the server interrupts a task corresponding to the first RPC request being executed by the server. In a specific implementation manner, please refer to that the first client sends the target request to the server in step 401 in fig. 4 and that the first client sends the target request to the server in step 501 in fig. 5, which is not described herein again.
Optionally, the server 600 may further include a first processing unit 602, where the first processing unit 602 is configured to: and if the server determines that the task being executed by the server is the task corresponding to the first RPC request according to the second identifier of the first RPC request, the server interrupts the task being executed. In a specific implementation manner, please refer to step 402 in fig. 4: the server side interrupts the task corresponding to the first RPC request according to the target request and step 502 in fig. 5: and the server interrupts the task corresponding to the first RPC request according to the target request, which is not described herein again.
Specifically, the first processing unit 602 is configured to execute a target task corresponding to the target request according to the target request. In a specific implementation manner, please refer to step 503 in fig. 5: and the server executes the target task corresponding to the target request, which is not described herein again.
Specifically, the receiving unit is further configured to receive a second RPC request sent by the second client, where the second RPC request indicates that the server executes a task corresponding to the second RPC request. In a specific implementation manner, please refer to step 403 in fig. 4: and the second client sends a second RPC request to the server, which is not described herein again.
Optionally, the server 600 may further include a second processing unit 603, where the second processing unit 603 is configured to execute a task corresponding to the second RPC request. In a specific implementation manner, please refer to step 404 in fig. 4: and the server executes the task corresponding to the second RPC request, which is not described herein again.
Specifically, the first processing unit is further configured to: determining a task corresponding to the first RPC request in a task list of a server according to the second identifier of the first RPC request, wherein the task list comprises tasks which are not executed by the server; or deleting the task corresponding to the first RPC request in the task list. In a specific implementation manner, please refer to step 402 in fig. 4: the server side interrupts the task corresponding to the first RPC request according to the target request and step 502 in fig. 5: and the server interrupts the task corresponding to the first RPC request according to the target request, which is not described herein again.
The division of the modules in the embodiments of the present application is schematic, and only one logical function division is provided, and in actual implementation, there may be another division manner, and in addition, each functional module in each embodiment of the present application may be integrated in one processing unit, may also exist alone physically, or may also be integrated in one module by two or more modules. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode.
In this embodiment, the server 600 may perform operations performed by the server in any one of the embodiments shown in fig. 4 to fig. 5, which are not described herein again.
Referring to fig. 7, a first client in the embodiment of the present application is described below, where the client 700 provided in the embodiment of the present application may be the first client in fig. 4 or fig. 5, and the client 700 includes:
a sending unit 701, configured to send a target request to a server, where the target request includes a first identifier, the first identifier indicates that the server preferentially executes a task corresponding to the target request, the target request includes a second identifier of the first RPC request, and the target request includes a task that indicates that the server interrupts the first RPC request. In a specific implementation manner, please refer to step 401 in fig. 4: the first client sends a target request to the server and step 501 in fig. 5: the first client sends the target request to the server, which is not described herein again.
Specifically, the target request further includes a target task instructing the server to execute the target request.
The division of the modules in the embodiments of the present application is schematic, and is only a logical function division, and in actual implementation, there may be another division manner, and in addition, each functional module in each embodiment of the present application may be integrated in one processing unit, or may exist alone physically, or two or more modules are integrated in one module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode.
In this embodiment, the client 700 may perform operations performed by the first client in any one of the embodiments shown in fig. 4 to fig. 5, which are not described herein again.
Referring to fig. 8, a client 800 provided in this embodiment of the present application, which may be the second client in fig. 4, includes:
the sending unit 801 is configured to send a second RPC request to the server, where the second RPC request indicates that the server executes a task corresponding to the second RPC request. In a specific implementation manner, please refer to step 403 in fig. 4: the second client sends the second RPC request to the server, which is not described herein again.
The division of the modules in the embodiments of the present application is schematic, and is only a logical function division, and in actual implementation, there may be another division manner, and in addition, each functional module in each embodiment of the present application may be integrated in one processing unit, or may exist alone physically, or two or more modules are integrated in one module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode.
In this embodiment, the client 800 may perform the operations performed by the client in the embodiment shown in fig. 4, which are not described herein again.
When the integrated module may be implemented in the form of hardware, and the server side may have the structure shown in fig. 9, the processing unit provided in fig. 6 may correspond to the processor 901 in fig. 9. The processor 901 may be a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application, for example: one or more Digital Signal Processors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs). The server side may further comprise a communication interface 902, and the communication interface 902 is used for communicating with other server sides. The server side further comprises: a memory 903 for storing programs executed by the processor 901. The memory 903 may be a volatile memory (volatile memory), such as a random-access memory (RAM); or a non-volatile memory (non-volatile memory), such as a read-only memory (ROM), a flash memory (flash memory), a Hard Disk Drive (HDD) or a solid-state drive (SSD); or a combination of the above types of memories, for storing program code, server-side configuration files within a TSN domain, or other content that may implement the methods of the present application. The memory 903 is any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to such.
A processor 901 is configured to execute program code stored in a memory 903, the processor 901. The embodiment of the present application does not limit the specific connection medium among the communication interface 902, the processor 901, and the memory 903. In the embodiment of the present application, the memory 903, the processor 902, and the communication interface 902 are connected by the bus 904 in fig. 9, the bus is represented by a thick line in fig. 9, and the connection manner between other components is merely illustrative and not limited. The bus may be divided into an address bus, a data bus, a control bus, etc.
In one example, the communication interface 902 is configured to receive a target request sent by a first client, where the target request includes a first identifier indicating that the server performs a task corresponding to the target request preferentially, and the target request includes a second identifier of the first RPC request, and the target request includes a task indicating that the server interrupts the task corresponding to the first RPC request.
The processor 901 is configured to interrupt the task corresponding to the first RPC request according to the target request.
The processor 901 is configured to execute a target task corresponding to the target request according to the target request.
The processor 901 is configured to interrupt the task being executed if the server determines, according to the second identifier, that the task being executed by the server is the task corresponding to the first RPC request.
Optionally, the processor 901 is configured to determine, according to the second identifier, a task corresponding to the first RPC request in a task list of the server, where the task list is a task that has not been executed by the server, and delete the task corresponding to the first RPC request in the task list.
In one example, the communication interface 902 is configured to receive a first RPC request sent by a client, receive a target request sent by the client, where the target request includes a first identifier indicating that the server preferentially executes a task corresponding to the target request, and the target request includes a second identifier of the first RPC request indicating that the server interrupts the task corresponding to the first RPC request; and the second RPC request is used for receiving the second RPC request sent by the second client, and the second RPC request indicates the server to execute the task corresponding to the second RPC request.
The processor 901 is configured to interrupt the task corresponding to the first RPC request according to the target request.
The processor 901 is configured to request a corresponding task according to the execution of the second RPC.
The processor 901 is configured to interrupt the task being executed if the server determines, according to the second identifier, that the task being executed by the server is the task corresponding to the first RPC request.
Or, the processor 901 is configured to determine, according to the second identifier, a task corresponding to the first RPC request in a task list of the server, where the task list is a task that has not been executed by the server, and delete the task corresponding to the first RPC request in the task list.
The server 900 may implement the functions of the server in fig. 4 and 5, and may refer to the description of the method related to the drawings in detail.
When the integrated module may be implemented in a hardware form, the first client may have a structure shown in fig. 10, and the processing unit provided in fig. 7 may correspond to the processor 1001 in fig. 10. The processor 1001 may be a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application, for example: one or more Digital Signal Processors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs). The first client may also include a communication interface 1002, the communication interface 1002 for communicating with other clients. The client further comprises: the memory 1003 is used for storing programs executed by the processor 1001. The memory 1003 may be a volatile memory (volatile memory), such as a random-access memory (RAM); or a non-volatile memory (non-volatile memory), such as a read-only memory (ROM), a flash memory (flash memory), a Hard Disk Drive (HDD) or a solid-state drive (SSD); or a combination of the above types of memories for storing program code that implements the methods of the present application, configuration files for clients within the TSN domain, or other content. The memory 1003 is any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to such.
The processor 1001 is configured to execute the program code stored in the memory 1003, and the processor 1001. In the embodiment of the present application, a specific connection medium among the communication interface 1002, the processor 1001, and the memory 1003 is not limited. In fig. 10, the memory 1003, the processor 1002, and the communication interface 1002 are connected by a bus 1004, the bus is shown by a thick line in fig. 10, and the connection manner among other components is only schematically illustrated and not limited. The bus may be divided into an address bus, a data bus, a control bus, etc.
In one example, the communication interface 1002 is configured to send a target request to a server, where the target request includes a first identifier indicating that the server preferentially executes a task corresponding to the target request, and the target request includes a second identifier of the first RPC request, and the target request indicates that the server interrupts the task corresponding to the first RPC request.
Specifically, the target request further includes a target task instructing the server to execute the target request.
The first server 1000 may implement the functions of the first server in fig. 4 and fig. 5, and specifically refer to the description of the method related to the drawings.
When the integrated module may be implemented in a hardware form, the second client may have a structure shown in fig. 11, and the processing unit provided in fig. 8 may correspond to the processor 1101 in fig. 11. The processor 1101 may be a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application, for example: one or more Digital Signal Processors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs). The second client may also include a communication interface 1102, the communication interface 1102 being used to communicate with other clients. The client further comprises: a memory 1103 for storing programs executed by the processor 1101. The memory 1103 may be a volatile memory (volatile memory), such as a random-access memory (RAM); or a non-volatile memory (non-volatile memory), such as a read-only memory (ROM), a flash memory (flash memory), a Hard Disk Drive (HDD) or a solid-state drive (SSD); or a combination of the above types of memories for storing program code that implements the methods of the present application, profiles for clients within the TSN domain, or other content. The memory 1103 is any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to such.
The processor 1101 is configured to execute program code stored in the memory 1103, and the processor 1101. In the embodiment of the present application, a specific connection medium among the communication interface 1102, the processor 1101, and the memory 1103 is not limited. In the embodiment of the present application, the memory 1103, the processor 1102, and the communication interface 1102 are connected by the bus 1104 in fig. 11, the bus is represented by a thick line in fig. 11, and the connection manner between other components is merely illustrative and not limited thereto. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 11, but that does not indicate only one bus or one type of bus.
In one example, the communication interface 1102 is configured to send a second RPC request to the server, where the second RPC request instructs the server to execute a task corresponding to the second RPC request.
The second server 1100 may implement the functions of the second server in fig. 4, and specifically refer to the description of the method related to the drawing.
Referring to fig. 12, a NETCONF network system 1200 provided in the embodiment of the present application includes a server 1201 in the embodiment of fig. 6, a first client 1202 in the embodiment of fig. 7, and a second client 1203 in the embodiment of fig. 8, where the server 1201 is connected to the first client 1202 and the second client 1203, respectively.
The system may perform the operations performed by the NETCONF network system in the embodiment shown in any of fig. 4 to 5.
The server 1201 is configured to receive a target request sent by a first client, where the target request includes a first identifier, the first identifier indicates that the server preferentially executes a task corresponding to the target request, the target request includes a second identifier, and the target request indicates that the server interrupts the task corresponding to the first RPC request.
The server 1201 is further configured to interrupt a task corresponding to the first RPC request being executed by the server according to the target request, and execute the target task corresponding to the target request according to the target request.
The server 1201 is further configured to receive a second RPC request sent by the second client, where the second RPC request indicates that the server executes a task corresponding to the second RPC request.
The server 1201 is further configured to: and the server determines that the task being executed by the server is the task corresponding to the first RPC request according to the second identifier, and interrupts the task corresponding to the first RPC request being executed.
The server 1201 is further configured to: and determining a task corresponding to the first RPC request in a task list of the server according to the second identifier, wherein the task list comprises tasks which are not executed by the server, and deleting the task corresponding to the first RPC request in the task list.
The first client 1202 is configured to send a target request to a server, where the target request includes a first identifier, the first identifier indicates that the server preferentially executes a task corresponding to the target request, the target request includes the second identifier, and the target request indicates that the server interrupts the task corresponding to the first RPC request.
The second client 1203 is configured to send a second RPC request to the server, where the second RPC request indicates that the server executes a task corresponding to the second RPC request.
Embodiments of the present application also provide a computer-readable storage medium, in which at least one program instruction or code is stored, and the program instruction or code is loaded by a processor and executed to enable a computer to implement the method for managing a network device as shown in any one of fig. 4 and 5 above.
The present application provides a computer program, which when executed by a computer, can cause the processor or the computer to execute the corresponding steps and/or flows in the method embodiments in fig. 4 and fig. 5.
The present application provides a chip, which includes a processor, configured to call and execute instructions stored in a memory, so that a communication device in which the chip is installed executes each corresponding step and/or flow in the method embodiments in fig. 4 and fig. 5.
The embodiment of the present application provides another chip, including: the system comprises an input interface, an output interface, a processor and a memory, wherein the input interface, the output interface, the processor and the memory are connected through an internal connection path, the processor is used for executing codes in the memory, and when the codes are executed, the processor is used for executing corresponding steps and/or processes in the method embodiment.
As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.

Claims (17)

1. A method of managing network devices, the method comprising:
in the process of executing a task corresponding to a first Remote Procedure Call (RPC) request at a server, the server receives a target request sent by a first client, the target request comprises a first identifier, the first identifier indicates that the server preferentially executes the task corresponding to the target request, the target request comprises a second identifier of the first RPC request, and the target request indicates that the server interrupts the task corresponding to the first RPC request according to the second identifier.
2. The method of claim 1, wherein the target request further comprises a target task;
the method further comprises the following steps:
the server side interrupts the task corresponding to the first RPC request according to the target request;
and the server executes the target task.
3. The method according to claim 1, wherein after the server receives the target request sent by the first client, the method further comprises:
the server side receives a second RPC request sent by a second client side, and the second RPC request indicates the server side to execute a task corresponding to the second RPC request;
and the server executes the task corresponding to the second RPC request.
4. The method of claim 2, wherein the server side interrupts the task corresponding to the first RPC request according to a target request, including:
and the server determines that the task being executed by the server comprises a task corresponding to the first RPC request according to the second identifier, and interrupts the task corresponding to the first RPC being executed.
5. The method of claim 2, wherein the server side interrupts the task corresponding to the first RPC request according to the target request, and comprises:
the server side determines that a task list of the server side comprises a task corresponding to the first RPC request according to the second identifier;
and the server side deletes the task corresponding to the first RPC request in the task list.
6. A method of managing a network device, the method comprising:
the method comprises the steps that a first client sends a target request to a server side, the target request comprises a first identification, the first identification indicates that the server side preferentially executes a task corresponding to the target request, the target request comprises a second identification of a first Remote Procedure Call (RPC) request, and the target request indicates that the server side interrupts the task corresponding to the first RPC request, which is executed by the server side.
7. The method of claim 6, wherein the target request further comprises a target task, and wherein the target task is used to instruct the server to execute the target task.
8. An apparatus, characterized in that the apparatus comprises:
the receiving unit is used for receiving a target request sent by a first client in the process of executing a task corresponding to a first Remote Procedure Call (RPC) request, wherein the target request comprises a first identifier, the first identifier indicates that the task corresponding to the target request is preferentially executed, the target request comprises a second identifier of the first RPC request, and the target request comprises an indication that a server-side interrupt server-side is executing the task corresponding to the first RPC request.
9. The apparatus of claim 8, wherein the target request further comprises a target task;
the apparatus further comprises:
and the first processing unit is used for interrupting the task corresponding to the first RPC request according to the target request and executing the target task according to the target request.
10. The apparatus of claim 8, further comprising a second processing unit;
the receiving unit is further configured to receive a second RPC request sent by a second client, where the second RPC request indicates that the server executes a task corresponding to the second RPC request;
and the second processing unit is used for executing the task corresponding to the second RPC request.
11. The device according to claim 9, wherein the first processing unit is specifically configured to: and determining the task being executed by the server side as the task corresponding to the first RPC request according to the second identifier, and interrupting the task corresponding to the first RPC request being executed.
12. The device according to claim 9, wherein the first processing unit is further configured to:
determining a task corresponding to the first RPC request in a task list of a server according to the second identifier, wherein the task list is a task which is not executed by the equipment;
and deleting the task corresponding to the first RPC request in the task list.
13. An apparatus, characterized in that the apparatus comprises:
the transmission unit is used for transmitting a target request to a server side, the target request comprises a first identifier, the first identifier indicates that the server side preferentially executes a task corresponding to the target request, the target request comprises a second identifier of a first Remote Procedure Call (RPC) request, and the target request indicates that the server side interrupts the task corresponding to the first RPC request which is being executed by the server side.
14. The apparatus of claim 13, wherein the target request further comprises a target task instructing the server to execute.
15. A computer-readable storage medium, comprising instructions or code which, when executed on a computer, cause the computer to perform the method of any one of claims 1 to 7.
16. A computer program product, characterized in that the computer program comprises program code which, when run by a computer, causes the computer to carry out the method according to any one of claims 1-7.
17. A system, characterized in that the system comprises a server side and a client side, the server side executes the method according to any one of claims 1-5, and the client side executes the method according to claim 6 or 7.
CN202011378969.4A 2020-11-30 2020-11-30 Method, device and system for managing network device Pending CN114640579A (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202011378969.4A CN114640579A (en) 2020-11-30 2020-11-30 Method, device and system for managing network device
PCT/CN2021/133533 WO2022111635A1 (en) 2020-11-30 2021-11-26 Method for managing network device, and device and system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011378969.4A CN114640579A (en) 2020-11-30 2020-11-30 Method, device and system for managing network device

Publications (1)

Publication Number Publication Date
CN114640579A true CN114640579A (en) 2022-06-17

Family

ID=81753783

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011378969.4A Pending CN114640579A (en) 2020-11-30 2020-11-30 Method, device and system for managing network device

Country Status (2)

Country Link
CN (1) CN114640579A (en)
WO (1) WO2022111635A1 (en)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7146427B2 (en) * 2002-04-23 2006-12-05 Lsi Logic Corporation Polling-based mechanism for improved RPC timeout handling
CN102594888B (en) * 2012-02-16 2014-07-02 西北工业大学 Method for enhancing real-time performance of network file system
US10452497B2 (en) * 2015-08-14 2019-10-22 Oracle International Corporation Restoration of UI state in transactional systems
CN109144679B (en) * 2017-06-27 2022-03-29 华为技术有限公司 Interrupt request processing method and device and virtualization equipment
CN108111499B (en) * 2017-12-15 2021-07-16 腾讯科技（深圳）有限公司 Business processing performance optimization method and device, electronic equipment and storage medium
CN111796735B (en) * 2020-06-29 2023-02-03 维沃移动通信（杭州）有限公司 Application program control method and device and electronic equipment

Also Published As

Publication number Publication date
WO2022111635A1 (en) 2022-06-02

Similar Documents

Publication Publication Date Title
CN111278031B (en) PDU type setting method, UE strategy setting method, entity and storage medium
US9244817B2 (en) Remote debugging in a cloud computing environment
CN108713309B (en) SD-WAN system, use method of SD-WAN system and related device
US20200213937A1 (en) Network Slice Instance Processing Method and Apparatus, and System
CN108028833A (en) A kind of method, system and the relevant device of NAS data accesses
CN104219316A (en) Method and device for processing call request in distributed system
CN103370917B (en) Message treatment method and server
CN107872489A (en) A kind of file section method for uploading, device and cloud storage system
CN112600693B (en) Service request processing method, system, electronic equipment and computer storage medium
EP3742785A1 (en) Session management method and device
KR20200023485A (en) Transmission of Control Data in Proxy-Based Network Communications
CN113517985B (en) File data processing method and device, electronic equipment and computer readable medium
CN112395107A (en) Tax control equipment control method and device, storage medium and electronic equipment
JP7027453B2 (en) Methods and terminals for determining the reason for establishment
CN109361762A (en) A kind of document transmission method, apparatus and system
JP5462207B2 (en) Device management method and apparatus
CN110324384B (en) Data pushing method and device
CN107548038A (en) Method for processing short messages and device
CN115550354A (en) Data processing method and device and computer readable storage medium
CN114640579A (en) Method, device and system for managing network device
CN111294377A (en) Network request sending method of dependency relationship, terminal device and storage medium
CN113542282A (en) Cross-computing center file transmission method, device, equipment and storage medium
CN113079055B (en) AGV operation data dynamic acquisition method and device
CN114051024A (en) File background continuous transmission method and device, storage medium and electronic equipment
CN113691520A (en) Method, device, storage medium and electronic device for acquiring streaming media information

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination