Architektur

Wie die einzelnen Teile von Mister Download Manager zusammenpassen.

Crates

Abhängigkeiten zeigen nach innen: app, cli, mcp und nmhost verwenden engine und ipc; die Engine weiß nichts von der Benutzeroberfläche. Die App sieht die Engine nur über ihre Ereignisse (Fortschritt, Segmenttabellen-Snapshots, abgeschlossen, fehlgeschlagen).

Engine

Download
 ├─ probe()              size, resumable?, validators (ETag / Last-Modified), file name
 ├─ Planner (pure)       segment table: when a connection is free, the largest remaining
 │                       part is split in half (planner.rs, tested by random simulation)
 ├─ Worker × N           one HTTP/1.1 connection each, reused across segments; slow ones
 │                       are dropped and their part re-split
 │    └─ writes at its offset into <name>.mdm.part (created sparse)
 ├─ HostLimits           learns how many connections each server accepts
 ├─ Limiter (shared)     per-download and global token buckets
 ├─ State                segment table saved atomically (craft-atomic) for crash-safe resume
 └─ events → channel     Progress, Done, Failed

Wenn alle Segmente abgeschlossen sind, wird die Part-Datei mit der erwarteten Größe abgeglichen und umbenannt; das Dateidatum kann dem des Servers folgen.

FTP und FTPS (ftp.rs) durchlaufen denselben Planer, dieselben Worker und denselben Zustand: Ein Segment ist REST + RETR auf einer Kontrollsitzung anstelle eines Bereichs- GET, SIZE und MDTM stehen für die Header, und Sitzungen werden pro Download gepoolt und zwischen Segmenten wiederverwendet.

App

Ein egui-Fenster, das auf feste Pixelkoordinaten gezeichnet wird, plus ein sofortiger Viewport pro Dialog. app.rs enthält den Zustand (Downloads, Warteschlangen, Einstellungen, die Auswahl der Liste) und wandelt Menü-, Symbolleisten-, Tastatur- und IPC-Befehle in Aktionen um. Jeder Dialog ist ein eigenes Modul und gibt ein Outcome zurück (offen, geschlossen, mit einem Wert abgeschlossen). Windows-spezifische Aufrufe sind auf win32.rs beschränkt und ihre Linux- und macOS-Pendants auf unix.rs (beginnend mit der Sitzung, dem Browser-Host, Sounds, im Ordner anzeigen, dem Absturz-Handler); jede andere Datei ist sicheres, portables Rust. Schriftarten stammen vom System: Windows-Schriftartenordner, macOS-Systemschriftarten, fontconfig unter Linux (theme.rs).

Die Download-Liste und die Einstellungen werden atomar in %APPDATA%\misterdownloadmanager\ (downloads.json) gespeichert. Der Browser-Host liest dieselbe Datei für die Erfassungsregeln, sodass eine Änderung in den Optionen für den nächsten erfassten Download gilt.

Browser-Integration

page ──► extension ──native messaging──► mdm-nmhost ──ipc──► app

Die Erweiterung fragt den Host, welche Dateitypen übernommen werden sollen, prüft jeden Download dagegen und bricht den Browser-Download erst ab, nachdem die App ihn akzeptiert hat; andernfalls behält der Browser ihn.

Übersetzungen

Jeder Text, den die Benutzeroberfläche anzeigt, durchläuft crate::i18n (craft-i18n-Kataloge, i18n/<locale>.tsv). tools/i18n/extract.py erstellt i18n/en.tsv aus der Quelle neu, mit einem Hinweis für Übersetzer zu jedem Text (was es ist, wo es angezeigt wird, seine Platzhalter).

Tests und Benchmarks

cargo testführt Unit-Tests und End-to-End-Downloads gegen mdm-labserver mit injizierten Fehlern (langsame, abgebrochene und abgelehnte Verbindungen, Server ohne Bereiche, sich ändernde Dateien) aus. tools/bench führt den veröffentlichten Geschwindigkeitsvergleich aus; seine Rohdaten befinden sich in docs/bench/.