pycopy-umqtt.simple 1.3.5

设计要求

• 内存效率。
• 避免臭名昭著的设计反模式，如“回调地狱”。
• 通过单个客户端支持发布和订阅 对象（另一种选择是有单独的客户机类 用于发布和订阅）。

API设计

基于上述要求，API有以下特点：

• 与mqtt消息相关的所有数据都被编码为字节。这包括 消息内容和主题名称（即使mqtt规范声明 这个主题名是utf-8编码的）。原因很简单： 通过网络套接字接收的是二进制数据（字节）和 要把它转换成字符串需要额外的步骤 关于那个的记忆。注意，这只适用于主题名（因为 它们既可以发送也可以接收）。由指定的其他参数 作为utf-8编码的mqtt（例如clientid）被接受为字符串。
• 订阅的消息通过回调传递。这是为了避免 对订阅的消息使用队列，否则它们可能是 随时收到（包括客户要求其他类型 对于服务器响应，有两种选择：要么交付它们 立即通过回调或排队直到“预期”响应 到达）。请注意，不需要排队是一种错觉： 在这种情况下，运行时调用堆栈形成一个隐式队列。而且不像 显式队列，很难控制。这个设计是被选中的 因为在处理订阅消息的常见情况下 最有效率的。但是，如果在订阅回调中， 已发布QoS为“0”的消息，这可能导致深度，或 无限递归（后者意味着应用程序将终止 使用RuntimeException）。

API参考

考虑到上述api特性，umqtt非常接近 遵循MQTT控制操作，并将它们映射到类方法：

• connect(...)-连接到服务器。如果此连接返回true 使用存储在服务器上的持久会话（如果 使用clean_session=true参数（默认）。
• disconnect()-断开与服务器的连接，释放资源。
• ping()-ping服务器（响应由wait_msg（）自动处理）。
• publish()-发布消息。
• subscribe()-订阅主题。
• set_callback()-为收到的订阅消息设置回调。
• set_last_will()-设置mqtt“last will”消息。应该叫 在connect（）之前。
• wait_msg()-等待服务器消息。订阅消息将是 通过set_callback（）传递到回调集，任何其他消息 将在内部处理。
• check_msg()-检查是否有来自服务器的挂起邮件。如果是， 处理方法与wait_msg（）相同，如果不是，则立即返回。

wait_msg()和check_msg()是“主循环迭代”方法，阻塞 以及非阻塞版本。它们应该周期性地循环调用， wait_msg()如果没有其他前台任务要执行 （即，您的应用程序只对订阅的mqtt消息作出反应），check_msg() 如果你也处理其他前台任务。

注意，如果您只需要调用wait_msg()/check_msg()，则不需要调用wait_msg()。 发布消息，不要订阅它们。

有关api的更多详细信息，请参见源代码 （很短，很容易复习）并提供了一些例子。

支持的MQTT功能

发布和订阅都支持QoS 0和1。QOS2不是 支持保持代码小。除了客户，只有“干净的 从现在起，connect支持session参数。

自动重新连接的MQTT客户机

有一个单独的umqtt.robust模块，它构建在umqtt.simple 并添加自动重新连接支持以防网络错误。 详情请参阅其文件。