CN114363306A - Data transmission method based on Netconf protocol and related equipment - Google Patents
Data transmission method based on Netconf protocol and related equipment Download PDFInfo
- Publication number
- CN114363306A CN114363306A CN202111511027.3A CN202111511027A CN114363306A CN 114363306 A CN114363306 A CN 114363306A CN 202111511027 A CN202111511027 A CN 202111511027A CN 114363306 A CN114363306 A CN 114363306A
- Authority
- CN
- China
- Prior art keywords
- server
- client
- identifier
- hello
- hello packet
- 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
Links
Images
Classifications
-
- 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/01—Protocols
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/26—Special purpose or proprietary protocols or architectures
Abstract
The embodiment of the application discloses a data transmission method based on a Netconf protocol and related equipment. The method in the embodiment of the application comprises the following steps: the client receives a first hello message sent by the server, wherein the first hello message comprises a first capability information set of the server and an equipment identifier of the server, and the client installs an equipment driver corresponding to the server according to the equipment identifier of the server. The client can obtain the equipment identifier of the server in the hello message negotiation process with the server, and can complete the selection and installation of the equipment driver without additional interactive client, so that the time for establishing a communication channel between the client and the server to complete connection is shortened, and the connection efficiency is improved.
Description
Technical Field
The present invention relates to the field of network configuration, and in particular, to a data transmission method based on a Netconf protocol and a related device.
Background
With the development of the information age, a network configuration protocol (Netconf) is widely used in a Software Defined Network (SDN). The Netconf protocol adopts a structure of a client (client) and a server (server).
The method comprises the steps that a communication channel is established between a client and a server to complete connection, multiple interactions are needed, the client and the server establish a session by utilizing hello message negotiation, then the client sends a query message to the server to query equipment identifiers of the server, such as equipment types, manufacturers and versions, the client receives a query response which is sent by the server and carries the equipment identifiers of the client, and then the client installs equipment drivers corresponding to the server.
However, besides hello message interaction, message interaction also needs to be inquired between the client and the server, interaction needed by the two parties to establish a communication channel is long in time consumption, and therefore connection efficiency is low.
Disclosure of Invention
The embodiment of the application provides a data transmission method based on a Netconf protocol and related equipment, so that the time required for establishing a communication channel between a client and a server is shortened, and the connection efficiency is improved.
In a first aspect, an embodiment of the present application provides a data transmission method based on a Netconf protocol, where the method includes the following steps.
The client receives a first hello message sent by the server, wherein the first hello message comprises a first capability information set of the server and an equipment identifier of the server, and the client installs an equipment driver corresponding to the server according to the equipment identifier of the server.
In the embodiment, the client can obtain the device identifier of the server in the hello message negotiation process with the server, and the selection and installation of the device driver can be completed without additional interactive clients, so that the time required for establishing a communication channel between the client and the server is shortened, and the connection efficiency is improved.
Optionally, in some possible embodiments, the device identifier of the server includes at least one of a device type, a device vendor, a device version, and a device model.
In the embodiment, specific types of the server device identifiers are listed, so that the practicability of the scheme is improved.
Optionally, in some possible embodiments, the installing, by the client, the device driver corresponding to the server according to the device identifier of the server includes:
and the client searches the device driver corresponding to the device identifier of the server from a preset device driver set, and then the client installs the device driver.
In the embodiment, a specific embodiment is provided in which the client installs the device driver according to the device identifier of the server, so that the realizability of the scheme is improved.
Optionally, in some possible embodiments, the method further comprises:
and the client sends a second hello message to the server, wherein the second hello message comprises a second capability information set of the client.
In this embodiment, the client and the server need to perform hello packet negotiation by sending hello packets carrying respective capability information sets to the opposite end, so that the scheme is more complete.
Optionally, in some possible embodiments, the second hello packet further includes a device identifier of the client, where the device identifier of the client includes at least one of a device type, a device vendor, a device version, and a device model.
In this embodiment, similar to the first hello packet, the second hello packet may also carry the device identifier of the client, thereby improving the extensibility of the scheme.
Optionally, in some possible embodiments, the first hello packet further includes a session identifier, and the session identifier is used to identify a session established between the client and the server.
In this embodiment, the session between each group of the client and the server has the session identifier corresponding thereto, and the specific session identifier may be carried in the first hello message, thereby further improving the integrity of the scheme.
In a second aspect, an embodiment of the present application provides a data transmission method based on a Netconf protocol, where the method includes the following steps.
The server sends a first hello message to the client so that the client installs the device driver corresponding to the server according to the device identifier of the server, wherein the first hello message comprises a first capability information set of the server and the device identifier of the server.
Optionally, in some possible embodiments, the device identifier of the server includes at least one of a device type, a device vendor, a device version, and a device model.
Optionally, in some possible embodiments, the method further comprises:
and the server receives a second hello message sent by the client, wherein the second hello message comprises a second capability information set of the client.
Optionally, in some possible embodiments, the second hello packet further includes a device identifier of the client, where the device identifier of the client includes at least one of a device type, a device vendor, a device version, and a device model.
Optionally, in some possible embodiments, the first hello packet further includes a session identifier, and the session identifier is used to identify a session established between the client and the server.
In a third aspect, an embodiment of the present application provides a client based on a Netconf protocol, including:
the receiving unit is used for receiving a first hello message sent by a server, wherein the first hello message comprises a first capability information set of the server and an equipment identifier of the server;
and the installation unit is used for installing the equipment driver corresponding to the server according to the equipment identifier of the server.
Optionally, in some possible embodiments, the device identifier of the server includes at least one of a device type, a device vendor, a device version, and a device model.
Optionally, in some possible embodiments, the mounting unit is specifically configured to:
searching a device driver corresponding to the device identifier of the server from a preset device driver set;
and installing the equipment driver.
Optionally, in some possible embodiments, the client further includes:
and the sending unit is used for sending a second hello message to the server, wherein the second hello message comprises a second capability information set of the client.
Optionally, in some possible embodiments, the second hello packet further includes a device identifier of the client, where the device identifier of the client includes at least one of a device type, a device vendor, a device version, and a device model.
Optionally, in some possible embodiments, the first hello packet further includes a session identifier, and the session identifier is used to identify a session established between the client and the server.
In a fourth aspect, an embodiment of the present application provides a server based on a Netconf protocol, including:
the sending unit is used for sending a first hello message to the client so that the client installs the device driver corresponding to the server according to the device identifier of the server, and the first hello message comprises a first capability information set of the server and the device identifier of the server.
Optionally, in some possible embodiments, the device identifier of the server includes at least one of a device type, a device vendor, a device version, and a device model.
Optionally, in some possible embodiments, the server further includes:
and the receiving unit is used for receiving a second hello message sent by the client, wherein the second hello message comprises a second capability information set of the client.
Optionally, in some possible embodiments, the second hello packet further includes a device identifier of the client, where the device identifier of the client includes at least one of a device type, a device vendor, a device version, and a device model.
Optionally, in some possible embodiments, the first hello packet further includes a session identifier, and the session identifier is used to identify a session established between the client and the server.
In a fifth aspect, an embodiment of the present application provides a client based on a Netconf protocol, including:
the system comprises a processor, a memory, a bus and an input/output interface;
the memory stores program codes;
the processor executes the data transmission method based on the Netconf protocol in any of the embodiments of the first aspect when calling the program code in the memory.
In a sixth aspect, an embodiment of the present application provides a server based on a Netconf protocol, including:
the system comprises a processor, a memory, a bus and an input/output interface;
the memory stores program codes;
the processor executes the data transmission method based on the Netconf protocol as in any of the embodiments of the second aspect when calling the program code in the memory.
In a seventh aspect, an embodiment of the present application provides a computer storage medium, which includes instructions, and when the computer storage medium runs on a computer, the computer is caused to execute the data transmission method based on the Netconf protocol in any implementation manner of the first aspect.
In an eighth aspect, an embodiment of the present application provides a computer program product containing instructions, which when run on a computer, causes the computer to execute the Netconf protocol-based data transmission method in any implementation manner of the first aspect.
According to the technical scheme, the embodiment of the application has the following advantages:
in the embodiment of the application, a client receives a first hello message sent by a server, wherein the first hello message includes a first capability information set of the server and an equipment identifier of the server, and the client installs an equipment driver corresponding to the server according to the equipment identifier of the server. Through the description, the client can obtain the equipment identifier of the server in the hello message negotiation process with the server, and the selection and installation of the equipment driver can be completed without additional interactive client, so that the time required for establishing a communication channel between the client and the server is shortened, and the connection efficiency is improved.
Drawings
Figure 1 is a schematic diagram of a SDN architecture;
fig. 2 is a schematic diagram of an embodiment of the data transmission method based on Netconf protocol according to the present application;
fig. 3 is a schematic structural diagram of a first hello packet;
fig. 4 is a schematic diagram of another embodiment of the data transmission method based on Netconf protocol according to the present application;
fig. 5 is a schematic diagram of an embodiment of a client based on Netconf protocol according to the present application;
fig. 6 is a schematic diagram of an embodiment of a server applying for a Netconf-based protocol;
fig. 7 is a schematic structural diagram of a client based on the Netconf protocol according to the present application;
fig. 8 is a schematic structural diagram of a server based on the Netconf protocol according to the present application.
Detailed Description
The embodiment of the application provides a data transmission method based on a Netconf protocol and related equipment, a client can acquire an equipment identifier of a server in a hello message negotiation process with the server, and equipment driver selection and installation can be completed without additional interactive clients, so that the time for establishing a communication channel between the client and the server to complete connection is shortened, and the connection efficiency is improved.
The terms "first," "second," "third," "fourth," and the like in the description and in the claims of the present application and in the drawings described above, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are, for example, capable of operation in sequences other than those illustrated or otherwise 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.
The Netconf protocol used in the present application is first introduced below:
the Netconf protocol is a network configuration and management protocol based on extensible markup language (XML), and uses a simple Remote Procedure Call (RPC) based mechanism to implement communication between a client (client) and a server (server). The client may be a script or an application program running on the network manager, and the server may be a typical network device.
The Netconf protocol employs a layered structure. Each layer separately wraps an aspect of the protocol and provides related services to the upper layers. The layered structure allows each layer to focus on only one aspect of the protocol, is simpler to implement, and minimizes the impact of inter-dependent, internally implemented changes between layers on other layers. Specifically, the Netconf protocol can be divided into the following four layers.
Secure transport layer (secure transport): and a communication path is provided for interaction between the client and the server. Any transport layer protocol bearer that meets basic requirements may be used, for example, a Secure Shell (SSH) protocol may be used as a bearer protocol of the Netconf protocol.
Message (messages) layer: a simple transport protocol layer independent mechanism is provided for generating RPC request and response message frames. The client encapsulates the RPC request content in an < RPC > element and sends the element to the server, and the server encapsulates the request processing result in a < RPC-reply > element and responds to the client.
Operation (operations) layer: a set of basic operations are defined, which can be called using XML-encoded parameters as the RPC calling methods.
Content (content) layer: the data model definition of the management object depends on the implementation condition of the Netconf protocol.
The main functions of the client comprise: carrying out system management on the network equipment by utilizing a Netconf protocol; sending a < rpc > request to the server for one or more specific parameter values; and receiving the alarm and the event actively sent by the server so as to acquire the current state of the managed equipment.
The main functions of the server side include: maintaining information data of the managed device and responding to a request of the client; after receiving the request of the client, the data is analyzed, and then a response is returned to the client; when the equipment fails or other events occur, the server side actively informs the client side of the alarm and the event of the equipment, and reports the current state change of the equipment to the client side.
The Netconf protocol is introduced above, and a specific application scenario of the present application based on the Netconf protocol is introduced below:
the present application may be applied to a Software Defined Network (SDN), please refer to fig. 1, where fig. 1 is a schematic structural diagram of an SDN. The network structure of the SDN is a three-layer model, in which a collaborative application layer is mainly various upper layer applications that embody a user's intention, such applications are called collaborative layer applications, and typical applications include an Operation Support System (OSS) and the like. The control layer is the control center of the system, and the controller is responsible for the generation of the internal switching path and the boundary service route of the network and is responsible for processing the network state change event. The forwarding layer mainly comprises a basic forwarding network formed by network equipment, the layer is responsible for executing the forwarding of user data, and forwarding table items required in the forwarding process are generated by the control layer.
In SDN, the control plane of the network element is on the controller, responsible for protocol computations, generating flow tables, while the forwarding plane is only on the network device. The network equipment centrally manages and issues the flow table through the controller, so that the network equipment does not need to be operated one by one, and only the controller needs to be configured. The third party application only needs to define a new network function in a programming mode through an open interface provided by the controller and then runs on the controller.
The client in the Netconf protocol corresponds to a controller in an SDN scenario, and the server in the Netconf protocol corresponds to a network device in an SDN scenario. The application is described by uniformly adopting the names of a client and a server. In addition, the present application may also be applied to other network scenarios based on the Netconf protocol, except for the SDN scenario, and is not limited herein.
In an SDN scenario, a client may interface multiple service ends, and in addition to hello packet negotiation, interaction between the client and the service ends requires driver selection according to device identifiers of manufacturers, versions, types, and the like of the service ends, so that the client can install drivers corresponding to different service ends, a communication channel between the client and the service end is established after the drivers are installed successfully, and the client further sends configuration information to the corresponding service end through the communication channel. Specifically, the client may obtain the device identifier of the server by sending the query packet to the server, and multiple interactions including hello packets and query packets are required to be performed to establish a communication channel between the client and the server, which is low in efficiency.
The whole idea of the application is that the client can obtain the device identifier of the server in the hello message negotiation stage, and the selection and installation of the device driver can be completed without additional interactive clients, so that the time required for establishing a communication channel between the client and the server is shortened, and the connection efficiency is improved.
The following detailed description of embodiments of the present application:
referring to fig. 2, fig. 2 is a schematic diagram of an embodiment of a data transmission method based on Netconf protocol according to the present application. In this example, the data transmission method based on the Netconf protocol includes the following steps.
201. And the client sends a second hello message to the server.
In this embodiment, the client needs to exchange respective capability information sets with the server in order to establish a session with the server, and then the client may send a second hello packet to the server, where the second hello packet includes the second capability information set of the client.
It should be noted that the session between the client and the server is supported on the SSH protocol, so before hello packet interaction between the client and the server, the client needs to initiate an SSH connection with the server.
202. And the server side sends the first hello message to the client side.
In this embodiment, after the server receives the second hello packet sent by the client, the server further sends the first hello packet to the client, so as to complete hello packet negotiation between the client and the server, and the client can discover the function of the server through hello packet negotiation and use the operation, parameters and content defined by the capability information sets.
Referring to the schematic structural diagram of the first hello packet shown in fig. 3, the first hello packet includes a secure transport layer protocol (e.g., SSH), a message identifier (e.g., hello), and a payload, where the payload includes a device identifier of the server in addition to the first capability information set of the server. The device identifier of the server may include at least one of a device type, a device vendor, a device version, and a device model. It should be noted that, in practical applications, the device identifier of the server includes, but is not limited to, the above examples.
Optionally, the first hello packet may further include a session identifier (session-id), that is, the server may allocate a session identifier to the session, so as to uniquely identify the session.
It should be noted that the second hello packet and the first hello packet may adopt an XML encoding format, and represent complex hierarchical data by text, which supports using both a conventional text compiling tool and an XML dedicated editing tool to read, store and operate configuration data.
A specific form of the content in the payload of the first hello packet is listed below.
</hello>
Wherein, the tag of < capabilities > represents the first capability information set of the server, the tag of < session-id > represents the session identifier of the session, the tag of < system-identifiers > identifies the device identifier of the server, and further, under the tag of < system-identifiers > there are included < device-type > representing the device type (e.g. OLT), < version > representing the device version (e.g. release1.0.0), < vendor > representing the device vendor (e.g. Huawei), and < model > representing the device model (e.g. MA 5800).
It should be noted that the tag name of the < system-identifiers > is only an example, and in practical applications, other tag names may also be used to represent the device identifier of the server, which is not limited herein. In addition, for the setting mode of the device identifier, in addition to the mode of setting the sub-tag under the tag, each device identifier may be directly tiled, and a total tag similar to < system-identifiers > is not set, which may specifically be as follows:
203. and the client installs the equipment driver corresponding to the server according to the equipment identifier of the server.
In this embodiment, the client needs to install a driver corresponding to the server in order to establish a communication channel with the server, and the configuration information can be sent to the server through the driver interface (communication channel) only after the driver is successfully installed. Therefore, after receiving the device identifier of the server, the client can determine the device driver corresponding to the server according to the device identifier.
Specifically, the client locally may store a device driver set corresponding to each of the multiple servers, and each device driver has a device identifier corresponding to the device driver, for example, a device driver a corresponding to the device identifier a, a device driver B corresponding to the device identifier B, and the like. Then the client can select the device driver corresponding to the device identifier from the device driver set according to the received device identifier of the server, and the client can install the device driver in the next step.
It should be noted that the manner in which the client selects and installs the device driver is only an example, and other embodiments may also be used in practical applications, for example, after receiving the device identifier of the server, the client may download the device driver corresponding to the device identifier from a server dedicated for storing the device driver, and further complete installation of the device driver. The details are not limited herein.
It should be noted that, in addition to the device driver described above, the client may also install a device adapter (device adapter) corresponding to the server according to the device identifier of the server.
In the embodiment of the application, the client sends a second hello message carrying a second capability information set of the client to the server, and then the client receives a first hello message sent by the server, wherein the first hello message comprises a first capability information set of the server and an equipment identifier of the server, and further the client installs an equipment driver corresponding to the server according to the equipment identifier of the server. Through the description, the client can obtain the equipment identifier of the server in the hello message negotiation process with the server, and the selection and installation of the equipment driver can be completed without additional interactive client, so that the time required for establishing a communication channel between the client and the server is shortened, and the connection efficiency is improved.
Optionally, in step 201, the second hello packet sent by the client to the server may also carry the device identifier of the client itself. Referring to fig. 4, fig. 4 is a schematic diagram of another embodiment of the data transmission method based on Netconf protocol according to the present application. In this example, the data transmission method based on the Netconf protocol includes the following steps.
401. And the client sends a second hello message to the server.
In this embodiment, the second hello message sent by the client to the server carries the device identifier of the client in addition to the second capability information set of the client. It should be noted that the device identifier of the client is similar to the device identifier of the server, and may also include at least one of a device type, a device manufacturer, a device version, and a device model. In addition, the structure of the second hello packet and the specific form of the payload thereof are similar to those described in relation to step 202 in the embodiment shown in fig. 2, and detailed description thereof is omitted here.
402. And the server judges whether to accept hello message negotiation according to the equipment identifier of the client, if not, the step 403 is executed, and if so, the step 404 is executed.
In this embodiment, after receiving the second hello packet sent by the client, the server may determine whether to accept the hello packet negotiation initiated by the client according to the device identifier of the client carried in the second hello packet. For example, in some scenarios, the server a can only accept hello packet negotiation initiated by the client a, but cannot accept hello packet negotiation initiated by other clients such as the client B, and the like, so that the server a may locally store the device identifier of the client a, and further the server checks the device identifier carried in the received hello packet and the locally stored device identifier, and accepts the hello packet negotiation if the checking is successful, and rejects the hello packet negotiation if the checking is unsuccessful.
403. And if the server rejects the hello message negotiation, the server sends a rejection response to the client.
404. And if the server receives the hello message negotiation, the server sends a first hello message carrying the first capability information set and the equipment identifier of the server to the client.
405. And the client installs the equipment driver corresponding to the server according to the equipment identifier of the server.
In this embodiment, the steps 404 and 405 are similar to the steps 202 and 203 in the embodiment shown in fig. 2, and detailed description thereof is omitted here.
The above describes the data transmission method based on the Netconf protocol in the embodiment of the present application, and a client based on the Netconf protocol in the embodiment of the present application is introduced as follows:
referring to fig. 5, an embodiment of a client based on the Netconf protocol in the embodiment of the present application includes:
the sending unit 501 is configured to send a second hello packet to the server, where the second hello packet includes a second capability information set of the client;
the receiving unit 502 is configured to receive a first hello packet sent by a server, where the first hello packet includes a first capability information set of the server and an equipment identifier of the server;
the installing unit 503 is configured to install the device driver corresponding to the server according to the device identifier of the server.
Optionally, the device identifier of the server includes at least one of a device type, a device manufacturer, a device version, and a device model.
Optionally, the mounting unit 503 is specifically configured to:
searching a device driver corresponding to the device identifier of the server from a preset device driver set;
and installing the equipment driver.
Optionally, the second hello packet further includes a device identifier of the client, where the device identifier of the client includes at least one of a device type, a device manufacturer, a device version, and a device model.
Optionally, the first hello packet further includes a session identifier, where the session identifier is used to identify a session established between the client and the server.
In this embodiment of the application, the sending unit 501 sends a second hello packet carrying a second capability information set of the client to the server, and the receiving unit 502 receives a first hello packet sent by the server, where the first hello packet includes a first capability information set of the server and an equipment identifier of the server, and then the installation unit 503 installs an equipment driver corresponding to the server according to the equipment identifier of the server. Through the description, the client can obtain the equipment identifier of the server in the hello message negotiation process with the server, and the selection and installation of the equipment driver can be completed without additional interactive client, so that the time required for establishing a communication channel between the client and the server is shortened, and the connection efficiency is improved.
The following introduces a service end based on the Netconf protocol in the embodiment of the present application:
referring to fig. 6, an embodiment of a server based on the Netconf protocol in the embodiment of the present application includes:
a receiving unit 601, configured to receive a second hello packet sent by a client, where the second hello packet includes a first capability set of the client;
a sending unit 602, configured to send a first hello packet to the client, so that the client installs a device driver corresponding to the server according to the device identifier of the server, where the first hello packet includes a first capability information set of the server and the device identifier of the server.
Optionally, the device identifier of the server includes at least one of a device type, a device manufacturer, a device version, and a device model.
Optionally, the second hello packet further includes a device identifier of the client, where the device identifier of the client includes at least one of a device type, a device manufacturer, a device version, and a device model.
Optionally, the first hello packet further includes a session identifier, where the session identifier is used to identify a session established between the client and the server.
The above describes the client and the server in the embodiment of the present application from the perspective of the modular functional entity, and the following describes the client and the server in the embodiment of the present application from the perspective of hardware processing:
referring to fig. 7, the client in the present application includes one or more processors 701, memories 702 and communication interfaces 703, wherein the processors 701, the memories 702 and the communication interfaces 703 are connected to each other through a bus.
In particular, the client may be used to perform all or part of the actions performed by the client in the embodiments shown in fig. 2 and 4.
Referring to fig. 8, the server in the present application includes one or more processors 801, a memory 802 and a communication interface 803, wherein the processors 801, the memory 802 and the communication interface 803 are connected to each other through a bus.
Specifically, the server may be configured to perform all or part of the actions performed by the server in the embodiments shown in fig. 2 and fig. 4.
It should be understood that the Processor mentioned in the embodiments of the present Application may be a Central Processing Unit (CPU), and may also be other general purpose processors, Digital Signal Processors (DSP), Application Specific Integrated Circuits (ASIC), Field Programmable Gate Arrays (FPGA) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components, and the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
It will also be appreciated that the memory referred to in the embodiments of the application may be either volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The non-volatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable PROM (EEPROM), or a flash Memory. Volatile Memory can be Random Access Memory (RAM), which acts as external cache Memory. By way of example, but not limitation, many forms of RAM are available, such as Static random access memory (Static RAM, SRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic random access memory (Synchronous DRAM, SDRAM), Double Data Rate Synchronous Dynamic random access memory (DDR SDRAM), Enhanced Synchronous SDRAM (ESDRAM), Synchronous link SDRAM (SLDRAM), and Direct Rambus RAM (DR RAM).
It should be noted that when the processor is a general-purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, the memory (memory module) is integrated in the processor.
It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and the like.
The above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions in the embodiments of the present application.
Claims (27)
1. A data transmission method based on a network configuration Netconf protocol is characterized by comprising the following steps:
a client receives a first hello message sent by a server, wherein the first hello message comprises a first capability information set of the server and an equipment identifier of the server;
and the client side installs the equipment driver corresponding to the server side according to the equipment identifier of the server side.
2. The method of claim 1, wherein the device identifier of the server comprises at least one of a device type, a device vendor, a device version, and a device model.
3. The method according to claim 1 or 2, wherein the client installing the device driver corresponding to the server according to the device identifier of the server comprises:
the client searches the device driver corresponding to the device identifier of the server from a preset device driver set;
and the client side installs the device driver.
4. The method according to any one of claims 1 to 3, further comprising:
and the client sends a second hello message to the server, wherein the second hello message comprises a second capability information set of the client.
5. The method of claim 4, wherein the second hello packet further comprises a device identifier of the client, and wherein the device identifier of the client comprises at least one of a device type, a device vendor, a device version, and a device model.
6. The method according to any one of claims 1 to 5, wherein the first hello packet further comprises a session identifier, and the session identifier is used for identifying a session established between the client and the server.
7. A data transmission method based on a network configuration Netconf protocol is characterized by comprising the following steps:
the method comprises the steps that a server side sends a first hello message to a client side, so that the client side installs a device driver corresponding to the server side according to a device identifier of the server side, and the first hello message comprises a first capability information set of the server side and the device identifier of the server side.
8. The method of claim 7, wherein the device identifier of the server comprises at least one of a device type, a device vendor, a device version, and a device model.
9. The method according to claim 7 or 8, characterized in that the method further comprises:
and the server receives a second hello message sent by the client, wherein the second hello message comprises a second capability information set of the client.
10. The method of claim 9, wherein the second hello packet further comprises a device identifier of the client, and wherein the device identifier of the client comprises at least one of a device type, a device vendor, a device version, and a device model.
11. The method according to any one of claims 7 to 10, wherein the first hello packet further comprises a session identifier, and the session identifier is used for identifying a session established between the client and the server.
12. A client based on Netconf protocol, comprising:
a receiving unit, configured to receive a first hello packet sent by a server, where the first hello packet includes a first capability information set of the server and an equipment identifier of the server;
and the installation unit is used for installing the equipment driver corresponding to the server according to the equipment identifier of the server.
13. The client of claim 12, wherein the device identifier of the server includes at least one of a device type, a device vendor, a device version, and a device model.
14. The client according to claim 12 or 13, wherein the installation unit is specifically configured to:
searching the device driver corresponding to the device identifier of the server from a preset device driver set;
and installing the equipment driver.
15. The client according to any one of claims 12 to 14, wherein the client further comprises:
and the sending unit is used for sending a second hello message to the server, wherein the second hello message comprises a second capability information set of the client.
16. The client of claim 15, wherein the second hello packet further comprises a device identifier of the client, and wherein the device identifier of the client comprises at least one of a device type, a device vendor, a device version, and a device model.
17. The client according to any one of claims 12 to 16, wherein the first hello packet further includes a session identifier, and the session identifier is used to identify a session established between the client and the server.
18. A server based on Netconf protocol, comprising:
a sending unit, configured to send a first hello packet to a client, so that the client installs a device driver corresponding to the server according to a device identifier of the server, where the first hello packet includes a first capability information set of the server and the device identifier of the server.
19. The server according to claim 18, wherein the device identifier of the server comprises at least one of a device type, a device vendor, a device version, and a device model.
20. The method according to claim 18 or 19, wherein the server further comprises:
a receiving unit, configured to receive a second hello packet sent by the client, where the second hello packet includes a second capability information set of the client.
21. The server according to claim 20, wherein the second hello packet further comprises a device identifier of the client, and wherein the device identifier of the client comprises at least one of a device type, a device vendor, a device version, and a device model.
22. The server according to any one of claims 18 to 21, wherein the first hello packet further includes a session identifier, and the session identifier is used to identify a session established between the client and the server.
23. A client based on Netconf protocol, comprising:
the system comprises a processor, a memory, a bus and an input/output interface;
the memory stores program codes;
the processor executes the Netconf protocol-based data transmission method of any of claims 1 to 6 when calling the program code in the memory.
24. A server based on Netconf protocol, comprising:
the system comprises a processor, a memory, a bus and an input/output interface;
the memory stores program codes;
the processor, when calling the program code in the memory, executes the Netconf protocol-based data transmission method according to any of claims 7 to 11.
25. A computer-readable storage medium comprising instructions that, when executed on a computer, cause the computer to perform the Netconf protocol-based data transmission method of claims 1 to 11.
26. A computer program product containing instructions which, when run on a computer, cause the computer to carry out the procedure of the Netconf protocol-based data transmission method of claims 1 to 11.
27. A data transmission system comprising a client as claimed in claim 23 and a server as claimed in claim 24.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111511027.3A CN114363306A (en) | 2019-07-09 | 2019-07-09 | Data transmission method based on Netconf protocol and related equipment |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111511027.3A CN114363306A (en) | 2019-07-09 | 2019-07-09 | Data transmission method based on Netconf protocol and related equipment |
| CN201910618734.9A CN112217845B (en) | 2019-07-09 | 2019-07-09 | Data transmission method based on Netconf protocol and related equipment |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910618734.9A Division CN112217845B (en) | 2019-07-09 | 2019-07-09 | Data transmission method based on Netconf protocol and related equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114363306A true CN114363306A (en) | 2022-04-15 |
Family
ID=74048349
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111511027.3A Pending CN114363306A (en) | 2019-07-09 | 2019-07-09 | Data transmission method based on Netconf protocol and related equipment |
| CN201910618734.9A Active CN112217845B (en) | 2019-07-09 | 2019-07-09 | Data transmission method based on Netconf protocol and related equipment |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910618734.9A Active CN112217845B (en) | 2019-07-09 | 2019-07-09 | Data transmission method based on Netconf protocol and related equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (2) | CN114363306A (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113141390B (en) * | 2021-03-11 | 2022-05-27 | 新华三技术有限公司合肥分公司 | Netconf channel management method and device |
| CN114024998B (en) * | 2021-11-11 | 2023-05-23 | 瑞斯康达科技发展股份有限公司 | Method and device for supporting multiple sessions based on netconf protocol |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060174103A1 (en) * | 2004-09-16 | 2006-08-03 | Nokia Corporation | System and method for integrating PKI and XML-based security mechanisms in SyncML |
| US11336511B2 (en) * | 2006-09-25 | 2022-05-17 | Remot3.It, Inc. | Managing network connected devices |
| US20090089408A1 (en) * | 2007-09-28 | 2009-04-02 | Alcatel Lucent | XML Router and method of XML Router Network Overlay Topology Creation |
| CN101296124B (en) * | 2008-06-27 | 2012-04-04 | 华为技术有限公司 | Method for acquiring equipment information |
| CN105281940B (en) * | 2014-07-18 | 2020-08-21 | 南京中兴软件有限责任公司 | Method, equipment and system for HELLO message interaction based on NETCONF protocol |
| CN107222321B (en) * | 2016-03-21 | 2020-08-14 | 华为技术有限公司 | Configuration message sending method and device |
| CN112087318B (en) * | 2016-04-25 | 2024-02-02 | 华为技术有限公司 | Network management method, server, client and system |
| CN109413123A (en) * | 2017-08-16 | 2019-03-01 | 华为技术有限公司 | Session keeping method and relevant device |
| CN109936505B (en) * | 2017-12-15 | 2021-06-22 | 上海诺基亚贝尔股份有限公司 | Method and apparatus in data-centric software-defined networks |
| CN109151095B (en) * | 2018-11-01 | 2021-03-19 | 联想(北京)有限公司 | Method and apparatus for network communication |
-
2019
- 2019-07-09 CN CN202111511027.3A patent/CN114363306A/en active Pending
- 2019-07-09 CN CN201910618734.9A patent/CN112217845B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN112217845A (en) | 2021-01-12 |
| CN112217845B (en) | 2022-01-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3748908B1 (en) | Method, system, network device, storage medium for creating a network slice | |
| CN105939365B (en) | Master control borad User space obtains the method and device of data from business intralaminar nuclei state | |
| CN115442423A (en) | Method for discovering services provided by a network repository function | |
| CN115296993B (en) | System, function and interface for interconnected multi-domain network fragment control and management | |
| EP2429225A1 (en) | Method for provisioning parameters of terminal, system thereof, and terminal management device | |
| US11418385B2 (en) | Network alarm method, device, system and terminal | |
| US20120278456A1 (en) | Method and apparatus for data configuration | |
| US11726808B2 (en) | Cloud-based managed networking service that enables users to consume managed virtualized network functions at edge locations | |
| CN112838940B (en) | Network controller frame and data processing method | |
| CN106713420B (en) | The dispositions method and device of monitoring | |
| CN112217845B (en) | Data transmission method based on Netconf protocol and related equipment | |
| CN113285816B (en) | Control request sending method, device and system based on key value configuration | |
| CN111064626B (en) | Configuration updating method, device, server and readable storage medium | |
| WO2015168981A1 (en) | Attribute operating method and apparatus | |
| CN115248692A (en) | Device and method for supporting cloud deployment of multiple deep learning framework models | |
| CN113556359B (en) | Communication protocol conversion method, device, system and gateway device | |
| CN111309691A (en) | Data sharing exchange system and exchange method based on bus architecture | |
| CN111770122A (en) | Service communication agent SCP registration method, service calling method and network equipment | |
| CN103428013B (en) | Device management method, system and gateway device | |
| CN110995829B (en) | Instance calling method and device and computer storage medium | |
| CN107395766B (en) | HazelCast-based decentralized communication system and implementation method | |
| EP4322483A1 (en) | System architecture for implementing dds communication on basis of autosar, communication method, and device | |
| CN109274715A (en) | The platform resource management system of vehicle-mounted multi-channel communication systems | |
| CN110943975B (en) | Service registration method, device, computer equipment and storage medium | |
| US11804986B2 (en) | Method for the remote management of a device connected to a residential gateway |
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 |