CN102685203B - The method and apparatus of transmitting data resources - Google Patents

Abstract

Embodiments of the present invention provide a method and device for data resource transmission in an Internet of Things system. In the Internet of Things system, the method for transmitting data resources of a node through fragmentation based on a lightweight application layer protocol includes: obtaining the data resource capacity information of the node, where the resource capacity information is the size of the data capacity to be transmitted; option request message, wherein the first fragmentation option includes a recommended fragmentation capacity; the receiving node carries a response message of the second fragmentation option, wherein the second fragmentation option includes a determined fragmentation capacity; according to the determined fragmentation capacity and The data resource capacity information of the node, and the data resource of the node is transmitted in fragments. According to the embodiment of the present invention, the capacity information of the data resource of the node to be transmitted can be obtained, and the fragment capacity used for data transmission can be determined through fragment capacity negotiation, thereby reducing the error rate during the transmission process, and concurrently transfer data.

Description

Method and device for data resource transmission

technical field

The embodiments of the present invention relate to the field of network communication, and more specifically, to a method and device for data resource transmission.

Background technique

The lightweight application layer protocol (Constrained Application Protocol, referred to as "CoAP") is mainly used in IoT (Machine to Machine, referred to as "M2M") scenarios, such as: home controllers, building automation, smart energy, sensor networks Wait. In such an environment, the functions of these machines are relatively simple. Generally, the processor has only 8 bits, the storage space is small, it does not support complex transmission protocols, and the data transmission rate is also low. CoAP provides a request/response interaction model that supports embedded resource discovery, including key web page concepts such as Uniform Resource Identifiers (URIs) and content types. CoAP can be easily translated to Hypertext Link Protocol (HTTP) for integration into networks. The traditional solution for data transmission based on CoAP does not calculate the exact capacity of data resources, and cannot evaluate the exact number of subcontracts. Therefore, data resources cannot be obtained concurrently, resulting in low transmission efficiency.

Contents of the invention

Embodiments of the present invention provide a data resource transmission method and device, which can support the improvement of transmission efficiency in CoAP.

In the embodiment of the present invention, a method for improving transmission efficiency based on a lightweight application layer protocol in the Internet of Things system is proposed, and the data resources of the nodes can be transmitted through fragmentation, including: obtaining the data resource capacity information of the nodes , the resource capacity information is the size of the data capacity to be transmitted; send a request message carrying the first fragmentation option to the node, where the first fragmentation option includes the recommended fragmentation capacity; receive a response message from the node carrying the second fragmentation option, where The second fragmentation option includes a determined fragmentation capacity, and the determined fragmentation capacity is less than or equal to the recommended fragmentation capacity; according to the determined fragmentation capacity and the data resource capacity information of the node, the data resource of the transmission node is fragmented.

In an embodiment of the present invention, a method for transmitting data resources of a node through fragmentation based on a lightweight application layer protocol in an Internet of Things system is provided, and a request message carrying a first fragmentation option is received, wherein the first fragmentation The options include the recommended fragmentation capacity; send a response message carrying the second fragmentation option, where the second fragmentation option includes the determined fragmentation capacity, and the determined fragmentation capacity is less than or equal to the recommended fragmentation capacity; according to the determined fragmentation Capacity, the data resource of the transmission node.

In an embodiment of the present invention, a client device for transmitting data resources of a node through fragmentation based on a lightweight application layer protocol in an Internet of Things system is provided. The client device includes: an acquisition unit for acquiring data of a node Resource capacity information; a sending unit, configured to send a request message carrying a first fragmentation option, wherein the first fragmentation option includes a recommended fragmentation capacity, and a receiving unit, receiving a response message carrying a second fragmentation option, wherein the second Fragmentation options include determined fragmentation capacity, the determined fragmentation capacity is less than or equal to the recommended fragmentation capacity; the transmission unit is used to transmit the data resource of the node in fragments according to the determined fragmentation capacity and the data resource capacity information of the node.

In an embodiment of the present invention, a server device for transmitting data resources of a node through fragmentation based on a lightweight application layer protocol in an Internet of Things system is provided. The server device includes: a receiving unit, configured to receive option request message, wherein the first fragmentation option includes a recommended fragmentation capacity, and the sending unit is configured to send a response message carrying a second fragmentation option, wherein the second fragmentation option includes a determined fragmentation capacity, and a determined fragmentation The slice capacity is less than or equal to the recommended slice capacity; the transmission unit is used to transmit the data resource of the node according to the determined slice capacity.

According to the embodiment of the present invention, the capacity information of the data resource of the node to be transmitted can be known, and the fragment capacity used for data transmission can be determined through fragment capacity negotiation, thereby reducing the error rate during the transmission process, and concurrently transfer data.

Description of drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following will briefly introduce the accompanying drawings that need to be used in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only some of the present invention. Embodiments, for those of ordinary skill in the art, other drawings can also be obtained according to these drawings without paying creative labor. In the attached picture:

FIG. 1 is a flowchart of a method for transmitting data according to an embodiment of the present invention;

Fig. 2 is a flow chart of a specific implementation process of a gateway acquiring data resources from a sensor in an embodiment of the present invention;

Fig. 3 is a structural diagram of an improved fragmentation option in an embodiment of the present invention;

FIG. 4 is a flow chart of a specific implementation process of a gateway obtaining data resources from a sensor in an alternative embodiment of the present invention;

Fig. 5 is a structural diagram of an improved fragmentation option in an alternative embodiment of the present invention;

FIG. 6 is a flow chart of a specific implementation process for a gateway in an alternative embodiment of the present invention to obtain data resources from sensors;

Figure 7 is a structural diagram of an improved fragmentation option in an alternative embodiment of the present invention;

Fig. 8 is a flow chart of a specific implementation process of a gateway sending data resources to a sensor according to an embodiment of the present invention;

Figure 9 is a block diagram of a client device according to an embodiment of the present invention;

Fig. 10 is a block diagram of a server device according to an embodiment of the present invention;

FIG. 11 is a flowchart of a method for transmitting data according to an embodiment of the present invention;

Fig. 12 is a structural diagram of a client device for transmitting data according to an embodiment of the present invention;

Fig. 13 is a structural diagram of a server device for transmitting data according to an embodiment of the present invention.

detailed description

The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some of the embodiments of the present invention, but not all of them. Based on the embodiments of the present invention, all other embodiments obtained by persons of ordinary skill in the art without creative efforts fall within the protection scope of the present invention.

CoAP is based on User Datagram Protocol (User Datagram Protocol, referred to as "UDP") for transmission, and is based on a connectionless message processing mode. Its interaction mode can be a synchronous response or an asynchronous response. The message type may be: a message requiring confirmation (Confirmable), a message not requiring confirmation (Non-confirmable), an confirmation message (Acknowledgment), and a reset message (Reset). A pair of request and response can be associated by a message ID (Message ID).

There are four methods supported by CoAP: obtaining resources (Get), updating resources (Put), creating resources (Post) and deleting resources (Delete). A resource is identified by a Representational State Transfer ("REST") URI. We usually refer to the resource owner as a node or server, including but not limited to sensors, controllers, endpoints (End-point), etc., and the resource requesting party as a client, including but not limited to gateways (Proxy), network side devices.

The CoAP protocol supports different options (Option) to explain the semantics of the data in the CoAP message body, such as Block (fragmentation), Location (position), Token (token) options, etc. Different options support different functions, and New functions can be extended by defining new Option.

