首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

是否需要为只发布的MQTT客户端设置cleanSession参数(持久会话)?

对于MQTT客户端,是否需要为其设置cleanSession参数(持久会话)取决于具体的应用场景和需求。

cleanSession参数是MQTT协议中的一个可选参数,用于控制客户端与服务器之间的会话状态。当cleanSession参数设置为true时,表示客户端请求一个新的、非持久的会话,服务器会删除之前的会话信息。当cleanSession参数设置为false时,表示客户端请求一个持久会话,服务器会保留之前的会话信息。

在以下情况下,建议为MQTT客户端设置cleanSession参数为true:

  1. 临时性数据传输:如果你的应用只需要临时传输一些数据,而不需要保留会话状态,可以设置cleanSession为true。这样可以减少服务器的负担,避免存储过多的会话信息。
  2. 客户端不需要接收离线消息:如果客户端不需要接收离线消息,即只关心实时数据,可以设置cleanSession为true。这样可以减少网络传输的数据量,提高传输效率。
  3. 客户端不需要保留订阅信息:如果客户端不需要保留之前的订阅信息,即不需要自动重新订阅之前的主题,可以设置cleanSession为true。这样可以简化客户端的逻辑处理。

在以下情况下,建议为MQTT客户端设置cleanSession参数为false:

  1. 持久性数据传输:如果你的应用需要持久地传输数据,并且需要保留会话状态,可以设置cleanSession为false。这样可以确保客户端重新连接时能够恢复之前的会话信息。
  2. 客户端需要接收离线消息:如果客户端需要接收离线消息,即需要获取客户端在离线期间发布的消息,可以设置cleanSession为false。这样可以确保客户端能够获取到所有的消息。
  3. 客户端需要保留订阅信息:如果客户端需要保留之前的订阅信息,并且自动重新订阅之前的主题,可以设置cleanSession为false。这样可以确保客户端重新连接时能够恢复之前的订阅状态。

需要注意的是,设置cleanSession参数为false可能会增加服务器的负担和网络传输的数据量,因此在设计应用时需要权衡利弊。

腾讯云提供了MQTT相关的产品和服务,例如物联网通信(IoT Hub)和消息队列 MQTT 版(CMQ for MQTT)。您可以通过以下链接了解更多信息:

  1. 物联网通信(IoT Hub):https://cloud.tencent.com/product/iothub
  2. 消息队列 MQTT 版(CMQ for MQTT):https://cloud.tencent.com/product/cmq_mqtt
页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

MQTT协议通俗讲解

