简介面向VB.NET开发者的MQTT通信完整工程同时提供服务端与客户端实现适合智能家居、环境监测、工业自动化等物联网场景解决低带宽、高延迟网络下设备消息发布与订阅的问题。代码基于MqttNet开源库封装覆盖服务器监听、客户端连接、用户名密码认证、主题订阅、消息推送、断开资源清理等核心环节并附有可运行的VB源文件与演示程序。压缩包共541个文件、26.4MB包含189个dll依赖运行库、133个xml配置与文档、23个txt说明笔记、7个vb核心源码及sln工程、exe可执行文件、config、pdb调试符号等目录组织完整便于直接编译和二次修改。项目已吸引1813人学习参考可参照其客户端类与服务器示例快速将MQTT能力集成进VB.NET桌面应用或服务并基于Visual Studio调试环境验证发布订阅流程。适合刚开始接触MQTT协议或希望在.NET项目中落地物联网通信的开发者参考。 在维护一版基于 VB.NET 的车间设备数据看板时我遇到过最头疼的问题几十台工位控制器每两秒轮询一次接口数据库连接经常被打满网络稍有抖动页面数据就断崖。后来把 MQTT 引入系统用一块轻量级消息总线替代了大部分轮询整个架构立刻清爽了很多。这篇文章就整理一下用 VB.NET 做 MQTT 服务器、客户端时会踩到的坑以及一套可以直接拿来用的落地方案。无论你是要把现有 WinForm 改造为设备接入端还是想在本地搭一个测试用 MQTT broker这份经验都能省掉不少试错成本。1. MQTT 在 VB.NET 业务系统里的价值为什么我放弃轮询改用消息总线1.1 发布/订阅模型与设备接入场景MQTT 本质上是一个基于 TCP 长连接的发布/订阅消息协议核心角色有三个Broker、Publisher、Subscriber。Broker 是消息中转站负责管理连接、转发主题消息Publisher 往某个主题发消息Subscriber 订阅自己感兴趣的主题Broker 收到消息后按主题匹配推送给订阅者。这个模型最大的优点就是解耦发送方不需要知道哪些人接收接收方也不需要知道消息从哪来。放到 VB.NET 业务系统里典型场景是这样的车间有几十台 PLC、工控机或传感器网关它们不断产生温度、转速、开关状态等数据。传统做法是写一个定时器每两秒去挨个调设备的 HTTP 接口或者让设备把数据 POST 到 Web API。这种做法在设备数量少的时候还能撑住设备一多轮询线程、HTTP 握手、服务器数据库连接数都会成为瓶颈。用 MQTT 之后设备端负责发布数据VB.NET 服务端只订阅对应主题消息一来就处理。服务器不需要主动去问也就少了大量的无效请求。设备不在线时Broker 还可以通过遗嘱消息或断线事件感知到这在设备运维场景里非常实用。1.2 和 HTTP 轮询相比站在 VB.NET 工程师视角的实际收益我从实际项目里总结了几条最直观的收益实时性更高。轮询周期再短也有延迟而 MQTT 是消息到达后立刻推送秒级甚至毫秒级响应。网络开销小。MQTT 的消息头很小长连接复用不会像 HTTP 那样每次请求都要建立连接。服务端压力低。以前数据库要被轮询请求频繁打满现在数据是按事件写入整体负载降了一个量级。设备在线状态清晰。通过会话、心跳和遗嘱机制可以判断设备是否活着而不只是靠“超时没返回”来猜。当然MQTT 不是银弹它不适合浏览器直连、需要大型文件传输的场景也不适合对每条消息都要做复杂加密传输的业务。但在设备数据采集、通知推送、消息总线上它比 HTTP 轮询合适得多。1.3 先想清楚系统里需要“服务器”还是“客户端”很多新手拿到需求上来就问“VB.NET 怎么写 MQTT 服务器”其实大部分项目只需要写客户端。如果你的环境里已经有 Mosquitto、EMQX、HiveMQ 这类独立 Broker那 VB.NET 端只需要实现 MQTT 客户端负责订阅和发布。只有几种情况才需要考虑在 VB.NET 程序内嵌一个 MQTT 服务器现场无法安装额外服务程序要一键启动、开箱即用你是做桌面软件交付希望软件自带一个本地消息中枢供多个模块间通信内部测试需要临时起一个 Broker不想维护独立中间件。理解了这一点选型就会清晰很多。下面先讲依赖包的选择因为这一步错了后面全是折腾。2. NuGet 包二选一M2Mqtt 与 MQTTnet 的兼容性和坑2.1 M2Mqtt老牌但停更M2Mqtt 是 Eclipse Paho 的 .NET 移植版很多老项目里都能看到它的身影。接口是同步风格写起来比较直白但在 .NET 6/8 下容易出兼容性问题项目也基本不再更新。如果你维护的是一个历史遗留的 .NET Framework 4.5/4.6 WinForm 程序M2Mqtt 还能跑但我不建议在新项目里用。它最大的坑有两点一是异步支持弱事件回调和重连逻辑要自己造轮子二是 Broker 功能不完整官方没有提供服务端实现想内嵌服务器很难。2.2 MQTTnet新项目的首选MQTTnet 是目前 .NET 生态里维护最活跃的 MQTT 库之一同时支持客户端和服务端API 是异步风格而且对 .NET Framework 4.6.2、.NET Core、.NET 5 都有兼容。一个 NuGet 包就能把 VB.NET 里的 Client 和 Server 都写出来非常省事。我用的是 NuGet 命令行直接装Install-Package MQTTnet需要注意MQTTnet 从 3.x 到 4.x 接口变化蛮大。3.x 里的MqttServerOptionsBuilder、WithConnectionValidator这类写法到 4.x 可能被MqttServerOptions、ValidatingConnectionAsync事件替代。所以看网上旧示例时不要直接抄以你自己项目里引用的版本为准。这里放一张简单对比表方便你快速决策对比项M2MqttMQTTnet维护状态基本停更持续维护客户端支持支持支持服务端支持不支持内置支持异步编程弱强.NET 6/8 兼容费劲友好老 .NET Framework 项目可救急也能用看版本学习资料少社区多我个人现在的选择很明确除非老项目实在不能升级否则一律用 MQTTnet。它把一个库做完了客户端和服务端还支持 TLS、遗嘱消息、保留消息、QoS 等全套 MQTT 能力对 VB.NET 开发者来说是最省心的选择。3. VB.NET 下内置 MQTT 服务器从最小实现到业务可用3.1 最小 Broker 实现在 VB.NET 里创建一个内嵌 Broker 并不复杂。引用 MQTTnet 后主要代码就几行Imports MQTTnet Imports MQTTnet.Server Public Async Function StartBrokerAsync() As Task Dim mqttFactory As New MqttFactory() Dim server mqttFactory.CreateMqttServer() Dim options New MqttServerOptionsBuilder() .WithDefaultEndpoint() .WithDefaultEndpointPort(1883) .Build() AddHandler server.StartedAsync, Async Sub(args) Console.WriteLine(MQTT Broker 已启动端口 options.DefaultEndpointPort) End Sub Await server.StartAsync(options) End Function端口 1883 是 MQTT 的标准明文端口如果你要上 TLS 加密一般用 8883。这个最小实现已经能接收客户端连接支持多主题发布订阅。对于内网设备数据采集、模块间通信来说已经满足大部分需求。要提醒的是WinForm 里启动 Broker 一定要用异步调用不要在 UI 线程里StartAsync().Wait()否则界面会被阻塞连接多了还会卡死。3.2 鉴权与连接控制生产环境里不能裸奔。MQTTnet 通过ValidatingConnectionAsync事件对每个客户端连接做校验可以检查 UserName、Password、ClientId也可以限制客户端来源 IP。下面这段代码实现了最简单的用户名密码校验AddHandler server.ValidatingConnectionAsync, Async Sub(args) If args.UserName admin AndAlso args.Password 123456 Then args.ReasonCode MqttConnectReasonCode.Success Else args.ReasonCode MqttConnectReasonCode.BadUserNameOrPassword End If End Sub在实际项目里我还会顺手做一件事把args.ClientId记录下来放到一个ConcurrentDictionary里做在线统计。这样每个设备连接上来时程序就能实时知道哪个设备在线哪个设备掉线了。设备掉线配合遗嘱消息能快速触发告警。3.3 保留消息、遗嘱和 broker 级配置Broker 层面有两个重要特性一定要把握保留消息和遗嘱消息。保留消息Retain发布消息时把 Retain 标志位设为 TrueBroker 会保存这条主题的最后一条消息。新客户端订阅该主题时不用等设备再次上报立刻就能收到最新值。这个机制非常适合设备配置、系统状态这类需要“最后值”的场景。遗嘱消息Will客户端在连接时指定一个遗嘱主题和遗嘱内容。如果客户端异常断开Broker 会替它向遗嘱主题发布这条消息。比如一台设备连上来时把遗嘱设为devices/d0001/status内容为offline一旦设备断电或断网其他订阅者马上就能收到下线通知。在 MQTTnet 客户端里遗嘱消息是在构建连接选项时配置的后面客户端章节我会给出代码。4. 客户端实战订阅、发布、QoS 与典型回调问题4.1 客户端连接与主题订阅VB.NET 客户端连接到 Broker 的代码也非常简洁Imports MQTTnet Imports MQTTnet.Client Public Shared mqttClient As IMqttClient Public Async Function ConnectClientAsync() As Task Dim mqttFactory As New MqttFactory() mqttClient mqttFactory.CreateMqttClient() Dim options New MqttClientOptionsBuilder() .WithTcpServer(127.0.0.1, 1883) .WithClientId(vb-dashboard) .WithCredentials(admin, 123456) .WithCleanSession(True) .Build() Dim result Await mqttClient.ConnectAsync(options, CancellationToken.None) If result.ResultCode MqttClientConnectResultCode.Success Then Console.WriteLine(连接成功) Else Console.WriteLine(连接失败 result.ResultCode.ToString()) End If End Function连接之后要订阅主题MQTT 的主题支持通配符匹配单级#匹配多级。比如我想订阅所有设备的状态消息可以这样写Await mqttClient.SubscribeAsync( New MqttTopicFilterBuilder() .WithTopic(devices//status) .WithQualityOfServiceLevel(MqttQualityOfServiceLevel.AtLeastOnce) .Build() )这样devices/d0001/status、devices/d0002/status都能收到而不用逐个订阅每个设备。4.2 发布与 QoS 语义发布一条消息同样简单Dim payload Encoding.UTF8.GetBytes({speed:120,temp:36.5}) Await mqttClient.PublishAsync(New MqttApplicationMessageBuilder() .WithTopic(devices/d0001/realdata) .WithPayload(payload) .WithQualityOfServiceLevel(MqttQualityOfServiceLevel.AtLeastOnce) .WithRetainFlag(False) .Build() )QoS 是 MQTT 里最容易被人忽略的点。它有三级QoS 0最多一次消息可能丢失适合高频传感器数据丢了下一帧补上QoS 1至少一次保证消息到达但可能重复适合状态通知QoS 2只一次最严格但性能开销最大适合计费、订单这类不允许重复的业务。我见过不少项目不管三七二十一全部用 QoS 2结果 Broker 负载高得离谱。这里建议先用 QoS 1只有业务上明确不允许重复时才用 QoS 2。4.3 不要在回调线程里干重活MQTTnet 收到订阅消息后会触发ApplicationMessageReceivedAsync事件。很多新手会直接把数据库写入、发邮件、调第三方接口全塞到回调里这是大忌。收到消息的回调跑在线程池线程上如果你在里面做耗时操作下一个消息只能排队消息积压会越来越严重最后看起来像“卡死了”。正确的做法是把消息转交给独立的消息处理队列比如用Channel或ConcurrentQueue由后台消费线程统一处理。我在项目里的做法是AddHandler mqttClient.ApplicationMessageReceivedAsync, Async Sub(args) Dim topic args.ApplicationMessage.Topic Dim payload Encoding.UTF8.GetString(args.ApplicationMessage.Payload) MessageQueue.Enqueue(New DeviceMessage(topic, payload)) End Sub这样回调只做接收和入队几百毫秒就能返回真正的业务处理在队列消费线程里慢慢做。实测下来消息吞吐和系统稳定性都有明显提升。5. 工程化避坑断线重连、证书、防火墙与现场排查5.1 断线重连与避免重连风暴现场网络不可能永远稳定客户端断开后必须自动重连。MQTTnet 里可以通过DisconnectedAsync事件实现AddHandler mqttClient.DisconnectedAsync, Async Sub(args) Console.WriteLine(连接断开2秒后尝试重连...) Await Task.Delay(2000) If Not mqttClient.IsConnected Then Try Await mqttClient.ConnectAsync(ClientOptions, CancellationToken.None) Catch ex As Exception Console.WriteLine(重连失败 ex.Message) End Try End If End Sub有个细节重连失败后不能立刻再重连否则大量客户端同时涌入会造成“重连风暴”。正确做法是使用指数退避比如第一次等 2 秒失败后等 4 秒、8 秒、16 秒最多不超过 60 秒。5.2 端口、防火墙和 Windows 服务化部署如果 Broker 部署在服务器上客户机连不上第一件事不是查代码而是查防火墙。1883 端口需要放行如果用 TLS 还要放行 8883。在 Windows Server 上可以用 PowerShell 开端口New-NetFirewallRule -DisplayName MQTT 1883 -Direction Inbound -Protocol TCP -LocalPort 1883 -Action Allow如果 Broker 是写在一个 WinForm 程序里很多人会直接挂个窗体跑在服务器上这是很不专业的做法。建议把 Broker 封装成 Windows 服务用Topshelf或Worker Service托管开机自启、崩溃自动拉起都方便。5.3 MQTT 工具箱与排查清单调试 MQTT 时我习惯准备两个工具命令行里有mosquitto_sub和mosquitto_pub图形化界面用 MQTTX。遇到“客户端连不上 Broker”时从下往上排查先看 Broker 日志确认有没有收到 TCP 连接用mosquitto_sub -h 服务器IP -p 1883 -t # -v测试是否能订阅全部消息再看端口telnet 服务器IP 1883能通说明网络没问题最后才是鉴权问题确认用户名密码、ClientId 是否被占用。遇到“订阅不到消息”时90% 是主题写错或通配符用错。订阅devices/#能收到devices/d0001/status但订阅devices/只能收到devices/d0001/status这种单级主题收不到devices/d0001/child/status。还有一个我自己踩过的坑客户端连接后用CleanSessionTrue意味着重连后服务端不会保留之前的会话这时候如果只靠订阅关系恢复前的消息就会丢失。对于需要持久订阅的业务可以把CleanSession设为 False并配置持久会话。整套方案在我维护的看板系统里已经稳定运行了两年多设备在线状态实时刷新数据上报不再靠轮询内嵌 Broker 的功能也让现场部署变得异常简单。最后再分享一条实操习惯任何 MQTT 改动上线前先用 MQTTX 模拟设备端发布和订阅把主题、QoS、保留标志全部验一遍再回到 VB.NET 程序里联调。这套流程看起来多花十几分钟但能帮你省下大半夜的故障排查时间。本文还有配套的精品资源点击获取