CoAP supports the block option (Block Option), which is mainly used to transmit larger resources in pieces to adapt to the application scenario of low-bandwidth transmission. The Block option can be 1 byte, 2 bytes or 3 bytes, which is selected according to the length required by the capacity of the number of fragments.

In the traditional solution, the exact capacity of data resources is not calculated, and the exact number of subcontracts cannot be evaluated, so concurrent acquisition is impossible. In addition, it is not known whether the resource is static or dynamic.

In the following description, the resource owner is usually referred to as the server, and the sensor is taken as an example, and the resource requesting party is called the client, and the gateway is taken as an example. However, sensors or gateways are not used as constraints to servers or clients.

Since the precise capacity of the target resource is not known, when the gateway uses the Block Option in the <Get> command, it can only obtain in order, that is, select to obtain Block 0, and when Block 0 returns, then obtain Block1 until the last Block. Cannot send <Get> requests concurrently.

The field structure of the Block option generally includes the NUM field, the M field and the SZX field, where

NUM represents the serial number of the slice, which can be an unsigned integer number of 4 to 20 bits. 0 means the first shard.

M: A bit is used to indicate whether there are other fragments behind the current fragment. Its value is 1, which means there are fragments behind, and 0, which means there are no fragments behind, which is the last fragment.

SZX: It is used to represent the fragmentation capacity, and its calculation formula is: fragmentation capacity=2^(SZX+4), that is, 2 to the power of (SZX+4). Since SZX is represented by 3 bits, its value can be 0~7, so the value range of the slice capacity is: 2^4~2^11, that is, 16~2048.

The instructions for using the Block option are as follows:

In the <Get> request, the NUM field of the Block option gives the serial number of the currently requested fragment, and when the fragment serial number is 0, SZX gives the capacity of each fragment suggested by the gateway. In the <Get> response or <Put>/<Post> request, the NUM field of the Block option describes the sequence number of the currently transmitted fragment, and the M field indicates whether there are subsequent fragments.

In the <Put>/<Post> response, the NUM field of the Block option indicates the fragment sequence number of the current response.

When the gateway uses the <Get> method to obtain the first block (Block), NUM is set to 0 and carries the suggested block capacity (ie SZX), the sensor node can choose to agree to the proposed block capacity, or choose A shard smaller than the suggested shard is returned in the response, along with the first shard's data in the response.

The present invention considers that the gateway knows the precise capacity of the target resource in advance, so the gateway can choose whether to use BlockOption to send a request for resource acquisition, and can also implement concurrent requests, that is, while requesting Block0, it can also request Block 1 without waiting. The order of requesting blocks can also be handled flexibly.

In the simple design scheme, there are three options for Block Option, which can be one byte, two bytes, or three bytes. Depending on the capacity of resources, the number and capacity of blocks (Blocks) are different, and the required The length is also different. The agreement stipulates that except for the last fragment, the capacity of the fragments must be the same, but each transmission still needs to carry the M bit (indicating whether there are fragments behind) and SZX (the capacity of the fragment).

Every time in the request and response, the M bit and the SZX bit need to be transmitted, but in fact, except for the last fragment, the values of the M bit and SZX are the same every time, and repeated transmission wastes transmission resources. The purpose of repeatedly sending SZX assumes that neither party saves the negotiated SZX, the first response carries the negotiated SZX, the gateway obtains it from the response and sends it again in the request, so neither the gateway nor the sensor needs to save the state. In one request-response round, a total of one byte is wasted. If there are many fragments, a lot of bytes are wasted. For M2M devices, transmission resources are limited, and this waste of transmission resources is considerable. Assuming that the data to be transmitted is 64M, and the payload capacity of each block is 1024byte, the number of block entries sent is: 65536. Then the number of the sent Block options divided by bytes is:

(1) One byte: 16

(2) Two bytes: 4080

(3) Three bytes: 61440

If M and SZX can not be sent, the data that can be saved by the request plus the response is 65536 bytes (byte), that is, 64K data. In addition, if these two fields are not required, the NUM field can use up all bits (bits), and the number of data packets that need to be sent is changed to:

(1) One byte: 256

(2) Two bytes: 65280

At this time, there is no need to send the structure of 3 bytes, so the data can be saved as 61440*2bytes, that is, 60K data. Then a total of 124K data bits are saved, and the data rate is saved by 0.189%. The saving percentage of the header field is (16+4080*2+61440*3-256-65280*2)/(16+4080*2+61440*3)=61680/192496=32%.

Formula to save data volume:

T is the total number of blocks, S is the fragmentation capacity (Block Size), and the percentage of saved traffic (only the header field is compared):

When T<16: no savings; both are one byte;

When 16<T<256: 1-T*1/(16*1+(T-16)*2), the simple design requires 2 bytes, and the optimal design requires only one byte;

256<T<4096: 1-(256*1+(T-256)*2))/(16*1+(T-16)*2), the simple design requires 2 bytes, and the optimal design requires 2 bytes;

When 4096<T<65256: 1-(256*1+(4096-256)*2+(T-4096)*3))/(256*1+(T-256)*2), simple design requires 3 bytes, the preferred solution requires 2 bytes.

When T>65256, there is no saving, and both the preferred embodiment of the present invention and the simple design require 3 bytes.

In the simple design scheme, when using the Put/Post command, the fragmentation capacity negotiation is inefficient. In the Put/Post request, for the first shard, the data of the first shard and the recommended shard capacity need to be sent. If the sensor node chooses a different shard capacity, the gateway needs to follow the shard capacity of the sensor. If it is resent, the fragment data sent last time will be wasted. Moreover, when the gateway uses the Put/Post request to send large-capacity resources based on the fragmentation option, it cannot inform the sensor of resource capacity information in advance. During the transmission process, the sensor receives and caches the received resources. If the sensor finds that the storage space is not enough , and the resource has not been transferred, only a 413 error status code can be sent back, indicating that the requested resource is too large, and the transfer ends. Part of the previously transmitted resources are useless, and the transmission resources are wasted. If the gateway can inform the sensor of the capacity information of the resource to be transmitted in the first fragment message, the sensor can compare the resource capacity information with the storage capacity, and if the capacity is insufficient, return the status code 413 "The requested resource is too large" in advance. To end the resource transmission, so as to achieve the purpose of saving transmission resources.

To continue uploading from a breakpoint on the Internet, that is to continue downloading from the place where the file has already been downloaded. When the gateway requests data from the sensor, it needs to add an additional piece of information to indicate the range of the requested data download (Range), indicating where to start.

For example, the gateway uses the browser to pass the request information to the web sensor, which requires starting from 2000070 bytes:

GET/down.zip HTTP/1.0

User-Agent: NetFox

Range: bytes=2000070-

Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

Among them, RANGE: bytes=2000070-, the meaning of this line is to tell the sensor down.zip that the file starts to be transmitted from 2000070 bytes, and the previous bytes do not need to be transmitted.

The disadvantage of this solution is that there is no fragmentation mechanism, and neither does it support the negotiation of the fragmentation capacity nor the negotiation of the total number of fragments. The embodiment of the present invention considers negotiating the fragment capacity and/or the total number of fragments during the fragment transmission process. Therefore, the present invention provides a method for data slice transmission, which can obtain the precise capacity of the target data resource, negotiate the slice capacity, obtain the total number of slices, and perform data resource transmission according to the total number of slices.

The flow of an embodiment of the present invention will be specifically described below with reference to FIG. 1 . Fig. 1 is a flowchart of an embodiment of the present invention.

