MQTT_3.1protocol 中文版

物联网重要通讯协议，可以成为物联网通讯的标准Mnemonic EnumerationDescriptionReservedReservedCONNECTClient request to connect to ServerCONNACKConnect AcknowledgmentPUBLISH01234Publish messagePUBACKPublish Acknowledgment■■■■v■■■v■■■L-■■電■v■■■v■PUBRECPublish Received (assured delivery part 1)PUBRELPUBCOMP5678Publish Release(assured delivery part 2)Publish Complete (assured delivery part 3)SUBSCRIBEClient Subscribe requestSUBACKSubscribe acknowledgmentUNSUBSCRIBE10Client Unsubscribe requestUNSUBACK11Unsubscribe acknowledgmentPINGREQ12PING RequestPINGRESP13PING ResponseDISCONNECT14Client is disconnectingReserved15Reserved0->保留;1->连接请求:客户端请求连接到服务器2->连接确认;3->发布消息;4->发布确认;5->发布信息收到(确保分发的第1部分)6->发布信息分发(确保分发的第2部分);7->发布完成(确保分发的第3部分);8->客户端订阅请求9->订阅确认;10->客户端取消订阅请求;11->取消订阅确认12->ping请求13->ping响应14->客户端正在断开连接15>保留;21.1.2. FLAGS(DUP、QoS、 Retain)byte1剩余的bts包含如下的字段:DUP,QoS及 RETAIN,bt位置如下表所示Bit position Name DescriptionDUP Duplicate delivery2-1QOSQuality of Service0RETAIN RETAIN flagDUP位置:byte1,bit3当 client或者 serve试图重发“ PUBLISH"、“ PUBREL"、" SUBSCRIBE"或“ UNSUBSCRIBE"消息时,这个fag会被设置。这个flag适用于QoS值大于零(0),且需要确认的消息。当DUP位被设置时可变头部包含一个消息I消息接收者应将这个Flag视作为一个提示,那就是这个消息此前可能已经被接收过。但是检测消息是否重复时不应该依赖此flag。Qos位置:byte1,bits2-1此fag标明了发布消息的交付质量等级。QoS级别如下表所示Qos value bit 2 bit 1 Description000At most once Fire and Forget<=101 At least once Acknowledged delivery >=1210E× actly once Assured deliver1ReservedRETAIN位置:bye1,bit0这个标识只会用于“ PUBLISH"”消息。当客户端发布一个消息到服务器端时,如果 Retain flag被设为1,则服务器在将消息分发给当前的订阅者后应该保留这条消息(类似 state类型的发布)。当一个新的订阅者订阅某一个主题,如果 Retain flag被设置,则此主题最后保留的消息会被发送给此订阅者。如果没有任何保留的消息,则不会发送。这对于发布者基于" report by excepion”发布消息时非常有用,这种情况下,两个消息之间可能会有一定的间隔。这样,新的订阅者会立即接收保留的数据,或者目前为止最好的结果数据如果初始 PUBLISH到达时,某个订阅者已经存在,那么在服务器给这个订阅者发布一个 PUBLISH时Retain标识不应该被重置,不管初始 PUBLISH的 Retain flag是什么。这样,客户端就可以区分正在接收的消息是保留的消息还是刚刚发布的消息。(类似状态消息支持先订阋后发布,如果是先有订阅者,后有发布者时, Retain不会被设置,因为此订阅者收到的不是保留消息)保留的消息在服务器重启后应该继续保留(持久保存保留消息)。如果服务器收到了一个 payload长度为0且 Retain flag设置在某一个主题上的消息,则服务器可以删除此主题的保留消息。(状态类发布的消息可被删除,收到消息体长度为O, Retain为1的某个主题的消息时, Server会删除此 topIc的保留消息)2.1.2.Byte22. 1.2. 1. Remaining Length位置:byte2表示当前消息剩余的字节数,包括可变报文头以及 payload对于长度多达127个字节的消息,可变长度的编码方案用了一个单独的字节。对于较长的消息处理方式如下。每个字节的7位用于编码 Remaining Length数据,第8位表示在下面还有值。每个字节编码128个值和一个“延续位”。例如,数字64,编码为一个字节,十进制表示为64,十六进制表示为0×40。数字321(=65+2*128)编码为两个字节,重要性最低的放在前面,第一个字节为65+128=193。注意:如果最高位被设置,则表明后续至少还有一个字节。第二个字节是2。协议限制表示所用的字节数最大只能到四个字节,这样,应用程序所能发送的消息长度最长可达268435455(256M)。系列的数字分别表示为:0xFF,0XFF,0xFF,0x7F。下表显示了增加字节数后, Remaining Length所表示的值DigitsFromTo10(0x00127(0X7F)234128(0×80,0x01)16383(0xFF,0x7F)16384(0×80,0X80,0×01)2097151(0×FF,0XFF,0X7F)2097152(0×80,0X80,0×80,0×01)268435455(0×F,0XF,0xFF,0x7F)分别表示:1个字节时,从0到1272个字节时,表示从128到163833个字节时,表示从16384到20971514个字节时,表示从2097152到268435455将十进制数字按照可变长度编码规范进行编码的算法如下:digit=X MoD 128Ⅹ=XDIV12//if there are more digits to encode, set the top bit of this digitif(xdigit digit OR 0x80endifutput’ digitwhile( X>0MOD在C语言中是模运算符号,Iv是整数除(inC),R是位或操作(linC)对 Remaining length域进行解码的算法如下mu1 tippie”=1value= odigit =next digit ircm stream'value += (digit AND 127) multipliermultipliewhile ((digit AND 128)!=0)AND是位与操作(&inC当算法结束时,vlue以字节为单位包含了 Remaining lengthRemaining Length编码不是可变报文头的一部分。编码 Remaining Length所用的字节数不会添加到 Remaining Length的值中。可变长度”扩展字节( extension bytes)”是固定报文头的一部分,而不是可变报文头的一部分。22 variable header/可变报文头某些炎型的MQT命令消息也包括一个 variable header组件,位于 fixed header和 payload之间Remaining Length字段的可变长度不是 variable header的部分, Remaining Length值的字节数没有把 remaining length字段的字节计算在内。 Remaining Length的值只考虑 variable header和playload。更多信息查看 Fixed headerariable header各个字段的格式在下面的章节,按照每个字段在报文头中必须出现的顺序进行描述。2.2.1. Protocol name协议名Protocol name(协议名称)出现在 MQTT CONNECT消息的 variable header中。该字段是UTF8编码的字符串,代表协议名称 MQlsdp,大写显示。222. Protocol version协议版本协议版本表示在 CONNECT消息的 maria| e header中。这个字段是一个8位的无符号值,表示客服端所使用的协议的修订级别,当前版本的协议为3(0×03),如表所示bit754320Protocol version002.2.3. Connect flagsClean session,Wl!wⅧi!QoS和 Retain flags都会在 CONNECT消息的可变报文头中体现。Position: Connect flags字节的第1位如果不设置(0),那么,客户端订阋者断开连接后,服务器必须存储客户端的订阅信息。还包括对订阅的主题所对应的ρσS1和QoS2消息的持续存储,这样,当客户端重新连接时能够把消息分发给客户端。服务器还必须保持在连接断开时正在分发中的消息的状态,这些信息必须一直保持,知道客户端重新建立连接。(类似持久订阅)如果设置(1)那么服务器必须丢弃任何之前维护的关于客户端的信息并将这个连接看作“cean”。当客户端断开连接时,服务器还必须丢弃任何状态。(类似非持久订阅)通常情况下,一个客户端要么釆用这个模式,要么采用另外一个模式,且不会改变,该选择将取决于应用。客户端如果采用 clean会话,将不会接收到过期的信息,每次连接时必须重新订阅。客户端如果采用non- clean会话,将不会错过任何在连接断开时所发布的QoS1或者Q。S2的信息。QoS0的消息永远不会被存储,因为这类消息是基于最佳条件发布的。(意思是:发布Q。oS0的消息时,发布相关的条件很好)这个标志以前被称为" lean start”,现在已经被重命名,因为事实上它应用于整个会话,而不仅仅是应用于最初的连接阶段。服务器可以为客户端提供一种管理机制,用于清除所存储的那些永远都不会重连的客户端的信息。(由ClientID区分每个客户端)bit654|3210User NamePasswordWillCleanFlagFlagRetainQos FlagReservedSessionXXXXX这个字节的Bt0of在这个协议的当前版本中没有用到,为以后版本保留。位置: Connect flags字节的第2位当服务器与客户端通信时遇到/O错误或客户端没有在 Keep Alive期内进行通讯时, Server会代表客户端发布一个Wi消息。服务器收到来自客户端的 DISCONNECT消息时,并不会触发W消息的发送。如果设置了 Will flag, Connect flags的字节中就必须有W!QoS和 Will Retain字段, payload中必须有 Will Topic和wⅲ message字段。(可以用于监控客户端与服务器之间的连接状况)Wi!flag的格式如下表所示bit765421User Name PasswordWillIllwIllCleanFlagadRetain Qos FlagSessionReservedXXXX这个字节的Bit0在此协议的当前版本中没有被用到,为将来预留。位置: Connect flags字节的第4、3位连接中的客户端如果在 Will QOS字段中为W消息指定了QoS级别,一旦发生非主动的连接断开,Wi消肖息将会被发送。Ⅵ消息定义在 CONNECT消息的 payloadi中。如果设置了 Will flag,那么Wi!QoS字段是强制性的,否则 Will Qos字段的值将被忽略。WQoS的值是0(0×00),1(0×01),or2(0×02)。 Will Qos标志显示在下面的表格中。bit75431User NamePasswordWillWillWillCleanReservedFlaFlagetainQos FlagessIon1X位置: connect flags字节的第5位wi! Retain flag指明了服务器是否应该保留W消息,此Wi消息是在客户端意外断开连接时由服务器代表客户端所发布的。如果设置 Will flag,则 Will Retain flag是强制性的,否则 Will Retain flag将被忽略。Will Retain flag的格式如下表所示7654321User namePasswordWillWillWillCleanReservedlagadRetain Q。 s FlagSessionXXXXBit0本版本不用,为以后预留.Position: Connect flags字节的第6、7位连接中的客户端可以指定用户名和密码,设置这两个标志位意味着一个用户和一个可选的密码会包含在 CONNECT消息的 payload里。如果设置了 User name标志,则 User name字段是强制性的,否则υ Iser name的值将被忽略。如果设置 Password标志,则 Password字段是强制性的,否则 Password的值将被忽略。如果没有设置UserName,而提供 Password是无效的。仅仅提供了 password而没有提供 user name是无效的。bit7654320User namePasswordWillWillCleanFlagFlagRetainFlagReservedSessionX XX