《coap的块传输详解》由会员分享，可在线阅读，更多相关《coap的块传输详解（32页珍藏版）》请在金锄头文库上搜索。
1、基于CoAP的块传输详解,Jade 2016/12,目录,概述 新的Options和Response Examples Others,概述,RFC7959定义了CoAP协议的块输出规范，对于resource representation无法通过一个CoAP数据包承载时，发起块传输过程 为何在CoAP引入块传输 CoAP基于UDP，最大传输数据报的长度为64KByte，无法支持FW升级（除非开发基于CoAP的特定应用） 避免数据报文分片(基于IP) 避免适配层分片（基于RFC4919 6LoWPAN）,术语说明,Payload：指的是单个CoAP Message中的内容 Body：通过块传输的R
2、esource Presentation整体内容,目录,概述 新的Options and Response Examples Others,新增的Option,CoAP块传输标准新增了4个Option(size1最早在RFC7252中定义，RFC7959扩展了其含义) 块传输机制采用Block1和Size1完成Request中Resource Presentation的块传输；采用Block2和Size2完成Response中的Resource Presentation的块传输 Size Option是Elective且Safe-to-Forward的，并且是No-Cache-Key,Bloc
3、k Option格式,Option Value为变长0-3个字节的无符号数 NUM：具有给定大小的块序列内的块（NUM）的相对数（从0开始编号），即块序号 M：是否有更多块 SZX:块大小，取值0-6，实际每个块的payload为2*(4+SZX)，即块大小为16-1024Byte,Block Option语义,Block1和Block2都可以出现在Request和Response中，但是含义不同： Block1出现在Request中和Block2出现在Response中，代表正在执行块传输，它们描述了正在传输的Payload在整个Body的哪个部分，此称为描述性用法(descriptive
4、usage) Block1和Block2用在上述相反的情况，提供了对如何形成或处理有效载荷的附加控制，此称为控制性用法(control usage),描述性用法,Block1出现在Request中和Block2出现在Response中，Option value取值含义： NUM：表示当前Message的Payload在整个body中的编号 M：表示是否还有更多块才能完成整个body的传输 SZX：当M为1时，表示当前Message的Payload的大小(2*(SZX+4)；当M为0时，实际Payload为1到2*（SZX+4）Byte； 参考Example-1 of Block2和Exampl
5、e-1 of Block1,Block2的控制性用法,Block2出现在Request中，属于控制性用法： NUM：期望Response传输的块号 M：无意义，设置为0 SZX：当NUM为0时，表示希望采用的块大小；当NUM非0时，直接采用上一个接收到的Response中的块daxiao 说明 Block2作为描述性用法(出现在携带块的Response中)，Client端有机会通过Request中携带Block2(NUM:0,M:0,SZX:期望值)通知Server，Client端希望采用的块大小；参考Example-2 of Block2。如果Request建议一个比较大的SZX值，下一个R
6、equest必须将SZX调整为Response中的SZX，最终结果是Server使用其选择的较小的SZX或者是Server采用Request建议的SZX完成Body的传输 当Client收到Server发送的携带Block2的Response时，如果M不为0，Client需要继续发送携带Block2（NUM:上一个Response中Block2的NUM+1，M:1，SZX：上一个Response中Block2的SZX）的Request，请求Server继续传输下一个块，直到Server端返回的Response中Block2的M为0。参考Example-1 of Block2,Block1的控制
7、性用法,Block1出现在Response中，属于控制性用法： NUM：表示正在确认的块号 M：如果Request中Block1中的M为1，Server可以选择是否单独对每个块执行操作或者是以原子方式处理整个主体的请求，或者是两者的任何混合： 如果Response中M置1，表示这不是对Request的最终的Response(Example-2 of Block2)，这表明Server希望收集body后原子的执行Request 如果Response中M置0(即使Request中M为1)，表明该Request已经执行，并且该Response是针对本次Request的最终Response(Examp
8、le-2 of Block1)(包括对之前Request中M为1，对应Response为M为1的序列)（怪异） SZX：表明Server期望接收的块的最大值（可以是初始交换的SZX或者更小值）(Example-3 of Block1)，如果Server通过Response中Block1指定了比初始交换更小的值，Client需要使用该值进行后续Block的传输，并在下一个Request中块号,Size1和Size2 Option,块传输时，了解整个body的大小，是有一定优势的，因此定义了Size1和Size2 Option Size1 Option：用于指示通过Request传输的Repres
9、entation的大小，场景： Size Indication：出现携带Block1的Request中，用于Client向Server指示Representation的大小（Byte) Size Accept Indication：出现在4.13 Response中(CoAP协议规范)，表示Server期望并且能处理的Representation的大小 Size2 Option：用于指示通过Response传输的Representation的大小，场景： Size Request：出现在Request中，Value取值为0，用于Client向Server请求其提供Representation的
10、大小 Size Indication：出现在携带Block2的Response中，用于Server向Client指示通过块传输的body的大小(Byte),新增的Response Code,块传输新增了两个Response Code，并扩展了一个原CoAP规范中Response Code使用场景 2.31 Continue：表明Server收到了本次通过Request传输的块，期望Client继续发送下一个块，目前还不能执行该Request，返回最终的Response 4.08 Request Entity Incomplete：表明Server由于多种原因：client未发送所有块；没有按S
11、erver要求的顺序发送块；块发送时间跨度太大导致Server已丢弃块，未能完成body的接收。协议也说明，返回该Response的原因可能是Client发送的块的Content-Format与Server对于当前Resource状态不匹配 4.13 Request Entity Too Large：原CoAP协议指出Server返回一个携带size1的Response，表明Server期望和能处理的Request Entity的最大值；块传输规范指出允许server在未来执行一个原子处理，但是无存储空间处理新的块时，返回该Response；还允许Server不使用Block1的请求返回4.1
12、3 Respone作为客户端尝试发送Block1的提示；最后，允许Server对携带Block1的Request，返回一个包含比Request中更小的SZX的Block1，提示Client以该SZX发送块,目录,概述 新的Options and Response Examples Others,Example-1 of Block2,过程： Client发出Get Request Server启动块传输，Option2 NUM为0，M:1，SZX为128，payload包含128Byte的内容 Client继续用Get 获取下一个期望的块，Option2 NUM为1,M:0,size为128
13、Server返回编号为2的块，以此循环，最后一个块M为0，表示所有块完成传输 Client发出Request携带Option2，属于控制性用法；Server返回响应携带Option2属于描述性用法,Option:NUM/M/SZX,Example-2 of Block2,Client对于块传输SZX有预期，所以在第一个Request携带了Option2，随后的交互过程同Exampe-1,Example-3 of Block2,Client在收到Server的Response后，表示对于Server选择的SZX不爽，发出的第二个Request中携带了比Server更小的SZX，此Request中
14、的NUM为2(=128/64)，Server满足Client的要求，后续块都通过SZX传送(除最后一个),Example-4 of Block2,上图模拟Request未到达Server引起的重传场景，由于块传输基于RFC7252的Request/Response模型，不会对块传输带来额外的变更,Example-5 of Block2,上图模拟Response丢失的场景,Example-1 of Block1,过程 Client启动块传输，发出携带Option1的Request，payload中包含SZX为128字节的内容 Server返回Response，携带Option1，表示该块已收到；
15、 Client继续通过携带Option1的Request，发送下一块；Server返回2.31 response；依此类推直到最后一个块 Client发出最后一个块，Option1中的M选项为0 Server收集到所有块后，执行相应的处理，返回2.04 Changed,Example-2 of Block1,对比Example-1 of Option1 ，Example-2 of Option1对应于不需要收集整个body就可返回final Response的场景,Example-3 of Block1,上图Server不满Client选择的SXZ大小，所以返回第一个Response中携带了其
16、预期的SZX，并确认第一个大小为128Byte的块已收到；Client随后满足Server的要求，后续Request发送SZX为64Byte的块，更改SZX后的第一个Request封包的NUM要结合之前发送的字节数和当前协商的SZX重新计算,Example-1 of Combine Block1 and Block2,上图Server不满Client选择的SXZ大小，,Example-2 of Combine Block1 and Block2,上图Server不满Client选择的SXZ大小，,Example-1 of Combine Observe and Block2,Example-2 of Combine Observe and Option2,目录,概述 新的Options and Response Examples Others,组播相关-在组播中使用Block2,协议针对组播场景，有如下说明 Client可以在组播GET Request中携带Block2(NUM为0)通知Server，Client端期望接收的Response的大小 Serve
