IOT网络协议
MQTT协议
消息队列遥测传输协议(MQTT,Message Queuing Telemetry Transport), ISO标准(ISO/IEC PRF 20922)。
介绍
基于发布(Public)/订阅(Subscribe)范式的消息协议,
工作在TCP/IP协议族之上
为低性能远程设备和糟糕网络状况设计
两个网络实体:消息代理(message broker)与客户端(client).
三种身份:发布者(Publish)、代理(Broker)、订阅者(Subscribe)。
消息代理(Message broker)
接收客户端的消息并转发到客户端,代理的角色(Broker),路由转发?那个客户端订阅了这个主题的消息,就把这个消息发给对应的客户端
多个客户端订阅同一个主题,收到相同消息的时间是一致的吗?换句话讲,消息代理是并行分发还是串行分发?
消息代理收到一个没有订阅者的消息,一般是丢弃掉,除了发布者标记为保留消息(retained message)
客户端(Client)
发送控制消息(Publish),携带主题信息。订阅特定的消息(Subscribe)。客户端不知道是谁订阅了这些消息,只管发布。
客户端只与消息代理进行连接,有多个代理。客户端与代理是一对多的吗?
客户端怎么保证消息到达了?想要同步操作怎么办?
控制消息最小只有2字节的数据(头部),最多256MB数据,14种预定消息类型用来:连接客户端与代理、断开连接、发布数据、确认数据接收、监督客户端与代理连接。
使用Last Will(遗言)和Testament(遗嘱)特性通知有关各方客户端异常中断的机制。
消息
消息作为客户端和服务端通信的媒介,一个消息分成主题(Topic)和负载(Payload)两个部分
Topic
消息的类型,订阅者订阅了这个消息之后,就会收到这个Topic的Payload
Payload
消息的内容,真正的业务数据
服务质量(Qos)
MQTT会构造连接,建立客户端与服务器之间的连接,提供一个有序无损的、基于字节流的双向传输通道。有数据通过该通道时,会将Qos和Topic相连。
0.最多一次传送(只发,数据到没到不管)
1.至少一次传送(确认数据交付)
2.正好一次传送(保证数据交付成功)
问:1和2有什么大的区别吗?
数据到了和数据到了并收到回复了?
订阅(Subscription)
订阅包括主题筛选器(Topic Filter)和Qos。订阅和一个会话(Seesion)关联。一个会话会有多个订阅,每个订阅有不同的主题筛选器。我只订阅我感兴趣的内容。
会话(Session)
客户端与服务端建立连接之后形成一个会话。
主题筛选器(Topic Filter)
表示订阅到的感兴趣的内容,我执行订阅我感兴趣的内容,其他内容我并不关心。对主题名进行筛选。
RTP/RTSP/RTMP
TLV
WebRTC
COAP
https://github.com/1248/microcoap
编解码有bug,都依赖同一块内存。
option-delta
可以肯定的是第一个字节的数据肯定是有的,第一个字节的数据一定要有。
针对第一个字节的数据进行解析,
前4个bit作为Delta,可以表示[0, 15]
后4个bit作为长度,[0,15]
规定是:delta的[13,15]作为保留值
- delta = 13
- delta = 14
- delta = 15
option-length选项
4bit的无符号整数,[0,12]表示option值长度(byte),[13,15]保留做其他作用
- 13: 后面有8bit的额外数据(无符号整型)跟在第一个字节之后,现在的option长度等于8bit的值+13
- 14: 后面有16bit的无符号整型(大端)跟在后面,现在option长度计算方式: 269 + 16-bit数字的值。为什么是269?因为13的方式已经存不下了(13 + 256 = 269)只能开新的。那么现在option长度最多能表示多少: (269 + 2 ^ 16)= 65805(byte)
- 15: 保留,当前做错误消息处理