RDMA项目踩坑（一）：为什么最后一块数据必须使用实际长度？

关键词：RDMA、SEND/RECV、ibv_wc、文件传输、尾块处理

S｜Situation：从 TCP 文件流迁移到 RDMA 消息传输

我在使用 C 语言和 librdmacm、libibverbs 实现文件同步时，最初沿用了传统 Socket 编程的思路：申请一块固定大小的内存，循环读取文件并发送，接收端按缓冲区容量推进文件偏移。这个方案在文件大小恰好为缓冲区整数倍时不容易暴露问题，但文件通常存在不足一块的尾部数据。此时，如果 SEND 的 SGE 长度仍设置为整个缓冲区大小，发送端就会把本次没有从文件读取到的内存也发送出去。即便接收端最终按照文件总长度停止循环，也无法说明每一条消息的内容都正确。

项目中，发送端通过 ibv_post_send() 提交 IBV_WR_SEND，接收端通过 ibv_post_recv() 提交 IBV_WR_RECV，两端使用 RC Queue Pair。这里的关键认知是：RDMA SEND/RECV 是消息语义 ，不是 TCP recv() 那样的任意字节流分段。接收缓冲区容量与实际收到的消息长度不是一回事。

T｜Task：保证每一块写入的数据都真实有效

目标有三个：第一，发送端每次只提交本次从文件读取到的字节；第二，接收端使用完成队列返回的实际长度更新偏移；第三，对尾块、空消息、超长消息和文件总长度做边界检查。更进一步，需要明确"本地 SEND 完成"不等于"对端已经将数据写入文件"，不能用一个发送完成事件冒充整个同步事务成功。

A｜Action：从 SGE 到 WC 逐层检查长度

发送端应当把本次 fread() 返回的有效长度作为 SEND 的长度，而不是无条件使用固定缓冲区容量：

复制代码

size_t chunk = remaining < capacity ? remaining : capacity;
size_t nread = fread(send_buf, 1, chunk, fp);
if (nread != chunk) {
    /* 处理文件变化、I/O 错误或意外 EOF */
    return -1;
}
if (rdma_post_send(cm_id, nread) != 0) return -1;

接收端在确认 wc.status == IBV_WC_SUCCESS 且 wc.opcode == IBV_WC_RECV 后，才能使用 wc.byte_len：

复制代码

if (wc.byte_len == 0 || wc.byte_len > total - idx) {
    return -1;
}
memcpy(file_mapping + idx, recv_buf, wc.byte_len);
idx += wc.byte_len;

如果消息采用自定义头部，例如 type 和 length 共 8 字节，还需要验证 wc.byte_len >= sizeof(header)，以及 header.length == wc.byte_len - sizeof(header)。否则，头部中的长度可能因为缓冲区被覆盖或数据损坏而与实际接收长度不一致。对于 6 MiB 缓冲区，真正可装载的文件数据容量是 RDMA_BUFFER_SIZE - sizeof(rdma_msg_t)，不能忘记为协议头预留空间。

假设文件大小为 644130 字节，每次最多发送 65536 字节：前九块都是 65536 字节，最后一块只有 54306 字节。接收端使用实际长度推进，最终偏移正好是 644130；如果每次加 65536，统计结果就会超过文件真实大小。尤其在使用 mmap() 时，若连 memcpy() 长度也写错，可能造成越界访问或文件内容污染。

R｜Result：建立可验证的消息长度契约

这一轮修正的直接成果是明确了三种长度：发送端 SGE 长度代表实际要发送的消息字节数；接收端 SGE 长度代表可容纳的最大字节数；成功 RECV 完成中的 wc.byte_len 代表实际收到的消息长度。三者不能混用。项目后续在 AOF 同步中加入 8 字节消息头，仍然沿用这个原则。需要说明的是，长度校验只能解决单条消息的边界正确性，并不能独立解决接收队列未准备好、缓冲区复用或 AOF 并发变化等问题。最终是否完成整个文件同步，还要由应用层确认。

反思

1. RDMA SEND/RECV 与 TCP send/recv 在数据边界上有什么区别？

答： TCP 提供有序字节流，不保留应用层每次 send() 的消息边界，因此需要自行设计长度字段或分隔符。RDMA 的 SEND/RECV 在成功完成时对应消息接收语义；一次 SEND 消息由一个匹配的 RECV WR 接收，前提是接收缓冲区足够大且工作请求成功。底层 iWARP 可能使用 TCP 承载，但应用层仍应按 RDMA 消息完成语义处理。

2. `wc.byte_len` 与接收端 `sge.length` 有什么区别？

答： sge.length 是本次注册接收内存允许写入的容量；对于成功的 RECV 完成，wc.byte_len 是实际接收到的字节数。不能因为分配了 6 MiB 接收缓冲区，就认为每次都收到了 6 MiB 数据。使用 wc.byte_len 前应检查 WC 状态和 opcode。

3. 如何设计文件传输的完整性校验？

答：单块校验包括消息类型、头部长度、WC 实际长度和写入返回值；文件级校验包括总字节数、块序号或偏移、可选的 CRC32/SHA-256，以及最终 FINISHED 确认。若源文件在同步期间可变，还必须引入快照或一致性边界，哈希校验无法替代数据一致性设计。

详细技术分析请查看

0voice - github