Repository navigation
Congestion and Deployment
可靠交付使用 ACK/NACK、ACK 缺口快速重传和有上限的超时退避。原发送路径有固定可靠在途窗口;可选 SendOptions 提供帧/字节限制、队列预算和 flush 突发量。这些是本地流量/队列控制,不是自适应带宽估计或 TCP/QUIC 式拥塞窗口算法。
RecoveryOptions 可以在重试截止时间唤醒和探测符合条件的尾包,不会增加拥塞识别、速率 pacing 或动态带宽控制。不同交付通道仍共享同一网络路径。
可用带宽从 100 Mbps 降到 2 Mbps、RTT 从 30 ms 升到 800 ms 时,保持原生产速率会使应用、传输、内核及瓶颈队列累积。固定在途窗口限制一部分未确认数据,但不会自行保证瓶颈低延迟,部分队列可能丢包。
队列丢包与随机丢包呈现相同 ACK/NACK 症状。快速重传可能增加送入链路的负载;超时退避延缓重复重传,新的无歧义 RTT 样本更新 SRTT/RTO。实现不会区分随机与拥塞丢包;Karn 排除和反馈到达时间决定适应不是瞬时完成。业务消息还可能等待排序缺口,即使传输 ACK 仍有进展。
不能承诺任意持续过载下都维持低延迟。历史恢复链路阶跃实验只测试特定链路与负载,不代表拥塞公平性保证。README 的随机丢包回环测试不等于拥塞 WAN 测试。
- 发送前限制任务和活跃会话数量,监测应用队列年龄及吞吐。
- 可替换状态选择
UnreliableSequenced,应用主动合并过期更新;不可靠消息并不自动拥有全局优先级。 - 根据实测 RTT 和消息大小选择在途限制。小窗口可能减少突发也可能限制吞吐;大队列可能只增加等待。
- 多连接共享已知瓶颈时在应用层显式限速或 pacing;
SendOptions没有每秒包数或 Mbps 参数。 - 对比默认/策略、随机/队列丢包、链路阶跃/恢复、稀疏/持续负载,记录交付校验、RTT 范围、队列/丢包计数及与其他流量的公平性。
链路测试必须在任务专属网络命名空间或一次性 VM 内整形,不修改主机 qdisc、路由或 sysctl。
库不提供 TLS、认证加密、身份或业务鉴权。地址、GUID 和握手成功不是身份认证,可靠交付也不认证消息内容。
接收和重组上限控制有限资源,但不是完整公网滥用防护。应用需要准入限制、有界反序列化、逐用户配额及选定的认证/安全层;加入载荷安全层时须考虑消息前缀、MTU 与互通要求。
普通异步/同步 API 面向依赖支持的平台。socket 分片和 recvmmsg 接收批处理仅 Linux 可用,用 #[cfg(target_os = "linux")] 保护调用;不要假定 Windows/macOS 存在这些方法。
没有内置 Sans-I/O、非阻塞轮询接口或 Bevy 插件。事件循环可通过异步任务,或独立同步网络线程与有界应用队列集成。
English · 简体中文 · GitHub · crates.io 1.4.0 · Reviewed / 核对:2026-10-12 / b909c93
- Overview
- Quick start
- Blocking calls and shared runtimes
- Public API index
- Five reliability modes
- RakNet wire format and recovery
- Message lifecycle and limits
- Bytes and explicit batching
- Send policy
- Recovery policy and tail probes
- Every configuration parameter
- Concurrency and socket tuning
- Errors, deadlines and cancellation
- Congestion and deployment boundaries
- Benchmark results
- Benchmark methodology
- Benchmark reproduction
- Minecraft Bedrock proxy
- Troubleshooting and development
- Release history and upgrading