基本概念 Basic Conception Session 会话 定义 定义:某个客户端(由ClientID作为标识)和某个服务器之间的逻辑层面的通信 生命周期(存在时间):会话 >= 网络连接 ClientID 客户端唯一标识,服务端用于关联一个Session 只能包含这些 大写字母,小写字母 和 数字(0-9a-zA-Z),23个字符以内 如果 ClientID 在多次 TCP连接中保持一致,客户端和服务器端会保留会话信息(Session) 同一时间内 Server 和同一个 ClientID 只能保持一个 TCP 连接,再次连接会踢掉前一个 CleanSession 标记 在Connect时,由客户端设置 0 —— 开启会话重用机制。网络断开重连后,恢复之前的Session信息。需要客户端和服务器有相关Session持久化机制。 1 —— 关闭会话重用机制。每次Connect都是一个新Session,会话仅持续和网络连接同样长的时间。 客户端 Session 已经发送给服务端,但是还没有完成确认的 QoS 1 和 QoS 2 级别的消息 已从服务端接收,但是还没有完成确认的 QoS 2 级别的消息 服务器端 Session 会话是否存在,即使会话状态的其它部分都是空 (SessionFlag) 客户端的订阅信息 (ClientSubcription) 已经发送给客户端,但是还没有完成确认的 QoS 1 和 QoS 2 级别的消息 即将传输给客户端的 QoS 1 和 QoS 2 级别的消息 已从客户端接收,但是还没有完成确认的 QoS 2 级别的消息 (可选)准备发送给客户端的 QoS 0 级别的消息 长连接维护与管理 Keep Alive 心跳 目的是保持长连接的可靠性,以及双方对彼此是否在线的确认。 客户端在Connect的时候设置 Keep Alive 时长。如果服务端在 1.5 * KeepAlive 时间内没有收到客户端的报文,它必须断开客户端的网络连接 Keep Alive 的值由具体应用指定,一般是几分钟。允许的最大值是 18 小时 12 分 15 秒 Will 遗嘱 遗嘱消息(Will Message)存储在服务端,当网络连接关闭时,服务端必须发布这个遗嘱消息,所以被形象地称之为遗嘱,可用于通知异常断线。 客户端发送 DISCONNECT 关闭链接,遗嘱失效并删除 遗嘱消息发布的条件,包括: 服务端检测到了一个 I/O 错误或者网络故障 客户端在保持连接(Keep Alive)的时间内未能通讯 客户端没有先发送 DISCONNECT 报文直接关闭了网络连接 由于协议错误服务端关闭了网络连接 相关设置项,需要在Connect时,由客户端指定 Will Flag —— 遗嘱的总开关 0 -- 关闭遗嘱功能,Will QoS 和 Will Retain 必须为 0 1 -- 开启遗嘱功能,需要设置 Will Retain 和 Will QoS Will QoS —— 遗嘱消息 QoS 可取值 0、1、2,含义与消息QoS相同 Will Retain —— 遗嘱是否保留 0 -- 遗嘱消息不保留,后面再订阅不会收到消息 1 -- 遗嘱消息保留,持久存储 Will Topic —— 遗嘱话题 Will Payload —— 遗嘱消息内容 消息基本概念 报文标识 Packet Identifier 存在报文的可变报头部分,非零两个字节整数 (0-65535] 一个流程中重复:这些报文包含 PacketID,而且在一次通信流程内保持一致: PUBLISH(QoS>0 时),PUBACK,PUBREC,PUBREL,PUBCOMP SUBSCRIBE, SUBACK UNSUBSCIBE,UNSUBACK 新的不重复:客户端每次发送一个新的这些类型的报文时都必须分配一个当前 未使用的PacketID 当客户端处理完这个报文对应的确认后,这个报文标识符就释放可重用。 独立维护:客户端和服务端彼此独立地分配报文标识符。因此,客户端服务端组合使用相同的报文标识符可以实

01

ACP互联网架构认证笔记-MQ消息队列服务

