upload: make MaxUpload=0 mean literal unlimited - #461

Summary

When MaxUpload is left at 0 (the user-facing "unlimited" value), aMule was not actually uploading uncapped. The throttler loop was setting allowedDataRate to the currently measured upload rate + 5 KB/s on every iteration:

// Before
if (thePrefs::GetMaxUpload() == UNLIMITED) {
    allowedDataRate = (uint32)theStats::GetUploadRate() + 5 * 1024;
}

This behaves as a hard cap that tracks the current rate. Peer-side slow-start or a transient stall pins the rate low, which keeps allowedDataRate low, which prevents the rate from recovering. In practice the uplink ends up well below its real ceiling on any link faster than a few hundred KB/s.

This PR makes MaxUpload=0 mean what the UI label says — no throttling at all, let the kernel and TCP congestion control do the rate-limiting. Same semantics as modern P2P applications.

Why not auto-sense the uplink?

The leftover "+5 KB/s per iteration" was the vestige of an old UploadSpeedSense experiment. Before landing this minimal fix we attempted two richer auto-sense strategies on separate branches to see whether one could legitimately replace the static UNLIMITED_RATE path. Both were dropped:

Attempt 1 — upload-throttle-adaptive (eMule 0.70b port)

Ported eMule 0.70b's nSlotsBusyLevel signed counter + CalculateChangeDelta adaptive-step table (0.5% → 16% of current rate depending on how saturated the slot queue is). The design relies on eMule's LastCommonRouteFinder — a ~900-line ICMP-based uplink probe that detects the uplink ceiling from the outside. aMule has never had a portable equivalent (no LCRF port to macOS/Windows), so the only feedback signal left was the observed send rate itself. With no independent probe, the loop overshoots the real uplink by 8-10× before multiplicative-decrease kicks in, saturates the uplink completely, and collapses downloads for the rest of the connection.

Attempt 2 — upload-tcp-info (per-socket RTT inflation probe)

Per-socket TCP_INFO sample (Linux getsockopt(TCP_INFO) via <linux/tcp.h>, macOS TCP_CONNECTION_INFO, Windows WSAIoctl(SIO_TCP_INFO)). Compared tcpi_min_rtt baseline against an EWMA-smoothed current RTT — AIMD-style: inflation beyond max(baseline × 1.25, baseline + 5ms) → back off, idle → additively ramp.

Tightened nicely against tc-shaped lab uplinks (convergence within a couple of seconds, steady ±5% of the shaped ceiling). But real-world testing exposed a fundamental problem: RTT inflation can't distinguish peer-side congestion from our own uplink saturation. A single slow leecher with a saturated downlink, or an ed2k server under load, both show the same RTT inflation pattern as our uplink saturating — and there are always some of those. The algorithm pulled the global estimate down on legitimate full-speed uploads.

tcpi_sndbuf_limited exists on recent Linux kernels and would in principle let us tell "I'm waiting on the send buffer" from "peer is slow", but it's Linux-only and not wired up on the macOS/Windows equivalents.

Both branches are preserved in the fork for future work if someone finds a portable, peer-vs-uplink-disambiguating signal.

Decision

Modern P2P clients all treat 0 as literal "no throttling" and let the kernel + TCP congestion control do the rate-limiting. That's the same uplink aMule shares with the rest of the network stack, so the kernel is in a better position to throttle it than any userspace heuristic we could write without an independent probe. Do the same here.

Changes

Three minimal changes, 26 insertions / 5 deletions total.

src/include/common/Constants.h

Add an UNLIMITED_RATE = UINT_MAX sentinel, distinct from the user-facing UNLIMITED = 0 pref value, so the throttle loop can tell "pref says unlimited" from "budget is zero":

const unsigned UNLIMITED = 0;

// Internal sentinel for "no upload throttling at all" — used when the user
// has set MaxUpload=0 in prefs. Distinct from UNLIMITED=0 (the user-facing
// pref value) so the throttle loop can skip the per-iteration rate cap math
// entirely rather than dividing a budget by zero or by a meaningless ramp.
#include <climits>
const unsigned UNLIMITED_RATE = UINT_MAX;

src/UploadBandwidthThrottler.cpp

In the UNLIMITED branch of Entry(), set allowedDataRate = UNLIMITED_RATE so the per-iteration cap is skipped entirely:

if (thePrefs::GetMaxUpload() == UNLIMITED) {
    // MaxUpload=0 means literal unlimited — bypass the per-iteration rate cap
    // so SendFileAndControlData() is never throttled.
    allowedDataRate = UNLIMITED_RATE;
} else {
    allowedDataRate = thePrefs::GetMaxUpload() * 1024;
}

Multiplying UINT_MAX by timeSinceLastLoop would overflow the sint32 bytesToSpend accumulator, so cap the budget rate at 1 GB/s for the bytesToSpend math — still far above any real uplink, and every socket send() will short-circuit well below this ceiling:

const uint32 bytesToSpendRate = (allowedDataRate == UNLIMITED_RATE)
    ? (1024u * 1024u * 1024u)
    : allowedDataRate;
bytesToSpend += (sint32) (bytesToSpendRate / 1000.0 * timeSinceLastLoop);

src/UploadQueue.cpp

GetMaxSlots() in the UNLIMITED branch previously computed:

nMaxSlots = (uint32)(kBpsUp / kBpsUpPerClient) + 2;

…which is a chicken-and-egg trap: with observed uplink at 0 B/s (fresh start, no peers connected yet) it caps at 2 slots, and 2 slots cannot carry enough parallel TCP flows to break cold-start and let the uplink ramp. Keep the speed-based formula but floor it at N_FLOOR = 20 so there is always enough concurrency for the ramp:

const uint32 N_FLOOR = 20;
float kBpsUp = theStats::GetUploadRate() / 1024.0f;
uint32 bySpeed = (uint32)(kBpsUp / kBpsUpPerClient) + 2;
nMaxSlots = bySpeed > N_FLOOR ? bySpeed : N_FLOOR;

MAX_UP_CLIENTS_ALLOWED (250) still caps the upper end.