Module plan 

Deciding how many connections each source gets, before any of them exist.

Why this is a separate decision from scheduling

crate::sched partitions BYTES across connections that already exist, and it does so from measurement. This module answers the question one level up and one moment earlier: given a list of sources and a socket budget, how many connections should each source be given in the first place? Nothing has been measured yet, so the only inputs are the budget, the etiquette ceilings, and whatever the publisher said about their mirrors.

It lives in the I/O-free core rather than in the transport because it is pure arithmetic over a policy, it has to be identical under the simulator and under real HTTP, and getting it wrong is invisible at runtime — an allocation that quietly exceeds a stated ceiling looks exactly like one that does not.

What a mirror list adds to the problem

Two things a bare URL list does not have:

• A ranking. Metalink priority (RFC 5854) and preference (3.0) say which mirrors the publisher expects to serve well. Splitting evenly ignores it; splitting only by it concentrates the object on one host and throws away the redundancy that made the list worth having. allocate takes it as a proportional weight, so rank 1 gets more than rank 4 and rank 4 still gets a connection.
• Per-mirror ceilings. Metalink 3.0 maxconnections is an operator of a volunteer machine stating a limit for their own host. It binds tighter than the client’s own per-host default and must never be rounded up past.

More sources than sockets is the normal case

A distribution image’s mirror list names fifteen to twenty hosts; politeness and physics together justify perhaps four connections. So most of the list is not allocated at all — it is a reserve bench, drawn on by crate::sched::Scheduler::replace_source when a source dies. allocate therefore returns zero for the surplus rather than shaving everyone to fractional shares, and reserves names who is on the bench.

Structs

SourcePlan

What is known about one candidate source before the transfer starts.

Functions

allocate

Split requested connections across sources, honouring every ceiling.

reserves

The sources allocate gave no connections to, best-ranked first.