CN115022252A - Method and equipment for configuring maximum length of transmission data packet - Google Patents

Method and equipment for configuring maximum length of transmission data packet Download PDF

Info

Publication number
CN115022252A
CN115022252A CN202210615778.8A CN202210615778A CN115022252A CN 115022252 A CN115022252 A CN 115022252A CN 202210615778 A CN202210615778 A CN 202210615778A CN 115022252 A CN115022252 A CN 115022252A
Authority
CN
China
Prior art keywords
length
data packet
value
cloud server
maximum
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.)
Granted
Application number
CN202210615778.8A
Other languages
Chinese (zh)
Other versions
CN115022252B (en
Inventor
伍经纹
阙远
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hisense Mobile Communications Technology Co Ltd
Original Assignee
Hisense Mobile Communications Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hisense Mobile Communications Technology Co Ltd filed Critical Hisense Mobile Communications Technology Co Ltd
Priority to CN202210615778.8A priority Critical patent/CN115022252B/en
Publication of CN115022252A publication Critical patent/CN115022252A/en
Application granted granted Critical
Publication of CN115022252B publication Critical patent/CN115022252B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
    • H04L47/365—Dynamic adaptation of the packet size
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

The application provides a method and equipment for configuring the maximum length of a transmitted data packet, wherein when a handshake request is sent to a cloud server to determine that the cloud server supports data packet length negotiation, data is sent to the cloud server by using the data packet with the corresponding length according to the value of the length of a reference data packet configured as a variable, and the maximum length of the data packet transmitted by the cloud server is captured; according to the comparison result of the maximum length and the value of the current reference data packet length, adjusting the value of the reference data packet length until the handshake process is finished when the adjustment condition is met; when receiving an OTA upgrading instruction of the cloud service terminal, performing handshaking and data packet downloading with the OTA service terminal by using a preset value of the maximum reference data packet length. By the method, the problem of insufficient memory during handshake with the cloud server is solved, and incomplete data reception during subsequent data packet downloading with the OTA server is also guaranteed.

Description

Method and equipment for configuring maximum length of transmission data packet
Technical Field
The present application relates to the field of communications technologies, and in particular, to a method and an apparatus for configuring a maximum length of a transmission data packet.
Background
The smart home is considered as a model of a new 'ecological' environment, and users manage and remotely control household appliances, vehicles and the like through a network and a transmission protocol, so that the safety of data transmission of the smart home is very important. When the wireless WIFI module is accessed to a cloud service end or an Over The Air (OTA) service end, a layer of encryption protocol is added to be an effective data protection mode. When the encryption protocol is used for connecting the cloud server or the OTA server, the handshake of the WIFI module and the server occupies 32KB of internal memory (input/output data volume), and at the moment, the maximum data volume (maximum fragment length) of data transmitted from the WIFI module to the server or from the server to the WIFI module is 16KB, so that when the WIFI module is connected with the cloud server, the handshake fails due to insufficient internal memory. If the value of the maximum fragment length is directly reduced by a fixed value, the WIFI module is accessed to the cloud end, and then an OTA firmware upgrading process is executed if the WIFI module is accessed to the OAT server end, at the moment, when the WIFI module is accessed to the OTA server end, the maximum data volume (maximum fragment length) of data transmitted to the OTA server end or the WIFI module by the OTA server end is the reduced maximum fragment length, and then the value of the maximum fragment is too small, so that the complete data packet cannot be received, and upgrading failure is caused.
Disclosure of Invention
In order to solve the problem that if the value of the maximum fragment length is directly reduced by a fixed value, when a WIFI module is accessed to a cloud terminal and the WIFI module is accessed to an OTA server, the maximum data volume (the maximum fragment length) of data transmitted to the WIFI module by the WIFI module to the OTA server or from the OTA server is the reduced maximum fragment length, the maximum fragment value is too small, so that a complete data packet cannot be received, and the upgrading is failed, the method and the equipment for configuring the maximum length of the transmission data packet are provided.
In a first aspect, the present application provides a method for configuring a maximum length of a transmission data packet, which is applied to a WIFI module, and the method includes:
sending a handshake request to a cloud server, and determining whether the cloud server supports data packet length negotiation according to feedback of the cloud server;
when the cloud server side supports data packet length negotiation, in each handshake interaction process with the cloud server side, sending data to the cloud server side by using data packets with corresponding lengths according to values of the lengths of the reference data packets configured as variables, and capturing the maximum length of the data packets transmitted by the cloud server side;
according to the comparison result of the maximum length and the value of the current reference data packet length, when the adjustment condition is met, the value of the reference data packet length is adjusted until the handshake process is finished;
when receiving an OTA upgrading instruction of the cloud service terminal in the air, handshaking and data packet downloading are carried out with the OTA service terminal by using the preset value of the maximum standard data packet length.
In one possible implementation, sending a handshake request to a cloud server includes:
acquiring an initial value of a reference data packet length configured as a variable according to the configuration indication;
and sending a handshake request to the cloud server by using the data packet with the corresponding length according to the initial value of the length of the reference data packet, and triggering and executing a handshake process.
In a possible implementation manner, when it is determined that the cloud server does not support the packet length negotiation service, determining a value of a maximum transmission data length preconfigured by the cloud server according to feedback of the cloud server;
and in each subsequent handshake interaction process with the cloud server, sending data to the cloud server by using the data packet with the corresponding length according to the minimum value of the length of the reference data packet configured as the variable and the value of the maximum transmission data length configured in advance by the cloud server.
In a possible implementation manner, adjusting the value of the packet length until the handshake process is finished when the adjustment condition is satisfied according to a comparison result between the maximum length and the value of the current reference packet length includes:
and when the maximum length is determined to be not less than the value of the length of the current reference data packet according to the comparison result of the maximum length and the value of the length of the current reference data packet, the value of the length of the reference data packet is increased once according to a preset step length.
In a possible implementation manner, sending data to a cloud server by using a data packet with a corresponding length according to a value of a length of a reference data packet configured as a variable includes:
when the incremental value of the length of the reference data packet is determined to reach the configured length threshold of the transmission data packet, in each subsequent handshake interaction process with the cloud server, sending data to the cloud server by using the data packet with the corresponding length according to the length threshold of the transmission data packet until the handshake process is finished;
and when the incremental value of the length of the reference data packet is determined not to reach the configured length threshold of the transmission data packet, sending data to the cloud server by using the data packet with the corresponding length according to the value of the length of the reference data packet configured as the variable.
In a possible implementation manner, the performing handshake and data packet download with the OTA server by using a preset value of the maximum reference data packet length includes:
sending a handshake request to an OTA server, and determining that the OTA server supports data packet length negotiation according to the feedback of the OTA server;
when determining that the OTA server supports the negotiation of the data packet length, performing handshake and data packet downloading with the OTA server by using the preset value of the maximum reference data packet length;
and when determining that the OTA server does not support the negotiation of the data packet length, determining the value of the maximum transmission data length configured by the OTA server according to the feedback of the OTA server, and performing handshaking and data packet downloading with the OTA server by using the configured value of the maximum transmission data packet length.
In a second aspect, the present application provides a method for configuring a maximum length of a transmission data packet, which is applied to a cloud server, and the method includes:
receiving at least one data packet length negotiation request sent by a WIFI module end, and sending a result supporting data packet length negotiation to the WIFI module end;
and receiving a handshake request which is sent by the WIFI module end and carries the length value of the transmission data packet at least once, and feeding back a handshake result to the WIFI module end every time.
In a third aspect, the present application provides a device for configuring a maximum length of a transmission data packet, which is applied to a WIFI module end, and the device includes:
the sending module is used for sending a handshake request to a cloud server and determining whether the cloud server supports data packet length negotiation according to feedback of the cloud server;
the capturing module is used for sending data to the cloud server by using a data packet with a corresponding length according to a value of a reference data packet length configured as a variable in each handshake interaction process with the cloud server after determining that the cloud server supports data packet length negotiation, and capturing the maximum length of the data packet transmitted by the cloud server;
the adjusting module is used for adjusting the value of the length of the reference data packet until the handshake process is finished when the adjusting condition is met according to the comparison result of the maximum length and the value of the length of the current reference data packet;
and the handshake module is used for performing handshake and data packet downloading with the OTA server by using the preset value of the maximum standard data packet length when receiving the OTA upgrading instruction of the cloud server.
In a fourth aspect, the present application provides an apparatus for configuring a maximum length of a transmission data packet, which is applied to a cloud server, and the apparatus includes:
the receiving module is used for receiving the handshake request sent by the WIFI module end, determining whether a data packet length negotiation result is supported or not and feeding back the result to the WIFI module;
and the transmission module is used for determining the length of the data packet transmitted in the handshaking process according to the value of the length of the reference data packet adopted by the WIFI module end for sending data last time in the handshaking interaction process of the cloud server end at each time when the negotiation of the length of the data packet is supported, and transmitting the data to the WIFI module by using the determined length of the data packet.
In a fifth aspect, the present application provides a WIFI module device, the device includes:
a memory to store instructions;
a processor for reading instructions in the memory is capable of performing the method as in the first aspect above.
In a sixth aspect, the present application provides a cloud service device, including:
a memory to store instructions;
a processor for reading the instructions in the memory is capable of performing the method as in the second aspect above.
In a seventh aspect, the present application provides a computer storage medium storing a computer program for causing a computer to perform the method of the first or second aspect.
The application provides a method and equipment for configuring the maximum length of a transmission data packet, the value of the length of the fixed maximum transmission data packet is set to be a variable, the maximum transmission data packet length when a WIFI module is in handshake with a cloud service end and an OTA service end can be set respectively, when the WIFI module is connected with the cloud service end, handshake failure caused by insufficient memory can be avoided, and when the WIFI module is in handshake with the OTA service end, the value of a small maximum fragment before use can not appear, so that a complete data packet can not be received, and upgrade failure is caused.
Drawings
Fig. 1 is a diagram illustrating an application scenario of a method for configuring a maximum length of a transmission data packet according to an exemplary embodiment of the present invention;
fig. 2 is a diagram illustrating an application scenario of another method for configuring maximum length of a transmission data packet according to an exemplary embodiment of the present invention;
fig. 3 is a flowchart illustrating an exemplary WIFI module accessing a cloud server according to an exemplary embodiment of the present invention;
fig. 4 is a specific flowchart illustrating an exemplary method for accessing a WIFI module to a cloud server according to an exemplary embodiment of the present invention;
fig. 5 is a detailed flowchart illustrating an exemplary WIFI module accessing an OTA server according to an exemplary embodiment of the present invention;
fig. 6 is a flowchart illustrating an exemplary method for configuring maximum length of a transmitted data packet according to an exemplary embodiment of the present invention;
fig. 7 is a flowchart illustrating OTA firmware upgrade of a WIFI module according to an exemplary embodiment of the present invention;
fig. 8 is a schematic diagram illustrating an incremental determination procedure for configuring a maximum length of a transmitted data packet according to an exemplary embodiment of the present invention;
fig. 9 is a flowchart illustrating an exemplary method for configuring a maximum length of a transmission data packet by an OTA service end according to an exemplary embodiment of the present invention;
fig. 10 is a schematic detailed flowchart illustrating a method for configuring a maximum length of a transmission data packet by a cloud server according to an exemplary embodiment of the present invention;
fig. 11 is a schematic diagram illustrating an incremental flow of a method for configuring a maximum length of a transmission data packet by a cloud server according to an exemplary embodiment of the present invention;
fig. 12 is a schematic diagram illustrating a flow of determining that a length of a data packet is insufficient according to a method for configuring a maximum length of a data packet for transmission by a cloud server according to an exemplary embodiment of the present invention;
fig. 13 is a schematic view illustrating a handshake flow between a WIFI module and a cloud server according to an exemplary embodiment of the present invention;
fig. 14 is a schematic flowchart illustrating an exemplary method for configuring a maximum length of a transmission packet by an OTA service end according to an exemplary embodiment of the present invention;
fig. 15 is a schematic diagram illustrating a handshake flow between a WIFI module and an OTA server according to an exemplary embodiment of the present invention;
fig. 16 is a flowchart illustrating another exemplary method for configuring maximum length of transmitted data packets according to an exemplary embodiment of the present invention;
fig. 17 is a diagram illustrating an apparatus for configuring maximum length of transmission packets according to an exemplary embodiment of the present invention;
fig. 18 is a schematic diagram of another apparatus for configuring maximum length of transmitted data packets, according to an example embodiment of the present invention;
fig. 19 is a schematic structural diagram of a WIFI module apparatus according to an example embodiment of the present invention;
fig. 20 is a schematic structural diagram of a cloud service device according to an example embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present application will be described in detail and clearly with reference to the accompanying drawings. It is to be understood that the embodiments described are only a few embodiments of the present invention, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
In a possible implementation manner, the method for configuring the maximum length of the transmission data packet provided in the embodiment of the present application may be applied to a scenario in which a handshake is performed with a cloud server, that is, a secure communication is established with the cloud server, as shown in fig. 1, the method includes: the cloud server 101, the database 102, at least one wireless module, (the wireless module 103_1, the wireless module 103_2, and the wireless module 103_ N in the example in the figure). The wireless module end performs data interaction with the cloud server 101, and the database 102 stores data and programs required by the cloud server 101 for executing the method for configuring the maximum length of the transmission data packet.
In a possible implementation manner, a method for configuring a maximum length of a transmission data packet provided by an embodiment of the present application may be applied to a scenario in which a handshake is performed with an over-the-air OTA service end, that is, a secure communication is established with the OTA service end, as shown in fig. 2, including: the cloud server 101, the over-the-air server 201, the database 202, and at least one wireless module (the wireless module 203_1, the wireless module 203_2, and the wireless module 203_ N in the figure are illustrated). The cloud service end 101 sends an instruction for executing the OTA upgrade to the wireless module, the wireless module end performs data interaction with the OTA service end 201, and the database 202 stores data and programs required by the OTA service end 201 for executing the method for configuring the maximum length of the transmission data packet.
Before the WIFI module and the cloud server handshake, some files or parameters need to be configured in advance, and the process is as shown in fig. 3:
s301: acquiring router information in a Bluetooth or wireless network distribution mode;
s302: the wireless module is connected with the upper distribution network router;
s303: connecting an encryption cloud server, and establishing and initializing a wireless module encryption protocol network file descriptor;
s304: the wireless module acquires a domain name and a 433 port access server through a distribution network;
s305: initializing a wireless module end encryption protocol context and configuring parameters;
s306: and the wireless module and the cloud server perform handshake operation.
For the prior art, the specific implementation flow of handshake is shown in fig. 4:
s401: creating and initializing a network context, and only using a file descriptor fd at present;
s402: splicing a complete domain name through distribution network information, initializing the domain name and a 433 port, and connecting a terminal control program to obtain a file description valid character;
s403: the encryption protocol TLS/SSL context is initialized in preparation for a subsequent call to write configuration function (mbedtls _ SSL _ setup ()) to write configuration parameters, or to release memory use function (mbedtls _ SSL _ free ()) to clear the memory used by TLS/SSL.
S404: initializing an encryption protocol TLS/SSL configuration context, and preparing for loading a default configuration function (mbedtls _ SSL _ config _ defaults ()) for later calling to load default configuration or calling a release configuration function (mbedtls _ SSL _ config _ free ()) to release loaded configuration;
s405: configuring the overtime time of reading data from a cloud server by a wireless module by adopting the configuration of blocking input/output (I/O);
s406: a call setting function (mbedtls _ ssl _ set _ bio) configures a callback function for writing/reading/overtime reading cloud data of the wireless module, wherein the write callback function is as follows: mbedtls _ net _ send, read callback function: mbedtls _ net _ recv, the timeout read callback function is: mebedtls _ net _ recv _ timeout;
s407: loading a default value of the maximum transmission data packet length in the ssl.h file, wherein the default value is generally 16 KB;
s408: configuration certificate verification, default: NONE, at the server side, REQUIRED at the client side; configuring a random function; configuring a debugging callback function;
s409: calling a write configuration function (mbedtls _ ssl _ setup ()) to write all configuration parameters in S405-S408;
s410: the wireless module and the cloud server side perform handshake;
s411: determining whether the handshake process is successful, if so, performing S413, and if not, performing S412;
s412: releasing the description of the network file, releasing the configuration context of the encryption protocol, releasing the context of the encryption protocol, and clearing the connection memory;
s413: the wireless module is successfully accessed to the cloud server.
The mbedls _ SSL _ setup () function in S403 is used to prepare a data format of an SSL transmission packet, define different parameter values for different socket modes, and return 0 to perform handshake initialization function to indicate success, and return a character string "mbedls _ EER _ SSL _ ALLOC _ FAILED" to indicate failure to declare in the memory.
The function of mbedls _ SSL _ config _ defaults () in S404 indicates that a WIFI module accessing a cloud service is used as a client of an SSL, TLS belongs to a socket selection character string "stream" requiring connection, SSL default public parameter preset relates to authentication request mode selection, whether agreement is required, use version of the SSL, encryption component information, and the like, the function returns an identifier 0 successfully, and the return parameter "" mbedls _ EER _ XXX _ ALLOC _ FAILED "indicates that declaration in a memory fails.
In the prior art, the initialization step in the handshake process between the WIFI module and the OTA server is "initialize the packet address and 443 port issued by the cloud, the terminal control program is connected to obtain an effective file descriptor", which is different from S402 in the cloud server, and the other steps are substantially the same, as shown in fig. 5, and are not described herein again.
For the handshake process in the prior art, the value of the maximum transmission packet length in S407 is 16K, which may cause handshake failure due to too large 16K, and if the value is directly reduced, for example, the value is reduced to 10K, when the wireless module handshakes with the OTA service end, the value may be too small 10K, which may cause incomplete reception of the packet, so the embodiment of the present application provides a method for configuring the maximum length of the transmission packet, as shown in fig. 6, the method includes:
s601: and sending a handshake request to a cloud server, and determining whether the cloud server supports data packet length negotiation according to feedback of the cloud server.
After the WIFI module end sends a handshake request to the cloud server end, the WIFI module end negotiates the length of a reference data packet with the cloud server end, namely the maximum achievable length of the data packet in the process of data packet transmission between the WIFI module and the cloud server end, and the cloud server end supports negotiation service and does not support negotiation service.
And when the cloud server supports negotiation of the data packet length, sending data to the cloud server by using the data packet with the corresponding length according to the value of the data packet length determined every time by the WIFI.
In a possible implementation manner, when it is determined that the cloud server does not support the packet length negotiation service, determining a value of a maximum transmission data length preconfigured by the cloud server according to feedback of the cloud server;
and in each subsequent handshake interaction process with the cloud server, sending data to the cloud server by using the data packet with the corresponding length according to the minimum value of the length of the reference data packet configured as the variable and the value of the maximum transmission data length configured in advance by the cloud server.
The cloud service end also comprises a parameter 'value of the maximum transmission data packet length', when the cloud service end does not support negotiation of the data packet length, the cloud service end can feed back the value of the maximum transmission data packet length configured in advance to the WIFI module end, the WIFI module end can compare the value of the current standard data packet length with the value of the maximum transmission data packet length sent by the cloud service end, the minimum value of the current standard data packet length and the value of the maximum transmission data packet length sent by the cloud service end is selected, and handshake is carried out between the minimum value and the cloud service end.
S602: when the cloud server side is determined to support data packet length negotiation, in each subsequent handshake interaction process with the cloud server side, data are sent to the cloud server side by using data packets with corresponding lengths according to values of the lengths of the reference data packets configured as variables, and the maximum length of the data packets transmitted by the cloud server side is captured.
Different from the prior art S407, in the embodiment of the present application, a value of a length of a reference data packet (a maximum transmission data packet length) is configured to be a variable "len", where the value of the length of the reference data packet plays a role in a handshaking process between a WIFI module and a cloud server so that the length of a transmission data packet in the handshaking process does not exceed the reference, but before the value is determined, the length of the transmission data packet may be greater than the reference, and then the handshaking will fail, and it is necessary to re-determine the value of the length of the reference data packet and re-execute the handshaking process until the handshaking succeeds.
In one possible implementation, sending a handshake request to a cloud server includes:
acquiring an initial value of a reference data packet length configured as a variable according to the configuration indication;
and sending a handshake request to the cloud server by using the data packet with the corresponding length according to the initial value of the length of the reference data packet, and triggering and executing a handshake process.
An initial value is set for the variable "len", for example, 4KB, and specifically, the initial value can be set according to the memory size of the WIFI module, so that the initial value should not be set too small in order to avoid wasting server resources due to excessive data interaction.
When data are sent to a cloud server by using a data packet with a corresponding length according to a value of a reference data packet length configured as a variable, a maximum length function (mbedtls _ ssl _ get _ max _ record _ payload ()) for grabbing a transmission data packet is used for grabbing the maximum length of the data packet transmitted by the cloud server.
S603: and adjusting the value of the length of the reference data packet until the handshake process is finished when the adjustment condition is met according to the comparison result of the maximum length and the value of the length of the current reference data packet.
In the process of handshaking with the cloud service end, the WIFI module end sends a data packet (ssl.h header file) carrying the value of the length of the reference data packet to the cloud service end and indicates the length of the transmission data packet in the handshaking process, and when the length of the transmission data packet exceeds the reference, the handshaking fails.
In a possible implementation manner, adjusting the value of the packet length until the handshake process is finished when the adjustment condition is satisfied according to a comparison result between the maximum length and the value of the current reference packet length includes:
and when the maximum length is determined to be not less than the value of the length of the current reference data packet according to the comparison result of the maximum length and the value of the length of the current reference data packet, the value of the length of the reference data packet is increased once according to a preset step length.
In the process of determining the value of the length of the reference data packet, multiple negotiations with the cloud server and multiple handshaking processes may occur. In the process, the value of the length of the reference data packet is continuously adjusted until the handshake is successful.
S604: when receiving an OTA upgrading instruction of the cloud service terminal in the air, handshaking and data packet downloading are carried out with the OTA service terminal by using the preset value of the maximum standard data packet length.
The downloading process of the WIFI module OTA firmware is shown in fig. 7 and comprises 4 steps:
the first step is as follows: after the WIFI module is successfully connected (handshake) with the cloud server, the cloud server sends an OTA upgrading command to the WIFI module;
the second step is that: the WIFI module is disconnected with the cloud server after receiving an OTA (over the air) upgrading command sent by the cloud server;
the third step: establishing connection (handshaking) between the WIFI module and the OTA server, and sending a new firmware data packet, wherein the value of the length of the maximum reference data packet is carried in a ssl.h header file in the handshaking process, and in order to successfully handshake with the OTA server, other redundant processes (such as Bluetooth) at the WIFI module need to be closed in advance;
the fourth step: and the WIFI module downloads the new firmware package data.
After the WIFI module is successfully handshake with the cloud service end, when an OTA upgrade instruction is received, the WIFI module is handshake with the OTA service end and the downloading process of a data packet, in the process, the handshake process is similar to that of the cloud service end, the value of the length of the maximum standard number packet needs to be carried in a transmission data packet (ssl.h head file) for indicating the length of the transmission packet, and when the length of the transmission data packet is greater than the standard, the handshake or downloading of the data packet can be failed.
The embodiment of the application provides a method for configuring the maximum length of a transmission data packet, the value of the length of the fixed maximum transmission data packet is set to be a variable, the maximum transmission data packet length when a WIFI module shakes hands with a cloud service end and an OTA service end can be set respectively, when the WIFI module is connected with the cloud service end, shaking failure caused by insufficient memory can be avoided, when the WIFI module shakes hands with the OTA service end, the value of a small maximum fragment before use can not occur, and further a complete data packet can not be received, and the condition of upgrading failure is caused.
In the above S602, data is sent to the cloud server by using the data packet with the corresponding length according to the value of the length of the reference data packet configured as the variable, which may specifically be according to the following implementation manner, as shown in fig. 8:
according to the value of the length of the reference data packet configured as the variable, the data packet with the corresponding length is used for sending data to the cloud server, and the method comprises the following steps:
s801: when the incremental value of the length of the reference data packet is determined to reach the configured length threshold of the transmission data packet, in each subsequent handshake interaction process with the cloud server, sending data to the cloud server by using the data packet with the corresponding length according to the length threshold of the transmission data packet until the handshake process is finished;
s802: and when the incremental value of the length of the reference data packet is determined not to reach the configured length threshold of the transmission data packet, sending data to the cloud server by using the data packet with the corresponding length according to the value of the length of the reference data packet configured as the variable.
Firstly, handshaking is carried out by utilizing a data packet with a corresponding length according to an initial value of the length of a reference data packet and a cloud server, when the handshaking with the cloud server fails by utilizing the initial value, the initial value of the length of the reference data packet is increased by a preset step length, such as 1KB, then handshaking is carried out by utilizing the data packet with the corresponding length according to the increased value of the reference data packet, and if the handshaking is unsuccessful, the above process is executed until the handshaking is successful.
When the value of the length of the reference data packet is increased to the configured transmission data packet length threshold, for example, 8K, the data packet with the corresponding length is used for sending data to the cloud server according to the transmission data packet length threshold until the handshake process is finished, and at this time, the value of the length of the reference data packet is not increased.
The value of the preset step length and the threshold value can be specifically determined according to the performance of the WIFI module or the user requirement, and the value is not specifically limited here.
In the above S604, the handshake and the data packet download with the OTA server by using the preset value of the maximum reference data packet length may specifically be implemented by the following embodiments, as shown in fig. 9:
in a possible implementation manner, the performing handshaking and data packet downloading with the OTA server by using the value of the preset maximum reference data packet length includes:
s901: sending a handshake request to an OTA server, and determining that the OTA server supports data packet length negotiation according to the feedback of the OTA server;
s902: when determining that the OTA server supports the negotiation of the data packet length, performing handshake and data packet downloading with the OTA server by using the preset value of the maximum reference data packet length;
s903: and when determining that the OTA server does not support the negotiation of the data packet length, determining the value of the maximum transmission data length configured by the OTA server according to the feedback of the OTA server, and performing handshaking and data packet downloading with the OTA server by using the configured value of the maximum transmission data packet length.
Similar with the cloud service side, when the WIFI module shakes hands with the OTA service side and downloads the data packet, the negotiation of the length of the data packet with the OTA service side is also needed, and the OTA service side also has two conditions of supporting the negotiation service and not supporting the negotiation service.
Different from the cloud server side handshake, in this process, the WIFI module does not need to adjust the reference packet length, but sets a parameter of the maximum reference packet length (define MBEDTLS _ SSL __ MAX _ CONTENT _ LEN 16384) in the prior art as a variable according to the method provided by the embodiment of the present application (MBEDTLS _ SSL _ DYNAMICs _ MAX _ CONTENT _ LEN macro definition), so that when the WIFI module performs handshake with different server sides, it is supported to set different maximum reference packet lengths.
If the OTA server side supports the data packet length negotiation, the WIFI module determines to perform handshake and data packet downloading with the OTA server side by using a preset value of the maximum reference data packet length; and if the OTA server side does not support the data packet length negotiation, configuring a value of the maximum transmission data packet length by the OTA server side and feeding the value back to the WIFI module side, and confirming that the WIFI module uses the value of the maximum transmission data packet length to perform handshaking and data packet downloading with the OTA server side.
The specific implementation flow of the method for configuring the maximum length of the transmission data packet applied to the handshake scenario between the WIFI module and the cloud service provided in the embodiment of the present application is shown in fig. 10 to 12:
s1001: creating and initializing a network context, and only using a file descriptor fd at present;
s1002: splicing a complete domain name through distribution network information, initializing the domain name and a 433 port, and connecting a terminal control program to obtain a file description effective character;
s1003, carrying out: the encryption protocol TLS/SSL context is initialized in preparation for a subsequent call to write configuration function (mbedtls _ SSL _ setup ()) to write configuration parameters, or to release memory use function (mbedtls _ SSL _ free ()) to clear the memory used by TLS/SSL.
S1004: initializing TLS/SSL configuration context, and preparing for loading default configuration function (mbedtls _ SSL _ config _ defaults ()) for later calling to load default configuration or calling release configuration function (mbedtls _ SSL _ config _ free ()) to release loaded configuration;
s1005: setting the overtime time of the wireless module for reading data by adopting the configuration of blocking input/output (I/O);
s1006: calling a setting function (mbedtls _ ssl _ set _ bio) to configure a callback function for module writing/reading/overtime reading cloud data, wherein the writing callback function is as follows: mbedtls _ net _ send, read callback function: mbedtls _ net _ recv, the timeout read callback function is: mebedtls _ net _ recv _ timeout;
s1007: loading default encryption configuration parameters, and calling a function (MBEDTLS _ SSL _ DYNAMIC _ MAX _ CONTENT _ LEN) for adjusting the length of a maximum reference transmission data packet;
s1008: configuration certificate verification, default: NONE, at the server side, REQUIRED at the client side; configuring a random function; configuring a debugging callback function;
s1009: configuring the length of a reference data packet by calling a function for adjusting the length of the maximum reference transmission data packet;
s1010: writing all the configuration parameters into a callback function;
s1011: handshaking between the wireless module and the cloud server;
s1012: judging whether the length of the benchmark transmission data packet is insufficient or not by comparing the maximum length of the data packet transmitted by the captured cloud server with the length of the current benchmark data packet, if so, executing S1013, otherwise, executing S1014;
s1013: increasing the value of the length of the reference data packet according to a preset step length;
s1014: judging whether the handshake with the cloud server is successful, if so, determining that the cloud server is successfully accessed, otherwise, executing S1015;
s1015: releasing the description of the network file, releasing the configuration context of the encryption protocol, releasing the context of the encryption protocol, and clearing the connection memory.
The specific process of handshaking between the S1011 wireless module and the cloud server is shown in fig. 13:
1. the WIFI module end sends a hello client to the cloud server end, wherein the hello client comprises TLS/SSL version information, an encryption algorithm and a random number;
2. the cloud server feeds back a server client's server client' including TLS/SSL version information, a random number and a cloud server certificate to the WIFI module;
3. the WIFI module side checks whether the cloud server side certificate is legal or not;
4. the WIFI module end sends at least one supported encryption algorithm to the cloud server end for the server end to select;
5. the cloud server selects an encryption mode;
6. the cloud service end feeds back an encryption mode to the WIFI module end in a civilized form;
7. after receiving an encryption mode fed back by the cloud server, the WIFI module generates a random number as a symmetric encryption key, encrypts the random number by using a server public key and then sends the encrypted random number to the cloud server;
8. and after receiving the encrypted data, the cloud server decrypts the encrypted information by using the private key to obtain a symmetric encryption key, and completes handshake.
The specific implementation flow of the method for configuring the maximum length of the transmission data packet applied to the handshake scenario between the WIFI module and the OTA service provided in the embodiment of the present application is shown in fig. 14:
s1401: creating and initializing a network context, and only using a file descriptor fd at present;
s1402: initializing a data packet address and a 433 port issued by a cloud end, and connecting a terminal control program to obtain a file description valid character;
s1403: the encryption protocol TLS/SSL context is initialized in preparation for a subsequent call to write configuration function (mbedtls _ SSL _ setup ()) to write configuration parameters, or to release memory use function (mbedtls _ SSL _ free ()) to clear the memory used by TLS/SSL.
S1404: initializing TLS/SSL configuration context, and preparing for loading default configuration function (mbedtls _ SSL _ config _ defaults ()) for later calling to load default configuration, or calling release configuration function (mbedtls _ SSL _ config _ free ()) to release loaded configuration;
s1405: setting the overtime time of the wireless module for reading data by adopting the configuration of blocking input/output (I/O);
s1406: a call setting function (mbedtls _ ssl _ set _ bio) configures a callback function for the module to write/read/overtime read cloud data, wherein the write callback function is as follows: mbedtls _ net _ send, read callback function: mbedtls _ net _ recv, the timeout read callback function is: mebedtls _ net _ recv _ timeout;
s1407: loading default encryption configuration parameters and calling a function for adjusting the length of the reference transmission data packet;
s1408: configuration certificate verification, configuration random function and configuration debugging callback function;
s1409: configuring a maximum reference transmission data packet;
s1410: writing all the configuration parameters into a callback function;
s1411: handshaking between the wireless module and the OTA server;
s1412: judging whether the handshake is successful or not, if so, determining that the WIFI module is successfully accessed to the OTA server, and if not, executing S1413;
s1413: releasing the description of the network file, releasing the configuration context of the encryption protocol, releasing the context of the encryption protocol, and clearing the connection memory.
Different with the cloud service end is that, when the WIFI module is shaken hands with the OTA end, only need to utilize the biggest benchmark transmission data package length of predetermineeing to shake hands with the OTA service end and download of data package, need not right the value of biggest benchmark transmission data package length is adjusted.
Wherein the handshake process in S1411 is as shown in fig. 15:
1. the WIFI module end sends a hello client end to the OTA server end, wherein the hello client end comprises TLS/SSL version information, an encryption algorithm and a random number;
2. the OTA server feeds back a server client 'segment client' comprising TLS/SSL version information, a random number and an OTA server certificate to the WIFI module;
3. the WIFI module side checks whether the OTA server side certificate is legal or not;
4. the WIFI module end sends at least one supported encryption algorithm to the OTA server end for the server end to select;
5. the OTA server selects an encryption mode;
6. the OTA server side feeds back an encryption mode to the WIFI module side in a civilization mode;
7. after receiving the encryption mode fed back by the OTA server, the WIFI module generates a random number as a symmetric encryption key, encrypts the random number by using a server public key and then sends the encrypted random number to the OTA server;
8. and after receiving the encrypted data, the OTA server decrypts the encrypted information by using the private key to obtain a symmetric encryption key, and completes handshake.
Based on the same inventive concept, an embodiment of the present application further provides a method for configuring a maximum length of a transmission data packet, which is applied to a cloud server, and as shown in fig. 16, the method includes:
s1601: receiving a handshake request sent by a WIFI module end, determining whether a data packet length negotiation result is supported and feeding back the result to the WIFI module;
s1602: when the length negotiation of the data packet is determined to be supported, in the subsequent handshaking interaction process with the cloud server side every time, the length of the data packet transmitted in the handshaking process is determined according to the value of the length of the reference data packet adopted by the WIFI module side for transmitting data last time, and the determined length of the data packet is used for transmitting data to the WIFI module.
The negotiation and handshake process may include multiple times, and the specific method for configuring the maximum length of the transmission data packet is as described above and will not be described herein again.
Based on the same inventive concept, an embodiment of the present application provides an apparatus for configuring a maximum length of a transmission data packet, as shown in fig. 17, where the apparatus is applied to a WIFI module, and the apparatus 1700 includes:
a sending module 1701, configured to send a handshake request to a cloud server, and determine whether the cloud server supports packet length negotiation according to feedback of the cloud server;
a capture module 1702, configured to, when it is determined that the cloud server supports data packet length negotiation, send data to the cloud server by using a data packet with a corresponding length according to a value of a length of a reference data packet configured as a variable in each handshake interaction process with the cloud server, and capture a maximum length of the data packet transmitted by the cloud server;
an adjusting module 1703, configured to adjust, according to a comparison result between the maximum length and a value of the current reference packet length, the value of the reference packet length until the handshake process is ended when an adjustment condition is satisfied;
and a handshake module 1704, configured to perform handshake and data packet download with the OTA server by using a preset value of the maximum reference data packet length when receiving an OTA upgrade over-the-air instruction of the cloud server.
In a possible implementation manner, the sending module is configured to send a handshake request to a cloud server, and includes:
acquiring an initial value of a reference data packet length configured as a variable according to the configuration instruction;
and sending a handshake request to the cloud server by using the data packet with the corresponding length according to the initial value of the length of the reference data packet, and triggering and executing a handshake process.
In one possible embodiment, the handshake module is configured to:
when the cloud server side is determined not to support the data packet length negotiation service, determining a value of a maximum transmission data length preset by the cloud server side according to feedback of the cloud server side;
and in each subsequent handshake interaction process with the cloud server, sending data to the cloud server by using the data packet with the corresponding length according to the minimum value of the length of the reference data packet configured as the variable and the value of the maximum transmission data length configured in advance by the cloud server.
In a possible implementation manner, the adjusting module is configured to adjust the value of the packet length until the handshake process is finished when an adjustment condition is satisfied according to a comparison result between the maximum length and the value of the current reference packet length, and includes:
and when the maximum length is determined to be not less than the value of the length of the current reference data packet according to the comparison result of the maximum length and the value of the length of the current reference data packet, the value of the length of the reference data packet is increased once according to a preset step length.
In a possible implementation manner, the fetching module is configured to send data to the cloud server by using a data packet with a corresponding length according to a value of a length of a reference data packet configured as a variable, and includes:
when the incremental value of the length of the reference data packet is determined to reach the configured length threshold of the transmission data packet, in each subsequent handshake interaction process with the cloud server, sending data to the cloud server by using the data packet with the corresponding length according to the length threshold of the transmission data packet until the handshake process is finished;
and when the incremental value of the length of the reference data packet is determined not to reach the configured length threshold of the transmission data packet, sending data to the cloud server by using the data packet with the corresponding length according to the value of the length of the reference data packet configured as the variable.
In a possible implementation manner, the handshake module is configured to perform handshake and data packet download with the OTA server by using a value of a preset maximum reference data packet length, and includes:
sending a handshake request to an OTA server, and determining that the OTA server supports data packet length negotiation according to the feedback of the OTA server;
when determining that the OTA server supports the negotiation of the data packet length, performing handshake and data packet downloading with the OTA server by using the preset value of the maximum reference data packet length;
and when determining that the OTA server does not support the negotiation of the data packet length, determining the value of the maximum transmission data length configured by the OTA server according to the feedback of the OTA server, and performing handshaking and data packet downloading with the OTA server by using the configured value of the maximum transmission data packet length.
Based on the same inventive concept, an embodiment of the present application provides an apparatus for configuring a maximum length of a transmission data packet, as shown in fig. 18, and the apparatus 1800 is applied to a cloud server, and includes:
a receiving module 1801, configured to receive a handshake request sent by a WIFI module, determine whether a result of packet length negotiation is supported and feed back the result to the WIFI module;
the transmission module 1802 is configured to determine, when it is determined that data packet length negotiation is supported, a length of a data packet transmitted in the current handshake process according to a value of a reference data packet length used by the WIFI module end to transmit data last time in each handshake interaction process with the cloud server end, and transmit data to the WIFI module by using the determined length of the data packet.
Based on the same inventive concept, the embodiment of the present application further provides a WIFI module device, as shown in fig. 19, the device includes a processor 1901, a memory 1902, a communication interface 1903, and a bus 1904. The processor 1901, the memory 1902, and the communication interface 1903 are interconnected via a bus 1904.
The processor 1901 is configured to read and execute the instructions in the memory 1902, so that the at least one processor can execute the method for configuring the maximum length of the transmission data packet applied to the WIFI module device provided in the foregoing embodiments.
The memory 1902 is used for storing various instructions and programs for configuring the maximum length of the transmission data packet provided in the above embodiments.
The bus 1904 may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown in FIG. 19, but it is not intended that there be only one bus or one type of bus.
The processor 1901 may be a Central Processing Unit (CPU), a Network Processor (NP), a Graphics Processing Unit (GPU), or any combination of CPU, NP, and GPU. But also a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof. The PLD may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), a General Array Logic (GAL), or any combination thereof.
Based on the same inventive concept, an embodiment of the present application further provides a cloud service device, as shown in fig. 20, the device includes:
a memory to store instructions;
a processor for reading the instructions in the memory, performing the following processes:
receiving a handshake request sent by a WIFI module end, determining whether a data packet length negotiation result is supported and feeding back the result to the WIFI module;
when the length negotiation of the data packet is determined to be supported, in the subsequent handshaking interaction process with the cloud server side every time, the length of the data packet transmitted in the handshaking process is determined according to the value of the length of the reference data packet adopted by the WIFI module side for transmitting data last time, and the determined length of the data packet is used for transmitting data to the WIFI module.
The cloud service apparatus 130 according to this embodiment of the present application is described below with reference to fig. 20. The cloud service apparatus 130 shown in fig. 20 is only an example, and should not bring any limitation to the functions and the use range of the embodiment of the present application.
As shown in fig. 20, the cloud service apparatus 130 is represented in the form of a general electronic apparatus. Components of cloud services device 130 may include, but are not limited to: the at least one processor 131, the at least one memory 132, and a bus 133 that connects the various system components (including the memory 132 and the processor 131).
The processor 131 is configured to read and execute the instructions in the memory 132, so that the at least one processor can execute a method for configuring the maximum length of the transmission data packet according to the above embodiment.
Bus 133 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a processor, or a local bus using any of a variety of bus architectures.
The memory 132 may include readable media in the form of volatile memory, such as Random Access Memory (RAM)1321 and/or cache memory 1322, and may further include Read Only Memory (ROM) 1323.
Memory 132 may also include a program/utility 1325 having a set (at least one) of program modules 1324, such program modules 1324 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.
Cloud services device 130 may also communicate with one or more external devices 134 (e.g., keyboard, pointing device, etc.), with one or more devices that enable a user to interact with cloud services device 130, and/or with any devices (e.g., router, modem, etc.) that enable cloud services device 130 to communicate with one or more other electronic devices. Such communication may occur via input/output (I/O) interfaces 135. And cloud services device 130 may also communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the internet) via network adapter 136. As shown, network adapter 136 communicates with other modules for cloud services device 130 over bus 133. It should be understood that although not shown in the figures, other hardware and/or software modules may be used in conjunction with cloud services device 130, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.
In some possible embodiments, the aspects of the method for configuring the maximum length of the transmitted data packet provided by the present application may also be implemented in the form of a program product including program code for causing a computer device to perform the steps of a method for configuring the maximum length of the transmitted data packet according to various exemplary embodiments of the present application described above in this specification when the program product is run on the computer device.
Additionally, the present application provides a computer-readable storage medium that may include readable media in the form of volatile memory, such as Random Access Memory (RAM)1321 and/or cache memory 1322, and may further include Read Only Memory (ROM) 1323.
Memory 132 may also include a program/utility 1325 having a set (at least one) of program modules 1324, such program modules 1324 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.
The computer storage medium stores a computer program for causing a computer to execute the method of any one of the above embodiments.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
While the preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all alterations and modifications as fall within the scope of the application.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.

