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

问题背景

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

问题详细描述

1. 正常连接流程：用户首先配置NMEA输出的TCP连接，输入正确的IP和端口并成功连接；然后配置Moving Base的TCP连接，输入不同的IP和端口也成功连接。

2. 问题现象：当NMEA连接意外断开时，自动重连功能没有使用最初为NMEA配置的TCP连接参数，而是使用了最近保存在设置中的TCP参数（即Moving Base的配置）。

3. 根本原因：当前实现中，所有TCP连接的配置（主机和端口）都保存在相同的全局设置键值（TCP_host和TCP_port）中，没有为不同的功能模块区分存储空间。

技术分析

当前实现机制

1. 配置存储：MissionPlanner使用统一的Settings系统保存TCP连接参数，所有功能模块共享相同的键名。

2. 自动重连：当连接断开时，TCPSerial会从Settings中读取TCP_host和TCP_port值进行重连，而不考虑这些值可能已被其他功能修改。

问题影响

1. 功能冲突：多个TCP客户端功能无法独立工作，一个功能的配置会覆盖另一个功能的配置。

2. 用户体验：用户需要手动重新配置连接参数，失去了自动重连的便利性。

3. 数据错误：错误的重连可能导致发送到错误的服务器或端口，造成数据丢失或混乱。

解决方案

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

1. 实现思路：在TCPSerial类中增加字段存储初始连接参数，重连时使用这些本地值而非全局设置。

2. 优点：

   • 实现简单直接
   • 完全隔离不同功能的连接配置
   • 不影响现有Settings系统

3. 缺点：

   • 参数不会持久化，重启软件后需要重新配置
   • 与现有配置保存机制不一致

方案二：区分键名的配置存储（推荐）

1. 实现参考：借鉴CommsUdpSerial.cs中的ConfigRef模式

2. 具体实现：

   // 保存配置时
   OnSettings("TCP_port" + ConfigRef, Port, true);
   
   // 读取配置时
   dest = OnSettings("TCP_port" + ConfigRef, dest);
   

3. 使用示例：

   new TCPSerial() { ConfigRef = "SerialOutputNMEA", TCP_host = host, TCP_port = port };
   new TCPSerial() { ConfigRef = "MovingBase", TCP_host = host, TCP_port = port };
   

4. 优点：

   • 保持配置持久化
   • 不同功能配置完全隔离
   • 与现有UDP实现风格一致
   • 易于扩展和维护

5. 缺点：

   • 需要修改现有TCPSerial类的配置处理逻辑
   • 需要在所有使用处明确指定ConfigRef

实现建议

推荐采用方案二（区分键名的配置存储），因为：

1. 它保持了配置的持久化特性，符合用户预期
2. 与软件中已有的UDP实现模式一致，保持代码风格统一
3. 提供了更好的可扩展性，未来新增TCP客户端功能时不会产生冲突
4. 解决了根本问题而不仅仅是症状

额外考虑

1. 向后兼容：对于已经存在的配置，可以考虑添加迁移逻辑，将旧的TCP_host/TCP_port值迁移到新的键名下。

2. 错误处理：在自动重连失败时，应提供清晰的错误提示，帮助用户诊断问题。

3. 连接状态显示：在UI上明确显示每个TCP连接的当前状态和配置参数，提高透明度。

通过这种改进，MissionPlanner可以更好地支持多个TCP客户端功能的同时使用，提供更稳定可靠的连接体验。