基于lwip的TMS570平台UDP单播2MB数据分片传输方法问询

核心前提：完全不能依赖IP层原生的UDP分片机制完成大文件传输。嵌入式场景下受RAM容量、MAC缓存限制，lwip默认的IP分片缓存、重组能力仅支持最大几十KB的流量，超过阈值的包会被直接丢弃，必须在应用层实现自定义分片逻辑才能完成2MB量级的可靠传输。

自定义分片协议设计 #

• 拆分粒度选择：单片总长度（含控制头+有效负载）固定为不超过1472字节，匹配以太网标准MTU值，完全避开底层IP层的二次分片，传输效率最高。按这个粒度计算，2MB（2097152字节）总数据仅需拆分为约1440个分片，对嵌入式平台的处理开销极低。
• 每个分片前置自定义控制头，用于接收端拼接校验，头字段固定8字节即可：
  • 32位大消息ID：用于区分不同的传输任务，避免多任务并发发送时数据混淆
  • 16位当前分片序号：从0开始递增，标记分片在整个大消息中的位置
  • 16位单片有效负载长度：标记当前分片携带的真实数据长度
  • 可选16位CRC校验值：对当前分片的payload做校验，过滤传输中出错的分片
• 单片有效负载长度按控制头长度预留固定值，比如8字节控制头对应1464字节有效负载，减少计算开销。

发送端适配逻辑（TMS570+DP84640平台） #

• 源数据读取做零拷贝适配：TMS570片内RAM容量较小，2MB的源数据一般存放在片内Flash或外挂存储上，不需要一次性把全部数据读到RAM，循环分片时按偏移量直接从源地址读取对应长度的数据填入pbuf即可，最大程度节省RAM占用。
• 循环分片发送流程：
  1. 按当前分片序号计算数据偏移量：offset = 分片序号 * 单片有效负载长度
  2. 按字段填充自定义控制头
  3. 将控制头、对应偏移的有效负载拼接到pbuf中
  4. 调用udp_sendto()发送当前分片，发送完成后立刻释放对应pbuf，不长期占用内存
• 发送节奏适配DP84640的硬件特性：DP84640的MAC TX FIFO深度有限，连续高速发送时容易出现FIFO溢出丢包，每发送10~20个分片可插入几微秒的延时，或绑定netif层的发送完成回调触发下一批发送，避免丢片。

接收端拼接校验逻辑 #

• 提前分配极小的状态数组：按总分片数创建长度等于分片总数的标记数组，每个元素仅用1个字节标记对应序号的分片是否已正确接收，1440个分片仅需1.5KB内存，无RAM压力。
• 分片接收处理流程：
  1. 收到UDP包后先解析自定义控制头，校验大消息ID匹配、分片序号在总范围内、payload长度合法，不满足的包直接丢弃
  2. 对payload做CRC校验，校验不通过的包直接丢弃，不占用拼接缓存
  3. 将有效payload按分片序号对应的偏移写入接收缓冲区，标记对应位置的分片为已接收
  4. 遍历所有分片标记，当全部分片均标记为接收完成时，即完成2MB数据的全量拼接，可触发后续数据处理流程

平台专属避坑提示 #

• 不要开启lwip的原生IP分片功能：TMS570默认的lwip配置中IP分片缓存上限仅为几KB，即使强制开启，也无法承载63KB以上的单UDP包分片，超过MTU的包会被MAC层直接丢弃，完全无法传输
• 不要尝试一次性申请大尺寸连续内存：2MB的连续RAM在TMS570片内不存在，分片流程必须按块读取源数据，禁止一次性把全量数据读入RAM，否则会直接触发内存分配失败
• 分片发送时不要触发lwip的内存溢出：每个分片的pbuf申请要匹配lwip的堆配置阈值，不要申请超过PBUF_POOL_SIZE阈值的大pbuf，避免内存池耗尽导致后续包发送失败

内容的提问来源于stack exchange，提问作者priya