数据资源传输的方法和设备与流程

本发明实施例涉及网络通信领域，并且更具体地涉及数据资源传输的方法和设备。

背景技术：

轻量级应用层协议(Constrained Application Protocol，简称“CoAP”)主要是用于物联网(Machine to Machine，简称“M2M”)的场景中，比如：家庭控制器、楼宇自动化、智能能源、传感器网络等。在这样的环境中，这些机器的功能比较简单，一般处理器只有8位，存储空间小，不支持复杂的传输协议，数据传输速率也较低。CoAP提供一种请求/响应的交互模式，支持内嵌的资源发现，包括关键的网页概念，比如统一资源标识(URI)和内容类型。CoAP可以很容易地翻译到超文本链接协议(HTTP)，用于集成到网络中。基于CoAP传输数据的传统方案中不计算数据资源的准确容量，无法评估分包的精确数目，因此无法并发获取数据资源，造成传输效率低下。

技术实现要素：

本发明实施例提供了一种数据资源传输的方法和设备，能够支持在CoAP中提高传输效率。

在本发明的实施例中，提出了一种在物联网系统中基于轻量级应用层协议提高传输效率的方法，可以通过分片来传输节点的数据资源，包括：获取节点的数据资源容量信息，资源容量信息为待传输数据容量大小；向节点发送携带第一分片选项的请求消息，其中第一分片选项包括推荐的分片容量；接收节点携带第二分片选项的响应消息，其中第二分片选项包括确定的分片容量，确定的分片容量小于或等于推荐的分片容量；根据确定的分片容量以及节点的数据资源容量信息，分片传输节点的数据资源。

在本发明实施例中，提供了一种在物联网系统中基于轻量级应用层协议通过分片传输节点的数据资源的方法，接收携带第一分片选项的请求消息，其中第一分片选项包括推荐的分片容量；发送携带第二分片选项的响应消息，其中第二分片选项包括确定的分片容量，确定的分片容量小于等于推荐的分片容量；根据确定的分片容量，传输节点的数据资源。

在本发明实施例中，提供了一种在物联网系统中基于轻量级应用层协议通过分片传输节点的数据资源的客户端设备，客户端设备包括：获取单元，用于获取节点的数据资源容量信息；发送单元，用于发送携带第一分片选项的请求消息，其中第一分片选项包括推荐的分片容量，接收单元，接收携带第二分片选项的响应消息，其中第二分片选项包括确定的分片容量，确定的分片容量小于等于推荐的分片容量；传输单元，用于根据确定的分片容量以及节点的数据资源容量信息，分片传输节点的数据资源。

在本发明实施例中，提供了一种在物联网系统中基于轻量级应用层协议通过分片传输节点的数据资源的服务器设备，服务器设备包括：接收单元，用于接收携带第一分片选项的请求消息，其中第一分片选项包括推荐的分片容量，发送单元，用于发送携带第二分片选项的响应消息，其中第二分片选项包括确定的分片容量，确定的分片容量小于等于推荐的分片容量；传输单元，用于根据确定的分片容量，传输节点的数据资源。

根据本发明实施例，可以获知需要传输的节点的数据资源的容量信息，并通过分片容量协商确定传输数据时使用的分片容量，由此可以实现传输过程中错误率降低，并且可以并发地传输数据。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1是本发明一种实施例的传输数据的方法的流程图；

图2是本发明一种实施例的网关从传感器获取数据资源的具体实现过程的流程图；

图3是本发明一种实施例中改进的分片选项的结构图；

图4是本发明一种替代实施例的网关从传感器获取数据资源具体实现过程的流程图；

图5是本发明一种替代实施例中改进的分片选项的结构图；

图6是本发明一种替代实施例的网关从传感器获取数据资源的具体实现过程的流程图；

图7是本发明一种替代实施例中改进的分片选项的结构图；

图8是本发明一种实施例的网关向传感器发送数据资源的具体实现过程的流程图；

图9是本发明一种实施例的客户端设备的框图；

图10是本发明一种实施例的服务器设备的框图；

图11是本发明一种实施例的传输数据的方法的流程图；

图12是本发明一种实施例的传输数据的客户端设备的结构图；

图13是本发明一种实施例的传输数据的服务器设备的结构图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

CoAP是基于用户数据报协议(User Datagram Protocol，简称“UDP”)进行传输，是基于无连接的消息处理模式。其交互模式可以是同步的响应，也可以是异步的响应。消息类型可以是：需要确认的消息(Confirmable)、不需要确认的消息(Non-confirmable)、确认消息(Acknowledgement)、重置消息(Reset)。可以通过消息标识(Message ID)来关联一对请求和响应。

CoAP支持的方法有四个：获取资源(Get)、更新资源(Put)、创建资源(Post)和删除资源(Delete)。资源通过表述性状态转移(Representational State Transfer，简称“REST”)URI来识别。我们通常称资源的拥有方为节点或服务器，包括但不限于传感器、控制器、端点(End-point)等，请求资源方为客户端，包括但不限于网关(Proxy)、网络侧设备。

CoAP协议支持不同的选项(Option)，用以解释CoAP消息体中数据的语义，比如Block(分片)、Location(位置)、Token(令牌)选项等，不同的选项支持不同的功能，并且可以通过定义新的Option来扩展新的功能。

CoAP支持分片选项(Block Option)，主要用于将较大的资源进行分片传输，以适应于低带宽传输的应用场景。Block选项可以为1个字节、2个字节或3个字节，依据分片数目的容量所需要的长度进行选取。

传统方案中不计算数据资源的准确容量，无法评估分包的精确数目，因此无法并发获取。另外也不知道资源是静态的还是动态的。

