CN107070990B

CN107070990B - Method and device for transmitting data resources

Info

Publication number: CN107070990B
Application number: CN201710131638.2A
Authority: CN
Inventors: 李克鹏; 田林一; 卞永刚; 陈显锋
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2011-03-17
Filing date: 2012-03-02
Publication date: 2021-04-09
Anticipated expiration: 2032-03-02
Also published as: CN107071826B; CN106850841B; CN106878442B; CN102685203A; CN106850841A; CN102685203B; CN102685204B; CN107070990A; CN102685204A; CN107071826A; CN102130954A; CN106878442A

Abstract

The embodiment of the invention relates to a method and equipment for transmitting data resources. A data resource transmission method based on nodes of a lightweight application layer protocol in an Internet of things system comprises the following steps: sending a request message carrying a response mode option to a server, wherein the response mode option represents one of the following response modes: a one-time immediate response, a deferred one-time response, a deferred multiple responses, and a cancellation of the deferred multiple responses; and receiving a response message which is sent by the server and generated according to the response mode option. According to the embodiment of the invention, the client can specify the required response by specifying the response mode option in the message interaction process, so that the message interaction efficiency of the CoAP is improved.

Description

Method and device for transmitting data resources

Technical Field

The embodiment of the invention relates to the field of network communication, in particular to a method and equipment for transmitting data resources.

Background

A lightweight Application Protocol (CoAP) is mainly used in a scene of an internet of things (Machine to Machine, abbreviated as "M2M"), for example: home controllers, building automation, intelligent energy, sensor networks, and the like. In such an environment, the functions of these machines are relatively simple, the processor generally has only 8 bits, the storage space is small, the complex transmission protocol is not supported, 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 a network. In the traditional scheme of data transmission based on CoAP, the accurate capacity of data resources is not calculated, and the accurate number of sub-packets cannot be evaluated, so that the data resources cannot be acquired concurrently, and the transmission efficiency is low.

Disclosure of Invention

The embodiment of the invention provides a method and equipment for data resource transmission, which can support the improvement of transmission efficiency in CoAP.

In an embodiment of the present invention, a method for transmitting data resources of a node based on a lightweight application layer protocol in an internet of things system is provided, including: sending a request message carrying a response mode option to a server, wherein the response mode option represents one of the following response modes: a one-time immediate response, a deferred one-time response, a deferred multiple responses, and a cancellation of the deferred multiple responses; receiving a response message which is sent by the server and generated according to the response mode option

In an embodiment of the present invention, a method for transmitting data resources of a node based on a lightweight application layer protocol in an internet of things system is provided, including: receiving a request message which is sent by a client and carries a response mode option, wherein the response mode option represents one of the following response modes: a one-time immediate response, a deferred one-time response, a deferred multiple responses, and a cancellation of the deferred multiple responses; and sending a response message generated according to the response mode option to the client.

In an embodiment of the present invention, a client for transmitting data resources of a node based on a lightweight application layer protocol in an internet of things system is provided, including: a sending module, configured to send a request message carrying a response mode option to a server, where the response mode option represents one of the following response modes: a one-time immediate response, a deferred one-time response, a deferred multiple responses, and a cancellation of the deferred multiple responses; and the receiving module is used for receiving the response message generated according to the response mode option.

In an embodiment of the present invention, a server device for transmitting data resources of a node based on a lightweight application layer protocol in an internet of things system is provided, including: a receiving module, configured to receive a request message carrying a response mode option sent by a client, where the response mode option represents one of the following response modes: a one-time immediate response, a deferred one-time response, a deferred multiple responses, and a cancellation of the deferred multiple responses; and the sending module is used for sending a response message generated according to the response mode option to the client.

According to the embodiment of the invention, the client can specify the required response by specifying the response mode option in the message interaction process, so that the message interaction efficiency of the CoAP is improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required to be used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without inventive labor. In the drawings:

FIG. 1 is a flow chart of a method of transmitting data in accordance with one embodiment of the present invention;

FIG. 2 is a flowchart illustrating an implementation of a gateway obtaining data resources from sensors according to an embodiment of the present invention;

FIG. 3 is a block diagram of an improved slicing option in one embodiment of the present invention;

FIG. 4 is a flowchart of a specific implementation of a gateway obtaining data resources from sensors in accordance with an alternative embodiment of the present invention;

FIG. 5 is a block diagram of an improved sharding option in an alternative embodiment of the present invention;

FIG. 6 is a flowchart of a specific implementation of a gateway obtaining data resources from sensors in accordance with an alternative embodiment of the invention;

FIG. 7 is a block diagram of an improved sharding option in an alternative embodiment of the present invention;

FIG. 8 is a flowchart of a specific implementation of a gateway sending data resources to a sensor according to one embodiment of the invention;

FIG. 9 is a block diagram of a client device of one embodiment of the invention;

FIG. 10 is a block diagram of a server device of one embodiment of the invention;

FIG. 11 is a flow chart of a method of transmitting data in accordance with one embodiment of the present invention;

FIG. 12 is a flow chart of a method of transmitting data in accordance with one embodiment of the present invention;

FIG. 13 is a block diagram of a client transmitting data in accordance with one embodiment of the present invention;

fig. 14 is a block diagram of a server for transmitting data according to an embodiment of the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, not all, embodiments of the present invention. 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.

CoAP is based on User Datagram Protocol ("UDP") for transmission and is based on a connectionless message processing mode. The interaction mode can be synchronous response or asynchronous response. The message types may be: a message requiring Acknowledgement (confirmation), a message not requiring Acknowledgement (Non-confirmation), an Acknowledgement (Acknowledgement), a Reset message (Reset). A pair of request and response may be associated by a Message identification (Message ID).