In the process of S110, the capacity information of the data resource of the node is acquired. If the gateway acquires data from the sensor, the node's data resource capacity information is stored on the sensor. The gateway can obtain the capacity information of the data resource of the node from the sensor through the request message. If the gateway sends data to the sensor, the gateway already knows the capacity information of the node's data resources locally. Obtaining the data resource capacity information of the node is to prepare for the next step of negotiating the fragmentation capacity and determining the total number of fragments.

Next, in the process of S120, the gateway sends a request message carrying a first fragmentation option to the sensor, where the first fragmentation option includes a recommended fragmentation capacity. After receiving the request message sent in S120, the sensor determines the fragmentation capacity used in this data resource transmission process according to its own capability, and the fragmentation capacity determined by the sensor is less than or equal to the fragmentation capacity recommended by the gateway.

At S130, the gateway receives a response message carrying a second fragmentation option, where the second fragmentation option includes a determined fragmentation capacity, and the determined fragmentation capacity is less than or equal to the recommended fragmentation capacity. After receiving the determined fragment capacity, the gateway determines the total number of fragments of the data resource of the node to be transmitted according to the information about the capacity of the node's data resource.

Then, at S140, transmit the data resource in fragments according to the determined fragment capacity and the data resource capacity information of the node.

According to the embodiment of the present invention, the capacity information of the data resources to be transmitted can be known, and the fragment capacity used for data transmission can be determined through fragment capacity negotiation, thereby reducing the error rate during the transmission process and concurrently transmitting data .

The specific implementation process of the embodiment shown in FIG. 1 will be described below with reference to FIG. 2 . Fig. 2 shows an illustrative example in which a gateway acquires data from a sensor, which is only for illustrating the concept of the present invention, but not as a limitation to the present invention.

The specific description of the data resource acquisition process shown in Figure 2 is as follows:

ES210: The gateway sends a resource discovery request to the sensor, that is, obtains the resource list on the sensor through Get./wellknown/core.

ES220: The sensor returns a resource list and resource indication information to the gateway; the resource indication information mainly includes resource addressing information (ie URI), resource name, resource description information, content type, etc. The present invention expands the resource indication information, and the extended resource indication information includes: indication information of whether the resource is a dynamic resource or a static resource.

ES230: The gateway selects the target resource according to the resource list returned by the sensor, according to the indication information of the resource, and obtains the target resource according to the identification (information that can uniquely identify the resource, such as resource name, URI, etc.).

ES240: The sensor judges the capacity of the target resource. If the resource capacity is less than the capacity of a transport layer message packet, it will directly return the resource content to the gateway; if the resource capacity exceeds the capacity of a transport layer message packet, it will return the resource capacity information. Optionally, the sensor can use the sharding option to directly return the first shard according to the shard capacity determined by itself. Subsequent clients and sensors transmit the following shards using the shard option based on this determined shard capacity.

In an alternative embodiment of the present invention, if the target data resource is a dynamic data resource, an indication of the dynamic data resource is returned to the gateway at the same time, and a status code of 413 "request resource is too large" is used to instruct the gateway to use the Block option to obtain the resource.

If the data resource is a dynamic resource, the resource capacity in the indication information represents the capacity information of the current resource snapshot (Snapshot), and the sensor needs to cache the snapshot data; if it is a static resource, the resource capacity information in the indication information is accurate capacity information. Those skilled in the art should understand that if the data resource is a dynamic resource, the sensor can send a verification code of the resource snapshot, and if the gateway needs fresher data, it can send a new resource acquisition request later.

ES250: The gateway judges that the fragmentation option needs to be used according to the data resource capacity information, and sends a request message carrying the fragmentation option, negotiates with the sensor on the fragmentation capacity, and indicates the recommended fragmentation capacity.

ES260: The sensor determines the fragmentation capacity according to its own capabilities, and returns it to the gateway. Optionally, the sensor returns the total number of shards at the same time. Of course, since the gateway has obtained the data resource capacity information, the total number of fragments can also be determined by the gateway. It should be noted that the fragmentation capacity determined by the sensor can only be less than or equal to the fragmentation capacity recommended by the gateway.

ES270: The gateway sequentially sends requests from 1 to the total number of fragments to the sensor, requesting to obtain the fragmented data of the data resource corresponding to the fragment sequence number.

ES280: According to the determined fragment capacity, the sensor returns the fragment number and the fragment data of the data resource corresponding to the fragment number until the transmission is complete.

According to a preferred embodiment of the present invention, parallel processing can be realized in ES270, that is, the gateway can simultaneously request to obtain multiple fragment messages without waiting for the sensor to return a response message to the previous fragment request message.

The codes for ES210 to ES240 are, for example:

REQ: GET/.well-known/core---Send a request to the default URI, which is the root directory to get the resource list;

RES: 200OK -- The response identifier is obtained successfully, and it carries 2 sets of resource indication information;

REQ: GET /sensors/firmware - request firmware resource

RES: 413 "Request Entity Too Large" Size: 88000. The 413 status code indicates that the requested resource is too large, and its precise capacity is 88000 bytes.

If the data resource is a dynamic resource, that is, the data resource will change dynamically during the transmission process, for example, the following two solutions can be used for processing:

(1) When starting to transmit a data resource, create a snapshot of the resource (Snapshot), that is, cache the capacity information of the data resource at the moment, and transmit the capacity information, regardless of subsequent changes; corresponding to the above scheme.

(2) If the data resource is modified during transmission, the sensor can return an error code in the response message of any request message to obtain the data resource, indicating that the data resource has been changed and the gateway needs to obtain it again.

Optionally, the gateway and the sensor add authentication information during message interaction. The authentication information may include an identity (ID), and key information (Digest) calculated based on the identity and a password (Password). Identity and password can be pre-configured for both the gateway and the sensor. Configuration process:

For example, the algorithm of the key may be: Digest=MD5(ID: Password), that is, the character string composed of ID and Password is hashed (Hash) using the MD5 algorithm, and the value of Hash is Digest. The sender sends the ID and Digest, and the receiver obtains the Digest according to the same algorithm based on the received ID and the pre-stored Password, and compares it with the Digest sent by the sender. If they are consistent, the authentication is passed.

When the gateway acquires data resources from the sensor, as shown in Figure 2, it needs to know the capacity information of the data resources. According to an embodiment of the present invention, the gateway may adopt the following solution to obtain the data resource capacity information stored in the sensor.

(1) Extended link format (Link-format) keyword

In Link-format, expand a keyword, -sn, or -snapshot, which is used to indicate whether the resource data is snapshot data in the response to the request to obtain the data resource. If this parameter does not exist, or its value is 0, it indicates that it is a static resource; if the value of this parameter is 1, it indicates that the current data is a dynamic resource, and the acquired data is the current snapshot. Static resources refer to resources that are relatively stable for a period of time, that is, the content of the resource does not change frequently. The specific meaning can be defined in the standard. In the present invention, it mainly refers to the case where the value of the resource does not change.

Also expands keywords: -asz, information indicating the exact capacity of the resource.

Message instance:

The gateway sends a resource discovery request to the sensor:

REQ: GET/.well-known/core---Send a request to the default URI, which is the root directory to get the resource list

Sensor sends resource response to gateway:

RES: 200OK -- The response identifier was obtained successfully, and it carried 2 sets of resource indication information

The response message is encapsulated in the message body of the CoAP message, and the receiver (that is, the gateway) parses it according to the provisions in the Link-format standard.

(2) Add status code

