Batching

English · 简体中文

小包合并与批量接口

小消息的瓶颈经常是每个消息的帧处理、系统调用和调度成本。一个标准 RakNet frame set 可以带多个完整帧，减少数据报数量，同时保留每条应用消息的边界。

发送已经准备好的消息

use rust_raknet::{RaknetSocket, Reliability, error::Result};

async fn send_ready(socket: &RaknetSocket) -> Result<()> {
    let first: &[u8] = &[0xfe, 1, 10];
    let second: &[u8] = &[0xfe, 2, 20];
    socket.send_batch(&[first, second], Reliability::ReliableOrdered).await
}

Owned 接口使用 rust_raknet::Bytes：send_bytes_batch(&[Bytes], Reliability)。两种接口都有 *_with_order_channel 版本。

什么时候会合并

• 使用多消息批量接口，模式为 ReliableOrdered。
• 消息不需要分片，且相邻消息加帧头能一起放进协商 MTU。
• 每个数据报最多合并 8 条消息，受 MTU 进一步限制；一次 API 调用可以包含更多消息。
• 只处理已经就绪的消息，没有定时等待凑包。
• 其他模式、大消息分片、放不下的消息，仍走逐数据报发送路径。默认 MTU 下两个 800 B 消息就无法一起合并。

有效的 NACK 命中待确认数据，或可靠帧重传超时后，连接会永久退回单独发送，直到重新建立连接。预热阶段遇到丢包也会影响后续测量阶段。

原来的 send() 会不会合并

新连接仅调用普通 send() 时不主动启用小包合并，仍尽快发送。一旦某次适合合并的批量调用启用了该连接的合并状态，后续普通调用排队的消息也可能参与合并；这不是增加等待凑包的时间。

因此对比普通/批量接口要使用新建的独立连接，不能先测批量再复用同一连接测普通发送。

批量接收与转发

use rust_raknet::{RaknetSocket, Reliability, error::Result};

async fn forward(source: &RaknetSocket, destination: &RaknetSocket) -> Result<()> {
    let mut messages = Vec::with_capacity(8);
    loop {
        source.recv_bytes_batch(&mut messages, 8).await?;
        destination.send_bytes_batch(&messages, Reliability::ReliableOrdered).await?;
    }
}

recv_batch() / recv_bytes_batch() 每次会先清空输出，等待第一条消息后只排空已经就绪的消息。limit = 0 立即返回；单次最多取 64 条。双向代理需要两个方向并发运行，参考仓库代理示例。

Bytes 可以共享不可变数据，减少应用转发及重传队列的有效载荷复制；它不是网络到用户空间的端到端零拷贝。

批量成员会先验证，但发送过程被取消时仍可能已经发送或排队其中一部分；批量不是事务。

该不该启用

小包持续负载值得测试；稀疏消息与较大消息未必受益。分别观察吞吐、常见延迟、最慢 1% 延迟和内存，不要只看消息数。README 中 64 B / 1,024 连接 / 无注入丢包时批量更快，但 800 B / 1,024 连接时普通接口更快。

区分三种操作：应用层小消息合并、UDP sendmmsg 系统调用批量、可选 recvmmsg 接收批量。它们改变的成本不同。

性能方法 · 实现

同步 API · API 索引 · 错误与超时