multipath redundant模式下，多次传输单个大文件(1GB)，文件大小正确，但是md5sum经常不正确

[znscn]

稳定的有线网络环境下，传输单个大文件：

• single path模式下正常
• multipath minrtt模式下正常
• multipath roundrobin模式下正常
• multipath redundant模式下，文件大小正确，但是md5sum经常不正确

感觉似乎是stream的RecvBuf在合并写入multipath的重复数据时有问题。
请问一下，不知你们是否有发现这样的问题？

[glime-ai[bot]]

您好！关于您提到的在使用multipath redundant模式下传输大文件时出现的md5sum不正确的问题，这确实可能是由于在多路径冗余传输模式下，数据包的重复发送和接收处理可能存在问题，导致数据在合并时出现错误。

在multipath redundant模式下，所有数据包在所有可用路径上都会被发送，这样做的目的是为了最小化延迟并提高传输的可靠性。然而，如果在接收端的数据重组（Reassembly）和缓冲区管理（Buffer Management）处理不当，就可能会导致数据的错误重复，进而影响文件完整性验证（如md5sum）。

建议的解决步骤包括：

1. 检查和更新: 确保您使用的TQUIC库是最新版本，有时候这类问题可能已经在新版本中被修复。
2. 日志和调试: 开启更详细的日志记录，观察是否有重复数据包的处理错误。您可以利用TQUIC提供的日志级别设置（如DEBUG或TRACE）来获取更详细的内部操作信息。
3. 问题复现: 尝试在控制环境中复现问题，并观察在不同条件下（如不同的网络延迟和带宽）问题是否依旧存在。
4. 联系支持: 如果问题依旧存在，建议向TQUIC的开发团队报告这一问题，提供相关的日志文件和测试情况，以便他们能够更准确地定位问题并提供修复。

如果您需要进一步的技术支持，可以查看TQUIC的官方文档或直接在其GitHub页面提交issue。

希望这些信息对您有帮助！如果有其他问题或需要更多帮助，请继续提问。

This comment was generated by Glime.

[iyangsj]

@znscn 使用的tquic版本是多少

[znscn]

v0.8.1

[znscn]

刚使用最新的develop分支898605c测试，

server cmd:

./tquic_server --root /opt/files/ --enable-multipath --multipath-algor Redundant

client cmd:

./tquic_client https://192.168.3.10:4433/1GB --dump-dir=./  --enable-multipath --multipath-algor Redundant --local-addresses 192.168.1.10,192.168.2.10

问题1：
1G文件尚未传输完成，tquic_server crash:

thread 'main' panicked at 'range start must not be greater than end: 465 <= 0', /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bytes-1.6.0/src/bytes.rs:279:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

问题2：
1G文件传输完成，md5sum不正确

[iyangsj]

了解，下个版本会修复