MQ是消息服务中间件,基于高可用分布式集群技术,是消费模式基于发布订阅模式的消息系统。支持Java,C++以及.NET,PHP,Python,为分布式应用系统提供异步解耦、削峰填谷的能力,具备海量消息堆积、高吞吐、可靠重试等特性。具有消息查询,消息回溯(不是消息撤回,也不支持消息撤回),消息轨迹查询,堆积监控报警功能。 MQ协议支持接入方式 : TCP、HTTP(RESTful 风格)、MQTT。MQ支持公网访问,但可用性较低。 MQ应用场景 : 分布式事务,物联网应用,实时计算(将产生的数据实时流入到实时计算引擎来实现),同步大规模缓存。 实时计算引擎一般有 : Spark / Storm / EMR / ARMS / BeamRunner。 MQ拥有管理工具 : Web控制台,Open API,mqadmin命令集。拥有微消息队列(LMQ),RocketMQ消息队列,Kafka消息队列,跨域中继服务(CRS)等组件。 Web控制台提供消息查询、消息轨迹查询、重置消费位点、资源统计、监控报警等操作。消息查询有三种方式 :** 根据Message ID(精确查询),Message Key(模糊查询)以及Topic查询(范围查询),HTTP消息目前只支持Message ID和Topic两种查询方式。** 消息轨迹查询只支持TCP和HTTP协议,可追踪消息从生产者发出到消费者消费的整个链路中各个相关节点的时间地点。 重置消费位点可跳过堆积的消息,即不想消费这部分消息,或者只想消费某个时间点后的消息(这些消息不论之前是否消费过)。 资源报表可对消息发送和消息消费的数据进行统计,暂不支持HTTP消费数据的统计查询。 监控报警一般用在消息堆积数或者延迟时间超过阈值之后,对报警接收人发送短信,如果发现消息堆积很多,可检查阈值是否设置过小导致消息堆积,可调整业务代码或者对消费者进行扩容,可使用jstack查看是否消费线程阻塞。 微消息队列(LMQ)基于MQTT(Message Queuing Telemetry Transport 消息队列遥测传输)协议,标准协议端口为1883,支持加密SSL,WebSocket,Flash接入方式。协议重要部分主要分为 : MQ Core Service(负责底层的消息存储和分发),MQ私有协议服务器以及MQTT协议网关服务器(负责对客户端提供服务和协议转换)。主要使用场景有 : 直播互动、车联网、金融支付、即时聊天等。协议相关 : QoS(Quality of Service)指代消息传输的服务质量。它包括QoS0(最多分发一次)、QoS1(至少达到一次)和QoS2(仅分发一次)三种级别。cleanSession标识客户端建立TCP连接后是否关心之前状态(true or false)。 MQTT可进行实例管理(查看消息收发TPS、同时在线连接数、订阅关系数等信息,可设置实例报警),可申请MQTT Topic,可为Topic申请MQTT Group ID(一组逻辑功能完全一致的节点共用的组名,代表一类相同功能的设备,必须拥有Topic的读写权限)。可进行签名计算和签名生成。 MQTT可获取离线消息,可主动拉取离线消息,客户端每次拉取消息数量最多为30条,拉取请求的最大频率限制为5次/秒。离线消息优先级低,对其进行有限和最终能处理即可,要求比较实时。 MQTT可获取客户端上下线事件(上下线事件触发时,会向后端MQ推送一条上下线消息,通过订阅这条消息获取),上下线事件类型一般放在MQ的Tag中,有三种状态 : connect(客户端上线),disconnect(客户端主动断开连接),tcpclean(实际的TCP连接断开)。tcpclean代表客户端网络层连接的真实断开,判断客户端下线请使用tcpclean事件。 MQTT通过Token鉴权服务向客户端提供访问权限。客户端需要采用MQTT控制报文以同步发送模式并且QoS必须为1,来上传Token。客户端应该对Token做好持久化,监听Proxy下推的Token失效的通知消息,Token失效必须重新申请。 LMQ的Topic,ClientId长度最大为64个字符,消息大小最大为64K,消息保存时间最长为3天,单个客户端订阅Topic数量最大为30个(超过该限制数量的Topic会被丢弃),消息顺序性为上行顺序。 跨域中继服务(CRS,跨域哦,实现服务发布与订阅,实现不同网络的服务互通)提供三种MQ消息发送方式 :可靠同步发送(发出消息响应后才能发下一个消息,应用场景广,如重要通知邮件、报名短信通知、营销短信系统),可靠异步发送(不需要等待响应即可发下一个消息,应用场景一般是耗时长,对RT响应敏感的业务,如视频上传后通知转码服务,转码后通知推送转码结果),One Way(单向发送,不需要响应的方式,耗时超短,对可靠性要求不高的场

03

基于MQTTnet 3.0.12实现MQTT服务器和客户端「建议收藏」

现在物联网的概念很火,辣条从业7年来一直号称是“自动化工程师”,但其实到目前为止,所处的行业还是比较局限在自动化产线改造。就工业智能互联来说,水平方向上如何把流水线式的孤岛式机台联动起来,我们比较有经验,但是垂直方向上,如何做数采,或者说如何高效灵活的做数采,需要补课的东西还有很多。MQTT是IBM很早以前就提出来的协议,但很可惜一直没有接触过,新公司的项目上引用了MQTTnet的开源库,但是这个GitHub作者跳版跳得太狠了点,随着新版本的更新,改了很多旧版的东西,导致百度排在前几的文章都没法直接借鉴了,无奈之下,疯狂百度+阅读Git上源码,总算搞出来一个小的Demo,特此记录如下。

02

云端协议MQTT介绍

一、简述 MQTT(Message Queuing Telemetry Transport,消息队列遥测传输协议),是一种基于发布/订阅(publish/subscribe)模式的"轻量级"通讯协议,该协议构建于TCP/IP协议上,由IBM在1999年发布。MQTT最大优点在于,可以以极少的代码和有限的带宽,为连接远程设备提供实时可靠的消息服务。作为一种低开销、低带宽占用的即时通讯协议,使其在物联网、小型设备、移动应用等方面有较广泛的应用。 MQTT是一个基于客户端-服务器的消息发布/订阅传输协议。MQTT协议是轻量、简单、开放和易于实现的,这些特点使它适用范围非常广泛。在很多情况下,包括受限的环境中,如:机器与机器(M2M)通信和物联网(IoT)。其在,通过卫星链路通信传感器、偶尔拨号的医疗设备、智能家居、及一些小型化设备中已广泛使用。

03
领券