四种消息类型
可确认消息要求对端回确认，未收到时按初始超时与随机因子逐次加倍重传，重传次数有上限；不可确认消息不要求确认，适合可容错的周期数据；确认报文可以只做链路级确认，也可以在响应就把结果捎带回来；复位报文表示收到了但无法处理，例如上下文中找不到对应的请求。
类型与用途
| 类型 | 含义 | 适用 |
|---|---|---|
| 可确认消息 | 要求对端回复确认，未收到则重传 | 需要保证到达的请求或响应 |
| 不可确认消息 | 不要求确认 | 可容忍丢失的周期上报 |
| 确认消息 | 表示已收到，可捎带响应 | 与请求使用同一消息标识 |
| 复位消息 | 表示收到但无法处理 | 取消订阅、上下文缺失等场景 |
重传与去重参数
重传与去重参数
# 以下为规范默认值，具体实现可能不同，以所用实现文档为准
# 初始确认超时：约 2 秒
# 随机因子：1.0 至 1.5 之间，避免多个设备同时重传
# 重传次数上限：4 次
# 单次交互最长等待：约 45 秒
# 去重依据：对端地址加消息标识，在去重窗口内视为同一报文典型使用场景
- 关键控制指令：使用可确认消息并处理响应，确认设备确实执行
- 周期数据采集：容错要求低时可用不可确认消息降低开销
- 网络拥塞控制：调整重传参数避免重传放大拥塞
- 会话清理：对失效的通知回复复位报文，让服务端移除订阅关系
确认与响应是两件事：服务端可以先发确认再单独发响应，也可以把响应直接放在确认报文里捎带，客户端两种情形都要能处理。
在丢包率高的链路上大量使用可确认消息会让重传进一步放大拥塞，需要同时调整设备上报周期与业务超时。