2. Message生命周期：从创建、序列化、发送、确认到回收的完整流程

在SECS/GEM协议栈中，一个Message从诞生到消亡经历五个核心阶段：创建、序列化、发送、确认和回收。理解这一完整生命周期是设计高效流控与发送队列的基础。每个阶段都涉及特定的数据结构、状态转换和资源管理策略。

2.1 生命周期总览

下图展示了Message从创建到回收的完整状态流转，以及各阶段对应的核心操作。

2.2 阶段一：创建 (Creation)

Message创建阶段的核心任务是：分配内存、初始化Header、设置消息体。在SECS/GEM协议中，Message通常由上层应用（如EAP、MES）或协议栈内部（如控制消息）触发创建。

2.2.1 创建流程

1. 内存分配：从预分配的内存池中获取一个Message对象，避免频繁的堆分配/释放。
2. Header初始化：设置Device ID、Message ID、System Bytes、Stream/Function、W-Bit等字段。
3. 消息体绑定：将SML格式的数据项（如L、A、U2、F4等）附加到Message对象中。
4. 时间戳记录：记录创建时间，用于后续的超时判断和延迟统计。

2.2.2 Message对象结构

// C语言风格的Message结构定义示例
typedef struct {
    SECSHeader     header;          // 24字节固定头
    DataItem*      body;            // 消息体指针
    MessageState   state;           // 当前状态
    uint64_t       timestamp;       // 创建时间戳
    uint8_t        retry_count;     // 重试计数
    uint8_t        priority;        // 优先级
    uint32_t       msg_id;          // 内部消息ID
} SECSMessage;

2.3 阶段二：序列化 (Serialization)

序列化是将内存中的Message对象转换为HSMS字节流的过程。这是协议栈中最消耗CPU的环节之一，直接影响发送吞吐量。

2.3.1 序列化步骤

• Header序列化：将SECSHeader的各个字段按大端序写入10字节（SECS-I）或24字节（HSMS）的头部缓冲区。
• Body序列化：递归遍历DataItem树，将每个数据项按SML编码规则转换为字节流。
• 长度计算：计算总长度（Header长度 + Body长度），写入HSMS帧的Length字段。
• 校验和（可选）：部分实现会计算CRC32校验和，附加在帧尾。

2.3.2 序列化后的HSMS帧结构

// 序列化核心伪代码
int serialize_message(SECSMessage* msg, uint8_t* buffer, size_t* out_len) {
    // 1. 序列化Header
    serialize_header(&msg->header, buffer + 4);
    
    // 2. 序列化Body
    size_t body_len = serialize_data_item(msg->body, buffer + 14);
    
    // 3. 写入Length字段
    uint32_t total_len = 10 + body_len;  // Header(10) + Body
    buffer[0] = (total_len >> 24) & 0xFF;
    buffer[1] = (total_len >> 16) & 0xFF;
    buffer[2] = (total_len >> 8) & 0xFF;
    buffer[3] = total_len & 0xFF;
    
    *out_len = 4 + total_len;
    return 0;
}

2.4 阶段三：发送 (Sending)

发送阶段涉及入队、优先级调度和实际网络发送三个子步骤。这是流控和队列优化的核心战场。

2.4.1 发送流程

1. 入队：将序列化后的Message放入发送队列。根据优先级插入到对应队列的尾部。
2. 调度：发送线程从队列头部取出最高优先级的Message，准备发送。
3. 发送：通过TCP Socket发送HSMS帧。发送完成后，将Message状态更新为“发送中”。
4. 超时监控：启动T3定时器（等待确认超时），如果在规定时间内未收到确认，触发重发或错误处理。

2.4.2 发送队列架构

2.5 阶段四：确认 (Acknowledgment)

确认阶段是SECS/GEM协议可靠性的核心。发送方必须等待接收方的确认消息，才能确定Message是否被成功处理。

2.5.1 确认类型

2.5.2 确认处理流程

// 确认处理伪代码
void handle_acknowledgment(SECSMessage* msg, AckType ack) {
    switch (ack) {
        case ACK:
            msg->state = ACKNOWLEDGED;
            recycle_message(msg);  // 进入回收
            break;
        case CACK:
            if (cack_value == 0) {  // 成功
                msg->state = ACKNOWLEDGED;
                recycle_message(msg);
            } else {  // 失败，需要重发
                if (msg->retry_count < MAX_RETRY) {
                    msg->retry_count++;
                    enqueue_message(msg, msg->priority);  // 重新入队
                } else {
                    report_error(msg, "Max retry exceeded");
                    recycle_message(msg);
                }
            }
            break;
        case NACK:
            report_error(msg, "NACK received");
            recycle_message(msg);
            break;
        case TIMEOUT:
            if (msg->retry_count < MAX_RETRY) {
                msg->retry_count++;
                enqueue_message(msg, msg->priority + 1);  // 降低优先级重发
            } else {
                report_error(msg, "Timeout, max retry");
                recycle_message(msg);
            }
            break;
    }
}

2.6 阶段五：回收 (Recycling)

回收阶段负责将Message对象及其占用的资源归还给系统。高效的回收机制可以显著降低内存碎片和分配开销。

2.6.1 回收策略

• 内存池归还：将Message对象归还到预分配的内存池中，避免调用free()。
• 数据项释放：递归释放DataItem树中的每个节点，防止内存泄漏。
• 统计更新：更新发送统计信息（如成功数、失败数、平均延迟）。
• 回调通知：通知上层应用Message已处理完成（可选）。

2.6.2 回收流程对比

2.7 生命周期中的异常处理

在实际运行中，Message生命周期可能因各种异常而中断。以下是常见异常场景及处理策略：

• 序列化失败：如消息体过大、无效数据类型。处理：立即回收Message，上报错误。
• 发送失败：如TCP连接断开、Socket缓冲区满。处理：将Message重新入队，等待连接恢复后重发。
• 确认超时：T3定时器超时。处理：重发（最多N次），超过次数后回收并上报。
• 重复确认：收到重复的ACK。处理：忽略重复确认，避免重复回收。
• 内存池耗尽：无法分配新的Message对象。处理：阻塞创建请求，或丢弃低优先级消息。

2.8 生命周期与流控的关联

Message生命周期中的每个阶段都与流控策略紧密相关：