There are four methods supported by CoAP: acquiring a resource (Get), updating the resource (Put), creating the resource (Post) and deleting the resource (Delete). Resources are identified by a Representational State Transfer (REST) URI. We generally refer to the owner of the resource as a node or a server, including but not limited to a sensor, a controller, an End-point (End-point), and the like, and the resource requesting party is a client, including but not limited to a gateway (Proxy), a network side device.

The CoAP protocol supports different options (options) to interpret the semantics of the data in the CoAP message body, such as Block (fragmentation), Location (Location), Token (Token) options, etc., which support different functionalities and can be extended by defining a new Option.

The CoAP supports a Block Option (Block Option), and is mainly used for carrying out Block transmission on a larger resource so as to adapt to an application scenario of low-bandwidth transmission. The Block option may be 1 byte, 2bytes, or 3 bytes, and is selected according to the length required by the capacity of the number of fragments.

In the traditional scheme, the accurate capacity of data resources is not calculated, and the accurate number of the sub-packets cannot be evaluated, so that the sub-packets cannot be acquired concurrently. It is also unknown whether the resource is static or dynamic.

In the following description, the owner of the resource is generally referred to as a server, taking a sensor as an example, and the resource requesting party is referred to as a client, taking a gateway as an example. However, the sensor or gateway is not used as a limitation to the server or client.

Because the precise capacity of the target resource is not known, when the gateway uses the Block Option in the < Get > command, the gateway can only obtain the Block 0 in sequence, namely, the gateway selects to obtain the Block 0, and when the Block 0 returns, the gateway obtains the Block 1 until the last Block. The < Get > request cannot be sent concurrently.

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

NUM represents the sequence number of the segment, and may be an unsigned integer number of 4 to 20 bits. 0 denotes the first slice.

M: and using a bit to indicate whether other fragments exist behind the current fragment, wherein the value of 1 indicates that the fragments exist behind the current fragment, and the value of 0 indicates that the fragments do not exist behind the current fragment, namely the last fragment.

SZX: the method is used for representing the fragment capacity and has the calculation formula as follows: the fragmentation capacity is 2^ (SZX +4), i.e. 2 to the power of (SZX + 4). Because SZX is represented by 3 bits, the value of SZX can be 0 to 7, and the range of slice capacity: 2^4 to 2^11, namely 16 to 2048.

The use of the Block option is explained as follows:

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

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

When the gateway acquires the first fragment (Block) by using a < Get > method, NUM is set to 0 and carries the suggested fragment capacity (namely SZX), the sensor node can select to agree with the suggested fragment capacity or select a fragment smaller than the suggested fragment and return the fragment in a response, and simultaneously return the data of the first fragment in the response.

In the invention, the gateway is considered to know the accurate capacity of the target resource in advance, so that the gateway can select whether to use Block Option to send the request for acquiring the resource, and can also realize concurrent requests, namely, the gateway can request Block 1 at the same time of requesting Block 0 without waiting. The order in which blocks are requested can also be flexibly handled.

In a simple design scheme, the Block Option has three options, which can be one byte, 2bytes or three bytes, and the number and the capacity of the slices (blocks) are different according to the different capacities of the resources, and the required lengths are different. The protocol states that the capacity of the fragments must be the same except for the last fragment, but each time during each transmission, it is still necessary to carry M bits (indicating whether there are fragments behind) and SZX (capacity of fragments).

Each time in the request and the response, both the M bit and the SZX bit need to be transmitted, while in practice, the values of M bit and SZX are the same each time except for the last slice, and the repeated transmission wastes transmission resources. The aim of repeatedly sending the SZX is to assume that both sides do not store the negotiated SZX, the negotiated SZX is carried in the first response, and the gateway acquires the negotiated SZX from the response and sends the negotiated SZX in the request again, so that the gateway and the sensor do not need to store the state. In one request response round, one byte is wasted, if the number of fragments is large, the wasted bytes are large, and for the M2M device, the transmission resource is limited, and the waste of the transmission resource is considerable. Assuming that the data to be transmitted is 64M, the number of Block entries sent is 1024 bytes per Block with a load (payload) capacity: 65536. the number of the sent Block options divided by bytes is as follows:

(1) one byte: 16 are provided with

(2) Two bytes: 4080 pieces

(3) Three bytes: 61440 pieces of

If M and SZX may not be sent, the data that the request plus response can save is 65536 bytes (byte), i.e., 64K of data. In addition, if these two fields are not needed, the NUM field can be full of all bits (bits), and the number of packets that need to be sent is changed to:

(1) one byte: 256 of the above-mentioned raw materials

(2) Two bytes: 65280 there are

At this point, there is no need to send a 3-byte structure, and thus data can be saved at 61440 × 2bytes, i.e., 60K of data. The total saving in data bits 124K is 0.189% data rate. The percentage of head-space savings was (16+4080 x 2+61440 x 3-256 and 65280 x 2)/(16+4080 x 2+61440 x 3) ═ 61680/192496 x 32%.

Formula to save data volume:

t is the total number of blocks, S is the fragmentation Size, percentage of saved traffic (compare header only):

t < 16: no savings are made; both are one byte;

16< T < 256: 1-T1/(16 x 1+ (T-16) × 2), a simple design requires 2bytes, preferably only one byte;

256< T < 4096: 1- (256 x 1+ (T-256) × 2))/(16 x 1+ (T-16) × 2), 2bytes are required for a simple design scheme, and 2bytes are required for a preferred scheme;

