MissionPlanner中TCPSerial自动重连功能的问题分析与解决方案

问题背景

在MissionPlanner飞行规划软件中，用户报告了一个关于TCPSerial自动重连(autoReconnect)功能的问题。当同时使用SerialOutput NMEA和Moving Base(MB)两个功能，并且都配置为TCP客户端时，如果其中一个连接断开后尝试自动重连，会错误地使用另一个功能的TCP连接配置。

问题详细描述

具体表现为：

1. 用户首先配置NMEA输出为TCP客户端，输入正确的IP和端口并成功连接
2. 然后配置Moving Base为TCP客户端，输入不同的IP和端口并成功连接
3. 当NMEA连接意外断开时，自动重连功能会使用Moving Base的TCP配置而非NMEA原有的配置

技术原因分析

经过代码审查，发现问题的根本原因是MissionPlanner将所有TCP连接的配置(主机和端口)都存储在全局设置(Settings)中，使用相同的键名"TCP_host"和"TCP_port"。当多个功能模块都使用TCP连接时，后配置的模块会覆盖之前的配置，导致自动重连时无法获取正确的原始连接参数。

解决方案探讨

开发者提出了两种可行的解决方案：

方案一：本地存储连接参数

将每个TCP连接的配置参数(IP和端口)保存在各自的功能模块实例中，而不是全局设置中。这样每个连接都能维护自己的配置，互不干扰。

优点：

• 实现简单直接
• 各功能模块完全独立
• 不会影响其他全局设置

缺点：

• 配置无法在软件重启后持久化
• 需要修改现有架构

方案二：使用带功能标识的配置键

参考MissionPlanner中UDP连接的实现方式，为每个功能模块的TCP配置使用带标识符的键名存储。例如：

• "MovingBase_TCP_host"
• "SerialOutputNMEA_TCP_host"

优点：

• 配置可以持久化
• 与现有架构兼容
• 已有类似实现参考(UDP模块)

缺点：

• 需要修改所有使用TCP连接的功能模块
• 需要处理向后兼容

最终实现方案

开发者最终选择了方案二，参考了CommsUdpSerial.cs中的实现方式，使用ConfigRef来区分不同功能模块的TCP配置。核心实现思路如下：

1. 为每个TCP连接实例添加ConfigRef属性，用于标识功能模块
2. 存储配置时使用"TCP_host"+ConfigRef和"TCP_port"+ConfigRef作为键名
3. 读取配置时同样使用带标识符的键名

示例代码片段：

// 存储配置
OnSettings("TCP_host" + ConfigRef, Host, true);
OnSettings("TCP_port" + ConfigRef, Port, true);

// 读取配置
Host = OnSettings("TCP_host" + ConfigRef, Host);
Port = OnSettings("TCP_port" + ConfigRef, Port);

使用时为每个TCP连接实例指定唯一的ConfigRef：

new TCPSerial() { ConfigRef = "SerialOutputNMEA", Host = ip, Port = port };
new TCPSerial() { ConfigRef = "MovingBase", Host = ip, Port = port };

技术影响评估

这一改进对MissionPlanner的影响包括：

1. 解决了多TCP连接配置冲突的问题
2. 保持了配置的持久化能力
3. 与现有代码架构兼容
4. 为未来添加更多TCP连接功能提供了清晰的模式

最佳实践建议

对于MissionPlanner开发者：

1. 为每个使用TCP连接的功能模块指定唯一的ConfigRef
2. 在文档中记录这一模式，方便其他开发者遵循
3. 考虑将这一模式抽象为基类或辅助类，减少重复代码

对于MissionPlanner用户：

1. 升级到包含此修复的版本后，可能需要重新配置TCP连接
2. 不同功能的TCP连接配置现在会独立保存，互不影响

总结

MissionPlanner中TCP连接配置冲突的问题通过引入带功能标识符的配置键得到了有效解决。这一改进不仅修复了自动重连功能的问题，还为软件的多TCP连接支持建立了良好的架构基础。开发者可以参考UDP模块的实现，将这一模式应用到其他需要区分配置的功能模块中。