When receiving a data resource acquisition request from the gateway, if the resource is too large to be transmitted in one packet, the sensor notifies the gateway with a status code to indicate that the resource is too large and needs to be requested with a Block Option.

For example, status code 413 may be specified to indicate that the current data resource capacity is too large, and to instruct the gateway to use the Block option in the request. Other status codes can be specified as required to express other meanings and for other purposes.

Message instance:

The gateway sends a resource acquisition request to the sensor:

GET /sensordata

The sensor sends a response to the gateway with a status code:

ACK 413 (status code, indicating that the data resource capacity is too large)

(3) Add an option (Option) to indicate the capacity (Size) in the header field (Header) of CoAP

In the request, the gateway can use the Size Option to indicate the sensor, so that the sensor can return the capacity of the data resource; in the response, the sensor can use the Size Option to indicate the capacity of the data resource.

Or, even if the gateway does not indicate the Size Option, the sensor also uses the Size Option to indicate the resource capacity in the response, especially when the resource is relatively large, the sensor should indicate.

If the resource is small, the sensor directly returns the resource data in the message body (Body), the gateway should refer to the actual capacity of the resource data, and the resource capacity indicated in the Size Option can be used for checking.

If the resource is large, the sensor does not return the resource data, but only uses the Size Option to return the capacity of the data, and at the same time uses the status code to indicate to the gateway, so that the gateway can initiate a new request and use the Block Option to request.

The code of Size Option can be 16, the data type is integer, the data length is 1 to 4 bytes, and the data unit is byte. Size Option is mainly used in the response of the <Get> method and the request of the <Put>/<Post> method to indicate the capacity of the resource; if it is in the request of the <Get> method, its value has no practical meaning. It is recommended to set it to 0.

Message instance:

The gateway sends a resource acquisition request to the sensor:

GET /sensordata

The sensor sends a response to the gateway with a status code:

ACK+413+Size 51200 (50K bytes)

The specific implementation process of the embodiment shown in FIG. 1 will be described below with reference to FIG. 3 . Fig. 3 shows an illustrative example of sending data from a gateway to a sensor, which is only for illustrating the concept of the present invention, but not as a limitation to the present invention.

When the gateway uses the <Get> method to obtain the first block (Block) data, the NUM field is set to 0 and carries the recommended block size (ie SZX), the sensor can choose to agree to the recommended block size, or Select a shard size that is less than or equal to the recommended shard size and return it in the response. At the same time, return the shard data of the first shard in the response. Therefore, when the NUM field is 0, the <Get> request has dual semantics, one is to obtain the first fragment data, and the other is to negotiate the fragment capacity. This brings ambiguity in the processing of the protocol, and information such as data capacity cannot be carried.

The embodiment of the present invention improves this. In one embodiment of the present invention, when the gateway uses the Block Option in the request of the <Get> method, if the NUM field is set to 0, it means that both parties only perform fragmentation capacity Negotiation, and the negotiation of the total number of fragments. That is, in the response, the sensor uses the NUM field to return the total number of fragments, and uses the SZX field to return the fragment capacity determined by the sensor. The M field can be removed to save a bit for the NUM field. Because the requester, such as the gateway, knows the total number of fragments, it can know whether the fragment is the last fragment from the NUM field of the fragment, so there is no need to use the M field. In this case, if requesting to get shard data for the first shard, set NUM to 1, and so on.

It should be noted that if the gateway does not know the capacity of the data resource when sending the first request, BlockOption can use one byte. If the data resource of the sensor is large and the number of fragments is large, the sensor can use it in the response Two bytes or three bytes to return the total number of fragments.

When the Block Option is 2 bytes, it is designed so that the SZX field occupies the last three bits of the second byte, indicating the fragment capacity; the NUM field occupies the first byte plus the first 5 bits of the second byte , indicating the current fragment sequence number; if it is in the response message corresponding to the request where NUM is 0, it indicates the total number of fragments. Those skilled in the art understand that the message ID (Message ID) can be used to associate the request and the response, that is, both the request and the response carry a unique transaction ID, so that the sensor can understand that the response message is used to return the total number of fragments.

The following example illustrates the fragment capacity negotiation process, and the message example is:

The gateway sends a resource acquisition request to the sensor:

GET 00000 101 (NUM is 0, SZX is 101, which is 5, which means that the fragment capacity is 2 to the 9th power, which is 512)

The response sent by the sensor to the gateway:

ACK 10000 100 (NUM is: 10000, that is, the total number of fragments is 32, SZX is 100, that is, 4, indicating that the fragment capacity is 2 to the 8th power, that is, 256)

This design saves one bit (Bit), that is, the M bit is saved. The technical advantage is that the data traffic is saved and there is little change to the existing design. In this implementation, the Fragment Size (SZX) field is still sent each time.

In the existing technology, the fragment capacity (ie, the SZX field) is sent every time, no matter in the request message or the response message, except that the fragment capacity used in the first fragment and the last fragment may not be Except for the same, the capacities of other fragments are all the same. Repeatedly transmitting the same NUM field to each other wastes transmission resources.

In the embodiment of the present invention, when the gateway uses the Block Option in the request of the <Get> method, if NUM is set to 0, it means that the two parties only negotiate on the fragment capacity and the total number of fragments. That is, in the response, the sensor uses the NUM field to return the total number of fragments, and uses the SZX field to return the fragment capacity determined by the sensor. And both the gateway and the sensor store the determined fragment capacity for subsequent fragment data transmission messages. Except for the last shard data. In the subsequent <Get> method request, the gateway only sends the requested current fragmentation number, not the determined and unchanged fragmentation capacity, and the sensor only sends the current fragmentation number in the response message And the fragment data corresponding to the fragment sequence number, the fragment capacity is no longer sent. In this case, when NUM is 1, it means that the fragment data of the first fragment is requested, and so on.

Take the <GET> command to obtain data resources from sensors as an example to illustrate the above embodiment,

As shown in Figure 3, the new Block Option is designed as follows:

where structure (1) is used when NUM is 0:

In the <Get> request, NUM is 0, SZX is the second byte, which indicates the fragment capacity, and TotalNumber indicates the total number of fragments, which is not used in the request and does not need to be carried; in the <Get> response, NUM is 0 , SZX indicates the shard capacity determined by the sensor, and Total Number indicates the total number of shards.

In the existing technology, the interval of fragmentation capacity is relatively large, such as 2048, 1024, 512, which is not flexible enough. In fact, 512 is relatively small for a Block, and it is best to fit it into a UDP packet, that is, 1472 bytes. The present invention improves this. In one embodiment, for SZX, a new formula can be adopted, such as: (SZX+1)*8, then the range can be: 8-2048, but the decreasing interval is 8.

The structure (2) and structure (3) in Figure 3 are used when the NUM in the <Get> request is not 0, that is, when obtaining fragmented data:

When NUM is less than 256, use one byte to represent the fragment number, that is, structure (2); when NUM is greater than 2 to the 8th power (ie 256) and less than 2 to the 16th power (ie 65536), use two Byte to represent the fragment sequence number, that is, structure (3).

Since the NUM in structure (2) must be greater than 0, the previous byte of the NUM field in structure (3) is also greater than 0, so it can be distinguished from structure (1). For <Get> responses, the value of the NUM field is the same as The same as in the request, it can also be distinguished.

The following example illustrates that the message example is:

The gateway sends a resource acquisition request to the sensor:

GET 00000000 00000101 (NUM is 0, SZX is 101, which is 5, which means that the fragment capacity is 2 to the 9th power, which is 512)

