啊不知道昨天那个咋整的，显示代码块的地方好像不大对劲。。。

今天差不多把块传输的这部分看完了，也大概记了一点

coap 块传输

块传输新增了几个option

+--------+--------+-----------+
| Number | Name   | Reference |
+--------+--------+-----------+
| 23     | Block2 | RFC 7959  |
|        |        |           |
| 27     | Block1 | RFC 7959  |
|        |        |           |
| 28     | Size2  | RFC 7959  |
+--------+--------+-----------+

 Table 3: CoAP Option Numbers

size1在rfc7252中定义

为何引入块传输

coap基于udp,最大传输数据报长度为64kb
避免数据报文分片(基于IP)
避免适配层分片(基于RFC4919 6LoWPAN)

Block Option格式

0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  NUM  |M| SZX |
+-+-+-+-+-+-+-+-+

0                   1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          NUM          |M| SZX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0                   1                   2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   NUM                 |M| SZX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 1: Block Option Value

Option Value为变长0~33个字节的无符号数
NUM: 给定大小的块的序号,从0开始
M: 是否有更多块
SZX: 块大小,取值范围为0~6,实际代表的payload大小为2^(4+SZX),即16~1024Byte

Block Option语义

Block1 和 Block2 都可以出现在Request和response中,但是含义不同

Block1 出现在Request和Block2出现在response中时,代表正在执行块传输,描述了正在传输的payload在整个body的哪个部分,这里称为描述性用法
它们出现在相反的地方时,则提供了如何形成或者处理有效载荷的附加控制,这里称为控制性用法

这里再额外写一下自己关于这两个用法粗略的理解

当在进行块传输时,block option用来描述正在传输的块的信息,这种叫做描述性用法
当需要修改或者建议块传输的大小,请求传输块等情况时,block option用来指示期望的块的大小或者序号等,这种叫做控制性用法

描述性用法

Block1出现在Request和Block2出现在response中时.option value的取值含义如下

NUM: 表示当前Message的Payload在整个body中的编号
M: 表示是否还有更多块才能完成整个body的传输
SZX: 当M为1时,表示当前payload的大小2^(SZX+4),当M为0时,表示大小范围是1~2^(SZX+4)

控制性用法

Block2

当Block2出现在Rquest中时,属于控制性用法:

NUM: 期望response传输的块号
M: 无意义,设置为0
SZX: 当NUM为0时,表示希望采用的块的大小,当NUM不为0时,直接采用上一个接收到的Response中的大小

这里举两个例子

如果request中block2期望的值很大,response可能会返回小一些的值,并且下一个request中的szx必须调整为这个.

Block1

当Block1出现在response中,属于控制性用法

NUM: 表示正在确认的块号
M: 如果Request中的Block1的M为1,server可以选择是否对每个块执行单独的操作或者是以原子方式处理整个主题请求,或者混合.

如果response中M置1,不是对这个request最终的response,表明server希望收集body后原子的执行request

如果response中M置0,标明该request已经执行,并且这个response是最终的response(即使之前request中的M为1的情况)

SZX: 标明server期望接收的块的最大值,可能是初始交换的SZX值,也可能是server指定的更小的值,client需要使用该值进行后续的block的传输(这里有个注意事项,详见[实现注意事项1]

Size1 和 Size2 Option

块传输时,了解整个body的大小,是有一定优势的,因此定义了size1和size2 option

Size1 option: 用于指示通过request传输的representation的大小
Size2 option: 用于指示通过response传输的representation的大小

新增的response code

新增了两个response code,并扩展了一个原coap规范中response code的使用场景

2.31 Continue
4.08 Request Entity Incomplete
4.13 Request Entity Too Large

实现注意事项

当client请求块大小时,如果server不满于当前块的大小,但是仍然处理了这个包,后续的包的大小和num,需要安装服务器给的块大小重新进行计算.
例如第一个请求包为0/1/128,但是这里服务器返回0/1/32,则client继续传输数据的时候就是4/1/32,因为128/32=4,索引从0开始,这里可以理解为已经传了前四个包了.所以新的块传输请求num从4开始

coap协议学习笔记块传输