WO2022063058A1 - 基于netconf协议的传输方法、设备及存储介质 - Google Patents
基于netconf协议的传输方法、设备及存储介质 Download PDFInfo
- Publication number
- WO2022063058A1 WO2022063058A1 PCT/CN2021/119129 CN2021119129W WO2022063058A1 WO 2022063058 A1 WO2022063058 A1 WO 2022063058A1 CN 2021119129 W CN2021119129 W CN 2021119129W WO 2022063058 A1 WO2022063058 A1 WO 2022063058A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- compression
- data
- compression format
- sender
- format
- Prior art date
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 91
- 238000000034 method Methods 0.000 title claims abstract description 83
- 238000007906 compression Methods 0.000 claims abstract description 435
- 230000006835 compression Effects 0.000 claims abstract description 435
- 239000003550 marker Substances 0.000 claims description 25
- 238000004590 computer program Methods 0.000 claims description 6
- 238000004891 communication Methods 0.000 abstract description 3
- 230000003993 interaction Effects 0.000 description 23
- 230000008569 process Effects 0.000 description 18
- 238000007726 management method Methods 0.000 description 9
- 230000006837 decompression Effects 0.000 description 6
- 238000012546 transfer Methods 0.000 description 6
- 238000012545 processing Methods 0.000 description 5
- 230000006872 improvement Effects 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 230000001174 ascending effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 230000008094 contradictory effect Effects 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 238000013144 data compression Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
Images
Classifications
-
- 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/04—Protocols for data compression, e.g. ROHC
Definitions
- the embodiments of the present application relate to the field of communication technologies, and in particular, to a transmission method, device, and storage medium based on the NETCONF protocol.
- NETCONF is a protocol for managing network devices proposed by the Internet Engineering Task Force (IETF). Based on this, users can add, delete, and modify the configuration data of the controlled network devices.
- the controlled device reads configuration data and status data.
- the transmission based on the NETCONF protocol is usually a non-compressed text transmission method, although the message interaction between the client and the server can be realized based on this transmission method.
- the amount of configuration data for a management device may increase significantly, even reaching a scale of hundreds of megabytes. Therefore, if the non-compressed text transmission mode specified in the current NETCONF protocol is used, it will inevitably consume a lot of network resources and time, resulting in a huge transmission bottleneck.
- the embodiments of the present application provide a transmission method based on the NETCONF protocol, which is applied to a sending end, including: after establishing a session with a receiving end, exchanging compression capabilities with the receiving end to determine a target compression format; transmitting data to the receiving end , compress the data according to the target compression format, and transmit the compressed data to the receiving end.
- the embodiment of the present application also provides a transmission method based on the NETCONF protocol, which is applied to the receiving end, including: after establishing a session with the sending end, exchanging compression capabilities with the sending end to determine a target compression format; After the data is stored, the data is decompressed according to the target compression format.
- An embodiment of the present application further provides a transmission device based on the NETCONF protocol, including: a memory communicatively connected to at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor , so that at least one processor can execute any one of the above transmission methods based on the NETCONF protocol.
- Embodiments of the present application further provide a computer-readable storage medium storing a computer program.
- the computer program is executed by the processor, any one of the above-mentioned transmission methods based on the NETCONF protocol is implemented.
- FIG. 1 is a flowchart of a transmission method based on the NETCONF protocol provided by the first embodiment of the present application
- FIG. 3 is a flowchart of a transmission method based on the NETCONF protocol provided by the third embodiment of the present application.
- FIG. 5 is a schematic diagram of the interaction between a sender and a receiver of a transmission method based on the NETCONF protocol provided by the seventh embodiment of the present application;
- FIG. 6 is a schematic structural diagram of a transmission device based on the NETCONF protocol provided by the eighth embodiment of the present application.
- device and storage medium based on the NETCONF protocol proposed in this application whether it is the sender or the receiver, after establishing a session with the other party, it is determined by exchanging compression capabilities with the opposite end device that established the session.
- the target compression format so that in the process of data transmission, the sender can compress the data to be transmitted according to the target compression format, and the receiver can use the same target after receiving the data compressed by the sender according to the target compression format.
- the compressed format is decompressed, and then the original data is restored. In this way, the occupation of network resources can be reduced as much as possible in the case of large data volume interaction, and the network transmission time can be greatly shortened and the network pressure can be reduced.
- the first embodiment of the present application relates to a transmission method based on the NETCONF protocol. This method is mainly applied to the sender of data in the interaction process.
- the above-mentioned sender may be a client or a server.
- the receiving end for receiving the data transmitted by the above-mentioned sending end may be a server end or a client end.
- the above-mentioned client is specifically a NETCONF client, that is, a client that complies with the NETCONF protocol.
- the above-mentioned server is specifically a NETCONF server, that is, a server that complies with the NETCONF protocol.
- the two parties performing data interaction are usually the client and the server. Therefore, in this embodiment, if the sender is a NETCONF client, the receiver is a NETCONF server.
- Step 101 After establishing a session with the receiving end, perform compression capability exchange with the receiving end to determine a target compression format.
- the compression capability interaction mentioned in this embodiment essentially refers to a process in which the sender and the receiver negotiate and determine the target compression format.
- the compression format sorting rules mentioned in this embodiment are determined for the currently common compression formats.
- the compression format sorting rule may be determined according to the speed of compression, may also be determined according to the size of the compressed data, or may be both, that is, determined according to the level of compression efficiency.
- the compression format sorting rule requires that the compression formats supported by the sender be sorted according to the speed of compression, then in the obtained compression list of the sender, the compression format with the faster compression speed is located in the higher position.
- a compression format with a slower compression speed is located at a later position, that is, the compression formats in the compression list of the sender are arranged in descending order according to the order of compression speed from fast to slow.
- the compression format sorting rule requires that the compression formats supported by the sender be sorted according to the size of the compressed data
- the position of the compression format with the smaller data size after compression is located. The higher the position, the later the compressed format with the larger compressed data size is, that is, the compressed formats in the sender's compression list are arranged in ascending order according to the size of the compressed data from small to large.
- the compression format sorting rule requires that the compression formats supported by the sender be sorted according to the level of compression efficiency, then in the obtained compression list of the sender, the compression format with higher compression efficiency is located earlier. , the compression formats with lower compression efficiency are located later, that is, the compression formats in the compression list of the sender are arranged in descending order according to the order of compression efficiency from high to low.
- the sending end and the receiving end negotiate, and then determine whether the two parties are generating the corresponding compression list (the sending end compression list or the receiving end compression list). list) by the compression format collation. That is, the ordering rules of the compression format according to the data exchange parties are the same.
- the order of the compression format list obtained after sorting these compression formats is: 7z, bz2, zip, gz.
- the compression format is determined as the target compression format.
- the compression format arrangement rule negotiated and determined in this embodiment is to rank compression formats with high compression efficiency, or fast compression speed, or the size of the compressed data in the top position, in order to It is ensured that the determined target compression format is a compression format with high compression efficiency, or a fast compression speed, or a compression format with a small size of the compressed data. Therefore, the above-mentioned operation of traversing the compression list of the receiving end in sequence is specifically performed according to the following steps: Traverse in forward and backward order.
- the compression format in the received compression list of the receiver is taken as an example: bz2 and gz, then when the generated client compression list is: 7z and bz2, the compression format supported by the traversed receiver will be The format matches the compression format in the sender's compression list, and the final target compression format is bz2.
- the process of establishing a session between the sender and the receiver specifically, the sender first initiates a link establishment request to the receiver that needs to perform data interaction, that is, a request to establish a session link; then, After receiving the link establishment request initiated by the sender, the receiver makes a link establishment response to the link establishment request, thereby realizing the establishment of a session link or session channel between the sender and the receiver.
- Step 102 When transmitting data to the receiving end, compress the data according to the target compression format, and transmit the compressed data to the receiving end.
- the sender and the receiver can perform data transmission without affecting the bandwidth and network transmission load, and in the case of less time-consuming. , such data can be directly transmitted without compression. Therefore, in order to enable the transmission method based on the NETCONF protocol provided in this embodiment, both transmission efficiency and consumption of device resources can be considered.
- the compression threshold can be preset. Furthermore, when transmitting data to the receiving end, it is first determined whether the size of the data to be transmitted is larger than the compression threshold.
- the data to be transmitted when the size of the data to be transmitted is greater than the compression threshold, the data is compressed according to the determined target compression format, and the compressed data is transmitted to the receiving end; otherwise, the uncompressed data is directly compressed.
- the processed data is transmitted to the receiver.
- the compression threshold may be dynamically adjusted according to the network quality of the network channel between the sender and the receiver.
- the network quality of the network channel between the two parties is regularly detected. If the network quality deteriorates, for example, the network delay increases, the compression threshold is reduced, otherwise, the compression threshold is increased. Therefore, the data transmission between the sender and the receiver is made more flexible and efficient without increasing the network load.
- the sender after the sender establishes a session with the receiver, it determines the target compression format applicable to both by exchanging compression capabilities with the receiver, so that the In the process of data transmission, the sender can compress the data to be transmitted according to the target compression format, and the receiver can use the same target compression format for decompression after receiving the data compressed by the sender according to the target compression format. Then, the original data can be restored. In this way, the occupation of network resources can be reduced as much as possible in the case of large data volume interaction, and the network transmission time can be greatly shortened, and the network pressure can be reduced.
- the target compression format on which the compressed transmission method is based is directly determined by the sender and the receiver through negotiation, and the entire transmission process does not need to involve other third-party devices.
- URL Uniform Resource Locator
- the sender of the data needs to upload the transmitted data to a separate third-party file transfer server, and then the file transfer server or the sender corresponds to the data in the file transfer server.
- the URL of the storage location is sent to the receiving end, and finally the receiving end obtains the data provided by the sending end from the file server according to the URL.
- it also saves the number of network links.
- the data is directly transmitted between the sender and the receiver, the consistency of the transaction is better guaranteed.
- the second embodiment of the present application relates to a transmission method based on the NETCONF protocol.
- the second embodiment makes further improvements on the basis of the first embodiment.
- the main improvement is: when the compressed data is transmitted to the receiving end, the compressed data is encoded, and the encoded data obtained by encoding is encoded.
- the data corresponding to the current coded frame is inserted into the frame to identify the compression identifier of the compressed data, so that the receiving end can quickly and accurately determine the range of the data to be parsed and the current to be parsed according to the start marker in the coded frame and the end marker. Whether the data is compressed data and whether it needs to be decompressed according to the target compression format.
- the transmission method based on the NETCONF protocol involved in the second embodiment includes the following steps:
- Step 201 After establishing a session with a receiving end, perform compression capability exchange with the receiving end to determine a target compression format.
- step 201 in this embodiment is substantially the same as step 101 in the first embodiment, which will not be repeated here.
- Sub-step 2021 when transmitting data to the receiving end, compress the data according to the target compression format.
- Sub-step 2022 Encode the compressed data according to a preset encoding method to obtain an encoded frame.
- the encoded frame obtained by encoding the compressed data according to the preset encoding method includes, in addition to the encoded data itself, a start marker identifying the beginning of the data and an end marker identifying the end of the data.
- start identifier is to tell the receiving end from where to start parsing the received data.
- the above-mentioned end marker is used to tell the receiving end to which position to end the parsing.
- the above-mentioned analysis means that the receiving end restores the encoded frame to the data before encoding.
- Sub-step 2023 insert a compression marker in the encoded frame.
- the compression identifier mentioned above is to inform the receiving end that the encoded frame currently received is encoded based on the data compressed by the determined target compression format. That is, if the encoded frame carries a compression identifier, the receiving end will decompress the encoded frame based on the determined target compression format after receiving the encoded frame, so as to restore the original data transmitted by the transmitting end.
- Sub-step 2024 transmitting the encoded frame carrying the compression identifier to the receiving end.
- this embodiment takes the block transfer encoding (chunk encoding) based on the HyperText Transfer Protocol (HyperText Transfer Protocol, HTTP) as an example for specific description:
- the transmission layer of the sender will encode the compressed data into frames according to the following pseudocode:
- the compressed data when the compressed data is transmitted to the receiving end, the compressed data is converted into an encoded frame carrying a start identifier, an end identifier and a compression identifier. , so that the receiving end can know when the parsing starts, when the parsing starts, and whether the parsed data needs to be decompressed according to the determined target compression format. In this way, the correctness of the data transmission is effectively guaranteed, so that the Data can be transmitted to the other party better and more accurately.
- the third embodiment of the present application relates to a transmission method based on the NETCONF protocol. This method is mainly applied to the receiving end of the data in the interaction process.
- the above-mentioned receiving end may be a server end or a client end.
- the sender for transmitting data to the aforementioned receiver may be a client or a server.
- the above-mentioned client is specifically a NETCONF client, that is, a client that complies with the NETCONF protocol.
- the above-mentioned server is specifically a NETCONF server, that is, a server that complies with the NETCONF protocol.
- the two parties performing data interaction are usually the client and the server. Therefore, in this embodiment, if the sender is a NETCONF client, the receiver is a NETCONF server.
- Step 301 After establishing a session with the sender, perform compression capability exchange with the sender to determine a target compression format.
- the compression capability interaction mentioned in this embodiment essentially refers to a process in which the receiving end and the transmitting end negotiate and determine the target compression format.
- the compression format sorting rules mentioned in this embodiment are determined for the currently common compression formats.
- the compression format sorting rule may be determined according to the speed of compression, may also be determined according to the size of the compressed data, or may be both, that is, determined according to the level of compression efficiency.
- the compression format sorting rule requires that the compression formats supported by the receiving end be sorted according to the speed of compression, then in the obtained compression list of the receiving end, the compression format with the faster compression speed is located in the higher position.
- a compression format with a slower compression speed is located at a later position, that is, the compression formats in the compression list of the receiving end are arranged in descending order according to the order of compression speed from fast to slow.
- the compression format sorting rule requires that the compression formats supported by the receiving end be sorted according to the size of the compressed data, in the obtained compression list of the receiving end, the position of the compressed format with the smaller compressed data size is located. The higher the position, the later the compression format with the larger compressed data size is, that is, the compression formats in the compression list of the receiving end are arranged in ascending order according to the size of the compressed data from small to large.
- the compression format sorting rule requires that the compression formats supported by the receiving end be sorted according to the level of compression efficiency, then in the obtained compression list of the receiving end, the compression format with higher compression efficiency is located earlier. , the compression formats with lower compression efficiency are located later, that is, the compression formats in the compression list of the receiving end are arranged in descending order according to the order of compression efficiency from high to low.
- the receiver and the sender negotiate, and then determine whether the two parties are generating the corresponding compression list (the receiver compression list or the sender compression list). list) by the compression format collation. That is, the ordering rules of the compression format according to the data exchange parties are the same.
- the compression format sorting rules determined through negotiation between the receiving end and the transmitting end stipulate that the sorting is performed according to the order of compression efficiency from high to low.
- the order of the compression format list obtained after sorting these compression formats is: 7z, bz2, zip, gz.
- the compression formats supported by the receiving end are bz2 and gz
- the compression efficiency of bz2 is higher than that of gz
- the order of the compressed formats in the obtained list of compression formats of the receiving end is: bz2, gz.
- the compression format is determined as the target compression format.
- the compression format arrangement rule negotiated and determined in this embodiment is to rank compression formats with high compression efficiency, or fast compression speed, or the size of the compressed data in the top position, in order to It is ensured that the determined target compression format is a compression format with high compression efficiency, or a fast compression speed, or a compression format with a small size of the compressed data. Therefore, the above-mentioned operation of traversing the compression list of the receiving end in sequence is specifically performed according to the following steps: Traverse in forward and backward order.
- the compression format in the received compression list of the sender is: 7z, bz2 as an example, then when the generated compression list of the receiver is: bz2, gz, by traversing the compression supported by the sender The format matches the compression format in the receiver's compression list, and the final target compression format is bz2.
- the process of establishing a session between the receiving end and the sending end specifically, the sending end first initiates a chain establishment request to the receiving end that needs to perform data interaction, that is, a request to establish a session link; then, After receiving the link establishment request initiated by the sender, the receiver makes a link establishment response to the link establishment request, thereby realizing the establishment of a session link or session channel between the sender and the receiver.
- Step 302 after receiving the data transmitted by the sender, decompress the data according to the target compression format.
- the receiving end after the receiving end establishes a session with the sending end, it determines the target compression format suitable for both by exchanging compression capabilities with the sending end, so that the In the process of data transmission, the sender can compress the data to be transmitted according to the target compression format, and the receiver can use the same target compression format for decompression after receiving the data compressed by the sender according to the target compression format. Then, the original data can be restored. In this way, the occupation of network resources can be reduced as much as possible in the case of large data volume interaction, and the network transmission time can be greatly shortened and the network pressure can be reduced.
- the fourth embodiment of the present application relates to a transmission method based on the NETCONF protocol.
- the fourth embodiment is further improved on the basis of the third embodiment, and the main improvement is: the data transmitted by the transmitting end is the encoded frame obtained after encoding, and the encoded frame includes at least a start marker and an end marker.
- the data transmitted by the transmitting end is the encoded frame obtained after encoding
- the encoded frame includes at least a start marker and an end marker.
- the transmission method based on the NETCONF protocol involved in the fourth embodiment includes the following steps:
- Step 401 After establishing a session with the sender, perform compression capability exchange with the sender to determine a target compression format.
- step 401 in this embodiment is substantially the same as step 301 in the third embodiment, which will not be repeated here.
- Sub-step 4021 when the start identifier is identified from the encoded frame, detect whether the encoded frame carries a compression identifier.
- Sub-step 4022 when the encoded frame carries the compression identifier, decompress the encoded frame to the end identifier according to the target compression format.
- the receiving end can quickly determine when the parsing starts and when the parsing starts by identifying the start identifier and the end identifier in the received encoded frame. Identify whether the encoded frame carries a compression identifier, so as to determine whether the parsed data needs to be decompressed according to the determined target compression format. In this way, the correctness of data transmission is effectively ensured, so that the data can be better and more correct. transmitted to the other party.
- this embodiment cooperates with the method applied to the sending end provided in the first or second embodiment to realize the method applied to the receiving end for data transmission.
- the embodiment may be implemented in cooperation with the first or second embodiment. Therefore, the related technical details mentioned in the first or second embodiment are still valid in this embodiment, and are not repeated here in order to reduce repetition. Correspondingly, the related technical details mentioned in this embodiment can also be applied in the first or second embodiment.
- the fifth embodiment of the present application relates to a transmission device based on the NETCONF protocol, and the device is mainly located at the sending end.
- the transmission device based on the NETCONF protocol includes: a target compression format determination module and a compression module.
- the target compression format determination module is used to exchange compression capabilities with the receiver after establishing a session with the receiver to determine the target compression format; the compression module is used to transmit data to the receiver according to the The data is compressed in the target compression format, and the compressed data is transmitted to the receiving end.
- the target compression format determination module is specifically configured to determine the target compression format in the following manner:
- the compression format is determined as the target compression format.
- the transmission apparatus based on the NETCONF protocol may further include: a compression format ordering rule determination module.
- the compression format sorting rule determination module is configured to negotiate the compression format sorting rule with the receiving end, and after determining the compression format sorting rule, notify the target compression format determining module to execute the compression format according to the preset compression format
- the sorting rule is an operation of sorting the compressed format to obtain the compressed list of the sender.
- the compression module when transmitting data to the receiving end, is specifically configured to compress the data according to the target compression format in the following manner, and transmit the compressed data to the Receiving end:
- the data is compressed according to the target compression format, and the compressed data is transmitted to the receiving end.
- the transmission apparatus based on the NETCONF protocol may further include: a compression threshold determination module.
- a compression threshold determination module is configured to detect the network quality of the network channel with the receiving end; and determine the compression threshold according to the network quality.
- the compression module is specifically configured to transmit the compressed data to the receiving end in the following manner:
- the compressed data is encoded to obtain an encoded frame, and the encoded frame includes a start marker and an end marker;
- the compression identifier is used by the receiving end to decompress the encoded frame according to the target compression format after receiving the encoded frame;
- the encoded frame carrying the compression identifier is transmitted to the receiving end.
- this embodiment is a device embodiment corresponding to the first or second embodiment, and this embodiment can be implemented in cooperation with the first or second embodiment.
- the related technical details mentioned in the first or second embodiment are still valid in this embodiment, and are not repeated here in order to reduce repetition.
- the related technical details mentioned in this embodiment can also be applied in the first or second embodiment.
- the sixth embodiment of the present application relates to a transmission device based on the NETCONF protocol, and the device is mainly located at the receiving end.
- the device based on the NETCONF protocol includes: a target compression format determination module and a decompression module.
- the target compression format determination module is used to exchange compression capabilities with the sender after establishing a session with the sender to determine the target compression format; the decompression module is used to receive the data transmitted by the sender after receiving the data. , and decompress the data according to the target compression format.
- the target compression format determination module is specifically configured to determine the target compression format in the following manner:
- the compression format is sorted to obtain a receiver compression list
- the compression format is determined as the target compression format.
- the transmission apparatus based on the NETCONF protocol may further include: a compression format ordering rule determination module.
- a compression format sorting rule determination module configured to negotiate the compression format sorting rule with the sending end, and after determining the compression format sorting rule, notify the target compression format determining module to execute the compression format according to the preset compression format
- the sorting rule is an operation of sorting the compression format to obtain the compression list of the receiving end.
- the data transmitted by the sending end is an encoded frame obtained after encoding, and the encoded frame includes a start marker and an end marker.
- the decompression module is specifically configured to decompress the data according to the target compression format in the following manner:
- the coded frame When the coded frame carries the compression marker, the coded frame is decompressed to the end marker according to the target compression format.
- this embodiment is a device embodiment corresponding to the third or fourth embodiment, and this embodiment can be implemented in cooperation with the third or fourth embodiment.
- the related technical details mentioned in the third or fourth embodiment are still valid in this embodiment, and are not repeated here in order to reduce repetition.
- the related technical details mentioned in this embodiment can also be applied in the third or fourth embodiment.
- the sender of data may be a NETCONF client or a NETCONF server; the receiver of data may be a NETCONF server or a NETCONF client.
- any NETCONF client it can be used as both a data sender and a data receiver.
- any NETCONF server it can be used as both a data receiving end and a data sending end.
- the above-mentioned logic modules in the transmission device based on the NETCONF protocol which are respectively applied to the sender and the receiver, can be integrated and deployed to the sender and the receiver respectively.
- the transmission device deployed in the NETCONF client or the transmission device deployed in the NETCONF server may include a capability management module, a data processing module, a data analysis module, and a data transmission module.
- the capability management module mentioned above is essentially used to determine whether the data to be transmitted needs to be compressed, and when it is determined that the data to be transmitted needs to be compressed, communicate with the data interaction end (if the current capability management module is located in the NETCONF client, the data interaction end is the NETCONF server; otherwise, the data interaction end is the capability management module in the NETCONF client) to interact, and then determine the target compression format, compression format sorting rules, and compression thresholds .
- the above-mentioned data processing module is used to compress the data according to the determined target compression format; the data parsing module is used to decompress the received compressed data according to the determined target compression format. Compressed; the data sending module sends the processed data to the data exchange end.
- NETCONF server can interact with multiple NETCONF clients at the same time, so in order to distinguish and manage the NETCONF clients that interact with it, the NETCONF server can also include link management. module.
- the link management module is mainly used to manage session links established with different NETCONF clients.
- modules involved in this embodiment are logical modules.
- a logical unit may be a physical unit, a part of a physical unit, or multiple A combination of physical units.
- this embodiment does not introduce units that are not closely related to solving the technical problem raised by the present application, but this does not mean that there are no other units in this embodiment.
- the seventh embodiment of the present application relates to a transmission system based on the NETCONF protocol, including a sending end and a receiving end.
- the receiver makes a link establishment response according to the received link establishment request from the sender, thereby realizing the establishment of a session channel or link between the sender and the receiver.
- the two sides start the compression capability exchange operation, that is, negotiate to determine the target compression format, and can also determine their respective compression thresholds during this process.
- a hello message is sent to the receiver, and the hello message carries the compression transmission capability (compression threshold) and the sender's compression list , the hello message sent can be implemented by the following pseudo code:
- the hello message is sent by sending a hello message to the sender, and the hello message carries the compression transmission capability (compression threshold) and the compression list of the receiver.
- the message can be implemented by the following pseudo code:
- the transmission layer of the sender determines by judgment that the size of the data to be transmitted to the receiver exceeds the compression threshold (10M), It is necessary to perform data compression according to the target compression format negotiated with the receiving end, and use a preset encoding method to encode the compressed data into frames, and transmit the encoded frames obtained by encoding to the receiving end through the underlying communication layer.
- the receiving end When the receiving end removes the frame header frame by monitoring the start marker used to identify the start and the end marker used to identify the end, and when recognizing that the compression marker is carried, it samples the target compression format determined by negotiation, Decompress the received complete message, and then deliver the decompressed data to the message layer for parsing.
- the sender can compress the data to be transmitted according to the target compression format.
- the receiver After receiving the data compressed by the sender according to the target compression format, the receiver can use the same The target compression format is decompressed, and the original data is restored. In this way, the occupation of network resources can be reduced as much as possible in the case of large data volume interaction, and the network transmission time can be greatly shortened and the network pressure can be reduced.
- the eighth embodiment of the present application relates to a transmission device based on the NETCONF protocol, as shown in FIG. 6 , comprising: at least one processor 601 ; and a memory 602 communicatively connected to the at least one processor 601 ; wherein, the memory 602 Instructions executable by the at least one processor 601 are stored, and the instructions are executed by the at least one processor 601, so that the at least one processor 601 can execute the transmission method based on the NETCONF protocol described in any one of the above method embodiments.
- the memory 602 and the processor 601 are connected by a bus, and the bus may include any number of interconnected buses and bridges, and the bus connects one or more processors 601 and various circuits of the memory 602 together.
- the bus may also connect together various other circuits, such as peripherals, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein.
- the bus interface provides the interface between the bus and the transceiver.
- a transceiver may be a single element or multiple elements, such as multiple receivers and transmitters, providing a means for communicating with various other devices over a transmission medium.
- the data processed by the processor 601 is transmitted on the wireless medium through the antenna, and further, the antenna also receives the data and transmits the data to the processor 601 .
- Processor 601 is responsible for managing the bus and general processing, and may also provide various functions, including timing, peripheral interface, voltage regulation, power management, and other control functions.
- memory 602 may be used to store data used by processor 601 in performing operations.
- the ninth embodiment of the present application relates to a computer-readable storage medium storing a computer program.
- the computer program is executed by the processor, the transmission method based on the NETCONF protocol described in any one of the above method embodiments is implemented.
- the aforementioned storage medium includes: U disk, mobile hard disk, Read-Only Memory (ROM, Read-Only Memory), Random Access Memory (RAM, Random Access Memory), magnetic disk or optical disk and other media that can store program codes .
Abstract
本申请实施例涉及通信技术领域，公开了一种基于NETCONF协议的传输方法、设备及存储介质。本申请中，基于NETCONF协议的传输方法，应用于发送端，包括：在与接收端建立会话后，与接收端进行压缩能力交换，确定目标压缩格式；在向接收端传输数据时，根据目标压缩格式对数据进行压缩，并将压缩后的数据传输给接收端。
Description
交叉引用
本申请基于申请号为“202011041373.5”、申请日为2020年09月28日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此以引入方式并入本申请。
本申请实施例涉及通信技术领域，特别涉及一种基于NETCONF协议的传输方法、设备及存储介质。
NETCONF是国际互联网工程任务组(The Internet Engineering Task Force，IETF)提出的一种管理网络设备的协议，基于此，用户可以对被控制网络设备的配置数据进行增加、删除、修改操作，也可以从被控制设备读取配置数据和状态数据。
基于NETCONF协议的传输通常是非压缩文本传输方式，虽然基于这种传输方式可以实现客户端与服务端的消息交互。但是，随着设备复杂度的提高，以及云化设备的出现，一个管理设备的配置数据量可能会大幅上升，甚至可以达到几百兆规模。因此，如果使用目前NETCONF协议中规定的非压缩文本传输方式，势必会消耗大量网络资源和时间，造成极大的传输瓶颈。
发明内容
本申请的实施例提供了一种基于NETCONF协议的传输方法，应用于发送端，包括：在与接收端建立会话后，与接收端进行压缩能力交换，确定目标压缩格式；在向接收端传输数据时，根据目标压缩格式对数据进行压缩，并将压缩后的数据传输给接收端。
本申请实施例还提供了一种基于NETCONF协议的传输方法，应用于接收端，包括：在与发送端建立会话后，与发送端进行压缩能力交换，确定目标压缩格式；在接收到发送端传输的数据后，根据目标压缩格式对数据进行解压缩。
本申请实施例还提供了一种基于NETCONF协议的传输设备，包括：与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行如上的任意一种基于NETCONF协议的传输方法。
本申请实施例还提供了一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述的任意一种基于NETCONF协议的传输方法。
一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定。
图1是本申请第一实施例提供的基于NETCONF协议的传输方法的流程图；
图2是本申请第二实施例提供的基于NETCONF协议的传输方法的流程图；
图3是本申请第三实施例提供的基于NETCONF协议的传输方法的流程图；
图4是本申请第四实施例提供的基于NETCONF协议的传输方法的流程图；
图5是本申请第七实施例提供的基于NETCONF协议的传输方法的发送端与接收端之间的交互示意图；
图6是本申请第八实施例提供的基于NETCONF协议的传输设备的结构示意程图。
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请的各实施例进行详细的阐述。然而，本领域的普通技术人员可以理解，在本申请各实施例中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本申请的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可 以相互结合相互引用。
本申请提出的基于NETCONF协议的传输方法、设备及存储介质，不论是发送端还是接收端，在与对方建立会话后，通过与建立会话的对端设备进行压缩能力交换来确定适用于两者的目标压缩格式，从而在进行数据传输的过程中，发送端可以根据目标压缩格式对需要传输的数据进行压缩，接收端在接收到发送端根据目标压缩格式压缩后的数据后，可以采用相同的目标压缩格式进行解压缩，进而还原出原数据，通过这种方式可以在大数据量交互的情况下，尽可能减小对网络资源的占用，同时大幅度缩短网络传输时间，降低网络压力。
本申请的第一实施例涉及一种基于NETCONF协议的传输方法。该方法主要应用于交互过程中数据的发送端。
具体的说，在本实施例中，上述所说的发送端可以是客户端，也可以是服务端。
相应地，用于接收上述所说的发送端传输的数据的接收端可以是服务端，也可以是客户端。
此外，在本实施例中，上述所说的客户端，具体是NETCONF客户端，即遵循NETCONF协议的客户端。
相应地，上述所说的服务端，具体是NETCONF服务端，即遵循NETCONF协议的服务端。
此外，应当理解的是，在实际应用中，进行数据交互的两方，通常是客户端与服务端。因此，在本实施例中，若发送端是NETCONF客户端，则接收端是NETCONF服务端。
下面对本实施例的基于NETCONF协议的传输方法的实现细节进行说明，以下内容仅为方便理解而提供的实现细节，并非实施本方案的必须。
本实施例的具体流程如图1所示，具体包括以下步骤：
步骤101，在与接收端建立会话后，与所述接收端进行压缩能力交换，确定目标压缩格式。
具体的说，本实施例所说的压缩能力交互，实质就是指发送端与接收端协商确定目标压缩格式的过程。
关于该过程的实现，对于发送端来说，具体是通过以下几个步骤实现：
(1)获取本地支持的压缩格式，即获取发送端支持的压缩格式。
具体的说，由于不同的发送端自身支持的硬件资源的不同，因而不同的发送端所支持的压缩格式可能存在差异。故而，在与接收端协商确定目标压缩格式时，需要先获取自身支持的压缩格式，以保障最终确定的目标压缩格式是双方都支持的压缩格式。
(2)根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到发送端压缩列表。
具体的说，本实施例中所说的压缩格式排序规则，是针对目前常见的压缩格式确定的。该压缩格式排序规则可以是根据压缩速度的快慢确定，也可以是根据压缩后的数据大小来确定，还可以是兼顾着二者，即根据压缩效率的高低来确定。
比如说，若所述压缩格式排序规则要求根据压缩速度的快慢对发送端支持的压缩格式进行排序，则得到的发送端压缩列表中，压缩速度越快的压缩格式所处的位置越靠前，压缩速度越慢的压缩格式所处的位置越靠后，即发送端压缩列表中的压缩格式是按照压缩速度从快到慢的顺序进行降序排列的。
还比如说，若所述压缩格式排序规则要求根据压缩后的数据大小对发送端支持的压缩格式进行排序，则得到的发送端压缩列表中，压缩后数据大小越小的压缩格式所处的位置越靠前，压缩后数据大小越大的压缩格式所处的位置越靠后，即发送端压缩列表中的压缩格式是按照压缩后数据的大小从小到大的顺序进行升序排列的。
还比如说，若所述压缩格式排序规则要求根据压缩效率的高低对发送端支持的压缩格式进行排序，则得到的发送端压缩列表中，压缩效率越高的压缩格式所处的位置越靠前，压缩效率越低的压缩格式所处的位置越靠后，即发送端压缩列表中的压缩格式是按照压缩效率从高到低的顺序进行降序排列的。
应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
此外，值得一提的是，在实际应用中，为了保证发送端生成的发送端压缩列表和接收端生成的接收端压缩列表中相同压缩格式之间的位置关系相同，在生成发送端压缩列表和接收端压缩列表之前，需要先与进行数据交互的对端设 备，在本实施例中具体是发送端与接收端进行协商，进而确定双方在生成对应的压缩列表(发送端压缩列表或接收端压缩列表)时所依据的压缩格式排序规则。即，数据交互双方所依据的压缩格式排序规则是相同的。
为了便于理解，以下结合实例进行说明：
假设，经发送端与接收端协商确定的压缩格式排序规则，规定的是按照压缩效率从高到低的顺序进行排序。
以现有常用的几种压缩格式zip、7z、gz、bz2为例，基于上述压缩格式排序规则，针对这几种压缩格式排序后得到的压缩格式列表顺序为：7z、bz2、zip、gz。
也就是说，在基于上述压缩格式排序规则，对发送端和接收端的压缩格式进行排序时，上述4中压缩格式的位置关系是确定的。
假设，发送端自身支持的压缩格式为7z和bz2，则基于上述压缩格式排序规则可知，7z的压缩效率要高于bz2，故而得到的发送端压缩格式列表中压缩格式的排列顺序为：7z、bz2。
应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
(3)将所述发送端压缩列表传输给所述接收端，并接收所述接收端传输的接收端压缩列表，即进行压缩能力的交换。
(4)按序对所述接收端压缩列表进行遍历，将遍历到的所述接收端支持的压缩格式与所述发送端压缩列表中的压缩格式进行匹配。
相应地，若遍历到的所述接收端支持的压缩格式与所述发送端压缩列表中的压缩格式匹配，则将所述压缩格式确定为所述目标压缩格式。
此外，值得一提的是，由于本实施例中协商确定的压缩格式排列规则是将压缩效率高，或者压缩速度快，或者压缩后的数据大小小的压缩格式排在靠前的位置，因而为了保证确定的目标压缩格式为压缩效率高，或压缩速度快，或压缩后的数据大小小的压缩格式，故而上述所说的按序对所述接收端压缩列表进行遍历的操作，具体是按照从前往后的顺序进行遍历。
为了便于理解，此处以接收到的接收端压缩列表中的压缩格式为：bz2、gz为例，则在生成的客户端压缩列表为：7z、bz2时，通过将遍历到的接收端支 持的压缩格式与发送端压缩列表中的压缩格式匹配，最终确定的目标压缩格式为bz2。
此外，应当理解的是，在实际应用中，发送端与接收端建立会话的过程，具体是由发送端先向需要进行数据交互的接收端发起建链请求，即建立会话链接的请求；然后，接收端在接收到发送端发起的建链请求后，作出针对该建链请求的建链响应，进而实现发送端与接收端双方的会话链路或会话通道的建立。
步骤102，在向所述接收端传输数据时，根据所述目标压缩格式对所述数据进行压缩，并将压缩后的数据传输给所述接收端。
具体的说，由于压缩是需要占用设备资源的，因此对于数据量较小的数据，在不影响带宽和网络传输负载，以及耗时较小的情况下，发送端与接收端在进行数据传输时，可以对此类数据不进行压缩，即直接进行传输。故而，为了使得本实施例提供的基于NETCONF协议的传输方法既可以兼顾传输效率，又可以兼顾对设备资源的消耗。对于数据的发送端，不论是NETCONF客户端还是NETCONF服务端，均可以预先设置压缩阈值。进而，在向接收端传输数据时，先判断需要传输的数据的大小是否大于所述压缩阈值。
相应地，在需要传输的数据的大小，大于所述压缩阈值时，才根据确定的目标压缩格式对所述数据进行压缩，并将压缩后的数据传输给接收端；否则，直接将未经压缩处理的数据传输给接收端。
通过设置压缩阈值，从而可以根据需要传输的数据大小来决定是采用压缩方式传输，还是非压缩方式传输，从而既兼顾了传输效率，又兼顾了设备资源的消耗。
进一步地，为了实现压缩阈值的动态调整，在实际应用中，可以根据发送端与接收端之间的网络通道的网络质量来动态调整压缩阈值。
也就是说，在发送端与接收端的交互过程中，定期检测双方之间的网络通道的网络质量，如果网络质量变差，比如网络时延升高，则降低压缩阈值，反之则提高压缩阈值，从而在不增加网络负载的情况下，使得发送端与接收端之间的数据传输更加灵活高效。
通过上述描述不难发现，本实施例提供的基于NETCONF协议的传输方法，发送端在与接收端建立会话后，通过与接收端进行压缩能力交换来确定适用于 两者的目标压缩格式，从而在进行数据传输的过程中，发送端可以根据目标压缩格式对需要传输的数据进行压缩，接收端在接收到发送端根据目标压缩格式压缩后的数据后，可以采用相同的目标压缩格式进行解压缩，进而还原出原数据，通过这种方式可以在大数据量交互的情况下，尽可能减小对网络资源的占用，同时大幅度缩短网络传输时间，降低网络压力。
此外，由于本实施例提供的基于NETCONF协议的传输方法，压缩传输方式所依据的目标压缩格式是直接由发送端和接收端协商确定的，整个传输过程不需要涉及其他第三方设备，因而相较于传输统一资源定位器(Uniform Resource Locator，URL)，即数据的发送端需要将传输的数据上传到单独的第三方文件传输服务器，然后由文件传输服务器或者发送端将该数据在文件传输服务器对应的存储位置的URL发送给接收端，最后接收端根据该URL从文件服务器获取发送端提供的数据的方式，本实施例提供的基于NETCONF协议的传输方法无需构建第三方文件传输服务器，因而大大接收了实现成本，同时也节约了网络链接数开销。并且，由于数据是直接在发送端和接收端传输的，因而也更好的保证了事务的一致性。
本申请的第二实施例涉及一种基于NETCONF协议的传输方法。第二实施例在第一实施例的基础上做了进一步改进，主要改进之处为：在将压缩后的数据传输给接收端时，通过对压缩后的数据进行编码，并在编码获得的编码帧中插入标识当前编码帧对应的数据是压缩数据的压缩标志符，从而使得接收端能够根据编码帧中的开始标志符合结束标志符快速、准确的确定要解析的数据的范围，以及当前要解析的数据是否为压缩数据，是否需要根据目标压缩格式进行解压缩。
如图2所示，第二实施例涉及的基于NETCONF协议的传输方法，包括如下步骤：
步骤201，在与接收端建立会话后，与所述接收端进行压缩能力交换，确定目标压缩格式。
不难发现，本实施例中的步骤201与第一实施例中的步骤101大致相同，在此就不再赘述，以下主要针对不同之处，即构成步骤202的4个子步骤进行说明。
子步骤2021，在向所述接收端传输数据时，根据所述目标压缩格式对所述数据进行压缩。
子步骤2022，根据预设的编码方法，对压缩后的所述数据进行编码，得到编码帧。
具体的说，根据预设的编码方法对压缩后的数据进行编码获得的的编码帧中，除了包括编码后的数据本身，还包括标识数据开始的开始标志符和标识数据结束的结束标志符。
应当理解的是，上述所说的开始标志符是为了告诉接收端从何起开始对接收到的数据进行解析。
相应地，上述所说的结束标志符时为了告诉接收端解析到哪一个位置结束解析。
此外，需要说明的是，上述所说的解析是指接收端将编码帧还原成编码前的数据。
子步骤2023，在所述编码帧中插入压缩标志符。
具体的说，上述所说的压缩标志符，是为了告知接收端当前接收到的编码帧是基于确定目标压缩格式压缩后的数据编码而来的。即，如果编码帧中携带有压缩标志符，接收端在接收到所述编码帧，便会基于确定的目标压缩格式对所述编码帧进行解压缩，以还原出发送端传输的原数据。
子步骤2024，将携带有所述压缩标志符的编码帧传输给所述接收端。
为了便于说明，本实施例以基于超文本传输协议(HyperText Transfer Protocol，HTTP)的分块传输编码(chunk编码)为例进行具体说明：
具体的，发送端的传输层在按照确定的目标压缩格式对需要传输的数据进行压缩之后，会按照如下伪代码，将压缩后的数据编码成帧：
应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
由此，本实施例提供的基于NETCONF协议的传输方法，在将压缩后数据传输给接收端时，通过将压缩后的数据转换为携带有开始标志符、结束标志符和压缩标志符的编码帧，从而可以使得接收端能够获知从何时开始解析，解析到何时，并且解析的数据是否需要根据确定的目标压缩格式进行解压缩，通过这种方式，有效保证了数据传输的正确性，使得数据能够更好更正确的传输到对方。
本申请的第三实施例涉及一种基于NETCONF协议的传输方法。该方法主要应用于交互过程中数据的接收端。
具体的说，在本实施例中，上述所说的接收端可以是服务端，也可以是客户端。
相应地，用于向上述所说的接收端传输数据的发送端可以是客户端，也可以是服务端。
此外，在本实施例中，上述所说的客户端，具体是NETCONF客户端，即遵循NETCONF协议的客户端。
相应地，上述所说的服务端，具体是NETCONF服务端，即遵循NETCONF协议的服务端。
此外，应当理解的是，在实际应用中，进行数据交互的两方，通常是客户端与服务端。因此，在本实施例中，若发送端是NETCONF客户端，则接收端 是NETCONF服务端。
下面对本实施例的基于NETCONF协议的传输方法的实现细节进行说明，以下内容仅为方便理解而提供的实现细节，并非实施本方案的必须。
本实施例的具体流程如图3所示，具体包括以下步骤：
步骤301，在与发送端建立会话后，与所述发送端进行压缩能力交换，确定目标压缩格式。
具体的说，本实施例中所说的压缩能力交互，实质就是指接收端与发送端协商确定目标压缩格式的过程。
关于该过程的实现，对于接收端来说，具体是通过以下几个步骤实现：
(1)获取本地支持的压缩格式，即获取接收端支持的压缩格式。
具体的说，由于不同的接收端自身支持的硬件资源的不同，因而不同的接收端所支持的压缩格式可能存在差异。故而，在与发送端协商确定目标压缩格式时，需要先获取自身支持的压缩格式，以保障最终确定的目标压缩格式是双方都支持的压缩格式。
(2)根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到接收端压缩列表。
具体的说，本实施例中所说的压缩格式排序规则，是针对目前常见的压缩格式确定的。该压缩格式排序规则可以是根据压缩速度的快慢确定，也可以是根据压缩后的数据大小来确定，还可以是兼顾着二者，即根据压缩效率的高低来确定。
比如说，若所述压缩格式排序规则要求根据压缩速度的快慢对接收端支持的压缩格式进行排序，则得到的接收端压缩列表中，压缩速度越快的压缩格式所处的位置越靠前，压缩速度越慢的压缩格式所处的位置越靠后，即接收端压缩列表中的压缩格式是按照压缩速度从快到慢的顺序进行降序排列的。
还比如说，若所述压缩格式排序规则要求根据压缩后的数据大小对接收端支持的压缩格式进行排序，则得到的接收端压缩列表中，压缩后数据大小越小的压缩格式所处的位置越靠前，压缩后数据大小越大的压缩格式所处的位置越靠后，即接收端压缩列表中的压缩格式是按照压缩后数据的大小从小到大的顺序进行升序排列的。
还比如说，若所述压缩格式排序规则要求根据压缩效率的高低对接收端支持的压缩格式进行排序，则得到的接收端压缩列表中，压缩效率越高的压缩格式所处的位置越靠前，压缩效率越低的压缩格式所处的位置越靠后，即接收端压缩列表中的压缩格式是按照压缩效率从高到低的顺序进行降序排列的。
应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
此外，值得一提的是，在实际应用中，为了保证接收端生成的接收端压缩列表和发送端生成的发送端压缩列表中相同压缩格式之间的位置关系相同，在生成接收端压缩列表和发送端压缩列表之前，需要先与进行数据交互的对端设备，在本实施例中具体是接收端与发送端进行协商，进而确定双方在生成对应的压缩列表(接收端压缩列表或发送端压缩列表)时所依据的压缩格式排序规则。即，数据交互双方所依据的压缩格式排序规则是相同的。
为了便于理解，以下结合实例进行说明：
假设，经接收端与发送端协商确定的压缩格式排序规则，规定的是按照压缩效率从高到低的顺序进行排序。
以现有常用的几种压缩格式zip、7z、gz、bz2为例，基于上述压缩格式排序规则，针对这几种压缩格式排序后得到的压缩格式列表顺序为：7z、bz2、zip、gz。
也就是说，在基于上述压缩格式排序规则，对接收端和发送端的压缩格式进行排序时，上述4中压缩格式的位置关系是确定的。
假设，接收端自身支持的压缩格式为bz2和gz，则基于上述压缩格式排序规则可知，bz2的压缩效率要高于gz，故而得到的接收端压缩格式列表中压缩格式的排列顺序为：bz2、gz。
应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
(3)将所述接收端压缩列表传输给所述发送端，并接收所述发送端传输的发送端压缩列表。
(4)按序对所述发送端压缩列表进行遍历，将遍历到的所述发送端支持的压缩格式与所述接收端压缩列表中的压缩格式进行匹配。
相应地，若遍历到的所述发送端支持的压缩格式与所述接收端压缩列表中的压缩格式匹配，则将所述压缩格式确定为所述目标压缩格式。
此外，值得一提的是，由于本实施例中协商确定的压缩格式排列规则是将压缩效率高，或者压缩速度快，或者压缩后的数据大小小的压缩格式排在靠前的位置，因而为了保证确定的目标压缩格式为压缩效率高，或压缩速度快，或压缩后的数据大小小的压缩格式，故而上述所说的按序对所述接收端压缩列表进行遍历的操作，具体是按照从前往后的顺序进行遍历。
为了便于理解，此处以接收到的发送端压缩列表中的压缩格式为：7z、bz2为例，则在生成的接收端压缩列表为：bz2、gz时，通过将遍历到的发送端支持的压缩格式与接收端压缩列表中的压缩格式匹配，最终确定的目标压缩格式为bz2。
此外，应当理解的是，在实际应用中，接收端与发送端建立会话的过程，具体是由发送端先向需要进行数据交互的接收端发起建链请求，即建立会话链接的请求；然后，接收端在接收到发送端发起的建链请求后，作出针对该建链请求的建链响应，进而实现发送端与接收端双方的会话链路或会话通道的建立。
步骤302，在接收到所述发送端传输的数据后，根据所述目标压缩格式对所述数据进行解压缩。
通过上述描述不难发现，本实施例提供的基于NETCONF协议的传输方法，接收端在与发送端建立会话后，通过与发送端进行压缩能力交换来确定适用于两者的目标压缩格式，从而在进行数据传输的过程中，发送端可以根据目标压缩格式对需要传输的数据进行压缩，接收端在接收到发送端根据目标压缩格式压缩后的数据后，可以采用相同的目标压缩格式进行解压缩，进而还原出原数据，通过这种方式可以在大数据量交互的情况下，尽可能减小对网络资源的占用，同时大幅度缩短网络传输时间，降低网络压力。
本申请的第四实施例涉及一种基于NETCONF协议的传输方法。第四实施例在第三实施例的基础上做了进一步改进，主要改进之处为：针对发送端传输的数据为编码后得到的编码帧，且编码帧中至少包括的开始标志符和结束标志符的情况，在对接收到的数据进行解压缩时，通过识别编码帧中的开始标志符和结束标志符，确定何时开始处理接收到的数据，何时结束处理。同时，通过 识别编码帧中是否携带有压缩标志符，具体是否对当前处理的数据进行解压缩，从而使得接收端可以快速、准确的还原出采用压缩方式传输的数据和非压缩方式传输的数据。
如图4所示，第四实施例涉及的基于NETCONF协议的传输方法，包括如下步骤：
步骤401，在与发送端建立会话后，与所述发送端进行压缩能力交换，确定目标压缩格式。
不难发现，本实施例中的步骤401与第三实施例中的步骤301大致相同，在此就不再赘述，以下主要针对不同之处，即构成步骤402的2个子步骤进行说明。
子步骤4021，在从所述编码帧中识别到所述开始标志符时，检测所述编码帧中是否携带有压缩标志符。
子步骤4022，在所述编码帧中携带有所述压缩标志符时，根据所述目标压缩格式对所述编码帧进行解压缩至所述结束标志符。
由此，本实施例提供的基于NETCONF协议的传输方法，接收端通过识别接收到的编码帧中的开始标志符和结束标志符，从而可以快速确定从何时开始解析，解析到何时，通过识别编码帧中是否携带有压缩标志符，从而可以确定解析的数据是否需要根据确定的目标压缩格式进行解压缩，通过这种方式，有效保证了数据传输的正确性，使得数据能够更好更正确的传输到对方。
此外，通过上述描述不难发现，本实施例为与第一或第二实施例中提供的应用于发送端的方法相互配合，以实现数据传输的应用于接收端的方法，即在具体实现时，本实施例会与第一或第二实施例互相配合实施。因此，第一或第二实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在第一或第二实施例中。
此外，应当理解的是，上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在 该专利的保护范围内。
本申请的第五实施例涉及一种基于NETCONF协议的传输装置，该装置主要位于发送端。
具体而言，所述基于NETCONF协议的传输装置，包括：目标压缩格式确定模块和压缩模块。
其中，目标压缩格式确定模块，用于在与接收端建立会话后，与所述接收端进行压缩能力交换，确定目标压缩格式；压缩模块，用于在向所述接收端传输数据时，根据所述目标压缩格式对所述数据进行压缩，并将压缩后的数据传输给所述接收端。
此外，在另一个例子中，目标压缩格式确定模块，具体用于按照如下方式确定目标压缩格式：
获取本地支持的压缩格式；
根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到发送端压缩列表；
将所述发送端压缩列表传输给所述接收端，并接收所述接收端传输的接收端压缩列表；
按序对所述接收端压缩列表进行遍历，将遍历到的所述接收端支持的压缩格式与所述发送端压缩列表中的压缩格式进行匹配；
若遍历到的所述接收端支持的压缩格式与所述发送端压缩列表中的压缩格式匹配，则将所述压缩格式确定为所述目标压缩格式。
此外，在另一个例子中，基于NETCONF协议的传输装置还可以包括：压缩格式排序规则确定模块。
具体而言，压缩格式排序规则确定模块，用于与所述接收端协商所述压缩格式排序规则，并在确定所述压缩格式排序规则后，通知目标压缩格式确定模块执行根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到发送端压缩列表的操作。
此外，在另一个例子中，在向所述接收端传输数据时，压缩模块，具体用于按照如下方式根据所述目标压缩格式对所述数据进行压缩，并将压缩后的数据传输给所述接收端：
在向所述接收端传输数据时，判断所述数据的大小是否大于压缩阈值；
若所述数据的大小大于所述压缩阈值，则根据所述目标压缩格式对所述数据进行压缩，并将压缩后的数据传输给所述接收端。
此外，在另一个例子中，基于NETCONF协议的传输装置还可以包括：压缩阈值确定模块。
具体而言，压缩阈值确定模块，用于检测与所述接收端之间的网络通道的网络质量；根据所述网络质量确定所述压缩阈值。
此外，在另一个例子中，压缩模块，具体用于按照如下方式将压缩后的数据传输给所述接收端：
根据预设的编码方法，对压缩后的所述数据进行编码，得到编码帧，所述编码帧包括开始标志符和结束标志符；
在所述编码帧中插入压缩标志符，所述压缩标志符供所述接收端在接收到所述编码帧后根据所述目标压缩格式对所述编码帧进行解压缩；
将携带有所述压缩标志符的编码帧传输给所述接收端。
不难发现，本实施例为与第一或第二实施例相对应的装置实施例，本实施例可与第一或第二实施例互相配合实施。第一或第二实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在第一或第二实施例中。
本申请的第六实施例涉及一种基于NETCONF协议的传输装置，该装置主要位于接收端。
具体而言，所述基于NETCONF协议的装置，包括：目标压缩格式确定模块和解压缩模块。
其中，目标压缩格式确定模块，用于在与发送端建立会话后，与所述发送端进行压缩能力交换，确定目标压缩格式；解压缩模块，用于在接收到所述发送端传输的数据后，根据所述目标压缩格式对所述数据进行解压缩。
此外，在另一个例子中，目标压缩格式确定模块，具体用于按照如下方式确定目标压缩格式：
获取本地支持的压缩格式；
根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到接收端压 缩列表；
将所述接收端压缩列表传输给所述发送端，并接收所述发送端传输的发送端压缩列表；
按序对所述发送端压缩列表进行遍历，将遍历到的所述发送端支持的压缩格式与所述接收端压缩列表中的压缩格式进行匹配；
若遍历到的所述发送端支持的压缩格式与所述接收端压缩列表中的压缩格式匹配，则将所述压缩格式确定为所述目标压缩格式。
此外，在另一个例子中，基于NETCONF协议的传输装置还可以包括：压缩格式排序规则确定模块。
具体而言，压缩格式排序规则确定模块，用于与所述发送端协商所述压缩格式排序规则，并在确定所述压缩格式排序规则后，通知目标压缩格式确定模块执行根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到接收端压缩列表的操作。
此外，在另一个例子中，所述发送端传输的数据为编码后得到的编码帧，所述编码帧包括开始标志符和结束标志符。
相应地，解压缩模块，具体用于按照如下方式根据所述目标压缩格式对所述数据进行解压缩：
在从所述编码帧中识别到所述开始标志符时，检测所述编码帧中是否携带有压缩标志符；
在所述编码帧中携带有所述压缩标志符时，根据所述目标压缩格式对所述编码帧进行解压缩至所述结束标志符。
不难发现，本实施例为与第三或第四实施例相对应的装置实施例，本实施例可与第三或第四实施例互相配合实施。第三或第四实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在第三或第四实施例中。
通过上述描述不难发现，在实际应用中，数据的发送端可以是NETCONF客户端，也可以是NETCONF服务端；数据的接收端可以是NETCONF服务端，也可以是NETCONF客户端。
也就是说，对于任意一个NETCONF客户端，既可以作为数据的发送端， 也可以作为数据的接收端。
相应地，对于任意一个NETCONF服务端，既可以作为数据的接收端，也可以作为数据的发送端。
因而，在实际应用中，可以将上述分别应用于发送端和接收端的基于NETCONF协议的传输装置中的逻辑模块进行整合，并分别部署到发送端和接收端中。
为了便于理解，以下给出一种具体的实现方式：
不论是部署于NETCONF客户端内的传输装置，还是部署于NETCONF服务端内的传输装置，均可以包括能力管理模块、数据处理模块、数据解析模块、数据发送模块。
具体的说，上述所说的能力管理模块，实质就是用来确定需要传输的数据是否是需要压缩的，并在确定需要传输的数据是需要压缩的时候，与数据交互端(如果当前能力管理模块是位于NETCONF客户端内的，则数据交互端为NETCONF服务端；反之，则数据交互端为NETCONF客户端)中的能力管理模块进行交互，进而确定目标压缩格式、压缩格式排序规则，以及压缩阈值。
相应地，上述所说的数据处理模块，则是用于根据确定的目标压缩格式对数据进行压缩处理的；数据解析模块，则是用于根据确定的目标压缩格式对接收到的压缩数据进行解压缩的；数据发送模块，则是将处理后的数据发送到数据交互端的。
进一步地，由于在实际应用中，一个NETCONF服务端可以同时与多个NETCONF客户端进行数据交互，故而为了便于区分和管理与之进行数据交互的NETCONF客户端，NETCONF服务端中还可以包括链接管理模块。
具体而言，链接管理模块，主要是用于管理与不同NETCONF客户端建立的会话链接的。
此外，值得一提的是，本实施例中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本申请的创新部分，本实施例中并没有将与解决本申请所提出的技术问题关系不太密切的单元引入，但这并不表明本实施例中不存在其它的单元。
本申请的第七实施例涉及一种基于NETCONF协议的传输系统，包括发送端和接收端。
为了便于说明，以下结合图5，对发送端和接收端的具体交互流程进行说明。
(1)在进行基于NETCONF协议的传输，即进行数据交互时，发送端会向需要进行数据交互的接收端发起建链请求，即建立会话链接的请求。
(2)接收端根据接收到的来自发送端的建链请求，作出建链响应，从而实现发送端与接收端之间会话通道或链接的建立。
(3)在发送端与接收端之间的会话建立后，双方开始压缩能力交换操作，即协商确定目标压缩格式，在此过程中还可以同时确定各自的压缩阈值。
具体的说，针对发送端向接收端发送的压缩能力交互信息，在本实施例中具体是通过向接收端发送hello消息，并在hello消息中携带压缩传输能力(压缩阈值)和发送端压缩列表，发送的hello消息，具体可以通过如下伪代码实现：
针对接收端向发送端发送的压缩能力交互信息，在本实施例中具体是通过向发送端发送hello消息，并在hello消息中携带压缩传输能力(压缩阈值)和接收端压缩列表，发送的hello消息，具体可以通过如下伪代码实现：
通过上述两个hello消息可知，发送端和接收端预设的压缩阈值均为size＝10，即10M；发送端接收到的接收端压缩列表为：bz2，gz；接收端接收到的发送端压缩列表为：7z，bz2，gz。因此，最终协商确定的目标压缩格式为bz2。
应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
(4)当某次用户操作，例如是通过发送端配置一份大小为133M的数据到接收端，此时发送端的传输层通过判断确定需要传输到接收端的数据大小超过了压缩阈值(10M)，需要根据与接收端协商确定的目标压缩格式进行数据压缩，并采用预设的编码方法将压缩后的数据编码成帧，并将编码获得的编码帧通过底层的通信层传输给接收端。
以编码方式采用的是chunk编码为例，则对采用bz2压缩格式压缩后的数据进行编码后，得到的编码帧如下：
应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
(5)当接收端通过监控用于标识开始的开始标志符和标识结束的结束标志符后，去掉帧头帧为，并在识别到携带了压缩标志符时，采样协商确定的目标压缩格式，对收到的完整消息进行解压缩，再将解压后的数据投递给消息层进行解析处理。
由此，在本实施例提供的基于NETCONF协议的传输系统中，不论是发送端还是接收端，在与对方建立会话后，通过与建立会话的对端设备进行压缩能力交换来确定适用于两者的目标压缩格式，从而在进行数据传输的过程中，发送端可以根据目标压缩格式对需要传输的数据进行压缩，接收端在接收到发送端根据目标压缩格式压缩后的数据后，可以采用相同的目标压缩格式进行解压缩，进而还原出原数据，通过这种方式可以在大数据量交互的情况下，尽可能减小对网络资源的占用，同时大幅度缩短网络传输时间，降低网络压力。
本申请的第八实施例涉及一种基于NETCONF协议的传输设备，如图6所示，包括：包括至少一个处理器601；以及，与至少一个处理器601通信连接的存储器602；其中，存储器602存储有可被至少一个处理器601执行的指令，指令被至少一个处理器601执行，以使至少一个处理器601能够执行上述任意一种方法实施例所描述的基于NETCONF协议的传输方法。
其中，存储器602和处理器601采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器601和存储器602的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器601处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器601。
处理器601负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器602可以被用于 存储处理器601在执行操作时所使用的数据。
本申请的第九实施例涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述任意一种方法实施例所描述的基于NETCONF协议的传输方法。
即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本领域的普通技术人员可以理解，上述各实施例是实现本申请的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本申请的精神和范围。
Claims (12)
- 一种基于NETCONF协议的传输方法，应用于发送端，包括：在与接收端建立会话后，与所述接收端进行压缩能力交换，确定目标压缩格式；在向所述接收端传输数据时，根据所述目标压缩格式对所述数据进行压缩，并将压缩后的数据传输给所述接收端。
- 如权利要求1所述的基于NETCONF协议的传输方法，其中，所述与所述接收端进行压缩能力交换，确定目标压缩格式，包括：获取本地支持的压缩格式；根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到发送端压缩列表；将所述发送端压缩列表传输给所述接收端，并接收所述接收端传输的接收端压缩列表；按序对所述接收端压缩列表进行遍历，将遍历到的所述接收端支持的压缩格式与所述发送端压缩列表中的压缩格式进行匹配；若遍历到的所述接收端支持的压缩格式与所述发送端压缩列表中的压缩格式匹配，则将所述压缩格式确定为所述目标压缩格式。
- 如权利要求2所述的基于NETCONF协议的传输方法，其中，在所述根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到发送端压缩列表之前，所述方法还包括：与所述接收端协商所述压缩格式排序规则，并在确定所述压缩格式排序规则后执行所述根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到发送端压缩列表的步骤。
- 如权利要求1至3中任一项所述的基于NETCONF协议的传输方法，其中，所述在向所述接收端传输数据时，根据所述目标压缩格式对所述数据进行压缩，并将压缩后的数据传输给所述接收端，包括：在向所述接收端传输数据时，判断所述数据的大小是否大于压缩阈值；若所述数据的大小大于所述压缩阈值，则根据所述目标压缩格式对所述数据进行压缩，并将压缩后的数据传输给所述接收端。
- 如权利要求4所述的基于NETCONF协议的传输方法，其中，在所述判断所述数据的大小是否大于压缩阈值之前，所述方法还包括：检测与所述接收端之间的网络通道的网络质量；根据所述网络质量确定所述压缩阈值。
- 如权利要求1至5中任一项所述的基于NETCONF协议的传输方法，其中，所述将压缩后的数据传输给所述接收端，包括：根据预设的编码方法，对压缩后的所述数据进行编码，得到编码帧，所述编码帧包括开始标志符和结束标志符；在所述编码帧中插入压缩标志符，所述压缩标志符供所述接收端在接收到所述编码帧后根据所述目标压缩格式对所述编码帧进行解压缩；将携带有所述压缩标志符的编码帧传输给所述接收端。
- 一种基于NETCONF协议的传输方法，应用于接收端，包括：在与发送端建立会话后，与所述发送端进行压缩能力交换，确定目标压缩格式；在接收到所述发送端传输的数据后，根据所述目标压缩格式对所述数据进行解压缩。
- 如权利要求7所述的基于NETCONF协议的传输方法，其中，所述与所述发送端进行压缩能力交换，确定目标压缩格式，包括：获取本地支持的压缩格式；根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到接收端压缩列表；将所述接收端压缩列表传输给所述发送端，并接收所述发送端传输的发送 端压缩列表；按序对所述发送端压缩列表进行遍历，将遍历到的所述发送端支持的压缩格式与所述接收端压缩列表中的压缩格式进行匹配；若遍历到的所述发送端支持的压缩格式与所述接收端压缩列表中的压缩格式匹配，则将所述压缩格式确定为所述目标压缩格式。
- 如权利要求8所述的基于NETCONF协议的传输方法，其中，在所述根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到接收端压缩列表之前，所述方法还包括：与所述发送端协商所述压缩格式排序规则，并在确定所述压缩格式排序规则后执行所述根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到接收端压缩列表的步骤。
- 如权利要求7至9中任一项所述的基于NETCONF协议的传输方法，其中，所述发送端传输的数据为编码后得到的编码帧，所述编码帧包括开始标志符和结束标志符；所述根据所述目标压缩格式对所述数据进行解压缩，包括：在从所述编码帧中识别到所述开始标志符时，检测所述编码帧中是否携带有压缩标志符；若所述编码帧中携带有所述压缩标志符，则根据所述目标压缩格式对所述编码帧进行解压缩至所述结束标志符。
- 一种基于NETCONF协议的传输设备，包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至6中任一所述的基于NETCONF协议的传输方法；或者，如权利要求7至10中任一项所述的基于NETCONF协议的传输方法。
- 一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的基于NETCONF协议的传输方法；或者，如权利要求7至10中任一项所述的基于NETCONF协议的传输方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011041373.5 | 2020-09-28 | ||
| CN202011041373.5A CN114363419A (zh) | 2020-09-28 | 2020-09-28 | 基于netconf协议的传输方法、设备及存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2022063058A1 true WO2022063058A1 (zh) | 2022-03-31 |
Family
ID=80844919
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2021/119129 WO2022063058A1 (zh) | 2020-09-28 | 2021-09-17 | 基于netconf协议的传输方法、设备及存储介质 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN114363419A (zh) |
| WO (1) | WO2022063058A1 (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117478617A (zh) * | 2023-11-03 | 2024-01-30 | 石家庄常宏智能科技有限公司 | 一种多功能物联网关数据快速传输方法 |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117014520B (zh) * | 2023-10-08 | 2024-02-09 | 广东广宇科技发展有限公司 | 一种基于压缩算法的数据快速传输方法 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1905554A (zh) * | 2005-07-29 | 2007-01-31 | 华为技术有限公司 | 一种认证授权计费协议消息传输方法 |
| US7551729B1 (en) * | 2004-09-30 | 2009-06-23 | Nortel Networks Limited | Method and apparatus for increasing channel capacity in an IP-based voice messaging system |
| CN101848492A (zh) * | 2010-06-10 | 2010-09-29 | 中兴通讯股份有限公司 | 媒体网关间的报文传输方法、媒体网关和无线通信系统 |
| CN106817350A (zh) * | 2015-11-30 | 2017-06-09 | 中兴通讯股份有限公司 | 报文处理方法及装置 |
-
2020
- 2020-09-28 CN CN202011041373.5A patent/CN114363419A/zh active Pending
-
2021
- 2021-09-17 WO PCT/CN2021/119129 patent/WO2022063058A1/zh active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7551729B1 (en) * | 2004-09-30 | 2009-06-23 | Nortel Networks Limited | Method and apparatus for increasing channel capacity in an IP-based voice messaging system |
| CN1905554A (zh) * | 2005-07-29 | 2007-01-31 | 华为技术有限公司 | 一种认证授权计费协议消息传输方法 |
| CN101848492A (zh) * | 2010-06-10 | 2010-09-29 | 中兴通讯股份有限公司 | 媒体网关间的报文传输方法、媒体网关和无线通信系统 |
| CN106817350A (zh) * | 2015-11-30 | 2017-06-09 | 中兴通讯股份有限公司 | 报文处理方法及装置 |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117478617A (zh) * | 2023-11-03 | 2024-01-30 | 石家庄常宏智能科技有限公司 | 一种多功能物联网关数据快速传输方法 |
| CN117478617B (zh) * | 2023-11-03 | 2024-04-19 | 石家庄常宏智能科技有限公司 | 一种多功能物联网关数据快速传输方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114363419A (zh) | 2022-04-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2022063058A1 (zh) | 基于netconf协议的传输方法、设备及存储介质 | |
| JP5792850B2 (ja) | ネットワーク上でのファイルフォルダ送信 | |
| CN102638579B (zh) | 一种基于移动设备数据传输的数据处理方法及系统 | |
| US9866356B2 (en) | Data distribution method and device | |
| US9092319B2 (en) | State memory management, wherein state memory is managed by dividing state memory into portions each portion assigned for storing state information associated with a specific message class | |
| CN102970287A (zh) | 一种http请求数据的处理方法 | |
| CN103907327A (zh) | 电信网络中的不显眼内容压缩 | |
| WO2019000866A1 (zh) | 一种数据处理方法及物联网网关 | |
| US9794354B1 (en) | System and method for communication between networked applications | |
| CN112804707A (zh) | 数据传输方法、装置、计算机可读介质及电子设备 | |
| CN102752320B (zh) | 一种代理服务器主动压缩方法及代理服务器 | |
| CN106851733A (zh) | 一种针对移动网络应用的自适应http消息压缩方法 | |
| CN107615257B (zh) | 通信设备、通信方法及存储介质 | |
| TWI673983B (zh) | 一種資料壓縮傳輸方法和系統、及其終端和伺服器 | |
| US20160316022A1 (en) | Communication device, communication processing method, and storage medium | |
| CN103873443A (zh) | 信息处理方法、本地代理服务器和网络代理服务器 | |
| CN107147561B (zh) | 一种基于xmpp协议的即时通讯方法及系统 | |
| CN108040041A (zh) | 一种基于业务驱动的图像差异传输协议设计系统及方法 | |
| CN105635182A (zh) | 一种数据压缩传输方法及系统 | |
| CN108924773B (zh) | 消息处理方法及装置 | |
| WO2018129938A1 (zh) | 一种数据传输方法和装置 | |
| CN103906007A (zh) | 一种彩信转发方法及装置 | |
| CN107196819B (zh) | 一种网络连接的方法及其系统、计算机可读存储介质 | |
| CN104202124A (zh) | 一种erp数据包通讯方法 | |
| CN115834973B (zh) | 一种云端向本地终端数据高速传输方法及系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 32PN | Ep: public notification in the ep bulletin as address of the adressee cannot be established |
Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 18.08.2023) |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 21871428 Country of ref document: EP Kind code of ref document: A1 |