4 MQTT-SN架构

MQTT-SN的架构如图1所示。有3种类型的MQTT-SN组件：MQTT-SN客户端、MQTT-SN网关、MQTT-SN转发器。MQTT-SN客户端使用MQTT-SN协议连接到MQTT-SN网关，再连接到MQTT服务端。MQTT-SN网关可以集成到MQTT服务端里。如果是做为独立的网关，则MQTT服务端和MQTT-SN网关间将采用MQTT协议，它的主要功能就是MQTT和MQTT-SN之间的转换。
当客户端所在的网络无法直接连接到网关时，客户端也可以通过转发器来存取网关。转发器将它在无线网络侧所接收到的MQTT-SN侦进行简单封包，然后原封不动地发送给网关；相反的，它将从网关侧接收到的侦解封，然后同样原封不动地发送到客户端。
基于网关在MQTT和MQTT-SN间转发所起的作用，我们可以区分出2种类型的网关：透明网关和集聚网关。

对于每个连接的MQTT-SN客户端，透明网关将会和MQTT服务端建立并维护一个MQTT连接。该MQTT连接将会单独为端到端通信保留，而且对于客户端和服务端间的消息交换是透明的。有多少MQTT-SN客户端连接到网关，在网关和服务端之间就有多少MQTT连接。透明网关在两协议间将扮演语法翻译器的角色。因为MQTT-SN客户端和MQTT服务端间的所有消息交换是端到端的，所以服务端可以向客户端提供其实现的所有功能和特性。
虽然和集聚网关比起来，透明网关的实现比较简单，但是它要求服务端支持为每个活动的客户端保持一个单独的连接。一些MQTT服务端实现可能在能支持的并发连接数上有所限制。

不同于每个连接的客户端都有一个MQTT连接，集聚网关将只有一个到服务端的MQTT连接。MQTT-SN客户端到集聚网关的所有信息交换将只到网关。由网关决定哪些信息将进一步传递到服务端。虽然集聚网关的实现比透明网关更复杂，但它在拥有大量传感器的无线传感网络中是非常有用的，因为它减少了服务端必须并发支持的MQTT连接数。

用8226制作遥控灯在微信小程序里运行的步骤：
1、本程MQTT服务端使用阿里云物联网IOT平台的MQTT服务器。
2、准备就绪后，注册开发微信小程序如图，重点放在indexjs和indexwxml。
3、开发连接测试Nodemcu-Esp8266,主要有2步 *** 作，设置连接WIFI,初始化MQTT客户端。
4、发布小程序颁发，手机端测试是否可以正常发送消息到设备。

MQTT不存在上传和下发的定义，只有以topic为单位的推送和订阅。你的情况描述是服务器能看到推送的消息，说明网络、broker配置没有问题，要保证“服务器下发给客户端”能顺利实现的话请确认以下几点：

服务器端推送到的topic和客户端订阅的topic是一致的

本地设备开启了1883端口（或者你自定义的端口号），防火墙没有拦截

如果是自己写代码的话，客户端的on message回调函数里解析报文的逻辑是正确

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是轻量级基于代理的发布/订阅的消息传输协议，设计思想是开放、简单、轻量、易于实现。这些特点使它适用于受限环境。例如：
①网络代价昂贵，带宽低、不可靠。
②在嵌入设备中运行，处理器和内存资源有限。
该协议的特点有：
①使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。
②对负载内容屏蔽的消息传输。
③使用 TCP/IP 提供网络连接。
④有三种消息发布服务质量：
⑤"至多一次"，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。
⑥"至少一次"，确保消息到达，但消息重复可能会发生。
⑦"只有一次"，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。
⑧小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量。
⑨使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制。
WebSocket则提供使用一个TCP连接进行双向通讯的机制，包括网络协议和API，以取代网页和服务器采用>

简单回答一下,MQTT(MQTelemetryTransport)是针对物联网而设计的,如手机对家里的智能开关,而WebSocket是针对浏览器与服务器之间而设计的两者基本上是两个世界的东西

MQTT只是一个接口,让两个"物件"能够透过TCP协议通讯,但并没有规定(在应用层面上)通讯中要怎样"对答",如pop3邮件伺服器会有:

S:220我是xxx服务器

C:HELOmyServer

S:250Nicetomeetyou

C:authlogin

这些是没有硬性被定义的,两个"物件"之间要怎_"聊天",由你自己来定

WebSocket则是一个>

以上,只是很概念的说法,便於你理解,详细你得自己翻下文献了

首先需要搭建MQTT服务器，然后搭建MySQL数据库，然后使用海为组态写段程序，最后配置客户端验证即可。具体可以参考内容 Haiwell（海为）HMI/CBOX/IPC MQTT 配置应用教程 网页链接