The response sent by the sensor to the gateway:

ACK 00000000 00000100 00000000 00010000 (NUM is 0, Total Number is 10000, that is, the total number of fragments is 32, SZX is 100, that is, 4, indicating that the fragment capacity is 2 to the 8th power, that is, 256).

By redesigning the Block Option, at least 4 bits can be sent in each request or response. In the case of many fragments, the transmission efficiency can be greatly improved, transmission resources can be saved, and gateways and sensors can also be improved. processing efficiency on both sides.

Figure 4 shows an alternative embodiment of the invention. In the embodiment shown in FIG. 4 , ES410 to ES420 are the same as ES210 to ES240 in the embodiment shown in FIG. 2 , and will not be described again.

In the embodiment shown in Fig. 4, at ES450, the gateway sends a <GET> request to the sensor, uses the fragmentation option to negotiate the fragmentation capacity, and indicates the fragmentation capacity recommended by the gateway. In ES460, the sensor selects and determines the appropriate sharding capacity for sharding resources, and actively pushes all sharded data to the gateway without the need for the gateway to send a <GET> request again.

In the process of obtaining data resources in the embodiment of Figure 4, the design of the fragmentation option is shown in Figure 5, where:

Structure (1) is used for the gateway to send a <GET> request to the sensor. The SZX field indicates the fragmentation capacity recommended by the gateway. The fragmentation capacity finally selected and determined by the sensor is less than or equal to the fragmentation capacity recommended by the gateway. NUM is 0 to indicate that the gateway request is complete Resource, if NUM is not 0, it means that the gateway requests the specific NUM fragment data, when NUM is not 0, the sensor can only use the fragment capacity indicated by the SZX field.

Structure (2) and structure (3) are used for the sensor to return a complete resource fragmentation response message to the gateway. If the response to a specific fragmentation data request does not need to carry fragmentation options, structures (2) and (3) The M field in indicates whether it is the last slice, if the M field is 0, it means the last slice, if it is 1, it means it is not the last slice, and the NUM field indicates which slice is returned by the sensor.

The following example illustrates. Examples of messages are:

The gateway sends a request for data resource acquisition to the sensor:

CON GET 00000000 00000101 (NUM is 0, SZX is 101, which is 5, which means that the fragment capacity is 2 to the 9th power, which is 512)

The response sent by the sensor to the gateway:

ACK 200 00000011 (NUM is 1, M is 1, indicating the first fragment sent, and not the last fragment, and the fragment capacity is the capacity specified by the SZX field);

The sensor proceeds to send a CoAP response to the gateway:

CON 200 00000101 (NUM is 2, M is 1, indicating the second fragment sent, and not the last fragment, and the fragment capacity is the capacity specified by the SZX field);

The gateway returns an ACK response to CON;

The sensor sends the last fragment to the gateway:

CON 200 00000110 (NUM is 3, M is 0, indicating the third and last fragment sent, and the specific fragment capacity is calculated from the actual read data).

According to the embodiment shown in FIG. 4 , when the gateway obtains complete data resources from the sensor, it only needs to complete the negotiation of fragment capacity without sending a large number of fragment data acquisition requests, which greatly saves data transmission traffic.

Figure 6 shows another alternative embodiment of the invention. In the embodiment shown in FIG. 6 , ES610 to ES640 are the same as ES210 to ES240 in the embodiment shown in FIG. 2 , so the description will not be repeated.

The difference between Figure 6 and the embodiment shown in Figure 2 is that at ES650, the gateway sends a <GET> request to the sensor to request resources, and uses the fragmentation option to indicate the fragmentation capacity recommended by the gateway. At this time, the value filled in the NUM field If it is 0, it means that the last fragment is requested; in ES660, the sensor responds to the gateway request and returns the determined fragment capacity, the sequence number of the last fragment and the corresponding fragment data. Since the last fragment serial number corresponds to the total number of fragments, in ES670, the gateway can sequentially or concurrently obtain requests for other fragment data. In ES680, the sensor returns the sequence number of the fragment and the corresponding fragment data according to the determined fragment capacity. The ES670 and ES680 can interact multiple times until the fragmented data transmission is complete.

The fragmentation option used in the embodiment of FIG. 6 is shown in FIG. 7 , for example, a two-byte fragmentation option is used, including only the NUM field and the SZX field.

The following is an example in conjunction with Figure 6 and Figure 7, and the message example is:

The gateway sends a resource acquisition request to the sensor:

CON GET 00000000 00000101 (NUM is 0, which means that the last fragment is requested, and SZX is 101, which is 5, which means that the recommended fragment capacity is 2 to the 9th power, which is 512).

The response sent by the sensor to the gateway:

ACK 00000000 01000101 (NUM is 1000, which means 8, which means that the 8th fragment is returned, and SZX is 101, which is 5, which means that the determined fragment capacity is 2 to the 9th power, which is 512);

According to the information returned for the first time, the gateway already knows that there are 8 fragments in total, and has obtained the data of the 8th fragment. The gateway continues to send CoAP requests to the sensor, and can obtain the remaining fragments sequentially or concurrently. data. The following message example is a request to obtain the shard data of the first shard:

CON GET 00000000 00001101 (NUM is 1, which means that the first fragment is requested, SZX is 101, which is 5, which means that the fragment capacity is 2 to the 9th power, which is 512);

The sensor returns an ACK response to CON, which is the data of the first fragment;

The gateway can request all remaining shards sequentially or concurrently until all data is fetched.

According to the embodiment shown in Figure 6, the fragment data of the last fragment can be acquired while the fragment capacity is being negotiated. In the description of the preferred embodiment, the gateway can no longer send the SZX field but only the NUM field when sending the request to obtain fragmented data, thereby saving data traffic and improving transmission efficiency.

Figure 8 shows an embodiment when sending data to a sensor using the sharding option, for example using a resource create (Post) or update (Put) request. A specific description will be made below in conjunction with FIG. 8 .

The detailed process description shown in Figure 8 is as follows:

ES810: The gateway sends a resource creation (Post) or update (Put) request message to the sensor, uses the Size option to send resource capacity information, and uses the Fragmentation option to indicate the recommended fragmentation capacity and the total number of fragments. The fragmentation described here The total is calculated based on the recommended fragment capacity and the capacity of data resources to be sent, and the request message body does not carry specific resource data.

ES820: If the sensor is willing to receive this data, the return status code is, for example, 100 (that is, instructing the client to continue sending), and at the same time return the determined fragment capacity to the gateway. The determined fragment capacity can only be less than or equal to that recommended by the gateway Fragment capacity; if the sensor is not willing to receive this data, it will return an error code to instruct the client not to continue sending data. For example, if the storage capacity of the sensor is not enough to store the data of the indicated resource capacity, a return code of 413 "Request EntityToo Large" is returned.

ES830: The gateway judges whether it is the same as the recommended fragmentation capacity according to the determined fragmentation capacity returned by the sensor. If it is the same, it jumps to ES360; Data resource capacity, recalculate the total number of shards.

ES840: The gateway resends the determined shard capacity and the recalculated total number of shards to the sensor.

ES850: Sensor returns determined shard capacity.

ES860: The gateway sequentially sends the fragmented data of the data resources corresponding to the fragmented serial number to the sensor from 1 to the total number of fragmented fragments until the transmission is complete.

ES870: The sensor returns a confirmation message, which contains the sequence number of the received fragment.