Claims (10)

1. A method for configuring the maximum length of a transmission data packet is applied to wireless WIFI module equipment, and the method comprises the following steps:
sending a handshake request to a cloud server, and determining whether the cloud server supports data packet length negotiation according to feedback of the cloud server;
when the cloud server side supports data packet length negotiation, in each handshake interaction process with the cloud server side, sending data to the cloud server side by using data packets with corresponding lengths according to values of the lengths of the reference data packets configured as variables, and capturing the maximum length of the data packets transmitted by the cloud server side;
according to the comparison result of the maximum length and the value of the current reference data packet length, when the adjustment condition is met, the value of the reference data packet length is adjusted until the handshake process is finished;
when receiving an OTA upgrading instruction of the cloud service terminal in the air, handshaking and data packet downloading are carried out with the OTA service terminal by using the preset value of the maximum standard data packet length.
2. The method of claim 1, wherein sending a handshake request to a cloud server comprises:
acquiring an initial value of a reference data packet length configured as a variable according to the configuration instruction;
and sending a handshake request to the cloud server by using the data packet with the corresponding length according to the initial value of the length of the reference data packet, and triggering and executing a handshake process.
3. The method of claim 1, further comprising:
when the cloud server side is determined not to support the data packet length negotiation service, determining a value of a maximum transmission data length preset by the cloud server side according to feedback of the cloud server side;
and in each subsequent handshake interaction process with the cloud server, sending data to the cloud server by using the data packet with the corresponding length according to the minimum value of the length of the reference data packet configured as the variable and the value of the maximum transmission data length configured in advance by the cloud server.
4. The method of claim 1, wherein adjusting the value of the packet length until the handshake process is completed when an adjustment condition is satisfied according to a comparison result between the maximum length and the value of the current reference packet length comprises:
and when the maximum length is determined to be not less than the value of the length of the current reference data packet according to the comparison result of the maximum length and the value of the length of the current reference data packet, the value of the length of the reference data packet is increased once according to a preset step length.
5. The method of claim 4, wherein sending data to the cloud server by using a data packet with a corresponding length according to a value of a length of a reference data packet configured as a variable comprises:
when the incremental value of the length of the reference data packet is determined to reach the configured length threshold of the transmission data packet, in each subsequent handshake interaction process with the cloud server, sending data to the cloud server by using the data packet with the corresponding length according to the length threshold of the transmission data packet until the handshake process is finished;
and when the incremental value of the length of the reference data packet is determined not to reach the configured length threshold of the transmission data packet, sending data to the cloud server by using the data packet with the corresponding length according to the value of the length of the reference data packet configured as the variable.
6. The method of claim 1, wherein the performing handshaking and packet downloading with the OTA server using the preset value of the maximum reference packet length comprises:
sending a handshake request to an OTA server, and determining that the OTA server supports data packet length negotiation according to the feedback of the OTA server;
when the OTA server side is determined to support the data packet length negotiation, performing handshake and data packet downloading with the OTA server side by using a preset value of the maximum reference data packet length;
and when determining that the OTA server does not support the negotiation of the data packet length, determining the value of the maximum transmission data length configured by the OTA server according to the feedback of the OTA server, and performing handshaking and data packet downloading with the OTA server by using the configured value of the maximum transmission data packet length.
7. A method for configuring the maximum length of a transmission data packet is applied to a cloud service device, and the method comprises the following steps:
receiving a handshake request sent by a WIFI module end, determining whether a data packet length negotiation result is supported and feeding back the result to the WIFI module;
when the length negotiation of the data packet is determined to be supported, in the subsequent handshaking interaction process with the cloud server side every time, the length of the data packet transmitted in the handshaking process is determined according to the value of the length of the reference data packet adopted by the WIFI module side for transmitting data last time, and the determined length of the data packet is used for transmitting data to the WIFI module.
8. The utility model provides a WIFI module equipment which characterized in that, equipment includes:
a memory to store instructions;
a processor for reading instructions in said memory to perform the method of any of claims 1-6.
9. A cloud service apparatus, characterized in that the apparatus comprises:
a memory to store instructions;
a processor for reading the instructions in the memory, performing the following processes:
receiving a handshake request sent by a WIFI module end, determining whether a data packet length negotiation result is supported and feeding back the result to the WIFI module;
when the length negotiation of the data packet is determined to be supported, in the subsequent handshaking interaction process with the cloud server side every time, the length of the data packet transmitted in the handshaking process is determined according to the value of the length of the reference data packet adopted by the WIFI module side for transmitting data last time, and the determined length of the data packet is used for transmitting data to the WIFI module.
10. A computer storage medium, characterized in that the computer storage medium stores a computer program for causing a computer to perform the method of any one of claims 1-6 or to perform the method of claim 7.
CN202210615778.8A 2022-05-31 2022-05-31 Method and equipment for configuring maximum length of transmission data packet Active CN115022252B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210615778.8A CN115022252B (en) 2022-05-31 2022-05-31 Method and equipment for configuring maximum length of transmission data packet

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210615778.8A CN115022252B (en) 2022-05-31 2022-05-31 Method and equipment for configuring maximum length of transmission data packet

