pub enum Action {
Request {
conn: usize,
range: Range,
},
Cancel {
conn: usize,
},
Shrink {
conn: usize,
hi: u64,
},
}Variants§
Request
Issue GET with Range: bytes=lo-(hi-1) on this connection.
Cancel
Stop reading this connection’s current response; its range was reclaimed.
Shrink
The far end of this connection’s in-flight range moved DOWN to hi: a
repair handed the tail [hi, old_hi) to another connection. Stop reading
at hi.
§Why this action has to exist
The whole claim of this scheduler is that shrinking a laggard’s range is
free, because an HTTP range request names both ends and the far end is
enforced by the client. That is true of the protocol. It was NOT true of
this implementation: the repair below moved conns[vi].range and emitted
nothing, while the transport’s fetch loop runs while off < hi against
the hi it captured when the request was spawned. The victim therefore
kept pulling the bytes it had just been relieved of, at the same time as
the taker pulled them, over the same bottleneck.
So each repair cost roughly one stolen span of duplicated traffic instead of nothing, and since the duplicate traffic slowed the honest connections, it manufactured the very divergence that triggers a repair. That positive feedback loop is the measured “repair storm”: at n=8 on a stationary 5.3 MB transfer, 32-49 repairs where the correct count is 0, with in-run throughput decaying 439 -> 306 KiB/s.
A caller that ignores this action is not merely leaving an optimisation on the table; it reintroduces the storm.