qos

会话状态 为实现QoS等级1和QoS等级2协议流，客户端和服务端需要将状态与客户标识符相关联，这被称为会 话状态。服务端还将订阅信息存储为会话状态的一部分。会话可以跨越一系列的网络连接。它持续到最新的网络连接（Network Connections）加上会话过期间隔 （Session Expiry Interval）。 客户端的会话状态包括： 已发送给服务端，但是还没有完成确认的QoS等级1和QoS等级2的消息。 从服务端收到的，但是还没有完成确认的QoS等级2消息。 服务端的会话状态包括： 会话是否存在，即使会话状态其余部分为空。 客户端订阅信息，包括任何订阅标识符。 已发送给客户端，但是还没有完成确认的QoS等级1和QoS等级2的消息。 等待传输给客户端的QoS等级0（可选），QoS等级1和QoS等级2的消息。 从客户端收到的，但是还没有完成确认的QoS等级2消息。遗嘱消息和遗嘱延时间隔。 如果会话当前未连接，会话结束时间和会话状态将被丢弃。 保留消息不是会话状态的一部分，会话结束时不被删除。 存储会话状态 当网络连接打开时，客户端和服务端不能丢弃会话状态。当网络连接被关闭并且会话过期 间隔已过时，服务端必须丢弃会话状态 网络连接 MQTT v5.0使用的传输层协议是 [RFC0793] 定义的TCP/IP协议。下面的协议也支持： TLS [RFC5246] WebSocket

一）查看Customer到Provider的数据包的方式 1.使用的是Logback输出日志包的进行查看 添加logback的配置文件并且日志的级别必须为DEBUG <?xml version="1.0" encoding="UTF-8" ?> <configuration> <!--定义日志文件的存储地址 勿在 LogBack 的配置中使用相对路径--> <property name="LOG_HOME" value="${catalina.base}/logs/" /> <!-- 控制台输出 --> <appender name="Stdout" class="ch.qos.logback.core.ConsoleAppender"> <!-- 日志输出编码 --> <layout class="ch.qos.logback.classic.PatternLayout"> <!--格式化输出：%d表示日期，%thread表示线程名，%-5level：级别从左显示5个字符宽度%msg：日志消息，%n是换行符--> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{50} - %msg%n </pattern> </layout> </appender> <!-- 按照每天生成日志文件 -->

MQTT介绍： http://mqtt.org 服务器端 https://mosquitto.org/download/ PHP客户端 https://github.com/bluerhinos/phpMQTT MQTT QOS等级订阅和发布的关系 https://www.jianshu.com/p/ebe4b2c0461d qos ＝ 0：仅发一次，不管是否能收到 qos ＝ 1：没返回一直发，可能有重复接收（接收到消息可能未传递给客户端） qos ＝ 2：保证必须收到，并且不重复（使用MSG_ID保证不重复接收） 也就是服务器只会按pub和sub两者qos等级最小的那个qos规则来发送消息。 pub时指定的qos是服务器肯定按此规则接收，但是最终订阅者不一定。 sub时指定的qos表示订阅者可以接收的最高消息等级，也就是可能收到更低等级的消息。 遇到的问题 1. qos=2 一直没有测试成功，mosquitto 已经收到客户端的消息，但订阅端就是接收不到。 2. 当有多个订阅端时，又是后收到的消息居然会不全，前面会有乱码出现。 3. 没有HTTP简单直接；感觉没有HTTP可靠通用； 消息发布 <?php require("../phpMQTT.php"); $server = '127.0.0.1'; // 服务器IP $port = 1883; // 服务器端口

之前项目中使用到了mqtt，刚开始用着用着都不知道是干啥的，后来百度了一下： MQTT MQTT基于订阅者模型架构，客户端如果互相通信，必须在同一订阅主题下，即都订阅了同一个topic，客户端之间是没办法直接通讯的。订阅模型显而易见的好处是群发消息的话只需要发布到topic，所有订阅了这个topic的客户端就可以接收到消息了。 发送消息必须发送到某个topic，重点说明的是不管客户端是否订阅了该topic都可以向topic发送了消息，还有如果客户端订阅了该主题，那么自己发送的消息也会接收到。 MQTT特点 使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。这一点很类似于XMPP，但是MQTT的信息冗余远小于XMPP 对负载内容屏蔽的消息传输 使用TCP/IP提供网络连接。主流的MQTT是基于TCP连接进行数据推送的，但是同样有基于UDP的版本，叫做MQTT-SN。这两种版本由于基于不同的连接方式，优缺点自然也就各有不同了 三种消息传输方式QoS： 0代表“至多一次”，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。 1代表“至少一次”，确保消息到达，但消息重复可能会发生。 2代表“只有一次”，确保消息到达一次。这一级别可用于如下情况，在计费系统中

参考自： https://www.cnblogs.com/sxkgeek/p/9140180.html 目录 一、MQTT简介 二、特性 三、实现方式　　 四、MQTT的搭建（ubuntu） 五、MQTT权限配置 六、MQTT实现（Java语言） 正文 　　物联网是新一代信息技术的重要组成部分，也是“信息化”时代的重要发展阶段。其英文名称是：“Internet of things（IoT）”。顾名思义，物联网就是物物相连的互联网。这有两层意思：其一，物联网的核心和基础仍然是互联网，是在互联网基础上的延伸和扩展的网络；其二，其用户端延伸和扩展到了任何物品与物品之间，进行信息交换和通信，也就是物物相息。物联网通过智能感知、识别技术与普适计算等通信感知技术，广泛应用于网络的融合中，也因此被称为继计算机、互联网之后世界信息产业发展的第三次浪潮。 　　而在物联网的应用上，对于信息传输，MQTT是一种再合适不过的协议工具了。 回到顶部 一、MQTT简介 　　MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议），是一种基于发布/订阅（publish/subscribe）模式的轻量级协议，该协议构建于TCP/IP协议之上，MQTT最大优点在于，可以以极少的代码和有限的带宽，为连接远程设备提供实时可靠的消息服务。作为一种低开销