4096< T < 65256: 1- (256 × 1+ (4096-.

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

In a simple design scheme, when a Put/Post command is used, the negotiation of the fragmentation capacity lacks efficiency. In the Put/Post request, for the first fragment, the data of the first fragment and the recommended fragment capacity need to be sent, and if the sensor node selects different fragment capacities and the gateway needs to resend the data according to the fragment capacity of the sensor, the fragment data sent last time is wasted. And when the gateway uses Put/Post to request to send the resource with large capacity based on the fragment option, the gateway cannot inform the sensor of the resource capacity information in advance, during the transmission process, the sensor buffers the received resource while receiving, if the sensor finds that the storage space is insufficient and the resource is not transmitted completely, the gateway can only send back an error status code of 413 to indicate that the requested resource is too large, and the transmission is finished. Part of the resources transmitted before are not used, 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 fragmentation message, the sensor can compare the resource capacity information with the storage capacity, and if the capacity is insufficient, a status code of 'the requested resource is too large' is returned 413 in advance to end the resource transmission, so as to achieve the purpose of saving the transmission resource.

The breakpoint on the internet is to continue downloading from the place where the file has been downloaded. When the gateway requests data from the sensor, it adds a message to indicate the Range (Range) of the requested data, indicating where to start.

For example, a gateway uses a browser to pass request information to a Web sensor, requiring that 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

in which, the bytes is 2000070-and this line means telling the sensor down that this file is transmitted from 2000070 bytes, and the previous byte is not transmitted.

The disadvantage of this scheme is that there is no fragmentation mechanism, and it does not support negotiation of fragmentation capacity, nor negotiation of fragmentation total number. The embodiment of the invention considers the negotiation of the fragmentation capacity and/or the fragmentation total number in the fragmentation transmission process. The invention provides a data fragment transmission method, which can acquire the accurate capacity of target data resources, carry out the negotiation of the fragment capacity, acquire the total number of fragments and transmit the data resources according to the total number of fragments.

The flow of one embodiment of the present invention is specifically described below with reference to fig. 1. FIG. 1 is a flow chart of one embodiment of the present invention.

In the S110 process, capacity information of the data resource of the node is acquired. If the gateway acquires data from the sensor, the data resource capacity information of the node is stored on the sensor. The gateway can acquire 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 locally knows the capacity information of the data resource of the node. And acquiring the data resource capacity information of the node, and preparing for carrying out negotiation of the fragment capacity and determining the total number of fragments in the next step.

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 the recommended fragmentation capacity. After receiving the request message sent in S120, the sensor determines the fragment capacity used in the data resource transmission process according to its own capacity, and the fragment capacity determined by the sensor is less than or equal to the fragment capacity recommended by the gateway.

In 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. And 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 grasped data resource capacity information of the node.

Then, in S140, the data resource is transmitted in a fragmentation manner according to the determined fragmentation capacity and the data resource capacity information of the node.

According to the embodiment of the invention, the capacity information of the data resource needing to be transmitted can be obtained, and the fragment capacity used in data transmission is determined through the negotiation of the fragment capacity, so that the error rate in the transmission process can be reduced, and the data can be transmitted concurrently.

The following describes a specific implementation process of the embodiment shown in fig. 1 with reference to fig. 2. Fig. 2 shows an illustrative example of a gateway acquiring data from a sensor, which is merely illustrative of the concepts of the present invention and is not intended to be a limitation of the present invention.

The data resource acquisition process shown in fig. 2 is specifically described as follows:

ES 210: the gateway sends a resource discovery request to the sensor, namely a resource list on the sensor is obtained through get/webknown/core.

ES 220: the sensor returns a resource list and resource indication information to the gateway; the resource indication information mainly includes addressing information (i.e., URI) of the resource, a resource name, resource description information, a content type, and the like. The invention expands the resource indication information, and the expanded resource indication information comprises the following components: indication information of whether a resource is a dynamic resource or a static resource.

ES 230: the gateway selects the target resource from the resource list returned by the sensor according to the indication information of the resource, and acquires the target resource according to the identification mark (information capable of uniquely identifying the resource, such as resource name, URI and the like).

ES 240: the sensor judges the capacity of the target resource, and if the capacity of the resource is smaller than the capacity of a transmission layer message packet, the resource content is directly returned to the gateway; if the resource capacity exceeds the capacity of one transport layer message packet, resource capacity information is returned. Alternatively, the sensor may use the slicing option to directly return to the first slice according to its determined slicing capacity. Subsequent clients and sensors transmit the following slices using the slice option according to the determined slice capacity.

In an alternative embodiment of the present invention, if the target data resource is a dynamic data resource, a dynamic data resource indicator is returned to the gateway, and the gateway is instructed to use the Block option to acquire the resource with the 413 status code "request resource too large".

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 the resource is a static resource, the resource capacity information in the indication information is accurate capacity information. It will be appreciated by those skilled in the art that if the data resource is a dynamic resource, the sensor may send a check code of the resource snapshot and the gateway may subsequently send a new resource acquisition request if more fresh data is required.

ES 250: and the gateway judges that the fragmentation option needs to be used according to the data resource capacity information, sends a request message carrying the fragmentation option, performs fragmentation capacity negotiation with the sensor and indicates the recommended fragmentation capacity.

ES 260: and the sensor determines the fragment capacity according to the capacity of the sensor and returns the fragment capacity to the gateway. Optionally, the sensors return the total number of slices at the same time. Of course, since the gateway already obtains the data resource capacity information, the total number of fragments may 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.

ES 270: and the gateway sends requests to the sensor from 1 to the total number of the fragments in sequence to acquire the fragment data of the data resource corresponding to the fragment sequence number.

ES 280: and the sensor returns the fragment serial number and the fragment data of the data resource corresponding to the fragment serial number according to the determined fragment capacity until the complete transmission is finished.

According to a preferred embodiment of the present invention, parallel processing may be implemented in the ES270, that is, the gateway may request to acquire multiple fragment messages at the same time without waiting for the sensor to return a response message to the previous fragment request message.

The codes of the ESs 210 to ES240 are, for example:

REQ, GET/. well-know/core-sends a request to a default URI, namely a root directory acquisition resource list;

RES, 200OK, response mark is successfully obtained, and 2 groups of resource indication information are carried;

REQ GET/sensors/firmware-request firmware resource

The RES:413 "Request Entity Too Large" Size:88000.413 status code indicates that the requested resource is Too Large, with an exact Size of 88000 bytes.

If the data resource is a dynamic resource, that is, the data resource changes dynamically during the transmission process, for example, the following two schemes may be adopted to implement the processing:

(1) when data resources are transmitted, Snapshot (Snapshot) is established for the resources, namely capacity information of the data resources at the moment is cached, and the capacity information is transmitted regardless of subsequent changes; corresponding to the scheme.

(2) If the data resource is modified in the transmission process, the sensor can return an error code in any response message of the request message for acquiring the data resource, which indicates that the data resource is changed and the gateway needs to acquire the data resource again.

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

for example, the algorithm of the key may be: digest is MD5(ID: passed), that is, a character string composed of the ID and the passed is hashed (Hash) by using an MD5 algorithm, and the Hash value is Digest. And the sender sends the ID and the Digest, the receiver obtains the Digest according to the received ID and the prestored Password and the same algorithm, and compares the Digest with the Digest sent by the sender, if the Digest is consistent, the authentication is passed.

When the gateway acquires the data resource from the sensor, as shown in fig. 2, it needs to know the data resource capacity information. According to an embodiment of the present invention, the gateway may employ the following scheme to acquire the data resource capacity information stored in the sensor.

(1) Extended Link-format (Link-format) keywords

In Link-format, a key, -sn, or-snapshot is extended to indicate whether the resource data is snapshot data in the response to the get data resource request. If the parameter does not exist or the value of the parameter is 0, the parameter indicates that the resource is a static resource, and if the value of the parameter is 1, the parameter 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 over time, i.e., the content of the resource does not change frequently. Specific meanings may be defined in the standard. In the present invention, the case where the value of the resource does not change is mainly referred to.

The keywords are also expanded: asz, information indicating the exact capacity of the resource.

Message example:

the gateway sends a request for resource discovery to the sensor:

REQ GET/. well-know/core-sends a request to the default URI, i.e. the root directory GETs the resource list

The sensor sends the response of the resource to the gateway:

RES 200OK- -response identification acquisition success, and carries 2 groups of resource indication information

This response message is encapsulated in the message body of the CoAP message and the receiver (i.e., gateway) parses it according to the specifications in the Link-format standard.

(2) Incrementing a status code

When receiving a data resource acquisition request of a gateway, if the resource is too large and a packet cannot be transmitted, the sensor informs the gateway by using a status code to indicate that the resource is too large and a Block Option is required to request.

For example, a status code 413 may be specified to indicate that the current data resource is over-capacity, indicating that the gateway is using the Block option in the request. Other status codes may be defined as desired for other meanings and for other purposes.

Message example:

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

GET/sensordata

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

ACK 413 (status code, indicating too large capacity of data resources)

(3) Adding an Option (Option) for indicating the capacity (Size) in the head field (Header) of the CoAP

The gateway can indicate the sensor with a capacity Option (Size Option) in the request, and the sensor returns the capacity of the data resource; the sensor indicates the capacity of the data resource in response with Size Option.

Alternatively, even if the gateway does not have the indication of the Size Option, the sensor indicates the resource capacity with the Size Option in the response, and particularly, the sensor should indicate that the resource is large.

If the resource is small and the sensor returns the resource data directly in the Body of the message (Body), the gateway should be based on 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 larger, the sensor does not return the resource data, only the Size Option is used for returning the capacity of the data, and the status code is used for indicating the gateway, so that the gateway initiates a new request and uses the Block Option for requesting.

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

Message example:

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

GET/sensordata

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

ACK +413+ Size 51200(50K bytes)

The following describes a specific implementation process of the embodiment shown in fig. 1 with reference to fig. 3. Fig. 3 shows an illustrative example of a gateway sending data to a sensor, merely to illustrate the inventive concept and not as a limitation of the invention.

When the gateway acquires the first fragment (Block) data by using a < Get > method, the NUM field is set to be 0 and carries the recommended fragment capacity (namely SZX), the sensor can select the recommended fragment capacity agreed or select a fragment capacity less than or equal to the recommended fragment capacity, and return the fragment capacity in the response, and at the same time, return the fragment data of the first fragment in the response. Therefore, when the NUM field is 0, the < Get > request has dual semantics, namely acquiring the first fragment data and negotiating the fragment capacity. This makes the protocol ambiguous in terms of processing and also makes it impossible to carry information such as data capacity.

In an embodiment of the present invention, when the gateway uses Block Option in the request of the < Get > method, if the NUM field is set to 0, it indicates that both parties only perform negotiation of fragmentation capacity and negotiation of fragmentation total number. That is, the sensor returns the total number of slices in the response by using the NUM field and returns the capacity of the slices determined by the sensor by using the SZX field. The M field may be removed, saving one Bit for the NUM field. Since the requesting party, e.g. the gateway, knows the total number of fragments, it can know from the NUM field of the fragment whether the fragment is the last fragment, and therefore, it is not necessary to reuse the M field. In this case, if the fragment data of the first fragment is requested to be acquired, NUM is set 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, the Block Option may use one byte, and if the data resource of the sensor is larger and the number of fragments is larger, the sensor may use two bytes or three bytes in the response to return the total number of fragments.

When the Block Option is 2bytes, the Block Option is designed to be that the SZX field occupies the last three bits of the second byte, and the fragment capacity is represented; the NUM field occupies the first byte plus the first 5 bits of the second byte and represents the current fragment sequence number; and if the number is in the response message corresponding to the request with NUM being 0, the total number of the fragments is represented. Those skilled in the art will appreciate that the request and the response may be associated by a Message identifier (Message ID), i.e. both the request and the response carry a unique transaction identifier, so that the sensor can understand that the response Message is for returning the total number of fragments.

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

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

GET 00000101(NUM 0, SZX 101, i.e. 5, 9 power of 2 for slice capacity, i.e. 512)

Response sent by the sensor to the gateway:

ACK 10000100 (NUM 10000, i.e. total number of fragments is 32, SZX 100, i.e. 4, 8 power of fragment capacity is 2, i.e. 256)

This design saves one Bit (Bit), i.e., M bits, and has the technical advantages of saving data traffic and making no major changes to existing designs. In such an embodiment, the fragmentation capacity (SZX) field is still to be transmitted at a time.

In the prior art, the fragmentation capacity (i.e. SZX field) is sent each time, whether in a request message or in a response message, all the fragmentation capacities are the same except that the fragmentation capacity used in the first and last fragments may be different. Repeating the transmission of the same NUM field to each other wastes transmission resources.

In the embodiment of the invention, when the gateway uses the Block Option in the request of the < Get > method, if NUM is set to 0, it indicates that both parties only carry out negotiation of fragmentation capacity and negotiation of fragmentation total number. That is, the sensor returns the total number of slices in response using the NUM field and returns the capacity of the slices determined by the sensor using the SZX field. And both the gateway and the sensor store the determined fragmentation capacity for subsequent fragmented data transfer messages. Except for the last sliced data. In the request of the following < Get > method, the gateway only sends the current fragment serial number requested, but not sends the determined and unchanged fragment capacity, and the sensor only sends the current fragment serial number and the fragment data corresponding to the fragment serial number in the response message, and does not send the fragment capacity any more. In this case, when NUM is 1, it means that the fragment data of the first fragment is requested, and so on.

Taking the example of using a < GET > command to retrieve a data asset from a sensor, the above embodiment is described,

as shown in FIG. 3, the new Block Option is designed as follows:

where structure (1) is used for the case where NUM is 0:

in the < Get > request, NUM is 0, SZX is the second byte, which represents the fragment capacity, and Total Number represents the Total Number of fragments, which are not used in the request and do not need to be carried; in the < Get > response, NUM is 0, SZX represents the slice capacity determined by the sensor, and Total Number represents the Total Number of slices.

In the prior art, the interval of the fragmentation capacity is large, such as 2048, 1024 and 512, which is not flexible enough. In practice, 512 is small for a Block, and preferably just can be put into a UDP packet, i.e. 1472 bytes. The present invention improves this, and in one embodiment, for SZX, a new formula can be adopted, such as: (SZX +1) × 8, then the range may be: 8 to 2048, but the decrement interval is 8.

Structure (2) and structure (3) in fig. 3 are used for the case where NUM in the < Get > request is not 0, that is, the case when fragment data is acquired:

when NUM is less than 256, the fragment sequence number is represented by one byte, namely the structure (2); when NUM is greater than 8 powers of 2 (i.e., 256) and less than 16 powers of 2 (i.e., 65536), two bytes are used to represent the slice sequence number, i.e., structure (3).

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

Examples of messages are illustrated below:

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

GET 0000000000000101 (NUM 0, SZX 101, i.e. 5, representing the slicing capacity 2 to the power of 9, i.e. 512)

Response sent by the sensor to the gateway:

ACK 00000000000001000000000000010000 (NUM is 0, Total Number is 10000, i.e. Total Number of slices is 32, SZX is 100, i.e. 4, indicating that the capacity of a slice is 2 to the power of 8, i.e. 256).

By redesigning the Block Option, at least 4 bits can be sent in each request or response, and under the condition of more fragments, the transmission efficiency can be greatly improved, transmission resources can be saved, and the processing efficiency of both the gateway and the sensor can be improved.

Fig. 4 shows an alternative embodiment of the invention. In the embodiment shown in fig. 4, the ESs 410 to ES420 are the same as the ES210 to ES240 of the embodiment shown in fig. 2, and a description thereof will not be repeated.

In the embodiment shown in fig. 4, in ES450, the gateway sends a < GET > request to the sensor, performing slice capacity negotiation using the slice option, indicating the recommended slice capacity of the gateway. In ES460, the sensor selects and determines the appropriate fragmentation capacity for fragmenting the resource and pushes all fragmented data to the gateway proactively without the gateway having to issue a < GET > request.

In the process of acquiring data resources in the embodiment of fig. 4, the design of the fragmentation option is as shown in fig. 5, where:

the structure (1) is used for the gateway to send a < GET > request to the sensor, the SZX field indicates the fragment capacity recommended by the gateway, the fragment capacity finally selected and determined by the sensor is smaller than or equal to the fragment capacity recommended by the gateway, NUM is 0 and indicates that the gateway requests complete resources, NUM is not 0 and indicates that the gateway requests specific NUM fragment data, and the sensor can only use the fragment capacity indicated by the SZX field when NUM is not 0.

The structure (2) and the structure (3) are used for the sensor to return a fragment response message of a complete resource to the gateway, if a response to a specific fragment data request does not need to carry a fragment option, the M field in the structures (2) and (3) indicates whether the fragment is the last fragment, if the M field is 0, the fragment is the last fragment, a value of 1 indicates that the fragment is not the last fragment, and the NUM field indicates that the sensor returns the number of fragments.

The following examples are given. Examples of messages are:

the gateway sends a request for acquiring data resources to the sensor:

CON GET 0000000000000101 (NUM 0, SZX 101, i.e. 5, representing slice capacity 2 to the power of 9, i.e. 512)

Response sent by the sensor to the gateway:

ACK 20000000011 (NUM is 1, M is 1, which indicates the first fragment sent and is not the last fragment, and the fragment size is the size specified by the SZX field);

the sensor continues to send CoAP responses to the gateway:

CON 20000000101 (NUM is 2, M is 1, indicating the second fragment transmitted and not the last fragment, the fragment size being the size specified by the SZX field);

the gateway returns an ACK response to the CON;

the sensor sends the last fragment to the gateway:

CON 20000000110 (NUM 3, M0, indicating the third slice transmitted and the last slice, the specific slice size being calculated from the actual read data).

According to the embodiment shown in fig. 4, when the gateway acquires the complete data resource from the sensor, only the negotiation of the fragment capacity needs to be completed, and a large number of fragment data acquisition requests do not need to be sent, so that the data transmission flow is greatly saved.

Fig. 6 shows another alternative embodiment of the invention. In the embodiment shown in fig. 6, the ESs 610 to ES640 are the same as the ES210 to ES240 of the embodiment shown in fig. 2, and thus the description will not be repeated.

Fig. 6 differs from the embodiment shown in fig. 2 in that, in ES650, the gateway sends a < GET > request to the sensor requesting to acquire a resource, and uses a fragmentation option indicating the fragmentation capacity recommended by the gateway, where the NUM field is filled with a value of 0 indicating that the last fragmentation is requested to be acquired; in ES660, the sensor returns the determined fragment size and the sequence number of the last fragment and the fragment data corresponding thereto in response to the gateway request. Since the last fragment sequence number corresponds to the total number of fragments, in ES670, the gateway may sequentially or concurrently obtain requests for other fragment data. In ES680, the sensor returns the serial number of the fragment and the corresponding fragment data according to the determined fragment size. The ES670 and ES680 may interact multiple times until the fragmented data is transferred.

The fragmentation option used in the embodiment of fig. 6 is as shown in fig. 7, for example, a two-byte fragmentation option, which only includes a NUM field and an SZX field.

As illustrated below in conjunction with fig. 6 and 7, examples of messages are:

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

CON GET 0000000000000101 (NUM is 0, indicating that the last fragment is required to be acquired, SZX is 101, i.e. 5, indicating that the recommended fragment size is 9 powers of 2, i.e. 512).

Response sent by the sensor to the gateway:

ACK 0000000001000101 (NUM is 1000, i.e. 8, indicating that the 8 th fragment is returned, SZX is 101, i.e. 5, indicating that the determined fragment capacity is the 9 th power of 2, i.e. 512);

according to the first returned information, the gateway already knows that the total number of the 8 fragments is 8, and obtains the data of the 8 th fragment, and the gateway continues to send a CoAP request to the sensor, and can sequentially obtain or concurrently obtain the rest fragment data. The following message examples are requesting to obtain fragment data of the first fragment:

CON GET 0000000000001101 (NUM is 1, which indicates that the first fragment is required to be acquired, SZX is 101, i.e. 5, which indicates that the fragment capacity is 9 powers of 2, i.e. 512);

the sensor returns an ACK response to the CON, namely the data of the first fragment;

the gateway may request all remaining fragments in sequence or concurrently until all data is acquired.

According to the embodiment shown in fig. 6, the fragment data of the last fragment can be acquired while the fragment capacity is negotiated, and the fragment capacities used in the subsequent fragment data acquisition process are the same, so that in combination with the description of the foregoing preferred embodiment, the gateway can send the request for acquiring the fragment data without sending the SZX field but only the NUM field, thereby saving data traffic and improving transmission efficiency.

FIG. 8 illustrates an embodiment when a sharding option is used to send data to a sensor, such as using a resource creation (Post) or update (Put) request. This is described in detail below in conjunction with fig. 8.

The detailed flow shown in fig. 8 is explained as follows:

ES 810: the gateway sends a resource creation (Post) or update (Put) request message to the sensor, sends the capacity information of the resource by using the Size option, and indicates the recommended fragment capacity and the total number of fragments by using the fragment option, wherein the total number of fragments is calculated based on the recommended fragment capacity and the capacity of the data resource to be sent, and the request message body does not carry specific resource data.

ES 820: if the sensor is willing to receive the data, the status code is returned to be 100 (namely, the client is instructed to continue sending), and meanwhile, the determined fragmentation capacity is returned to the gateway, and the determined fragmentation capacity can only be smaller than or equal to the fragmentation capacity recommended by the gateway; if the sensor is not willing to receive this data, an error code is returned indicating that the client is not to continue sending data. For example, if the storage capacity of the sensor is not sufficient to store the data of the indicated resource capacity, a return code of 413 "Request Entity to Large" is returned.

ES 830: the gateway judges whether the fragment capacity is the same as the recommended fragment capacity or not according to the determined fragment capacity returned by the sensor, and if the fragment capacity is the same as the recommended fragment capacity, the gateway jumps to an ES 360; and if not, recalculating the total number of the fragments according to the determined fragment capacity information returned by the sensor and the data resource capacity.

ES 840: the gateway resends the determined fragment size and the recalculated fragment total to the sensor.

ES 850: the sensor returns the determined slice capacity.

ES 860: and the gateway sends the fragment data of the data resource corresponding to the fragment sequence number to the sensor in sequence from 1 to the total fragment number until the transmission is completed.

ES 870: the sensor returns a message confirming the reception, which contains the received fragment sequence number.

According to a preferred embodiment of the present invention, parallel processing may be performed in the ES860, that is, the gateway may simultaneously send a plurality of pieces of data to the sensor without waiting for the sensor to return a response message to the previous piece of data. Optionally, in accordance with a preferred embodiment of the present invention, the gateway and the sensor add authentication information in the message interaction. The configuration and interaction of the authentication messages may be in 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, the sensor informs the recommended capacity of the slice and the total number of slices instead of sending the first slice data. The sensor may return a response telling the gateway whether to continue sending data. In response, the sensor returns the total number of the fragments by using the NUM field, and returns the fragment capacity determined by the sensor by using the SZX field. And both the gateway and the sensor store the determined fragmentation capacity for subsequent fragmented data transfer messages. Except for the last sliced data. In the request of the subsequent < Put >/< Post > method, the gateway only sends the requested current fragment serial number, but not sends the determined and unchanged fragment capacity, and the sensor only sends the current fragment serial number and the fragment data corresponding to the fragment serial number in the response message, and does not send the fragment capacity any more. 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 slicing option is designed and used in a manner similar to that shown in FIG. 3, and is described below with reference to FIG. 3. In the < Put >/< Post > request, the NUM field is 0, the SZX field is the second byte and represents the recommended fragment capacity, and the Total Number represents the Total Number of fragments to be sent; in the response of < Put >/< Post >, the NUM field is 0, the SZX field represents the fragment 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, the new SZX is needed to send the < Put >/< Post > request again, and the recalculated total number of the fragments is carried, and the sensor sends back a response again. Later in < Put >/< Post > requests and responses, the SZX field is no longer carried.

By redesigning the fragmentation option, at least 4 bits can be reduced in each request or response, and under the condition of more fragments, the transmission efficiency can be greatly improved, the transmission resource can be saved, and the processing efficiency of both the gateway and the sensor can be improved.

In addition, in the prior art, in each request of fragment transmission, a Uniform Resource Identifier (URI) of a requested Resource needs to be carried, usually, the URI occupies dozens of bytes to dozens of bytes, and repeated transmission wastes transmission resources.

Fig. 9 is an embodiment of a client device for transmitting data resources via fragmentation in accordance with the present invention. The client device 900 shown in fig. 9 includes: an obtaining unit 910, configured to obtain data resource capacity information; a sending unit 920, configured to send a request message carrying a fragment option, where the fragment option includes a recommended fragment size, and a receiving unit 930, configured to receive a response message carrying a fragment option, where the fragment option includes a determined fragment size; and a transmission unit 940, configured to transmit the data resource in a fragmented manner according to the determined fragment capacity and the data resource capacity information.

According to a preferred embodiment of the present invention, the client device may further comprise a storage unit 950 for storing the determined fragmentation capacity. So that the SZX field need not be sent every time during the transmission of data resources.

According to another preferred embodiment of the present invention, the client device may further comprise an authentication unit 960 for sending and receiving authentication information.

Fig. 10 is an embodiment of a server device for transmitting data resources by fragmentation according to the present invention. The server apparatus 1000 shown in fig. 10 includes: a receiving unit 1010, configured to receive a request message carrying a fragmentation option, where the fragmentation option includes a recommended fragmentation capacity; a sending unit 1020, configured to send a response message carrying a fragmentation option, where the fragmentation option includes a determined fragmentation capacity; and a transmitting unit 1030, configured to transmit the data resource in a fragmentation manner 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 transmitting unit 1030 transmits the data resource in a fragmentation manner according to the determined fragmentation capacity and the data resource capacity information.

According to an embodiment of the present invention, the transmission unit 1030 may actively transmit data in slices without a client device requesting each sliced data when a request is received.

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

According to another preferred embodiment of the present invention, the server device may further include an authentication unit 1050 for transmitting and receiving authentication information.

According to the embodiment of the invention, the gateway can acquire the capacity information of the target resource and is used for deciding whether to acquire the resource in a fragmentation mode, so that the possibility of error is avoided, the fragmentation can be requested concurrently, the efficiency of data request is improved, the capacity of the resource is acquired, the storage space is conveniently allocated, and the number of the fragmentation is calculated.

By redesigning the fragmentation option, at least 4 bits can be sent in each request or response, and under the condition of more fragments, the transmission efficiency can be greatly improved, the transmission resource can be saved, and the processing efficiency of both parties can be improved.

In the prior art, after receiving a request from a client, a server may immediately send back a response, or may send back an ack (acknowledgement) response message first, indicating that the request message is received, and after processing, the response message, i.e., a deferred response, is being processed and the subsequent processing is completed. In addition, the client can subscribe a resource change, and the server sends a notification message back to the client once the resource information changes after receiving the subscription of the client to a certain resource.

The prior art does not satisfy the following requirements:

1. the client indicates the server in the request, which way the client needs to respond;

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

3. in the transmission process of the notification message, because the transmission capability of the network is unstable, the notification message sent by the server first may arrive at the client later than the message sent by the server later. Thus, the resource information received by the client is actually old information, and the client needs to have a mechanism capable of detecting the order of the plurality of notification messages.

FIG. 11 is a flow chart of one embodiment of the present invention. In the embodiment shown in fig. 11, in S1110, the client sends a request message to the server, where the request message carries a Response mode option, where the Response mode option may be a Deferred Response (Deferred Response) option or a Token (Token) option, and is used to indicate whether the server and the client receive a Deferred Response. For example, the response mode option represents: a one-time immediate response, a deferred one-time response, a deferred multiple responses, and a cancellation of the deferred multiple responses. If the response mode option is not carried, the server can determine whether to adopt a one-time immediate response or a delayed one-time response by default. Then, in S1120, the client may receive a response message generated according to the response mode option, which is transmitted by the server.

In the prior art, after receiving a request from a client, a server may immediately send back a response, or may send back an Ack first, indicating that a request message is received, and after processing, the response message, i.e., a deferred response, is being processed and is completed subsequently. In addition, the client can subscribe a resource change, and the server sends a notification message back to the client once the resource information changes after receiving the subscription of the client to a certain resource.

In one embodiment of the present invention, a one-byte delay (delayed) option may be used to indicate the response mode, wherein the first two bits (Bit) may be used for representation, and denoted by C:

c is 00, which represents one-time immediate response;

c-01, indicating a delayed one-time response;

c is 10: multiple responses, i.e., subscriptions, representing deferrals;

c-11: multiple responses indicating a cancellation of the deferral, i.e. a cancellation of the subscription.

For the subscription initiated by the client for a certain resource, the client may cancel the subscription, or the server may cancel the subscription, for example, the server sends back a response message to the client that needs to be confirmed, and if the client fails to confirm within a predetermined time, the server may consider that the client loses connection, thereby canceling the subscription.

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

For the 6 bits, a value between 0 and 63 can be represented, and assuming T, the time length can be represented by a power T of 2, namely 1 to 2^63 seconds. Such as:

0:2^0 ^1 second;

1:2^1 ^2 seconds;

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 a response can be cached, i.e. to indicate the freshness of the response. The present invention extends the meaning of this field, and may use the Max _ Age field in the request to indicate the limit of the time interval between multiple responses, such as multiple notification messages not being higher or lower than this time interval.

The order of the plurality of responses may be distinguished by a Message identification (Message ID). For example, it is specified that the message identifier must be generated incrementally according to the order of the response, and the receiver determines the order of the response according to the size of the message identifier.

According to another embodiment of the invention, a Token option may be used to indicate the manner of response, indicating an immediate response if the Token value is 0, and indicating that a deferred response may be accepted if the Token value is not 0.

According to another embodiment of the invention, a Timestamp (Timestamp) option may alternatively or additionally be added, either alone or in combination with the delay option, to indicate the manner of response. Specifically, the client may carry a timestamp option in the request, where the timestamp option includes a value of an expiration time, and requires the server to return a response within a specified time; the server carries a timestamp option in the response message, which indicates the time of generating the response message, so that the client can judge the sequence of the response message based on the timestamp option.

In one embodiment of the invention, the design scheme of the time stamp option can be represented by 1-6 bytes, if the represented time is short, the time stamp option is represented by one byte, and if the represented time is long, the time stamp option is represented by 3 bytes or 6 bytes. Specific expression methods include, for example, the following two methods:

(1) the first byte represents year, second byte represents month, third byte represents day, fourth byte represents hour, fifth byte represents minute, sixth byte represents second, for year, for example, 2000-year basis, the value of which indicates the first year after 2000, for example, 0, indicating 2000, 1, indicating 2001, and at most 2063 years.

(2) All three bytes are expressed in seconds, and the maximum can be expressed in 2^24-1 seconds, which is about 136 years.

Therefore, the client can know the sequence of the returned response messages, and errors caused by data transmission delay are avoided.

Fig. 13 is a block diagram of an embodiment of a client device for transmitting data resources according to the present invention, wherein the client device 1600 comprises: a sending module 1610, configured to send a request message carrying a response mode option; and a receiving module 1620, configured to receive a response message generated according to the response mode option.

The processes and features described with respect to the embodiment of the invention described with reference to fig. 11 are applicable to the client device shown in fig. 13. Specifically, for example, the response mode option carried in the request message sent by the sending module 1610 may be a deferral option, and may be, for example: a one-time immediate response, a deferred one-time response, a deferred multiple responses, and a cancellation of the deferred multiple responses.

According to an embodiment, the response mode option carried in the request message sent by the sending module 1610 may indicate a deferral time of a deferred one-time response or an expiration time of a deferred multiple responses.

According to one embodiment, the sending module 1610 sends a request message carrying a timestamp option, where the timestamp indicates the expiration time of receiving the response; the receiving module 1620 receives the response message carrying the timestamp option, where the timestamp indicates the generation time of the response message. The receiving module 1620 determines the order of the response messages according to the time indicated by the time stamp in the received response message.

Fig. 14 is an embodiment of a server apparatus for transmitting data resources according to the present invention, wherein the server apparatus 1700 comprises: a receiving module 1710, configured to receive a request message carrying a response mode option sent by a client; and a sending module 1720, which sends the response message generated according to the response mode option to the client.

The processes and features described with respect to the embodiment of the present invention described with reference to fig. 12 are applicable to the server apparatus shown in fig. 14. Specifically, for example, the response mode option carried in the request message received by the receiving module 1710 may be a deferral option, and may be, for example: a one-time immediate response, a deferred one-time response, a deferred multiple responses, and a cancellation of the deferred multiple responses.

According to the embodiment of the present invention, after the time indicated by the delayed access time option, the receiving module 1710 is configured to receive the request message retransmitted by the client.

And the client is used for receiving a specific response message sent by the client, wherein the specific response message carries a response code and a delayed access time option, and the response code indicates that the client cannot return an acknowledgement for the response message within the time indicated by the delayed access time option.

According to another embodiment of the present invention, the request message received by the receiving module 1710 may carry a timestamp option, where the timestamp option indicates an expiration time of receiving a response, and the response message sent by the sending module 1320 may also carry a timestamp option, where the timestamp option indicates a generation time of the response message.

Those of ordinary skill in the art will appreciate that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, computer software, or combinations of both, and that the components and steps of the examples have been described in a functional general in the foregoing description for the purpose of illustrating clearly the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied in hardware, a software module executed by a processor, or a combination of the two. A software module may reside in Random Access Memory (RAM), memory, Read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

Although a few embodiments of the present invention have been shown and described, it would be appreciated by those skilled in the art that changes may be made in these embodiments without departing from the principles and spirit of the invention, the modifications of which are intended to be within the scope of the invention.

Claims

1. A resource transmission method is applied to an M2M system based on a CoAP protocol, and comprises the following steps:

a client sends a request message to a server, wherein the request message carries an expiration option and is used for indicating the server to send a response message within the time indicated by the expiration option; the request also carries a response mode option, which is used for indicating the server to respond to the request of the client according to the response mode indicated by the response mode option, wherein a part of bits of one byte are used for indicating the response mode option, and the other part of bits are used for indicating the delay time of delayed one-time response or the deadline of delayed multiple responses;

the response mode comprises one of the following modes:

a one-time immediate response, or a delayed one-time response, or a delayed plurality of responses, or a cancellation of a delayed plurality of responses;

and the client receives a response message sent by the server according to the response mode option before the time indicated by the deadline option is overtime.

2. The method of claim 1, wherein the client abandons the request if the client does not receive a response from the server within the time indicated by the deadline option.

3. The method of claim 1,

the response message includes a response message generation time.

4. A client device comprising a processor and a memory, wherein the memory stores program instructions that, when executed by the processor, perform the method of any of claims 1-3.