在以下描述中，通常称资源的拥有方为服务器，以传感器作为示例，请求资源方为客户端，以网关作为示例。但是，传感器或者网关并不用作对服务器或者客户端的限制。

由于不知道目标资源的精确容量，网关在<Get>命令中使用Block Option时，只能按顺序来获取，即选获取Block 0，等Block 0返回时，再获取Block 1，一直到最后一个Block。不能并发地发送<Get>请求。

Block选项的字段结构一般包括NUM字段，M字段和SZX字段，其中

NUM表示分片的顺序序号，可以是4～20位的无符号整型数字。0表示第一个分片。

M：用一个比特位来表示当前分片后面是否还有其他分片，其值为1表示后面还有分片，为0表示后面没有分片，即为最后一个分片。

SZX：用于表征分片容量，其计算公式为：分片容量＝2^(SZX+4)，即2的(SZX+4)次方。由于SZX由3个比特位来表示，其值可以为0～7，所以分片容量的取值范围：2^4～2^11，即16～2048。

对于Block选项的使用说明如下：

在<Get>请求中，Block选项的NUM字段给出当前请求的分片的序号，并且当分片序号为0时，SZX给出网关建议的每个分片的容量。在<Get>响应中或是<Put>/<Post>请求中，Block选项的NUM字段描述当前传输的分片的序号，M字段表明后面是否还有后续分片。

在<Put>/<Post>响应中，Block选项的NUM字段表明当前响应的分片序号。

当网关使用<Get>方法获取第一个分片(Block)时，NUM被设置为0，并携带建议的分片容量(即SZX)，传感器节点可以选择同意建议的分片容量，或是选择一个比建议分片小的分片，并在响应中返回，同时，在响应中返回第一个分片的数据。

本发明考虑网关事先获知目标资源的精确容量，则网关可以选择是否用Block Option来发送资源获取的请求，也可以实现并发请求，即在请求Block 0的同时，也可以请求Block 1，而不必等待。在请求Block的顺序上也可以灵活处理。

简单设计方案中，Block Option有三个选择，可以是一个字节，可以是2个字节，也可以是三个字节，依据资源的容量不同，分片(Block)的数量容量不同，所需要的长度也不一样。协议规定，除了最后一个分片外，分片的容量必须相同，但每次传输中，还是每次都需要携带M位(表明后面是否还有分片)和SZX(分片的容量)。

每次在请求和响应中，M位和SZX位都需要传送，而实际上，除了最后一个分片外，M位和SZX的值每次都是相同的，重复的传输浪费传输资源。重复发送SZX的目的假定双方都不保存协商后的SZX，第一次响应中携带的是协商后的SZX，网关从响应中获取并再次在请求中发送，从而网关和传感器都不需要保存状态。在一次的请求响应回合中，共浪费一个字节，如果分片数目很多时，浪费的字节就很多了，对于M2M设备，传输资源是受限的，这个传输资源的浪费是很可观的。假设要传送的数据为64M的话，每个Block的负载(payload)容量为1024byte则发送的block条目数为：65536。则发送的Block选项按照字节来分的个数为：

(1)一个字节：16个

(2)两个字节：4080个

(3)三个字节：61440个

如果M和SZX可以不发送，则请求加上响应能够节省的数据为65536字节(byte)，即64K数据。另外，如果这两个字段不要，则NUM字段可以用满所有位(bit)，则需要发送的数据包的数目变更为：

(1)一个字节：256个

(2)两个字节：65280个

此时不需要发送3个字节的结构，因此还可以节省数据为61440*2bytes，即60K数据。则总共节省数据位124K，节省数据率0.189％。头域节省百分比为(16+4080*2+61440*3-256-65280*2)/(16+4080*2+61440*3)＝61680/192496＝32％。

节省数据量的公式：

T为总的Block数量，S为分片容量(Block Size)，节省的流量的百分比(只比较头域)：

T<16时：无节省；两者都是一个字节；

16<T<256时：1-T*1/(16*1+(T-16)*2)，简单设计方案需要2个字节，优选方案只需要一个字节；

256<T<4096时：1-(256*1+(T-256)*2))/(16*1+(T-16)*2)，简单设计方案需要2个字节，优选方案需要2个字节；

4096<T<65256时：1-(256*1+(4096-256)*2+(T-4096)*3))/(256*1+(T-256)*2)，简单设计方案需要3个字节，优选方案需要2个字节。

T>65256时，无节省，本发明优选方案实施例和简单设计方案都需要3个字节。

简单设计方案中，使用Put/Post命令时，分片容量协商缺乏效率。在Put/Post请求中，对于第一个分片，需要发送第一个分片的数据和推荐的分片容量，如果传感器节点选择不一样的分片容量，网关需要按照传感器的分片容量进行重新发送，则上次发送的分片数据被浪费掉了。而且，网关在使用Put/Post请求基于分片选项发送容量大的资源时，事先无法告知传感器资源容量信息，在传输过程中，传感器边接收，边缓存所接收的资源，如果传感器发现存储空间不够，而资源又未传输完成时，只能发送回一个413的错误状态码，表示请求的资源太大，结束此次传输。此前传输的部分资源则没用了，传输资源被浪费了。如果网关能够在第一个分片消息中告知传感器所要传输的资源的容量信息，传感器则可以比较资源容量信息与存储容量，如果容量不足，提前返回413“请求的资源太大”的状态码，来结束资源传输，以此来达到节省传输资源的目的。

互联网上的断点续传，也就是要从文件已经下载的地方开始继续下载。网关在向传感器请求数据的时候，要多加一条信息来表示请求下载数据的范围(Range)，表明从哪里开始。

比如，网关用浏览器来传递请求信息给Web传感器，要求从2000070字节开始：