1Unicode是什么Unicode（中文：万国码、国际码、统一码、单一码）是计算机科学领域里的一项业界标准。它对世界上大部分的文字系统进行了整理、编码，使得电脑可以用更为简单的方式来呈现和处理文字。简单说来，就是把世界上所有语言的字，加上所有能找到的符号（如高音谱号、麻将、emoji）用同一套编码表示出来。2UTF-8是什么UTF-8（8-bitUnicodeTransformationFormat）是一种针对Unicode的可变长度字符编码。可变长度的意思在于，如果能使用1字节编码，UTF-8绝对不会使用2字节去表示。举个例子，UTF-8的1字节部分和ASCII码是相同的。所以表示'A'这个字符的时候，UTF-8与ASCII码不仅编码相同，而且都是只使用1字节。3CharacterSet和Collation是什么CharacterSet是一套符号以及编码。Collation是characterset的排序方法。在中文版的MySQL中，characterset被翻译为“字符集”，collation被翻译为“整理”。举个例子，UTF-8是characterset，utf8_unicode_ci和utf8mb4_unicode_ci就是collation。Collation的作用主要有二：字符排序与查找字符。字符排序的作用是显而易见的，不过还是要用几个例子加以说明。比如要比较a和b的大小，因为在26个英文字母里面，a在b前，所以在编码的时候，也把a放在b前面。这样就产生了第一种排序方式，通过字符编码的大小来排序。而在中文里面，“年”和“日”的排序，除了按照字符编码大小，还可以有另外一些标准。比如可以按照笔画序，“年”的第一笔是丿，“日”的第一笔是丨，而丨是排在丿前的，所以就将“日”排在前面；也可以按拼音序，“年”是n开头，“日”是r开头，于是把“年”排在前面。除此以外，还可以定义部首序、笔画数序等等，而不同的排序方法会有不同的结果。英文也有大小写敏感与不敏感的排序方式。种种不同的排序方式，就形成了不同的collations。Collation的第二个作用则是查找字符是否在一个字符集里面。既然是一个有序的集合，则可以快速地通过一个编码值确定一个字符是否在集合内。这个特性是我们在不知不觉中使用的。比如使用中文输入法，就是通过输入法找到一个编码，通过collation把它查找出来的。4Unicode再深入：Plane和中日韩越统一表意文字utf8_unicode_ci和utf8mb4_unicode_ci这两个collations都是基于UTF-8编码的，但排序方面或多或少会有差别。可是更大的差别是它查找字符的集合。这需要提到一个Unicode的概念：Plane。41PlanePlane中文译作“Unicode平面字符映射”，不过我们还是叫它plane好啦。目前的Unicode字符分为17个planes，而每个plane拥有65536（即2^16）个代码点。可以认为一个plane就是一个范围的编码。Plane0也叫做BMP（BasicMultilingualPlane，基本多文种平面），存放着世界上各种语言与标记中最常用的字符。Plane1也叫做SMP（SupplementaryMultilingualPlane，多文种补充平面），放着表情符号（emoji）、字母与数学符号、音乐符号、太玄经（太极符号）、装饰符号、扑克牌、麻将符号、箭头扩展和一些世界上各种语言不太常用的文字等等。Plane2也叫做SIP（SupplementaryIdeographicPlane，表意文字补充平面），用于存放统一汉字（见42）的一些罕用字与汉藏语系其他语言的用字（如粤语用字）。42统一汉字的分布对于统一汉字（中日韩越统一表意文字，CJKVUnifiedIdeographs）来说，BMP存放着最初的版本（也是最常用字）与扩展A区的汉字。扩展B区到即将到来的扩展E区都放在SIP中。在这些区中，除了独立字源的字，还有同一个字源或部首不同的变体或写法。比如“户”的第一笔，中国大陆与香港写作“户”，台湾写作“户”，日本则写作“戸”。这些差异也会在Unicode中用三个不同的编码去表示。所以B区到E区有不少此种字体。举些B区的例子。网络上之前流行的“不会功夫不要艹我”被写成““xx巭嫑莪”，其中“xx”这个字就是在B区。而粤语“x鸡”（阉鸡）、“x完松”（和一个人发生关系后弃之而去）两个词的首字也是在B区。5utf8_unicode_ci和utf8mb4_unicode_ci的异同这两种collations所对应的字符都是UTF-8编码的一个子集。utf8_unicode_ci最多能找到3个字节的Unicode编码，而utf8mb4_unicode_ci则能找到4个字节的编码。由于调整后的UTF-8编码格式规定最多使用4字节（原来是6字节）编码，所以utf8mb4系列可以说是覆盖了整个Unicode编码。由于utf8_unicode_ci最多能找到3个字节的编码，意味着它只支持BMP中的字符，对于SMP与SIP以及其他头一字节不为0x00、需要4字节编码的planes来说，utf8_unicode_ci这种collation是无法支持。当使用4字节的字符（如emoji与B区以后的统一汉字）对使用此种collation的字段进行增删查改时，数据库会报一个非法字符的异常。而utf8mb4则没有此问题。由此也看出，utf8mb4_unicode_ci是utf8_unicode_ci的超集。6utf8mb4_unicode_ci的优缺点utf8mb4系列的Collation在MySQL55以上开始支持。相比起utf8_unicode_ci，它有如下的特性：1)在数据表中，对于BMP中的字符（最多使用3字节的字符，最常用的字符），两种collations具有完全相同的存储特性：相同的码值，相同的编码方式，相同的存储长度。不会增加任何的存储开销。2)在数据表中，对于其他plains的字符，utf8系列的collation根本不能存储，而utf8mb4系列的collations则可以存储。3)在数据表中，对于变长的字段（如VARCHAR2，TEXT），utf8mb4最大可存储的字符可能少于utf8系列的collation。4)在索引中，对于文本类型的字段，utf8mb4可索引的字符少于utf8系列的collations。如InnoDB的索引最多使用767字节。如果使用utf8mb4，每一个字符都会预留4字节做索引，而utf8则预留3字节。故此前者是191个字符，后者是255个字符。5)由于4)的原因，加上字符集大，utf8mb4的性能可能比utf8系列的collations低。6)若升级前的字段做了索引，需要把索引字符限制在191字符或以内。7当前系统用哪个好在当前的系统，全部都使用utf8_unicode_ci这种collation。但是在存储网页标题时，标题带有SMP或者SIP的字符，如emoji、粤语字，会引发数据库写入异常。于是，就有两种解决方向：1)扔掉。11)扔掉或截断引发异常的字。采取此种方法，需要对每一个标题进行扫描。12)扔掉整条记录。可以采取扫描法，或者扔掉引发异常的记录。2)升级到utf8mb4。会略为降低数据库性能。71性能考虑首先对于写入性能，查找字体的性能损耗由于在写入前字符都已经变成编码，基本可以忽略。对于网络传输的性能，则需要继续查找相关资料继续查证。但初步估计由于目前数据库在本地，故此这部分开销的增长不太明显。而对于索引的性能，由于网页标题这一字段没有做索引，在可预见的将来也未有此计划，故此没有性能的损耗，也没有升级兼容性的担心。况且，倘若走扔掉数据的方向，若采取扫描法，则需要付出扫描的开销。若采取扔掉记录法，则会先触发事务回滚，其他记录需要下次重新写入。而且当一批记录写入时有k个记录引发异常，则需要回滚与重试k次，除非使用扫描法预先扫描出这些异常的记录。但这也会引入额外的程序与数据库开销。若不使用事务，则数据库总体写入性能会大为降低。虽然没有实测过，但从感觉上来定性判断，似乎扔掉记录比升级collation带来的性能退化要大。72存储空间考虑当前的网页标题是使用VARCHAR2存储。对于现在可用的、常见的BMP字符，不会引入额外的存储开销。BMP字符在VARCHAR的类型下不会为每一字符引入额外33%的空间开销。反之，定长的CHAR就会引入这种额外开销。73目标数据考虑网页标题作为以后特征分析的数据源。在分析需求完全没有确定的情况下，我认为扔掉任何数据都是不宜采取的法，特别是整条记录扔掉更是不推荐。因为现阶段我们没有一套标准去判定何为有效数据、何为无效数据。有可能引发异常的那部分数据确实是没用的数据，也有可能那部分人群更倾向于在我们平台上活跃使用。既然各种可能性都存在，我们主动放弃一部分可能性，似乎不太恰当。74API设计与兼容性考虑由于utf8_unicode_ci与utf8mb4_unicode_ci都是使用UTF-8编码，所以对于JAVA，使用MyBatis生成的代码是一样的，都是使用String类型。这点已经实测过。加上这两种collations在BMP中的编码完全一致，所以使用3字节与4字节的系统，对于BMP中的字符都是完全兼容、正常显示的。而对于3字节的系统，4字节的字符一般会显示成一个方框，或者在一个方框中有几个小数字，不会引发系统异常。8总结诚然，emoji对分词分析目前来说还没有什么效果，粤语词而且在SIP中也只是其中一部分，也不知道有多少日本动漫或者爱情动作片的网页会遇到这些生僻字，音乐符号也少人用，太极符号也不是每次都出现，一些数学增补的字符与箭头增补图案也不是每个人都会用。这些加起来可能不知够不够全部的千分之一。但是倘若每一两个小时就会由于字符不能写入，引发数据库的异常。通过上面的分析，我认为增加这种兼容性带来的成本是可以接受的。故此，我建议使用升级的方法，兼容所有Unicode字符。

---