1、基于 CoAP 的 M2M 课程教学及实验设计 张笑非 刘镇 滕玮 江苏科技大学计算机学院 北京工业大学信息学部 摘 要： 阐述以 IETF Co AP 协议扩展标准 RFC 7959“Co AP 块级传输”中的案例作为M2M 课程教学内容, 提出通过 Eclipse 开源项目 Californium 中提供的 API 对实验内容进行设计并利用 JUnit 框架设计 Co AP 块级传输案例的测试用例, 测试结果验证了相应的块级传输流程。关键词： CoAP; 块级传输; 请求/应答对; Californium 项目; 作者简介：张笑非, 男, 讲师, 研究方向为通信技术研究与教学工作, 。基金
2、：江苏科技大学 2016 高教研究立项课题 (GJKTY201625) 0 引言当前, 全国众多高校的物联网专业都开设了 M2M 通信技术课程, 由于涉及的理论和技术框架还在发展中, 教学及实验内容也在不断建设和完善中。Co AP 是一种应用于受限节点和受限网络的 Web 传输协议, 类似 HTTP 但又不是盲目地在HTTP 的技术上进行缩减, 而是针对 M2M 应用进行优化, 实现 REST 架构风格的一个子集1。在物联网应用中, Co AP 成为 HTTP 的替代者而实现智能硬件到Web 的接入2。Co AP 的标准已在 IETF RFC 7252 中给出, 文献3提出将 RFC标准文档应
3、用于计算机网络教学中。MIT、Apache 等机构也都给出了多种编程语言版本的 Co AP 实现, 且文献4-6也提出网络编程在提高教学和实验效果方面的作用, 文献7分别就案例分解和重构在网络编程教学中的应用与改革进行了说明。这些都为在物联网专业的 M2M 通信技术课程中准备了充足的教学和实验素材。1 Co AP 教学设计本教学设计使用 IETF RFC 79598作为 M2M 通信技术课程中 Co AP 的教学内容。RFC 7959 是对 RFC 7252 的更新, 是对 Co AP 块级传输方式的定义。Co AP 消息的基本传输方式是在客户端和服务端之间, 通过一次请求/应答对完成, 可以
4、满足从传感器读取数据, 或向执行器发送指令等小型载荷需求, 但面对固件更新这种需要承载大型载荷的 M2M 应用时, 就需要对这些载荷进行分割。由于 Co AP 使用的传输层协议是 UDP 或 DTLS, 因此不能像 TCP 对 HTTP 消息一样进行分割和重新排列。RFC 7959 在不考虑使用 IP 碎片机制的情况下, 通过对 Co AP协议增加一对 Block 选项的方式, 对单个大型载荷进行分块、并通过多次请求/应答对完成传输。教学设计中之所以选择 RFC 7959 定义的 Co AP 块级传输作为教学内容, 是因为对于协议三要素 (语法、语义、时序) 而言, RFC 7252 中介绍的
5、单次请求/应答对作为时序部分较为简单。而基于块级传输的多次请求/应答过程, 能够帮助学生更好地理解 Co AP 消息在客户端/服务端之间的交换过程;同时也可以对比受限网络环境和常规互联网环境下, 由于需求差异导致协议栈的每一层功能和策略存在的差别。1.1 教学内容Co AP 块级传输中需要利用块选项 (Block Option) , 块选项分为 Block1 和Block2。Co AP 中的请求/应答对, 其中请求消息由客户端发送给服务端, 应答消息由服务端返还给客户端。若需进行分块的载荷来自客户端, 如 PUT 和 POST操作, 则块选项为 Block1。若需进行分块的载荷来自服务端, 如
6、接收到 GET 操作, 则块选项为 Block2。块选项是变长的, 可以是 1 个或 2 个或 3 个字节。块选项包含 3 个字段, 即 NUM、M 和 SZX, 其中 NUM 的长度可以是 4bit 或 12bit或 20bit, 是当前块在所属载荷分割出的多个块中的序列号;M 占 1bit, 1 表示还有后续块, 0 表示本块是最后一个;SZX 占 3bit, 是当前块尺寸的指数, 2 (SZX+4) 就是当前块的字节数。为了便于讲解, 后面的例子中会将块选项写成4 个部分, 即“块选项类型:NUM/M/2* (SZX+4) ”, 例如:2:2/0/32 表示一个Block2 块选项, 块
7、序号为 2、没有后续块、当前块的长度是 32 字节;1:3/1/128表示一个 Block1 块选项, 块序号为 3, 还有后续块, 当前块的长度是 128 字节。1.2 教学案例RFC 7959 的第 3 节给出 4 类案例, 每类案例中包含若干具体案例, 见表 1。这些案例涵盖了块级 GET、块级 PUT/POST 的消息交换过程, 其中块级 PUT 与块级POST 的消息交换过程是一样的, 它们的区别在于对原子性和幂等性上的要求不一样。这些案例演示了基本的块级转发流程、存在重传的块级转发流程, 存在块尺寸协商的块级转发流程。表 1 Co AP 块级传输案例 下载原表 1.2.1 简单块级
8、 GET 案例如图 1, 该案例给出一个 GET 请求被分解为三次请求/应答对, 客户端在第一次向服务端发起 Co AP GET 消息时, 并不知道服务端将要返回的载荷大小。服务端在第一次应答中建议的块尺寸是 128 字节, 并且 M 标志位为 1, 说明还有后续的块。于是客户端继续向服务端发送 GET 请求, 直到接收到的来自服务端的第 3 个应答时, 由于 M 标志位为 0, 说明整个载荷接收完毕。本案例中由于来自服务端的载荷被分割成 3 个块, 所以块选项类型是 Block2, 3 个块的 NUM 依次为 0、1、2, 每个块的尺寸都是 128 字节, 而实际情况中, 第 3 个块的长度
9、只需满足不小于 1 个字节、且不大于 128 字节。图 1 简单块级 GET 的消息交换过程 下载原图1.2.2 存在 CON 消息丢失的后期协商块级 GET 案例如图 2, 教学设计中利用该案例阐述了 Co AP 块级传输中的两个要素, 一个是块尺寸的后期协商, 另一个是重传机制。案例中 Co AP 消息过程包含 5 个请求/应答对, 这可以通过 MID 的值或块选项字段 NUM 看出。MID 是 Co AP 首部中的消息标示符, 该例中 MID 从 1234 到 1238 共 5 个;同样, NUM 字段在 5 次请求/应答对中分别是 0、2、3、4、5 共 5 个, 而没有 1, 这正是
10、后期协商造成的。图 2 存在 CON 消息丢失的后期协商块级 GET 的消息交换过程 下载原图客户端和服务端可以在消息交换中的多次修改块尺寸, 提供类似 TCP 的拥塞控制功能9。在教学设计中, 首先要讲解什么是早期协商, 即在第一次请求/应答对的请求消息中, 如果块选项的 SZX 被设置了值, 那这个值就是客户端期望服务端在后续应答时设置的块尺寸指数, 反之则说明客户端没有进行早期协商。第一次请求/应答对中的应答消息到达客户端后, 客户端对服务端设置的块尺寸128 字节并不满意, 因此在第二次的请求/应答对的请求消息将块尺寸设置为 64字节。由于第一次应答, 服务端已经返回了 128 字节,
11、 而这时客户端设置的块尺寸为 64 字节, 因此相当于之前已经发送了两个 64 字节的块, 第二次应答消息中的块相当于是第 3 个 64 字节了, 这就是为什么转发过程中没有出现 NUM为 1 的情况。其次, 在这个案例中, 还需要对 Co AP 的重传机制作讲解。Co AP 请求/应答对的可靠性是通过设置请求消息中的 Type 字段为“需确认”、即 CON, 客户端会通过计时器判断在规定时间内是否收到与请求消息 MID 相同的应答消息, 否则会重新发送同样的请求消息。该案例中模拟了第二次请求/应答对的请求消息丢失的情况, 若是应答消息丢失则仍由客户端重新发送请求, 服务端并不设置超时机制。1
12、.2.3 原子性块级 POST/块级应答组合案例如图 3, 教学设计中利用该案例阐述了 Co AP 块级传输中的两个要素, 一个是原子性块级传输, 另一个是 Block1 和 Block2 块选项的组合。整个 Co AP 消息过程包含 6 个请求/应答对, 即该例中 MID 从 1234 到 1239;过程的前半部分是客户端通过 Block1 块选项把发送给服务端的数据分成了 3 个块依次传输, 过程的后半部分是服务端通过 Block2 块选项把返回给客户端的结果分成了 4 个块依次传输。由于在第 3 次请求/应答对中通过双工的方式同时完成了最后一个Block1 块和第一个 Block2 块,
13、 所以双方交换 7 个块通过 6 次请求/应答对便完成了。在教学设计中, 首先要讲解原子性块级传输的机制, 与之相对的是无状态块级传输。它们的区别在于在服务端通过应答消息的 M 字段, 以表示块级传输过程中的所有请求/应答对构成一个原子性操作, 还是说每个请求/应答对构成独立的操作。从本案例块级传输的每一次应答消息可以看到, 除了最后一次应答消息, 之前应答消息的 M 字段均为 1, 说明服务端预期来自客户端更多的请求消息, 直到最后一次应答消息 M 字段为 0, 表示服务端认为之前接收到的所有请求/应答对成了一次原子性的块级传输过程。而在无状态块级传输中, 即使客户端发送的请求消息中通过 M
14、 字段置 1、以告知服务端本次请求/应答对后还有更多的请求/应答对, 但服务端每次向客户端发送的应答消息的 M 字段都为 0, 以表示服务端可以独立处理这些被分割的块, 每一个请求/应答对是独立的。图 3 原子性块级 POST/块级应答组合的消息交换过程 下载原图其次, 在这个案例中, 还需要对 Co AP 的 Block1 和 Block2 块选项组合机制作讲解。整个块级传输过程共包含 6 次请求/应答对, 其中第 3 次请求/应答对的应答消息中同时包含了 Block1 和 Block2 块选项。这是因为客户端通过前三次请求将输入数据提交给了服务端, 而服务端则在第三次应答中通过 Block
15、1 块选项 M 字段为 0 表示数据接收完成、同时还通过 Block2 块选项开始向客户端返回结果, 直到第 6 次应答通过 Block2 块选项 M 字段置 0 告知客户端结果返回完毕。2 Co AP 实验设计本实验设计使用 Eclipse 开源项目 Californium10作为 Co AP 的实验环境。Californium 是一个面向后台服务和强劲 Io T 设备的 Co AP 框架, 其为RESTful Web 服务提供的 API 支持 Co AP 的所有特性。实验设计在 Californium中将每个案例编写成 JUnit 测试单元来验证, 文献11就如何将 JUnit 应用到课程
16、教学中做了探讨。2.1 案例的测试框架设计由于每一个 Co AP 案例的测试设计都包含通用模块和独立模块, 因此在设计上利用 JUnit4 的标注机制。如图 4 所示, 用Before Class 定义 Co AP 网络参数初始化函数 init () , 用Before 定义 Co AP 客户端实例和服务端实例的创建函数 setup Endpoints () , 用After 定义 Co AP 客户端实例和服务端实例的销毁函数 shutdown Endpoints () , 用Test 分别定义三个块级传输过程函数test GET () 、test GETLate Negotional Los
17、t ACK () 、test Atomic Blo ckwise POSTWith Blockwise Response () 。图 4 实验测试流程 下载原图2.2 测试的通用模块设计锁步 (Lockstep) 也称为时钟同步, 是一种容错技术12。为了能够重现教学案例中的场景, 我们将服务端运行在正常模式, 而将客户端运行在锁步模式, 即客户端每次发送和等待接收, 都是通过明确的命令来控制。因此, 首先定义测试用例的静态初始化函数 init () , 在其中为 Co AP 服务端定义运行时的网络参数:接着就需要定义每次 Test 实例的初始化函数 setup Endpoints () ,
18、其中需要创建并启动运行在正常模式的 Co AP 服务端实例, 以及运行在锁步模式的 Co AP 客户端实例:最后定义每次 Test 实例运行完毕时执行的销毁函数 shutdown Endpoints () :2.3 测试的独立模块设计教学设计中的 3 个案例, 可以通过 Co AP 客户端的锁步模式完成相应的块级传输流程。其中, 客户端 client 通过函数 send Request 完成请求消息的发送、通过函数 expect Response 确认应答消息的接收。以案例 3 为例, 为了完成图3 中的块级传输流程, 先通过函数 generate Random Payload 为 Co AP
19、 两端生成指定长度的随机载荷;另外, Co AP 客户端需要指定 token 作为区分并发请求消息的标识符, 以及 path 作为 POST 请求创建资源的路径。案例 3 中的 6 次请求/应答对, 每一次请求/应答对在 Co AP 客户端锁步模式下、通过执行一对 send Request 和 expect Response 函数来完成测试。第一次请求/应答对:第二次请求/应答对:第三次请求/应答对:第四次请求/应答对:第五次请求/应答对:第六次请求/应答对:2.4 测试结果将通用模块和案例 3 独立模块的组合作为 JUnit 单元测试, 图 5 中的运行结果正确验证了案例 3 在教学设计上的
20、块级传输流程。图 5 案例 3 的 JUnit 单元测试结果 下载原图3 结语该设计方法可以被用到 M2M 课程其他知识点, 或者其他课程的教学和实验设计当中去, 特别是目前一些涉及新技术的物联网专业课程, 在实际的教学过程中让学生掌握先进技术的原理和开发方法, 以提高他们的专业素质和能力。参考文献1Shelby K S, Hartke C B.The Constrained Application Protocol (Co AP) , IETF RFC 7252, June 2014EB/OL.2017-06-16.https:/tools.ietf.org/pdf/rfc7252.pdf.
21、 2LevT, Mazhelis O, Suomi H.Comparing the cost-efficiency of Co AP and HTTP in Web of Things applicationsJ.Decision Support Systems, 2014, 63 (3) :23-38. 3王盛邦, 田海博.RFC 在网络协议教学中的应用J.现代计算机 (专业版) , 2013 (23) :35-39. 4张晓明, 杜天苍, 秦彩云.计算机网络编程课程的教学改革与实践J.实验技术与管理, 2010 (2) :4-7. 5胡静, 赵雷, 罗宜元, 等.网络工程专业的网络编程课程
22、教学与改革J.计算机教育, 2014 (18) :35-38. 6戚平, 石乐义.原始套接字编程在网络实验教学中的应用J.实验室研究与探索, 2012 (7) :325-327. 7吴杰, 梁妍.基于实验案例分解和重构的 Android 网络编程教学改革探索J.信息技术与信息化, 2016 (5) :103-110. 8Borman C.Shelby Z.Block-Wise Transfers in the Constrained Application Protocol (Co AP) , IETF RFC 7959, August 2016EB/OL.2017-06-16.https:/
23、tools.ietf.org/pdf/rfc7959.pdf. 9Castellani A P, Rossi M, Zorzi M.Back pressure congestion control for Co AP/6Lo WPAN networksJ.Ad Hoc Networks, 2014, 18 (1) :71-84. 10Kovatsch M, Lanter M, Shelby Z.Californium:Scalable cloud services for the Internet of Things with Co APC/Internet of Things.IEEE, 2014:1-6. 11朱冬玲.JUnit 在软件测试课程教学中的应用J.福建电脑, 2013 (10) :56-57. 12付爱英, 周晶晶.基于 Lockstep 的容错技术的研究J.科技广场, 2012 (7) :70-73.