According to a preferred embodiment of the present invention, parallel processing can be performed in the ES860, that is, the gateway can simultaneously send multiple fragmented data to the sensor without waiting for the sensor to return a response message to the previous fragmented message. Optionally, according to a preferred embodiment of the present invention, the gateway and the sensor add authentication information during message interaction. The configuration and interaction manner of the authentication message may adopt the same manner as described with reference to FIG. 2 .

In order to improve transmission efficiency and save data traffic, according to another preferred embodiment of the present invention, as described above for the <GET> method, in the request using the <Put>/<Post> method, when NUM is 0 , instead of sending the first fragment data, it informs the sensor of the recommended fragment capacity and the total number of fragments. The sensor can return a response telling the gateway whether to continue sending data. In the response, the sensor uses the NUM field to return the total number of shards, and uses the SZX field to return the shard capacity determined by the sensor. And both the gateway and the sensor store the determined fragment capacity for subsequent fragment data transmission messages. Except for the last shard data. In the subsequent <Put>/<Post> method request, the gateway only sends the requested current fragment number, not the fragment capacity that has been determined and remains unchanged, and the sensor only sends the current fragment number in the response message. The fragment sequence number and the fragment data corresponding to the fragment sequence number will no longer send the fragment capacity. In this case, when NUM is 1, it means that the fragment data of the first fragment is requested, and so on.

In this case, the design and usage of the slice option are similar to those shown in FIG. 3 , which will be described below with reference to FIG. 3 . In the <Put>/<Post> request, the NUM field is 0, the SZX field is the second byte, indicating the recommended fragment capacity, and the Total Number represents the total number of fragments to be sent; in <Put>/<Post >In the response, the NUM field is 0, and the SZX field indicates the fragmentation capacity determined by the sensor. The Total Number is useless and does not need to be carried; if the SZX field received by the gateway is inconsistent with the sent one, it needs to send <Put> again with a new SZX /<Post> request with the recalculated total number of shards, and the sensor sends back a response. In future <Put>/<Post> requests and responses, the SZX field will no longer be carried.

By redesigning the fragmentation option, at least 4 bits can be sent in each request or response. In the case of many fragments, the transmission efficiency can be greatly improved, transmission resources can be saved, and the gateway and Processing efficiency on both sides of the sensor.

In addition, the existing technology needs to carry the unified resource identifier (URI, Unified Resource Identifier) of the requested resource in each fragment transmission request. Usually, the URI occupies more than a dozen to dozens of bytes. Repeated transmission It will waste transmission resources. The present invention designs and uses Token (token) to associate multiple requests for fragment transmission, and only transmits the URI in the first fragment message. In subsequent fragment transmission requests, only the Token needs to be carried. Yes, since Token is usually 1 to 8 bytes, it can save a certain amount of traffic.

Fig. 9 is an embodiment of a client device for transmitting data resources through fragmentation according to the present invention. The client device 900 shown in FIG. 9 includes: an acquiring unit 910, configured to acquire data resource capacity information; a sending unit 920, configured to send a request message carrying a fragmentation option, wherein the fragmentation option includes a recommended fragmentation capacity, The receiving unit 930 is configured to receive a response message carrying a fragmentation option, wherein the fragmentation option includes a determined fragmentation capacity; and a transmission unit 940 is configured to, according to the determined fragmentation capacity and the data resource capacity information, divide The data resource is transferred in slices.

According to a preferred embodiment of the present invention, the client device may further include a storage unit 950, configured to store the determined slice capacity. So that in the data resource transmission process, the SZX field does not need to be sent every time.

According to another preferred embodiment of the present invention, the client device may further include an authentication unit 960, configured to send and receive authentication information.

Fig. 10 is an embodiment of a server device for transmitting data resources through fragmentation according to the present invention. The server device 1000 shown in Figure 10 includes: a receiving unit 1010, configured to receive a request message carrying a fragmentation option, wherein the fragmentation option includes a recommended fragmentation capacity; a sending unit 1020, configured to send a response carrying a fragmentation option message, wherein the fragmentation option includes a determined fragmentation capacity; and a transmission unit 1030, configured to transmit the data resources in fragments according to the determined fragmentation capacity.

According to an embodiment of the present invention, the sending unit 1020 is further configured to send a message carrying data resource capacity information, so that the transmission unit 1030 transmits the data in fragments according to the determined fragment capacity and the data resource capacity information resource.

According to an embodiment of the present invention, upon receiving a request, the transmission unit 1030 may actively transmit data in pieces, without requiring the client device to request for each piece of data.

According to a preferred embodiment of the present invention, the server device may further include a storage unit 1040, configured to store the determined fragment capacity. So that in the data resource transmission process, the SZX field does not need to be sent every time.

According to another preferred embodiment of the present invention, the server device may further include an authentication unit 1050, configured to send and receive authentication information.

According to the embodiment of the present invention, the gateway can obtain the capacity information of the target resource, and use it to decide whether to obtain the resource in a fragmented manner, which avoids the possibility of errors, and can also request fragments concurrently, improving the efficiency of data requests , and knowing the resource capacity is also convenient for allocating storage space and calculating the number of fragments.

By redesigning the fragmentation option, at least 4 bits can be sent in each request or response. In the case of many fragments, the transmission efficiency can be greatly improved, the transmission resources can be saved, and the communication between the two parties can also be improved. Processing efficiency.

In the existing technology, after receiving the request from the client, the server can send back a response immediately, or send back an Ack (Acknowledgment) response message first, indicating that the request message has been received and is being processed, and the subsequent processing is completed After that, send the response message, that is, the delayed response. In addition, the client can subscribe to the change of a resource. After the server accepts the client's subscription to a resource, once the resource information changes, it will send back a notification message to the client.

The prior art cannot meet the following requirements:

1. The client indicates to the server in the request which response it needs;

2. The client requests the server to send back a response within a specified time;

3. During the transmission of the notification message, due to the unstable network transmission capacity, the notification message sent by the server first may reach the client later than the message sent by the server later. In this way, the resource information received later by the client is actually old information, and the client needs to have a mechanism to detect the sequence of multiple notification messages.

Figure 11 is a flowchart of an embodiment of the present invention. In the embodiment shown in FIG. 11, at S1110, the client sends a request message to the server, and the request message carries a response mode option, and the response mode option may be a Deferred Response option or a Token option , used to indicate to the server, whether the client accepts deferred responses. For example, the corresponding mode options represent: one-time immediate response, deferred one-time response, deferred multiple responses, and cancel-deferred multiple responses. Then, at S1120, the client may receive the response message generated according to the response mode option.

In the existing technology, after receiving the request from the client, the server can send back a response immediately, or send back an Ack first, indicating that the request message has been received and is being processed, and then send the response after the subsequent processing is completed Message, that is, the delayed response. In addition, the client can subscribe to the change of a resource. After the server accepts the client's subscription to a resource, once the resource information changes, it will send back a notification message to the client.

In an embodiment of the present invention, for example, a one-byte Deferred option can be used to indicate the response mode, wherein the first two bits (Bit) can be used to indicate, and C is used to indicate:

C＝00: Indicates a one-time immediate response;

C=01: Indicates a delayed one-off response;

C=10: Indicates delayed multiple responses, ie subscription;

C=11: Indicates canceling the postponed multiple responses, that is, unsubscribing.

For a subscription to a resource initiated by the client, the client can cancel the subscription, or the server can cancel the subscription. For example, the server sends back a response message that needs to be confirmed, and the client fails to confirm within the predetermined time. Then the server can think that the client has lost connection and cancel the subscription.

