2.4.3 丢包检测与时序完整性机制 (Packet Loss Detection & Sequencing Integrity)

这是显控终端的“网络听诊器”。在单向 UDP 传输模式下，显控端不仅是被动的数据消费者，更是链路质量的唯一评判者。它需要利用 2.4.2 定义的协议头字段，实时诊断出“谁丢包了”、“延迟多少”、“服务器是否过热”，并将这些隐性故障转化为显性的运维指标。

一、约束输入与对齐 (Constraints & Alignment)

基于 TDP-2.4-DIST（分布式补丁）和 ECN-2025-001（显控扁平化），我们需对齐以下硬性约束：

多源独立性：丢包检测必须按站点 (StationID) 隔离。站点 A 的网络抖动绝不能触发站点 B 的告警。
时钟假设：显控终端作为系统的一部分，假设已通过 NTP/PTP 与总控服务器同步。因此，timestamp_us 可用于计算绝对的端到端延迟（Glass-to-Glass Latency）。
处理策略：显控端对于乱序包执行立即丢弃策略，以保证态势图的实时性。

二、权衡分析与选项呈现 (Trade-off Matrix)

议题 1：丢包判决逻辑 (Loss Judgment Logic)

选项	A. 简单间隙检测 (Simple Gap)	B. 统计窗口平滑 (Sliding Window Stats) (推荐)
机制	只要 `Seq != Last + 1` 就报警。	维护 1 秒滑动窗口。统计窗口内的丢包率 (PLR)。仅当 `PLR > 阈值` 时报警。
灵敏度	极高。偶发的单个丢包也会导致界面闪烁告警，造成“狼来了”效应。	适中。过滤掉偶发的网络毛刺，关注持续性的链路质量恶化。
适用性	调试模式。	生产环境标准解。

议题 2：时序异常处理 (Timing Anomaly)

选项	A. 仅基于序列号 (Seq Only)	B. 序列号 + 时间戳双重校验 (Seq + Time) (推荐)
机制	序列号递增即接收。	序列号递增且 `Timestamp > LastTimestamp`。
风险	无法检测“服务器时钟回跳”或“重放攻击”。	高健壮性。防止因服务器端时钟故障导致的逻辑混乱。

三、基线确立与实施规范

为了构建一个“可诊断”的显控终端，我们确立 B. 统计窗口平滑 + B. 双重校验 为基线。

1. 诊断上下文状态机 (Diagnostic Context)

显控端必须为每一个检测到的 station_id 维护一个独立的诊断上下文：

struct StationDiagnosticContext {
    uint32_t station_id;

    // 序列跟踪
    uint64_t last_seq_id = 0;
    uint64_t last_timestamp_us = 0;

    // 统计窗口 (1s)
    uint32_t expected_packets = 0;
    uint32_t lost_packets = 0;

    // 链路状态
    bool connected = false;
    uint64_t last_seen_local_us = 0; // 用于检测静默/断连
};

2. 核心诊断逻辑基线

显控端收到 TrackDataBatch 后的标准处理流水线：

步骤 1：源识别
- 读取 station_id。
- 在 Map 中查找对应的 StationDiagnosticContext。若无，则创建新上下文（视为新站点上线）。
步骤 2：时序完整性检查 (Sequencing)
- 乱序/重复：if (batch.seq <= ctx.last_seq) -> 立即丢弃。记录 Out-of-Order 计数。
- 丢包：if (batch.seq > ctx.last_seq + 1) -> 判定为丢包。
  - 丢包数 loss = batch.seq - ctx.last_seq - 1。
  - 更新统计：ctx.lost_packets += loss。
- 更新：ctx.last_seq = batch.seq。
步骤 3：端到端延迟遥测 (Latency Telemetry)
- 计算：latency = Now() - batch.timestamp_us。
- 诊断：
  - 若 latency > 200ms（典型阈值）：标记为 "High Latency"。
  - 若 latency < 0：标记为 "Clock Skew"（时钟不同步警告）。
步骤 4：服务器健康感知 (Server Health)
- 读取 throttle_level。
- 可视化：
  - Level 0：绿色（正常）。
  - Level 1：黄色（轻微发热）。显控端右上角显示小图标提示。
  - Level 2：红色（严重过热）。显控端弹出 Toast 提示“数据已降级”。

3. 断连判定机制 (Dead Link Detection)

机制：显控端需运行一个独立的 1Hz 定时器，遍历所有 StationDiagnosticContext。
判据：if (Now() - ctx.last_seen_local_us > 2000ms)。
动作：
- 将该 Station 标记为 "Disconnected"。
- 在态势图上灰置或清除该站点的所有目标。
- 触发声音告警。

总结：2.4.3 基线图谱

诊断维度	字段来源	判定逻辑	显控端行为
丢包 (Loss)	`batch_sequence_id`	`Current > Last + 1`	统计丢包率，不补发，仅告警。
乱序 (Reorder)	`batch_sequence_id`	`Current <= Last`	静默丢弃，防止画面回跳。
延迟 (Latency)	`timestamp_us`	`LocalTime - Timestamp`	超过阈值（如 200ms）提示“数据滞后”。
断连 (Dead)	(本地接收时间)	`Silence > 2s`	标记站点离线，清空目标。
过热 (Thermal)	`throttle_level`	`Level > 0`	UI 显性提示用户“服务器过热/数据降级”。

下一步行动：

至此，我们已经完整定义了数据如何发（2.4.1/2.4.2）以及如何收（2.4.3）。2.4.4 热节流响应在之前的讨论中已经涵盖（作为 Server 端行为），2.4.5 的核心也在本节的延迟遥测中定义了。

建议：我们可以结束 2.4 外部目标数据分发协议 的讨论，进入 2.5 数据结构定义与序列化规范（虽然我们在 2.4.2 中已经定义了 Proto，但可能还需要补充 C++ 内部结构体定义），或者直接进入 第三章：异构计算架构与资源调度。

鉴于我们在 2.4.2 中已经非常详细地定义了 .proto，且 02_核心数据结构.md 已经提供了 C++ 结构体定义，我建议跳过 2.5（除非您有特定结构体需要深究），直接进入 第三章，去解决最硬核的计算资源分配问题。

提问：您是否确认 2.4.3 的多站独立诊断基线？确认后我们是否直接进入 第三章？

6.2 KiB Raw Blame History Unescape Escape