Publications (2)

Publication Number Publication Date
CN115022252A true CN115022252A (en) 2022-09-06
CN115022252B CN115022252B (en) 2024-04-09

Family

ID=83071154

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210615778.8A Active CN115022252B (en) 2022-05-31 2022-05-31 Method and equipment for configuring maximum length of transmission data packet

Country Status (1)

Country Link
CN (1) CN115022252B (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117992091A (en) * 2024-04-02 2024-05-07 深圳朗田亩半导体科技有限公司 Firmware upgrading method and system based on file feature description

Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050149718A1 (en) * 2003-12-24 2005-07-07 Berlin Volker J. Translation of secure communications for handshake protocols
CN1863165A (en) * 2006-01-24 2006-11-15 华为技术有限公司 Method for reducing data IP fragmentation quantity in PS network
US20070171828A1 (en) * 2006-01-23 2007-07-26 Mitesh Dalal Method of determining a maximum transmission unit value of a network path using transport layer feedback
US20080101382A1 (en) * 2006-10-26 2008-05-01 Bannerjee Dwip N Efficient method for discovering path mtu for tcp connections
US20090245224A1 (en) * 2008-03-31 2009-10-01 Lockheed Martin Corporation Method and apparatus for providing quality of service in wireless networks and sensor networks
US20100272030A1 (en) * 2009-04-27 2010-10-28 Uppinder Singh Babbar System and method for optimally transferring data traffic on networks
CN101924689A (en) * 2009-06-16 2010-12-22 中兴通讯股份有限公司 Negotiation method of maximum segmentation parameters and network forwarding equipment
US20140245453A1 (en) * 2013-02-28 2014-08-28 Motorola Solutions, Inc. Method and apparatus for transmitting a user datagram protocol message that is larger than a defined size
US20150312384A1 (en) * 2014-04-25 2015-10-29 Cisco Technology, Inc. Managing sequence values with added headers in computing devices
CN105429910A (en) * 2015-11-06 2016-03-23 京信通信技术(广州)有限公司 Message transmission and processing method and device
CN106605371A (en) * 2015-05-26 2017-04-26 华为技术有限公司 Method, device, and system for adjusting packet length in near field communication (NFC)
CN106789717A (en) * 2016-12-26 2017-05-31 广东欧珀移动通信有限公司 Dynamic adjusts method, device and the terminal of the MTU of communication protocol data message transmission
US20170201544A1 (en) * 2016-01-12 2017-07-13 Hangzhou Dptech Technologies Co., Ltd. Tcp bypass interdiction method and device
CN110149374A (en) * 2019-04-28 2019-08-20 深圳市恒扬数据股份有限公司 A kind of document transmission method, terminal device and computer readable storage medium
CN111163037A (en) * 2018-11-07 2020-05-15 大唐移动通信设备有限公司 IP fragmentation optimization method and device
CN111314237A (en) * 2020-01-17 2020-06-19 深信服科技股份有限公司 Method, device and equipment for adjusting data packet transmission rate and readable storage medium
CN111654450A (en) * 2020-05-28 2020-09-11 北京小米移动软件有限公司 Data transmission method and device and storage medium
CN111800488A (en) * 2020-06-23 2020-10-20 翱捷科技股份有限公司 Data transmission method and system based on UDP (user Datagram protocol) and IPV6 (Internet protocol video protocol) protocols
CN114007209A (en) * 2021-10-28 2022-02-01 歌尔光学科技有限公司 BLE-based data transmission method and device and BLE master equipment
CN114039933A (en) * 2021-10-28 2022-02-11 山东浪潮科学研究院有限公司 IP transmission method, device, equipment and product of 5G network link

Patent Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050149718A1 (en) * 2003-12-24 2005-07-07 Berlin Volker J. Translation of secure communications for handshake protocols
US20070171828A1 (en) * 2006-01-23 2007-07-26 Mitesh Dalal Method of determining a maximum transmission unit value of a network path using transport layer feedback
CN1863165A (en) * 2006-01-24 2006-11-15 华为技术有限公司 Method for reducing data IP fragmentation quantity in PS network
US20080101382A1 (en) * 2006-10-26 2008-05-01 Bannerjee Dwip N Efficient method for discovering path mtu for tcp connections
US20090245224A1 (en) * 2008-03-31 2009-10-01 Lockheed Martin Corporation Method and apparatus for providing quality of service in wireless networks and sensor networks
US20100272030A1 (en) * 2009-04-27 2010-10-28 Uppinder Singh Babbar System and method for optimally transferring data traffic on networks
CN101924689A (en) * 2009-06-16 2010-12-22 中兴通讯股份有限公司 Negotiation method of maximum segmentation parameters and network forwarding equipment
US20140245453A1 (en) * 2013-02-28 2014-08-28 Motorola Solutions, Inc. Method and apparatus for transmitting a user datagram protocol message that is larger than a defined size
US20150312384A1 (en) * 2014-04-25 2015-10-29 Cisco Technology, Inc. Managing sequence values with added headers in computing devices
CN106605371A (en) * 2015-05-26 2017-04-26 华为技术有限公司 Method, device, and system for adjusting packet length in near field communication (NFC)
CN105429910A (en) * 2015-11-06 2016-03-23 京信通信技术(广州)有限公司 Message transmission and processing method and device
US20170201544A1 (en) * 2016-01-12 2017-07-13 Hangzhou Dptech Technologies Co., Ltd. Tcp bypass interdiction method and device
CN106789717A (en) * 2016-12-26 2017-05-31 广东欧珀移动通信有限公司 Dynamic adjusts method, device and the terminal of the MTU of communication protocol data message transmission
CN111163037A (en) * 2018-11-07 2020-05-15 大唐移动通信设备有限公司 IP fragmentation optimization method and device
CN110149374A (en) * 2019-04-28 2019-08-20 深圳市恒扬数据股份有限公司 A kind of document transmission method, terminal device and computer readable storage medium
CN111314237A (en) * 2020-01-17 2020-06-19 深信服科技股份有限公司 Method, device and equipment for adjusting data packet transmission rate and readable storage medium
CN111654450A (en) * 2020-05-28 2020-09-11 北京小米移动软件有限公司 Data transmission method and device and storage medium
CN111800488A (en) * 2020-06-23 2020-10-20 翱捷科技股份有限公司 Data transmission method and system based on UDP (user Datagram protocol) and IPV6 (Internet protocol video protocol) protocols
CN114007209A (en) * 2021-10-28 2022-02-01 歌尔光学科技有限公司 BLE-based data transmission method and device and BLE master equipment
CN114039933A (en) * 2021-10-28 2022-02-11 山东浪潮科学研究院有限公司 IP transmission method, device, equipment and product of 5G network link

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117992091A (en) * 2024-04-02 2024-05-07 深圳朗田亩半导体科技有限公司 Firmware upgrading method and system based on file feature description
CN117992091B (en) * 2024-04-02 2024-06-07 深圳朗田亩半导体科技有限公司 Firmware upgrading method and system based on file feature description

Also Published As

Publication number Publication date
CN115022252B (en) 2024-04-09

Similar Documents

Publication Publication Date Title
CN104994073B (en) Mobile phone terminal, server and its account number and apparatus bound control execute method
CN102378965B (en) Method and apparatus for sharing resources via an interprocess communication
US10645172B1 (en) Socket tunneling connections in a service provider environment
CN107342933B (en) Activation and binding method and device for intelligent equipment
US20210126919A1 (en) System and method to securely execute datacenter management operations remotely
CN107861760A (en) BIOS collocation method, terminal and server
CN105100052A (en) Server, mobile phone terminal and account and equipment binding execution and control methods thereof
CN109561054B (en) Data transmission method, controller and access device
CN108924219B (en) Method, device and system for remotely operating terminal
KR20100075605A (en) A method for accessing a portable device, corresponding portable device, host device and system
CN112187921B (en) Object file downloading method, device, system, server and storage medium
CN113438314B (en) Equipment control method and device, storage medium and electronic device
US20150304279A1 (en) Peripheral Interface for Residential laaS
CN115022252A (en) Method and equipment for configuring maximum length of transmission data packet
CN103987064A (en) Access point (AP) upgrading method and device
CN116760822A (en) Method, system and device for transmitting files of Internet of things equipment
EP2445171B1 (en) File transfer protocol client and implementing method thereof
CN104570967B (en) Long-range control method and system based on android system
CN106331051A (en) File transmission method and system, file receiving device and file transmission device
CN115297098A (en) Edge service acquisition method and device, edge computing system, medium and equipment
US8499023B1 (en) Servlet-based grid computing environment using grid engines and switches to manage resources
CN114827249A (en) Method and device for extending grid agent
WO2022220881A1 (en) Generating a software application
CN102325187A (en) System and method for integrating multiple function services
CN106921908B (en) Bluetooth sound box implementation method and system

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
CB02 Change of applicant information
CB02 Change of applicant information

Country or region after: China

Address after: 266071 Shandong city of Qingdao province Jiangxi City Road No. 11

Applicant after: Qingdao Hisense Mobile Communication Technology Co.,Ltd.

Address before: 266071 Shandong city of Qingdao province Jiangxi City Road No. 11

Applicant before: HISENSE MOBILE COMMUNICATIONS TECHNOLOGY Co.,Ltd.

Country or region before: China

CB02 Change of applicant information
CB02 Change of applicant information

Country or region after: China

Address after: 266100 No. 151, Zhuzhou Road, Laoshan District, Shandong, Qingdao

Applicant after: HISENSE MOBILE COMMUNICATIONS TECHNOLOGY Co.,Ltd.

Address before: 266071 Shandong city of Qingdao province Jiangxi City Road No. 11

Applicant before: HISENSE MOBILE COMMUNICATIONS TECHNOLOGY Co.,Ltd.

Country or region before: China

CB02 Change of applicant information
CB02 Change of applicant information

Country or region after: China

Address after: 266100 No. 151, Zhuzhou Road, Laoshan District, Shandong, Qingdao

Applicant after: Qingdao Hisense Mobile Communication Technology Co.,Ltd.

Address before: 266100 No. 151, Zhuzhou Road, Laoshan District, Shandong, Qingdao

Applicant before: HISENSE MOBILE COMMUNICATIONS TECHNOLOGY Co.,Ltd.

Country or region before: China

GR01 Patent grant
GR01 Patent grant