写 Broker 最容易一上来就盯着PUBLISH。但实际测试时第一关通常不是消息转发而是两个客户端都连192.168.20.100:1883为什么一个都连不上或者槽位刚置位就释放先给结论MQTT Broker 不是每个客户端开一个端口。Broker 是一个监听端口后面挂多个独立连接槽位。每个槽位必须有自己的 TCP 连接状态、MQTT 会话状态、收发缓冲和诊断快照。这里讲的是 PLC 侧轻量 Broker 的连接模型目标是让5~8个工业现场客户端稳定接入不是把 PLC 写成互联网高并发服务器。一、多个客户端连同一个端口是正常的很多 PLC 工程师第一次写服务器时会本能怀疑两个客户端都连1883会不会端口冲突不会。冲突只发生在“多个服务端同时绑定同一个 IP:Port”。客户端连接同一个服务端端口是 TCP 服务器最基本的模型。监听端口只有一个。连接槽位可以有多个。二、监听句柄和连接句柄不是一个东西在 PLC 里写 Broker必须把这两件事分开对象作用生命周期NBS.TCP_Server打开监听端口Broker 运行期间长期存在NBS.TCP_Connection接收一个具体客户端连接每个客户端独立存在FB_MqttBrokerConnection管理 MQTT 会话跟客户端槽位绑定一个典型的接入链路是这里最重要的一点不能把所有客户端都塞进同一个TCP_Connection实例里复用。那样会把 TCP 句柄、读写状态、错误状态、MQTT 会话全部搅在一起。三、客户端槽位应该保存什么FB_MqttBrokerConnection不是“一个读写工具”它是一个客户端会话容器。字段类别典型内容TCP 层连接句柄、Active 状态、读写错误、最近读写时间MQTT 层ClientID、协议版本、KeepAlive、Clean Session收发缓冲aRxBuf、aTxBuf、当前帧长度、批量写出长度队列协议响应队列、普通投递队列、QoS 事务表诊断xUsed、eState、eLastError、udiLastBytesRead状态机可以简化成这样四、为什么 xTcpAcceptActive 会闪现场真实现象是xTcpAcceptActive TRUE一下。aSnapshots[1].xUsed置位一下。马上又复位。uiAcceptFreeSlot从 1 到 2 又回 1。客户端最后连接失败。这个现象不能简单判断为“端口没开”。更像是现象可能原因优先看什么xTcpAcceptActive闪一下TCP 层已经看到新连接hLastAcceptHandle是否变化槽位xUsed闪一下槽位分配成功但后续释放stLastCleanupSnapshotudiLastBytesRead 0CONNECT 首包还没到首包等待窗口udiLastBytesRead 0但断开MQTT 解析失败eLastParseError、byLastConnectLevelxError FALSE但错误码不为 0错误生命周期没清干净xError与eLastError联动五、两个关键容忍窗口真实 PLC 网络不是理想状态机。客户端连接后NBS 层可能先给出句柄和短暂 Active但 MQTT CONNECT 首包不一定已经到达。如果这时严格判断“没读到包就断”槽位就会一闪而过。所以当前 Broker 固化了两个关键窗口常量作用cnConnectFirstReadDelayMs : 20新连接接入后允许 CONNECT 首包有一个短暂到达窗口cnConnectionInactiveGraceMs : 3000TCP Active 短暂掉 FALSE 时不立即误杀连接这两个参数不是为了“拖慢”而是为了不误杀。六、错误码必须和错误标志同步曾经出现过一个很误导人的现象xBrokerError FALSE eBrokerError uiClientSlotsFull这显然不对。如果xError FALSE当前错误码就应该回到uiNoError。否则在线监控会让人误以为槽位满了。正确原则状态xErroreLastError当前周期无错误FALSEuiNoError当前周期槽位满TRUEuiClientSlotsFull错误已恢复FALSEuiNoError历史需要保留走aDiagHistory不污染当前错误这就是为什么 Broker 同时保留“当前错误”和“诊断历史”。七、ST 代码入口这一篇重点看这些入口代码入口作用FB_MqttBroker.M_AcceptNewConnection从监听层接入新 TCP 客户端并分配空闲槽位FB_MqttBrokerConnection.M_Attach把 TCP 句柄挂到连接槽位FB_MqttBrokerConnection单客户端连接状态机ST_MqttBrokerConnectionSnapshot在线诊断快照典型接入逻辑可以压缩成这几步// 1. 顶层只负责发现新连接和寻找空闲槽位。 uiFreeSlot : M_FindFreeConnectionSlot(); // 2. 找到槽位后把 TCP 连接句柄交给对应连接 FB。 aConnections[uiFreeSlot].M_Attach( hConnection : hLastAcceptHandle, udiNowMs : udiNowMs); // 3. 后续读写和 MQTT 会话状态都由该槽位独立维护。 aConnections[uiFreeSlot]();注意这里的设计边界顶层 Broker 不应该直接替连接槽位读写 MQTT 报文。顶层负责调度槽位负责会话。八、现场排障表现场现象第一优先级检查第二优先级检查常见修复方向客户端连不上xRunning、hListenHandle绑定 IP、端口、防火墙先用0.0.0.0验证监听xTcpAcceptActive闪uiAcceptFreeSlot、hLastAcceptHandle槽位快照看是否首包未到就释放槽位一闪即没stLastCleanupSnapshotudiLastBytesRead增加首包等待和 Active 容忍两客户端只能连一个cnMaxClientSlots每槽位 TCP 句柄是否独立不要复用同一连接实例报uiClientSlotsFulluiActiveSlotCount是否有僵尸槽位清理关闭态和诊断历史模型边界与验证路径这一篇本质上讲的是连接生命周期模型。表面上看问题是xTcpAcceptActive闪了一下。往上看一层它其实是监听句柄、接入句柄、连接槽位和 MQTT 会话状态没有被拆清楚。结论可信度依据验证路径多客户端连接同一个1883是正常 TCP 服务端模型highTCP 服务端基本模型和现场双客户端测试两个客户端同时连接并观察uiActiveSlotCount每个客户端必须有独立槽位high源码中的FB_MqttBrokerConnection槽位模型分别观察aSnapshots[1]、aSnapshots[2]Active 瞬态变化需要容忍窗口mediumNBS 现场表现和用户测试现象对比首包等待窗口开启前后的连接稳定性这里不要把所有闪烁都直接定罪为网络问题。至少要先看三类对象TCP 接入句柄、槽位快照、CONNECT 解析结果。缺任何一个结论都只能算假设。九、这一篇你最该记住的 6 句话多个 MQTT 客户端连同一个1883端口是 Broker 的正常模型。一个监听端口后面必须分配多个独立连接槽位。每个客户端槽位都要独立保存 TCP 句柄、MQTT 会话、缓冲、队列和诊断。xTcpAcceptActive闪烁不等于端口没开通常要看槽位生命周期。新连接首包等待窗口和 Active 容忍窗口是解决 PLC 真实网络瞬态误断的关键。当前错误码和错误标志必须同步历史错误应该放诊断历史里。下篇预告下一篇讲 CONNECT 解析。重点不是“CONNECT 有哪些字段”而是MQTT 3.1、3.1.1、5.0 的协议名和协议级别如果写死为什么会让 Broker 反复断开。里面会讲一个很真实的坑byLastConnectLevel 100不是协议等级 100而是误读到了MQIsdp里的字符d。完整 ST 代码本篇涉及的完整代码入口MqttBroker/Device/Application/POUs/FBs/FB_MqttBroker.M_AcceptNewConnection.stMqttBroker/Device/Application/POUs/FBs/FB_MqttBrokerConnection.M_Attach.stMqttBroker/Device/Application/POUs/FBs/FB_MqttBrokerConnection.stMqttBroker/Device/Application/DUTs/ST_MqttBrokerConnectionSnapshot.st系列导航系列定位第 2 篇上一篇客户端写完了为什么我还要在 PLC 里写一个 MQTT Broker下一篇CONNECT 解析别写死MQTT 3.1、3.1.1、5.0 为什么会让 Broker 反复断开项目与资料开源项目名称MqttBroker前置系列MqttClient_V2_0核心关键词单端口多客户端、连接槽位、TCP 接入、诊断快照适合谁收藏客户端连接 PLC Broker 时反复失败的人不确定多个客户端能否共用1883端口的人想把 PLC TCP Server 写成稳定服务端的人正在看xTcpAcceptActive、uiAcceptFreeSlot、uiActiveSlotCount闪烁的人