4. T3 超时（Reply Timeout）

T3 超时是 SECS/GEM 通信中最核心的会话级超时参数之一，它直接决定了设备（Equipment）与主机（Host）之间一次事务（Transaction）的等待极限。理解 T3 的定义、作用及其对事务的影响，是正确配置 HSMS 链路恢复参数的前提。

4.1 T3 的定义与作用

T3（Reply Timeout） 是指发送方在发出一个需要回复的消息（Primary Message）后，等待接收方返回对应回复消息（Reply Message）的最大允许时间。如果在该时间内未收到预期的回复，发送方将判定该事务超时，并触发相应的超时处理流程。

T3 的作用可以归纳为以下三点：

• 防止事务挂起：当接收方因故障、负载过高或网络异常而无法回复时，T3 确保发送方不会无限期等待。
• 释放系统资源：每个未完成的事务都会占用发送方的消息缓冲区、事务 ID 和线程资源。T3 超时后，这些资源可以被回收。
• 触发链路恢复：T3 超时通常是 HSMS 链路降级或断开的先兆信号，可触发后续的 T5/T6/T7 等链路恢复流程。

4.2 T3 超时对事务的影响

T3 超时对 SECS/GEM 事务的影响是多层次的，从单个消息的丢失到整个链路的断开都有可能。以下是 T3 超时可能引发的连锁反应：

从协议栈的角度看，T3 超时的影响路径如下：

1. 发送方发出 Primary Message，启动 T3 计时器。
2. 若 T3 超时，发送方将丢弃该事务的上下文，并记录一次 T3_TIMEOUT 错误。
3. 发送方可以选择重试（Retry）或放弃（Abort），具体行为由上层应用决定。
4. 如果 T3 超时发生在 HSMS 控制消息（如 Link Test Request）上，则直接触发链路恢复流程。

4.3 T3 配置建议与常见值

T3 的配置需要在响应及时性和网络容忍度之间取得平衡。过短的 T3 会导致误超时（False Timeout），过长的 T3 会延迟故障发现。以下是不同场景下的配置建议：

配置 T3 时还需要注意以下事项：

• T3 必须小于 T6（Control Transaction Timeout）：通常 T6 是 T3 的 2~3 倍，确保控制事务有足够的时间完成。
• T3 与 T5（Connect Timeout）无关：T5 用于连接建立阶段，T3 用于已建立连接后的数据事务阶段。
• 设备端与主机端 T3 应保持一致：如果两端 T3 配置不同，可能导致一端认为超时而另一端仍在等待，造成事务状态不一致。

4.4 T3 超时处理流程示例

以下是一个典型的 T3 超时处理代码片段（伪代码），展示了发送方在 T3 超时后的标准处理逻辑：

// T3 超时处理示例（伪代码）
function sendPrimaryMessage(message, timeout = T3) {
    startTimer(timeout);
    send(message);
    
    while (timerRunning) {
        if (replyReceived) {
            stopTimer();
            return processReply(reply);
        }
        if (timerExpired) {
            // T3 超时处理
            logError("T3_TIMEOUT", message.id);
            releaseTransactionContext(message.id);
            
            // 根据重试策略决定是否重试
            if (message.retryCount < MAX_RETRIES) {
                message.retryCount++;
                sendPrimaryMessage(message, timeout);
            } else {
                notifyApplication("Transaction failed", message.id);
                triggerLinkHealthCheck();
            }
            return;
        }
    }
}