Since a byte is 8 bits, the extra last 6 bits (assuming its value is T) can be used to indicate the delay time of a delayed one-time response or the deadline of multiple delayed responses, that is, beyond this After the time, the subscription is automatically unsubscribed. When C is 01, T represents the delayed one-time response delay time; when C is 10, T represents the deadline for multiple delayed responses; when T is 00 or 11, T has no meaning and is set to 0.

For these 6 bits, it can represent a value between 0 and 63. Assuming T, you can use 2 to the T power to indicate the length of time. In seconds, it can represent 1 to 2^63 seconds. for example:

0: 2^0 = 1 second;

1: 2^1=2 seconds;

2: 2^2 = 4 seconds;

3: 2^3 = 8 seconds

4: 2^4 = 16 seconds;

63: 2^63 seconds.

In the prior art, the Max_Age field is used to indicate the maximum time that a certain response can be cached, that is, to indicate the freshness of the response. The present invention expands the meaning of this field, and can use the Max_Age field in the request to indicate the limitation of the time interval between multiple responses, for example, multiple notification messages must not be higher than this time interval, or must not be lower than this time interval.

The sequence of multiple responses can be distinguished by message ID (Message ID). For example, it is stipulated that message identifiers must be incrementally generated according to the order of responses, and the receiver judges the sequence of responses based on the size of the message identifiers.

According to another embodiment of the present invention, the Token (token) option can be used to indicate the response mode. If the Token value is 0, it indicates an immediate response, and if the Token value is not 0, it indicates that a delayed response can be accepted.

According to another embodiment of the present invention, a timestamp (Timestamp) option may be added alternatively or additionally, and the delay option may be used alone or in combination to indicate the response mode. Specifically, the client can carry a timestamp option in the request, and the timestamp option includes a deadline value, requiring the server to return a response within a specified time; the server carries a timestamp option in the response message, indicating that the response The time when the message was generated, so that the client can determine the order of the response messages based on the timestamp option.

In an embodiment of the present invention, the design scheme of the timestamp option can be represented by 1 to 6 bytes, if the represented time is short, use 1 byte, if the time is long, use 3 bytes or 6 bytes. The specific representation methods are as follows:

(1) Use year, month, day, hour, minute, second to represent, the first byte represents the year, the second byte represents the month, the third byte represents the day, and the fourth byte represents the hour, The fifth byte represents the minute, and the sixth byte represents the second. For the year, for example, it can be based on 2000, and its value indicates the number of years after 2000. For example, when it is 0, it indicates that it is 2000, and it is 1. The time indicates the year 2001, and it can indicate the year 2063 at most.

(2) All three bytes are represented by seconds, and the maximum can represent 2^24-1 seconds, which is about 136 years.

Thus, the client can know the order of the returned response messages, and avoid errors caused by data transmission delays.

Fig. 12 is a block diagram of an embodiment of a client device for transmitting data resources according to the present invention, wherein the client device 1200 includes: a sending module 1210, configured to send a request message carrying a response mode option; and a receiving module 1220 , used to receive the response message generated according to the response mode option.

The procedures and features described in the embodiment of the present invention with reference to FIG. 11 are applicable to the client device shown in FIG. 12 . Specifically, for example, the response mode option carried in the request message sent by the sending module 1210 may be a postponement option, for example, it may be: a one-time immediate response, a delayed one-time response, multiple delayed responses, and a canceled postponed multiple responses.

According to an embodiment, the response mode option carried in the request message sent by the sending module 1210 may indicate a delayed one-time delayed response time or delayed deadlines for multiple responses.

According to an embodiment, the sending module 1210 sends a request message carrying a timestamp option, and the timestamp indicates a deadline for receiving a response; the receiving module 1220 receives a response message carrying a timestamp option, and the timestamp indicates a generation time of the response message. The receiving module 1220 determines the order of the response messages according to the time represented by the timestamp in the received response messages.

Fig. 13 is an embodiment of a server device for transmitting data resources according to the present invention, wherein the server device 1300 includes: a receiving module 1310, configured to receive a request message carrying a response mode option; and a sending module 1320, configured to send Response message generated by the Response Mode option described above.

The processes and features described in the embodiment of the present invention with reference to FIG. 11 are applicable to the server device shown in FIG. 13 . Specifically, for example, the response mode option carried in the request message received by the receiving module 1310 may be a postponement option, for example, it may be: a one-time immediate response, a delayed one-time response, multiple delayed responses, and a canceled postponed multiple responses.

According to an embodiment of the present invention, the response mode option carried in the request message received by the receiving module 1310 may indicate a delayed one-time delayed response time or delayed multiple response deadlines.

According to an embodiment of the present invention, the postponement option in the request message received by the receiving module 1310 indicates the delayed multiple responses and the time interval between the delayed multiple responses, and the postponement option in the response message sent by the sending module 1320 Indicates cancellation of deferred multiple responses.

According to another embodiment of the present invention, the request message received by the receiving module 1310 may carry a timestamp option, which indicates the deadline for receiving the response, and the response message sent by the sending module 1320 may also carry the timestamp option , the timestamp option indicates the generation time of the response message.

Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the relationship between hardware and software Interchangeability. In the above description, the composition and steps of each example have been generally described according to their functions. Whether these functions are executed by hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods to implement the described functions for each specific application, but such implementation should not be regarded as exceeding the scope of the present invention.

The steps of the methods or algorithms described in connection with the embodiments disclosed herein may be implemented by hardware, software modules executed by a processor, or a combination of both. Software modules can be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other Any other known storage medium.

Although some embodiments of the present invention have been shown and described, those skilled in the art will understand that various modifications can be made to these embodiments without departing from the principles and spirit of the invention, and such modifications shall fall within into the scope of the present invention.

Claims (23)

