Skip to content

v0.3.2

Latest

Choose a tag to compare

@github-actions github-actions released this 20 Sep 10:02
· 1 commit to main since this release

XferRust v0.3.2 Release Notes

English | 简体中文

Summary

  • Fixed HTTP segmented downloads stalling for over ten seconds at 99%: when the last segment's connection went silent, the whole task sat at 99% with zero speed until the regular read-idle timeout (10s) fired, and the tail now uses a shorter timeout

Bug Fixes

  • Fixed HTTP segmented downloads stalling for over ten seconds at 99%: the read-idle timeout was a flat 10s, so once the last segment's connection went silently dead (no data and no FIN), every other worker was already parked and the task sat at 99% with zero speed until the 10s timeout fired and the segment was reconnected from its received watermark — with backoff and reconnect, users saw the progress freeze for over ten seconds (most visible near the end, when no other worker is pulling data). The tail now switches to a 3s read-idle timeout once the remaining bytes drop below the end-game threshold (8MiB), so a dead connection is dropped and reconnected much sooner and the final pause drops from over ten seconds to a few

Behavior Changes

  • The read-idle timeout during the end game (8MiB or less remaining) is tightened from 10s to 3s: slow servers that deliver the tail in bursts may now be disconnected and reconnected a few extra times (a short read does not consume the fatal failure budget, and the segment resumes from the bytes already received, so the task does not fail). Behavior in the middle of a download is unchanged

XferRust v0.3.2 发布说明

English | 简体中文

摘要

  • 修复 HTTP 分片下载收尾阶段「卡在 99% 十几秒」:最后一个分片的连接僵死时,整条任务停在 99% 零速直到常规读空闲超时(10s)才断开重连,现尾声改用更短的超时

问题修复

  • 修复 HTTP 分片下载收尾阶段「卡在 99% 十几秒」:分片下载的读空闲超时统一为 10s,而收尾时最后一个分片的连接一旦静默僵死(对端无数据也无 FIN),其余协程早已全部停靠,整条任务就停在 99% 零速,直到 10s 超时触发才断开、从已收水位重连续传——加上退避与重连,使用者看到的就是十几秒不动(剩余越少越明显,因为此时没有任何其他协程在拉数据);现剩余待下字节进入尾声门槛(≤ 8MiB)后改用 3s 读空闲超时,僵死连接更早被断开重连,收尾停顿由十几秒降到数秒

行为变更

  • 尾声(剩余 ≤ 8MiB)的读空闲超时由 10s 收紧到 3s:尾部「突发式发数据」的慢服务器可能被多断开几次重连(短读不消耗致命失败预算,断开后从已收水位续传,不会导致任务失败),下载中段的行为不变