1. MQTT中的QoS等级 MQTT设计了一套保证消息稳定传输的机制，包括消息应答、存储和重传。在这套机制下，提供了三种不同层次QoS（Quality of Service）： QoS0，At most once，至多一次； QoS1，At least once，至少一次； QoS2，Exactly once，确保只有一次。 QoS 是消息的发送方（Sender）和接受方（Receiver）之间达成的一个协议： QoS0 代表，Sender 发送的一条消息，Receiver 最多能收到一次，也就是说 Sender 尽力向 Receiver 发送消息，如果发送失败，也就算了； QoS1 代表，Sender 发送的一条消息，Receiver 至少能收到一次，也就是说 Sender 向 Receiver 发送消息，如果发送失败，会继续重试，直到 Receiver 收到消息为止，但是因为重传的原因，Receiver 有可能会收到重复的消息； QoS2 代表，Sender 发送的一条消息，Receiver 确保能收到而且只收到一次，也就是说 Sender 尽力向 Receiver 发送消息，如果发送失败，会继续重试，直到 Receiver 收到消息为止，同时保证 Receiver 不会因为消息重传而收到重复的消息。 注意： QoS是Sender和Receiver之间的协议

1. Retained消息 Retained 消息是指在 PUBLISH 数据包中 Retain 标识设为 1 的消息，Broker 收到这样的 PUBLISH 包以后，将保存这个消息，当有一个新的订阅者订阅相应主题的时候，Broker 会马上将这个消息发送给订阅者。有以下这些特点： 一个Topic只能有一条Retained消息，发布新的Retained 消息将覆盖老的 Retained 消息（所以想删除一个 Retained 消息也很简单，只要向这个主题发布一个 Payload 长度为 0 的 Retained 消息就可以了）； 如果订阅者使用通配符订阅主题，它会收到所有匹配的主题上的 Retained 消息； 只有新的订阅者才会收到 Retained 消息，如果订阅者重复订阅一个主题，也会被当做新的订阅者，然后收到 Retained 消息； Broker 收到 Retained 消息后，会单独保存一份，再向当前的订阅者发送一份普通的消息（Retained 标识为 0）。当有新订阅者的时候， Broker 会把保存的这条消息发给新订阅者（Retained 标识为 1）。 Retained消息和持久性会话的区别： Retained消息是Broker为每一个Topic单独存储的； 持久性会话是Broker为每一个Client单独存储的 1.1. 代码实践

1. 长连接 　　互联网推送消息主要基于通信双方建立长连接，从而实现实时推送效果。普通的 socket连接对服务器的消耗太大，所以出现了类似MQTT这种轻量级、低消耗的协议来维护长连接。维护长连接需要采用心跳机制，客户端发送一个心跳数据包给服务器，服务器返回给客户端一个心跳应答，从而完成一次客户端-服务器握手，这个握手是让双方都知道他们之间的连接是没有断开的。如果超过一个时间阈值，客户端没有收到服务器的心跳应答，或者服务器没有收到客户端的心跳请求，那么表示通信双方连接已经不存在。对客户端来说，则断开与服务器的连接重新建立一个连接，对服务器来说只要断开这个连接即可。 2. MQTT通信过程 如上图所示，客户端 A连接到消息代理（message broker）,消息代理返回确认消息。客户B发布消息温度25度，客户A订阅‘温度’，消息代理吧消息推给客户A，客户A发布温度20度，但客户B没有订阅，消息代理不推送。消息B又发布了温度38度，客户A就再次收到订阅的消息38度，最后客户端断开连接。以上过程包含如下： 1 CONNECT – 连接服务端：客户端到服务端的网络连接建立后， 客户端发送给服务端的第一个报文必须是CONNECT报文 2 CONNACK – 确认连接请求：服务端发送CONNACK报文响应从客户端收到的CONNECT报文。 服务端发送给客户端的第一个报文必须是CONNACK

原文：https://www.cnblogs.com/smartlife/articles/10182136.html 常用命令 订阅主题 mosquitto_sub -h 192.168.0.1 -p 1883 -u root -P root -t topicname 推送消息 mosquitto_pub -h 192.168.0.1 -p 1883 -u root -P root -t topicname -m "发送的消息内容" mosquitto重启 1.1 查看mosquitto的进程 命令：ps -aux | grep mosquitto 1.2 杀掉进程# 命令：kill -9 18248 1.3 启动# 命令：mosquitto -c /etc/mosquitto/mosquitto.conf -d mosquitto 启动命令 启动命令# mosquitto [-c config file] [ -d | --daemon ] [-p port number] [-v] -c 后面跟的是启动mosquitto可以调整的参数，比如是否开启基本认证，端口是什么，SSL单向和双向的认证配置等等。 -d 表示MQTT mosquitto将在后台运行。 -p 代表当前的mosquitto服务实例启动以后，其监听端口号，这个配置的覆盖[-c config file]