1. A method for transferring server data resources by fragmentation based on a lightweight application layer protocol in an Internet of Things system, characterized in that, comprising: The client sends a resource acquisition request to the server, the resource acquisition request carries a first capacity option field, and the first capacity option field is used to instruct the server to return the capacity of the data resource; The client receives the resource acquisition response returned by the server, the resource acquisition response carries a second capacity option field, and the second capacity option field is used to indicate the capacity of the data resource; The client sends a request message carrying a first fragmentation option to the server, where the first fragmentation option includes a recommended fragmentation capacity; The client receives a response message from the server carrying a second fragmentation option, wherein the second fragmentation option includes a determined fragmentation capacity, and the determined fragmentation capacity is less than or equal to the recommended fragmentation capacity ; The client receives the data resource of the server in fragments according to the determined fragmentation capacity and the capacity of the data resource of the server; Wherein, according to the determined fragmentation capacity and the capacity of the data resource of the server, receiving the data resource of the server by fragmentation includes: receiving a resource transfer message carrying a third fragment option, wherein the third fragment option only includes a fragment sequence number, and the resource transfer message carries a fragment of the data resource of the server corresponding to the fragment sequence number data. 2. The method according to claim 1, wherein the resource acquisition response further includes a status code indicating that the data resource capacity of the requested server is too large. 3. The method of claim 2, further comprising: The client receives the indication information indicating the static resource or the dynamic data resource, and if it is a dynamic resource, indicates the capacity of the data resource of the server in the form of a current snapshot. 4. The method according to claim 1, wherein the sending of the request message carrying the first fragmentation option comprises: Sending a request message carrying a first fragmentation option, where the first fragmentation option also includes the capacity of the data resource of the server. 5. The method of claim 1, wherein, Said sending the request message carrying the first fragmentation option includes: sending a request message carrying a first fragmentation option, where the first fragmentation option includes indication information that only negotiates fragmentation capacity; Said receiving the response message carrying the second fragmentation option includes: A response message carrying a second fragmentation option is received, where the second fragmentation option only includes the determined fragmentation capacity. 6. The method of claim 1, wherein, In the sending of the request message carrying the first fragmentation option, the uniform resource identifier of the requested resource and a token for associating the fragmentation message are also carried; In the message transmitting the data resource of the server, only the token associated with the fragmented message is transmitted. 7. The method of claim 1, wherein, According to the determined fragmentation capacity and the capacity of the data resource of the server, receiving the data resource of the server by fragmentation includes: According to the determined fragmentation capacity and the capacity of the data resource of the server, receive the data resources of the server in fragments sequentially or in parallel. 8. The method of claim 1, wherein, Said sending the request message carrying the first fragmentation option includes: Sending a request message carrying a first fragmentation option, wherein the first fragmentation option includes indication information for obtaining the data of the last fragmentation; Said receiving the response message carrying the second fragmentation option includes: receiving a response message carrying a second fragment option, wherein the second fragment option includes a total number of fragments, and the response message carries fragment data of the data resource of the server corresponding to the last fragment; According to the determined fragmentation capacity and the capacity of the data resource of the server, receiving the data resource of the server by fragmentation includes: According to the fragment capacity and the total number of fragments, the fragment data of the data resource of the server corresponding to other fragment serial numbers is acquired. 9. The method of claim 1, further comprising: The client sends a request message carrying authentication information; The client receives a response message carrying information indicating that the authentication is passed. 10. The method of claim 1, wherein, sending a request message carrying a first fragment option, wherein the first fragment option includes the total number of fragments, or A response message carrying a second fragment option is received, wherein the second fragment option includes a total number of fragments. 11. A method for transmitting data resources of a server in pieces based on a lightweight application layer protocol in an Internet of Things system, characterized in that, The server receives the resource acquisition request sent by the client, the resource acquisition request carries a first capacity option field, and the first capacity option field is used to instruct the server to return the capacity of the data resource; The server sends a resource acquisition response to the client, the resource acquisition response carries a second capacity option field, and the second capacity option field is used to indicate the capacity of the data resource; The server receives a request message carrying a first fragmentation option, wherein the first fragmentation option includes a recommended fragmentation capacity, The server sends a response message carrying a second fragmentation option, where the second fragmentation option includes a determined fragmentation capacity, and the determined fragmentation capacity is less than or equal to the recommended fragmentation capacity; The server sends the data resource of the server in fragments according to the determined fragmentation capacity and the capacity of the data resource of the server; Wherein, according to the determined fragmentation capacity and the capacity of the data resource of the server, sending the data resource of the server in fragments includes: sending a resource transfer message carrying a third fragment option, where the third fragment option only includes a fragment sequence number, and the resource transfer message carries a fragment of the data resource of the server corresponding to the fragment sequence number data. 12. The method according to claim 11, characterized in that, judging according to the capacity of the received data resource of the server, if the capacity of the server's data resource is greater than its own storage capacity, sending a message indicating that the capacity of the server's data resource is too large status code. 13. The method of claim 11, wherein, Said receiving the request message carrying the first fragmentation option includes: receiving a request message carrying the first fragmentation option, including indication information for obtaining the data of the last fragmentation; Said sending the response message carrying the second fragmentation option includes: sending a response message carrying a second fragment option, wherein the second fragment option includes the total number of fragments, and the response message carries fragment data of the data resource of the server corresponding to the last fragment; According to the determined fragmentation capacity and the capacity of the server's data resources, sending the server's data resources in fragments includes: Send the fragmented data of the data resources of the server corresponding to other fragmentation numbers according to the fragmentation capacity and the total number of fragments. 14. The method of claim 11, wherein, Said receiving the request message carrying the first fragmentation option includes: receiving a request message carrying a first fragmentation option, where the first fragmentation option includes indication information that only negotiates fragmentation capacity; Said sending the response message carrying the second fragmentation option includes: Sending a response message carrying a second fragmentation option, where the second fragmentation option only includes the determined fragmentation capacity. 15. The method of claim 11, wherein, According to the determined fragmentation capacity and the capacity of the server's data resources, sending the server's data resources in fragments includes: According to the determined fragmentation capacity and the capacity of the data resource of the server, send the data resources of the server in fragments sequentially or in parallel. 16. A client device based on a lightweight application layer protocol in an Internet of Things system that transmits data resources of a server in fragments, wherein the client device includes: A sending unit, configured to send a resource acquisition request to the server, where the resource acquisition request carries a first capacity option field, and the first capacity option field is used to instruct the server to return the capacity of the data resource; a receiving unit, configured to receive a resource acquisition response returned by the server, where the resource response carries a second capacity option field, and the second capacity option field is used to indicate the capacity of the data resource; the sending unit is also for sending a request message carrying a first fragmentation option, where the first fragmentation option includes a recommended fragmentation capacity, The receiving unit is further configured to receive a response message carrying a second fragmentation option, wherein the second fragmentation option includes a determined fragmentation capacity, and the determined fragmentation capacity is less than or equal to the recommended fragmentation capacity ; a transmission unit, configured to receive the data resources of the server in pieces according to the determined capacity of the pieces and the capacity of the data resources of the server; Wherein, the transmission unit is specifically used for: receiving a resource transfer message carrying a third fragment option, wherein the third fragment option only includes a fragment sequence number, and the resource transfer message carries a fragment of the data resource of the server corresponding to the fragment sequence number data. 17. The client device of claim 16, wherein The transmission unit sequentially or concurrently receives data resources of the server in pieces. 18. The client device of claim 16, wherein the device further comprises: A storage unit, configured to store the determined fragment capacity. 19. The client device of claim 16, wherein the device further comprises: The authentication unit is used for sending and receiving authentication information. 20. A server device based on a lightweight application layer protocol in an Internet of Things system that transmits data resources of a server in fragments, wherein the server device includes: A receiving unit, configured to receive a resource acquisition request sent by the client, where the resource acquisition request carries a first capacity option field, and the first capacity option field is used to instruct the server to return the capacity of the data resource; a sending unit, configured to send a resource acquisition response to the client, where the resource response carries a second capacity option field, and the second capacity option field is used to indicate the capacity of the data resource; The receiving unit is further configured to receive a request message carrying a first fragmentation option, wherein the first fragmentation option includes a recommended fragmentation capacity, The sending unit is further configured to send a response message carrying a second fragmentation option, wherein the second fragmentation option includes a determined fragmentation capacity, and the determined fragmentation capacity is less than or equal to the recommended fragmentation capacity ; a transmission unit, configured to send the data resource of the server in fragments according to the determined fragment capacity and the capacity of the data resource of the server; Wherein, the transmission unit is specifically used for: sending a resource transfer message carrying a third fragment option, where the third fragment option only includes a fragment sequence number, and the resource transfer message carries a fragment of the data resource of the server corresponding to the fragment sequence number data. 21. The server device according to claim 20, wherein: The transmission unit is configured to actively send the data resource of the server in fragments according to the determined fragmentation capacity and the capacity of the data resource of the server. 22. The server device according to claim 20, wherein the server device further comprises: A storage unit, configured to store the determined fragment capacity. 23. The server device according to claim 20, wherein the server device further comprises: The authentication unit is used for receiving and sending authentication information.