GET/down.zip HTTP/1.0

User-Agent:NetFox

Range:bytes＝2000070-

Accept:text/html,image/gif,image/jpeg,*；q＝.2,*/*；q＝.2

其中，RANGE:bytes＝2000070-，这一行的意思就是告诉传感器down.zip这个文件从2000070字节开始传，前面的字节不用传了。

这种方案的缺点是，没有分片机制，不支持分片容量的协商，也不支持分片总数的协商。本发明实施例考虑了在分片传输过程中，进行分片容量和/或分片总数的协商。为此本发明提供了一种数据分片传输的方法，可以获取目标数据资源的精确容量，进行分片容量的协商，获取分片总数，并根据分片总数进行数据资源传输。

以下参照图1具体说明本发明一种实施例的流程。图1是本发明一种实施例的流程图。

在S110过程中，获取节点的数据资源的容量信息。如果是网关从传感器获取数据，则节点的数据资源容量信息保存在传感器上。网关可以通过请求消息，向传感器获取节点的数据资源的容量信息。如果是网关向传感器发送数据，则网关本地已经知道了节点的数据资源的容量信息。获取节点的数据资源容量信息，是为下一步进行分片容量的协商并确定分片总数做准备。

接着，在S120的过程中，网关向传感器发送携带第一分片选项的请求消息，其中所述第一分片选项包括推荐的分片容量。传感器在收到S120中发送的请求消息之后，根据自身能力，确定本次数据资源传输过程中所使用的分片容量，并且传感器确定的分片容量小于等于网关推荐的分片容量。

在S130，网关接收携带第二分片选项的响应消息，其中所述第二分片选项包括确定的分片容量，所述确定的分片容量小于等于所述推荐的分片容量。网关在接到确定的分片容量之后，根据掌握的节点的数据资源容量信息，确定将要传输的节点的数据资源的分片总数。

然后，在S140，根据所述确定的分片容量以及所述节点的数据资源容量信息，分片传输所述数据资源。

根据本发明实施例，可以获知需要传输的数据资源的容量信息，并通过分片容量协商确定传输数据时使用的分片容量，由此可以实现传输过程中错误率降低，并且可以并发地传输数据。

以下结合图2说明如图1所示实施例的具体实现过程。图2表示的是网关从传感器获取数据的说明性示例，仅为说明本发明的构思，而不作为对本发明的限制。

图2所示数据资源获取过程具体描述如下：

ES210：网关向传感器发送资源发现请求，即通过Get./wellknown/core来获取传感器上的资源列表。

ES220：传感器向网关返回资源列表，以及资源指示信息；资源指示信息主要包括资源的寻址信息(即URI)、资源名称、资源描述信息、内容类型等。本发明对资源指示信息进行扩展，扩展的资源指示信息包括：资源是动态资源还是静态资源的指示信息。

ES230：网关根据传感器返回的资源列表，根据资源的指示信息，从中选择目标资源，并根据识别标识(能唯一识别资源的信息，比如资源名称、URI等)，获取目标资源。

ES240：传感器对目标资源容量进行判断，如果资源容量小于一个传输层消息包的容量，则直接返回资源内容给网关；如果资源容量超过一个传输层消息包的容量，则返回资源容量信息。可选地，传感器可使用分片选项，根据自身确定的分片容量，直接返回第一个分片。后续客户端和传感器根据此确定的分片容量，使用分片选项传输如下的分片。

在本发明一种替代实施例中，如果目标数据资源为动态数据资源，同时返回动态数据资源指示给网关，并用413“请求资源太大”的状态码指示网关使用Block选项来获取资源。

如果数据资源为动态资源，则指示信息中的资源容量表示的是当前的资源快照(Snapshot)的容量信息，传感器需要缓存此快照数据；如果是静态资源，则指示信息中的资源容量信息是精确的容量信息。本领域技术人员应该理解，如果数据资源为动态资源，则传感器可以发送资源快照的校验码，网关如果需要更新鲜的数据，可以后续再发送新的资源获取请求。

ES250：网关根据数据资源容量信息，判断需要使用分片选项，并发送携带分片选项的请求消息，与传感器器进行分片容量协商，指示推荐的分片容量。

ES260：传感器根据自身能力，确定分片容量，并将其返回给网关。可选地，传感器同时返回分片总数。当然，由于网关已经获取了数据资源容量信息，分片总数也可以由网关确定。需要说明的是，传感器确定的分片容量只能小于或等于网关推荐的分片容量。

ES270：网关从1一直到分片总数，依次向传感器发送请求，请求获取与分片序号对应的数据资源的分片数据。

ES280：传感器根据确定的分片容量，返回该分片序号及与该分片序号对应的数据资源的分片数据，直到完全传输完毕。

根据本发明的一种优选实施例，ES270中可以实现并行处理，即网关可以同时请求获取多个分片消息，而不需要等待传感器返回对前一个分片请求消息的响应消息。

ES210至ES240的代码例如为：

REQ:GET/.well-known/core---发送请求到默认的URI，即根目录获取资源列表；

RES:200OK--响应标识获取成功，并携带了2组资源指示信息；

</sensors/temp>；ct＝41；n＝"TemperatureC",--温度资源，内容类型41，名称为TemperatureC；

</sensors/light>；ct＝41；n＝"LightLux"--灯光资源，内容类型41，名称为LightLux；

</sensors/firmware>；ct＝52；n＝"firmware"；snapshot＝0--固件资源，内容类型52，名称为firmware，非动态资源；

</sensors/log>；ct＝52；n＝"log"；snapshot＝1--固件资源，内容类型52，名称为log，动态资源，当前数据为快照snapshot；

REQ:GET/sensors/firmware–请求固件资源

RES:413“Request Entity Too Large”Size:88000.413状态码表明请求的资源太大，其精确容量为88000字节。

如果数据资源为动态资源，即数据资源在传输的过程会动态变化，例如可以采用以下两种方案实施处理：

(1)在开始传送数据资源时，对该资源建立快照(Snapshot)，即缓存此刻该数据资源的容量信息，并传输这个容量信息，不管后续的变化；对应上述方案。

(2)如果数据资源在传输过程中被修改，传感器可以在任意一个获取数据资源的请求消息的响应消息中，返回错误码，指示数据资源已更改，网关需要重新获取。

可选地，网关和传感器在消息交互中，增加认证信息。认证信息中可包含身份标识(ID)、基于身份标识和密码(Password)算出来的密钥信息(Digest)。身份标识和密码可以是预先配置给网关和传感器双方。配置过程：

例如，密钥的算法可以为：Digest＝MD5(ID:Password)，即对ID和Password组成的字符串使用MD5算法进行哈希(Hash)，Hash的值为Digest。发送方发送ID和Digest，接收方根据接收到ID和预先存储的Password，根据同样的算法得出Digest，与发送方发送的Digest进行比较，如果一致，则认证通过。

网关从传感器获取数据资源时，如图2所示，需要知道数据资源容量信息。根据本发明一种实施例，网关可以采用如下方案来获取存储于传感器的数据资源容量信息。

(1)扩展链接格式(Link-format)关键字

在Link-format中，扩展一个关键字，-sn，或-snapshot，用于在获取数据资源请求的响应中，表明资源数据是否是快照数据。如果此参数不存在，或其值为0，表明是静态资源，如果此参数的值为1，则表明是当前数据是动态资源，获取的数据是当前的快照。静态资源是指一段时间内相对稳定的资源，即资源内容不会频繁更改。具体含义可以在标准中进行定义。在本发明中，主要指资源的值不改变的情况。

还扩展关键字：-asz,表明资源的准确容量的信息。

消息实例：

网关向传感器发送资源发现的请求：

REQ:GET/.well-known/core---发送请求到默认的URI，即根目录获取资源列表

传感器向网关发送资源的响应：

RES:200 OK--响应标识获取成功，并携带了2组资源指示信息

</sensors/temp>；ct＝41；n＝"TemperatureC",--温度资源，内容类型41，名称为TemperatureC

</sensors/light>；ct＝41；n＝"LightLux"--灯光资源，内容类型41，名称为LightLux

</sensors/firmware>；ct＝52；n＝"firmware"；asz＝65000；snapshot＝0--固件资源，内容类型52，名称为firmware，非动态资源，精确容量为65000字节；

</sensors/log>；ct＝52；n＝"log"；asz＝88000；snapshot＝1--固件资源，内容类型52，名称为log，动态资源，当前数据为快照snapshot，其精确容量为88000字节；

此响应消息是封装在CoAP消息的消息体中的，接收方(即网关)根据Link-format标准中的规定进行解析。

(2)增加状态码

在收到网关的数据资源获取请求时，如果资源太大，一个包传送不下，传感器用状态码来通知网关，用于表明，资源太大，需要用Block Option来请求。

比如，可以规定状态码413，用于表明当前数据资源容量过大，指示网关在请求中用Block选项。可以根据需要规定其他的状态码，以用于表示其他含义，用于其它目的。

消息实例：

网关向传感器发送资源获取的请求：

GET/sensordata

传感器向网关发送带状态码的响应：

ACK 413(状态码，表明数据资源容量太大)

(3)在CoAP的头字段(Header)中增加一个表明容量(Size)的选项(Option)

网关在请求中，可以用容量选项(Size Option)来指示传感器，让传感器返回数据资源的容量；传感器在响应中，用Size Option来指明数据资源的容量。

或者是，即使网关没有Size Option的指示，传感器也在响应中用Size Option指明资源容量，尤其是资源比较大的情况下，传感器应该指示。

如果资源较小，传感器直接在消息体(Body)中返回资源数据，则网关应该以资源数据的实际容量为准，Size Option中表明的资源容量可以用于核对。

如果资源较大，传感器不返回资源数据，只用Size Option返回数据的容量，同时用状态码指示给网关，让网关发起新的请求，用Block Option来请求。

Size Option的代码可以为16，数据类型为整型，数据长度为1～4个字节，数据单位为字节。Size Option主要用于<Get>方法的响应中，<Put>/<Post>方法的请求中，用于表示资源的容量；如果是在<Get>方法的请求中，其值没有实际的意义，推荐置为0。

消息实例：

网关向传感器发送资源获取的请求：

GET/sensordata

传感器向网关发送带状态码的响应：

ACK+413+Size 51200(50K字节)

以下结合图3说明如图1所示实施例的具体实现过程。图3表示的是网关向传感器发送数据的说明性示例，仅为说明本发明的构思，而不作为对本发明的限制。

当网关使用<Get>方法获取第一个分片(Block)数据时，NUM字段被设置为0，并携带推荐的分片容量(即SZX)，传感器可以选择同意推荐的分片容量，或是选择一个小于等于推荐的分片容量的分片容量，并在响应中返回，同时，在响应中返回第一个分片的分片数据。因此，在NUM字段为0时，<Get>请求有双重语义，一是获取第一个分片数据，二是进行分片容量的协商。这样带来协议在处理上的二义性，而且无法携带数据容量等信息。

本发明实施例对此进行了改进，在本发明的一种实施例中，网关在<Get>方法的请求中使用Block Option时，如果NUM字段被设置为0，表示双方只进行分片容量的协商，以及分片总数的协商。即传感器在响应中，使用NUM字段返回分片总数，使用SZX字段返回传感器确定的分片容量。M字段可以去掉，节省一个Bit，用于NUM字段。因为请求方，例如网关知道分片总数，所以从分片的NUM字段就可以知道该分片是否是最后一个分片，因此就不需要再使用M字段。在这种情况下，如果请求获取第一个分片的分片数据，则将NUM设置为1，依次类推。

需要说明的是，如果网关发送第一个请求时，不知道数据资源的容量，所以Block Option可以使用一个字节，如果传感器的数据资源较大，分片数目较大，则传感器可以在响应中使用二个字节或者三个字节来返回分片总数。

当Block Option为2个字节时，其设计成SZX字段占用第二个字节的最后三位，表示分片容量；NUM字段占用第一个字节加上第二个字节的前5位，表示当前分片序号；如果是在NUM为0的请求对应的响应消息中，则表示分片总数。本领域技术人员理解，可以用消息标识(Message ID)来关联请求与响应，即请求和响应中都携带唯一的事务标识，这样传感器就能理解此响应消息是用于返回分片总数。

以下举例说明分片容量协商过程，消息实例为：

网关向传感器发送资源获取的请求：

GET 00000 101(NUM为0，SZX为101，即5，表示分片容量为2的9次方，即512)

传感器向网关发送的响应：

ACK 10000 100(NUM为:10000，即总分片数为32，SZX为100，即4，表示分片容量为2的8次方，即256)

此设计省掉了一个比特位(Bit)，即把M位给省掉了，技术优势是节省了数据流量并且对现有设计的改动不大。在这种实施方式中，分片容量(SZX)字段每次仍然要发送。

在现有技术中，分片容量(即SZX字段)每次都要发送，不管是在请求消息中还是响应消息中，除了第一个分片和最后一个分片中使用的分片容量可能不一样之外，其他的分片容量全部都是一样的。重复互相传输相同的NUM字段浪费了传输资源。

在本发明实施例中，网关在<Get>方法的请求中使用Block Option时，如果NUM被设置为0，表示双方只进行分片容量的协商，以及分片总数的协商。即传感器在响应中，使用NUM字段返回总的分片数，使用SZX字段返回传感器确定的分片容量。并且网关和传感器双方存储所确定的分片容量，用于之后的分片数据传输消息。除了最后一个分片数据之外。网关在后续<Get>方法的请求中，只发送所请求的当前分片序号，而不发送已经确定并保持不变的分片容量，而且传感器在响应消息中，也只发送当前的分片序号和与该分片序号对应的分片数据，不再发送分片容量。在这种情况下，NUM为1时，表示请求第一个分片的分片数据，依次类推。

以采用<GET>命令从传感器获取数据资源为例，说明上述实施例，

如图3所示，新的Block Option的设计如下：

其中结构(1)用于NUM为0的情况：

在<Get>请求中，NUM为0，SZX是第二个字节，表示分片容量，Total Number表示分片总数，在请求时不使用，不需要携带；在<Get>响应中，NUM为0，SZX表示传感器确定的分片容量，Total Number表示分片总数。

在现有技术中，分片容量的间隔比较大，比如2048、1024、512，不够灵活。而实际上，512对于一个Block来说，比较小，最好是刚好能够放到一个UDP包里，即1472个字节。本发明对此进行了改进，在一种实施例中，对于SZX，可以采取新的公式，比如：(SZX+1)*8,则其范围可以为：8～2048，但是递减间隔为8。

图3中的结构(2)和结构(3)用于<Get>请求中NUM不为0的情况，即获取分片数据时的情况：

当NUM小于256时，用一个字节来表示分片序号，即结构(2)；当NUM大于2的8次方(即256)，小于2的16次方(即65536)时，使用两个字节来表示分片序号，即结构(3)。

由于结构(2)中的NUM必须大于0，结构(3)中的NUM字段的前一个字节也大于0，因此可以与结构(1)区分开，对于<Get>响应，NUM字段的值与请求中一样，也可以区分开。

以下举例说明，消息实例为：

网关向传感器发送资源获取的请求：

GET 00000000 00000101(NUM为0，SZX为101，即5，表示分片容量为2的9次方，即512)

传感器向网关发送的响应：

ACK 00000000 00000100 00000000 00010000(NUM为0，Total Number为10000，即分片总数为32，SZX为100，即4，表示分片容量为2的8次方，即256)。

通过对Block Option重新设计，可以在每个请求或响应中至少减少发送4个比特位，在分片较多的情况下，可以极大地提高传输效率，节省传输资源，同时也提高了网关和传感器双方的处理效率。

图4示出了本发明的一种替代实施例。在图4所示实施例中，ES410至ES420与图2所示实施例的ES210至ES240相同，不再重复描述。

在图4所示实施例中，在ES450，网关向传感器发送<GET>请求，使用分片选项进行分片容量协商，指示网关推荐的分片容量。在ES460中，传感器选择并确定合适的分片容量，用于将资源进行分片，并将所有分片数据主动推送给网关，而不需要网关再发<GET>请求。

在图4实施例获取数据资源过程中，分片选项的设计如图5所示，其中：

结构(1)用于网关向传感器发送<GET>请求，SZX字段表示网关推荐的分片容量，传感器最终选择并确定的分片容量小于等于网关推荐的分片容量，NUM为0表示网关请求完整资源，NUM不为0表示网关请求具体第NUM个分片数据，NUM不为0时传感器只能使用SZX字段所指示的分片容量。

结构(2)和结构(3)用于传感器向网关返回完整资源的分片响应消息，如果针对某个具体分片数据请求的应答，不需要携带分片选项，结构(2)和(3)中的M字段表示是否为最后一个分片，如果是M字段为0则表示最后一个分片，为1表示不是最后一个分片，NUM字段表示传感器所返回的是第几个分片。

以下举例说明。消息实例为：

网关向传感器发送数据资源获取的请求：

CON GET 00000000 00000101(NUM为0，SZX为101，即5，表示分片容量为2的9次方，即512)

传感器向网关发送的响应：

ACK 200 00000011(NUM为1，M为1，表示发送的第一个分片，并且不是最后一个分片，分片容量为SZX字段指定的容量)；

传感器继续向网关发送CoAP响应：

CON 200 00000101(NUM为2，M为1，表示发送的第二个分片，并且不是最后一个分片，分片容量为SZX字段指定的容量)；

网关返回对CON的ACK响应；

传感器向网关发送最后一个分片：

CON 200 00000110(NUM为3，M为0，表示发送的第三个分片，并且是最后一个分片，具体分片容量由实际读出数据算出)。

根据图4所示的实施例，在网关从传感器获取完整的数据资源时，仅需完成分片容量的协商，而不用发送大量的分片数据获取请求，大大节省了数据传输流量。

图6示出了本发明的另一种替代实施例。在图6所示实施例中，ES610至ES640与图2所示实施例的ES210至ES240相同，因此不再重复描述。

图6与图2所示实施例不同之处在于，在ES650，网关向传感器发送<GET>请求，请求获取资源，使用分片选项，指示网关推荐的分片容量，此时NUM字段填充的值为0，表示请求获取最后一个分片；在ES660，传感器响应网关请求，返回确定的分片容量以及最后一个分片的序号及与之对应的分片数据。由于最后一个分片序号对应分片总数，所以在ES670，网关就可以依次或者并发获取其他分片数据的请求。在ES680，传感器根据确定的分片容量，返回该分片的序号及对应的分片数据。ES670和ES680可以多次进行交互，直至分片数据传输完毕。

图6实施例中采用的分片选项如图7所示，例如采用两个字节的分片选项，仅包括NUM字段和SZX字段。

以下结合图6和图7举例说明，消息实例为：

网关向传感器发送资源获取的请求：

CON GET 00000000 00000101(NUM为0，表示要求获取最后一个分片，SZX为101，即5，表示推荐的分片容量为2的9次方，即512)。

传感器向网关发送的响应：

ACK 00000000 01000101(NUM为1000即为8，表示返回的是第8个分片，SZX为101即5，表示确定的分片容量为2的9次方，即512)；

根据第一次的返回信息，网关已经知道了一共有8个分片，并且得到了第8个分片的数据，网关继续向传感器发送CoAP请求，可以依次获取也可以并发获取剩下的分片数据。以下消息实例为请求获取第一个分片的分片数据：

CON GET 00000000 00001101(NUM为1，表示要求获取第一个分片，SZX为101，即5，表示分片容量为2的9次方，即512)；

传感器返回对CON的ACK响应，即第一个分片的数据；

网关可以依次或并发请求所有剩余分片，直到获取完所有的数据。

根据图6所示的实施例，可以在分片容量协商的同时，获取最后一个分片的分片数据，在后续分片数据获取过程中，所使用的分片容量均相同，因此可以结合前述优选实施例的描述，网关可以在发送获取分片数据的请求时，不再发送SZX字段，而仅发送NUM字段，由此可以节省数据流量，提高传输效率。

图8示出了使用分片选项向传感器发送数据，例如使用资源创建(Post)或更新(Put)请求时的实施例。以下结合图8进行具体描述。

图8所示详细的流程说明如下：

ES810：网关向传感器发送资源创建(Post)或更新(Put)请求消息，利用Size选项发送资源的容量信息，利用分片选项指示推荐的分片容量及分片总数，此处所述的分片总数是基于推荐的分片容量和待发送的数据资源的容量计算出的，请求消息体中不携带具体的资源数据。

ES820：传感器如果愿意接收此数据，则返回状态码例如为100(即指示客户端继续发送)，同时向网关返回确定的分片容量，所述确定的分片容量只能小于或等于网关推荐的分片容量；如果传感器不愿意接收此数据，则返回错误码指示客户端不要继续发送数据。比如，传感器的存储容量不足以存储所指示的资源容量的数据，则返回413“Request Entity Too Large”的返回码。

ES830：网关根据传感器返回的确定的分片容量，判断是否与推荐的分片容量相同，如果相同，则跳转到ES360；如果不相同，则根据传感器返回的确定的分片容量信息，并根据数据资源容量，重新计算分片总数。

ES840：网关重新向传感器发送确定的分片容量和重新计算的分片总数。

ES850：传感器返回确定的分片容量。

ES860：网关从根据分片序号从1一直到分片总数，依次向传感器发送与分片序号对应的数据资源的分片数据，直到完全传输完毕。

ES870：传感器返回确定接收的消息，其中包含接收到的分片序号。

根据本发明的一种优选实施例，ES860中可以进行并行处理，即网关可以同时向传感器发送多个分片数据，而不需要等待传感器返回对前一个分片消息的响应消息。可选地，根据本发明的一种优选实施例，网关和传感器在消息交互中，增加认证信息。认证消息的配置和交互方式可以采用参照图2所述的相同方式。

为了提高传输效率，节省数据流量，根据本发明另一种优选实施例，如前面针对<GET>方法所述地那样，在使用<Put>/<Post>方法的请求中，当NUM为0是，不再是发送第一个分片数据，而是告知传感器推荐的分片的容量和分片总数。传感器可以返回响应告知网关是否继续发送数据。传感器在响应中，使用NUM字段返回总的分片数，使用SZX字段返回传感器确定的分片容量。并且网关和传感器双方存储所确定的分片容量，用于之后的分片数据传输消息。除了最后一个分片数据之外。网关在后续<Put>/<Post>方法的请求中，只发送所请求的当前分片序号，而不发送已经确定并保持不变的分片容量，而且传感器在响应消息中，也只发送当前的分片序号和与该分片序号对应的分片数据，不再发送分片容量。在这种情况下，NUM为1时，表示请求第一个分片的分片数据，依次类推。

在此情况下，分片选项的设计以及使用方式均类似于图3所示，以下参照图3来说明。在<Put>/<Post>请求中，NUM字段为0，SZX字段是第二个字节，表示推荐的分片容量，Total Number表示待发送的分片总数数；在<Put>/<Post>响应中，NUM字段为0，SZX字段表示传感器确定的分片容量，Total Number没用，不需要携带；如果网关接收到的SZX字段与发送的不一致，需要用新的SZX再次发送<Put>/<Post>请求，并携带重新计算的分片总数，传感器再发回响应。以后<Put>/<Post>请求和响应中，不再携带SZX字段。

通过对分片选项重新设计，可以在每个请求或响应中至少减少发送4个比特位，在分片较多的情况下，可以极大地提高传输效率，节省传输资源，同时也提高了网关和传感器双方的处理效率。

另外，现有技术在每次分片传输的请求中，都需要携带所请求资源的统一资源标识(URI，Unified Resource Identifier)，通常URI都要占十几到几十个字节，重复的传输会浪费传输资源，本发明设计使用Token(令牌)来关联分片传输的多个请求，只在第一个分片消息中传送URI，在后续的分片传输请求中，只需要携带Token即可，由于Token通常是1～8个字节，因此可以节省一定的流量。

图9是本发明一种通过分片传输数据资源的客户端设备的实施例。图9所示客户端设备900包括：获取单元910，用于获取数据资源容量信息；发送单元920，用于发送携带分片选项的请求消息，其中所述分片选项包括推荐的分片容量，接收单元930，接收携带分片选项的响应消息，其中所述分片选项包括确定的分片容量；和传输单元940，用于根据所述确定的分片容量以及所述数据资源容量信息，分片传输所述数据资源。

根据本发明的一种优选实施例，所述客户端设备可以进一步包括存储单元950，用于保存所述确定的分片容量。以便在数据资源传输过程中，不需要每次均发送SZX字段。

根据本发明的另一种优选实施例，所述客户端设备可以进一步包括认证单元960，用于发送和接收认证信息。

图10是本发明一种通过分片传输数据资源的服务器设备的实施例。图10所示服务器设备1000包括：接收单元1010，用于接收携带分片选项的请求消息，其中所述分片选项包括推荐的分片容量；发送单元1020，用于发送携带分片选项的响应消息，其中所述分片选项包括确定的分片容量；和传输单元1030，用于根据所述确定的分片容量，分片传输所述数据资源。

根据本发明一种实施例，发送单元1020还用于发送携带数据资源容量信息的消息，以便于传输单元1030根据所述确定的分片容量和所述数据资源容量信息，分片传输所述数据资源。

根据本发明一种实施例，在接收到一次请求时，传输单元1030可以主动地分片传输数据，而不需要客户端设备针对每个分片数据进行请求。

根据本发明一种优选实施例，所述服务器设备可以进一步包括存储单元1040，用于保存所述确定的分片容量。以便在数据资源传输过程中，不需要每次均发送SZX字段。

根据本发明的另一种优选实施例，所述服务器设备可以进一步包括认证单元1050，用于发送和接收认证信息。

根据本发明实施例，网关可以获知目标资源的容量信息，用于决策是否用分片的方式来获取资源，这样避免了出错的可能性，也可以实现并发地请求分片，提高数据请求的效率，而且得知资源的容量也便于分配存储空间，计算分片的数量。

通过对分片选项重新设计，可以在每个请求或响应中至少少发送4个比特位，在分片较多的情况下，可以极大地提高传输效率，节省传输资源，同时也提高了双方的处理效率。

在现有技术中，在收到来自于客户端的请求后，服务器可以立即发回响应，也可以先发回一个Ack(Acknowledgement)响应消息，表明接收到了请求消息，正在处理中，后续等处理完后，再发送响应消息，即推迟的响应。另外，客户端可以订阅一个资源的改变，服务器在接受客户端对某个资源的订阅后，一旦资源信息发生变化，就向客户端发回通知消息。

现有技术不能满足如下的需求：

1、客户端在请求中指示服务器，自己需要哪种方式的响应；

2、客户端要求服务器在某个规定的时间内发回响应；

3、在通知消息的传送过程中，由于网络传输能力不稳定，可能服务器先发出的通知消息，比服务器后发出的消息，到达客户端的时间要晚。这样，客户端后收到的资源信息实际上是陈旧的信息，客户端需要有一种机制能够探测多个通知消息的顺序。

图11是本发明一种实施例的流程图。在图11所示实施例中，在S1110，客户端向服务器发送请求消息，该请求消息携带响应方式选项，所述响应方式选项可以是推迟响应(Deferred Response)选项或者是令牌(Token)选项，用来指示服务器，客户端是否接收推迟的响应。例如，所述相应方式选项表示：一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟的多个响应。然后，在S1120，客户端可以接收根据响应方式选项生成的响应消息。

在现有技术中，在收到来自于客户端的请求后，服务器可以立即发回响应，也可以先发回一个Ack，表明接收到了请求消息，正在处理中，后续等处理完后，再发送响应消息，即推迟的响应。另外，客户端可以订阅一个资源的改变，服务器在接受客户端对某个资源的订阅后，一旦资源信息发生变化，就向客户端发回通知消息。

在本发明的一种实施例中，例如可以采用一个字节的延迟(Deferred)选项来指示响应方式，其中，可以使用前两个比特位(Bit)来表示，用C来表示：

C＝00:表示一次性的立即响应；

C＝01:表示推迟的一次性的响应；

C＝10：表示推迟的多个响应，即订阅；

C＝11：表示取消推迟的多个响应，即取消订阅。

对于客户端发起的关于某个资源的订阅，可以由客户端取消订阅，也可以服务器取消订阅，比如服务器发回给客户端一个需要确认的响应消息，客户端在预定的时间内未能确认，则服务器可以认为客户端失去连接，从而取消订阅。

由于一个字节是8个比特位，多余的后6个比特位(假设其值为T)可以用于表示推迟的一次性的响应的推迟时间或者推迟的多个响应的截止时间，即超过此时间后，自动取消订阅。当C为01时，T表示推迟的一次性响应的推迟时间；当C为10时，T表示推迟的多个响应的截止时间；当T为00或11时，T没有意义，置为0。

对于这6个比特位，可以表示0～63之间的数值，假设为T，可以用2的T次方，来表明这个时间长度，以秒为单位，即可以表示1～2^63秒。比如：

0:2^0＝1秒；

1:2^1＝2秒；

2:2^2＝4秒；

3:2^3＝8秒

4:2^4＝16秒；

…

63:2^63秒。

在现有技术中，Max_Age字段用于表明某个响应可以被缓存的最大时间，即表明响应的新鲜度。本发明扩展这一字段的含义，可以在请求中用Max_Age字段表示多个响应之间的时间间隔的限制，比如多个通知消息不得高于此时间间隔，或者是不得低于此时间间隔。

对于多个响应的顺序，可以用消息标识(Message ID)来区分。比如，规定消息标识必须根据通响应的顺序来递增地生成，接收方根据消息标识的大小来判断响应的先后顺序。

根据本发明的另一种实施例，可以使用Token(令牌)选项来指示响应方式，如果Token值为0，来表示立即的响应，如果Token值不为0，则表示可以接受推迟的响应。

根据本发明的另一种实施例，可以替代地或另外增加时间戳(Timestamp)选项，与延迟选项单独或者相结合地来指示响应方式。具体来说，客户端可以在请求中携带时间戳选项，所述时间戳选项包括一个截止时间的值，要求服务器在指定的时间内返回响应；服务器在响应消息中，携带时间戳选项，表明响应消息生成的时间，这样，客户端可以基于时间戳选项来判断响应消息的顺序。

在本发明一种实施例中，所述时间戳选项的设计方案可以用1～6个字节来表示，如果表示的时间短，则用一个字节，如果时间长，则用3个字节或6个字节。具体表示方法例如以下两种：

(1)用年、月、日、时、分、秒来表示，第一个字节表示年、第二个字节表示月，第三个字节表示日，第四个字节表示小时，第五个字节表示分钟，第六个字节表示秒，对于年份，例如可以以2000年为基础，其值表明2000年之后的第几年，比如为0时，表明是2000年，为1时，表明是2001年，最多可以表示2063年。

(2)三个字节全部用秒来表示，最大可表示2^24-1秒，大约是136年。

由此，客户端可以知道返回的响应消息的顺序，避免数据传输延迟导致的错误。

图12是根据本发明的一种传输数据资源的客户端设备的实施例的框图，其中所述客户端设备1200包括：发送模块1210，用于发送携带响应方式选项的请求消息；和接收模块1220，用于接收根据所述响应方式选项生成的响应消息。

参照图11所述的本发明的实施例所描述的过程和特征均适用于图12所示的客户端设备。具体来说，例如，发送模块1210发送的请求消息中携带的响应方式选项可以是推迟选项，例如可以为：一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟的多个响应。

根据一种实施例，发送模块1210发送的请求消息中携带的响应方式选项可以表示推迟的一次性的响应的推迟时间或者推迟的多个响应的截止时间。

根据一种实施例，发送模块1210发送携带时间戳选项的请求消息，该时间戳表示接收响应的截止时间；接收模块1220接收携带时间戳选项的响应消息，该时间戳表示响应消息的生成时间。接收模块1220根据接收到的响应消息中的时间戳所表示的时间确定响应消息的顺序。

图13是根据本发明的一种传输数据资源的服务器设备的实施例，其中所述服务器设备1300包括：接收模块1310，用于接收携带响应方式选项的请求消息；和发送模块1320，发送根据所述响应方式选项生成的响应消息。

参照图11所述的本发明的实施例所描述的过程和特征均适用于图13所示的服务器设备。具体来说，例如，接收模块1310接收的请求消息中携带的响应方式选项可以是推迟选项，例如可以为：一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟的多个响应。

根据本发明的一种实施例，接收模块1310接收的请求消息中携带的响应方式选项可以表示推迟的一次性的响应的推迟时间或者推迟的多个响应的截止时间。

根据本发明的一种实施例，接收模块1310接收的请求消息中的推迟选项表示推迟的多个响应和推迟的多个响应之间的时间间隔，而发送模块1320发送的响应消息中的推迟选项表示取消推迟的多个响应。

根据本发明的另一种实施例，接收模块1310接收的请求消息中可以携带时间戳选项，该时间戳选项表示接收响应的截止时间，而发送模块1320发送的响应消息中也可以携带时间戳选项，所述时间戳选项表示响应消息的生成时间。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

尽管已示出和描述了本发明的一些实施例，但本领域技术人员应理解，在不脱离本发明的原理和精神的情况下，可对这些实施例进行各种修改，这样的修改应落入本发明的范围内。