Il Mulo è tornato: aMule è disponibile in versione 3.0

Dopo oltre cinque anni di silenzio, aMule torna con una versione che i suoi stessi sviluppatori definiscono “alive again“: la 3.0.0 rappresenta non solo un aggiornamento tecnico, ma una vera e propria rinascita per uno dei client eD2k più longevi della storia del peer-to-peer. Il progetto era stato dato per morto da molti osservatori, eppure la rete eD2k conta ancora un numero significativo di utenti che attendevano software funzionante e aggiornato.

Il ritorno non è stato privo di complicazioni. Gonosztopi, tra i più prolifici sviluppatori di aMule e manutentore del progetto per molti anni, è scomparso senza lasciare notizie, portandosi dietro l’unica proprietà del repository originale su GitHub. Gli altri membri rimasti nell’organizzazione non disponevano dei permessi necessari per gestire il progetto, costringendo il team a fondare una nuova organizzazione con nuovi repository. Stesso gruppo di persone, nuova casa digitale: il sito aggiornato è ora raggiungibile all’indirizzo amule-org.github.io.

Un nuovo motore sotto la scocca

Al centro di questa release c’è un lavoro di riscrittura radicale delle prestazioni di trasferimento, che produce risultati difficili da ignorare. Su macOS con Apple Silicon, la velocità sostenuta passa da 0,35 MB/s della versione 2.3.3 a 135 MB/s, con un incremento di 381 volte. Linux ARM raggiunge 117 MB/s contro i precedenti 0,34 MB/s, mentre Windows ARM ottiene 39 MB/s rispetto agli 0,36 MB/s di partenza. I test sono stati condotti su una finestra di 90 secondi, con un singolo peer su rete locale che scaricava un file da 30 GB.

Il confronto con eMule 0.70b su Windows risulta altrettanto significativo: in upload, aMule 3.0.0 sostiene 106 MB/s contro i 22 MB/s del concorrente, con un vantaggio di circa 4,8 volte. In download, il rapporto è di circa 1,9 volte a favore della nuova versione. I guadagni derivano principalmente da due interventi distinti: lato seeder, lo spostamento delle letture disco e della costruzione dei pacchetti ed2k fuori dal thread principale, con correzione di una race condition nell’implementazione ASIO; lato leecher, l’offload delle scritture disco per i file parziali e la correzione del meccanismo di throttling.

Proprio il throttling era uno dei bug più insidiosi del codice precedente. Con MaxUpload=0, invece di consentire upload illimitato, il vecchio codice calcolava la velocità consentita come “velocità attuale più 5 KB/s per iterazione”, bloccando di fatto il collegamento su connessioni veloci. Analogamente, MaxDownload non era un limite assoluto ma un controllore proporzionale che nudge il traffico verso un punto di convergenza generalmente inferiore a quello configurato. Entrambi i meccanismi sono stati riscritti con token bucket corretti, portando il rispetto del limite configurato entro il 2,5% su tutte le piattaforme.

Un’altra categoria di miglioramenti riguarda la scalabilità per chi gestisce librerie con oltre 100.000 file condivisi. Le strutture dati interne presentavano comportamenti quadratici rispetto alla dimensione del catalogo, rendendo l’interfaccia grafica inutilizzabile su collezioni grandi: il redesign dell’interfaccia WebUI e di amulegui su sharesets di grandi dimensioni porta i tempi di ridisegno da minuti a frazioni di secondo. Tra le ottimizzazioni algoritmiche: la ricerca in wxListCtrl passa da O(N) a O(1) tramite una hash map, l’indicizzazione delle keyword in SharedFileList durante il Reload viene corretta, e la deduplicazione degli hash in known.met scende a O(N log N).

CMake sostituisce definitivamente autotools come sistema di build, richiedendo almeno la versione 3.10 e wxWidgets 3.2.0. Questa scelta semplifica la compilazione su piattaforme diverse e modernizza l’intera catena di strumenti. Sul fronte della distribuzione, sono disponibili AppImage per x86_64 e aarch64, Flatpak, un file .dmg Universal2 per macOS che include ora anche aMuleGUI.app, e per Windows sia un archivio .zip portabile sia un installer NSIS, entrambi nelle varianti x64 e ARM64.

Tra le novità funzionali, la scansione automatica delle cartelle condivise viene ora gestita tramite wxFileSystemWatcher, con supporto per cartelle di arrivo per categoria e distinzione tra condivisione ricorsiva e intenzionale. Il supporto HTTPS, silenziosamente rotto da anni contro i server TLS moderni, è stato riscritto su wxWebRequest. Le ricerche Kad ora operano in parallelo con ampliamento progressivo della frontiera di esplorazione. Infine, MaxMindDB sostituisce la libreria GeoIP deprecata per la risoluzione IP-paese.

Vale la pena ricordare, a titolo di contesto storico, che la versione precedente significativa, la 2.3.3, era uscita nel febbraio 2021 dopo anni di ritardi, con contributi principali come il supporto sperimentale a CMake, il completamento automatico con TAB in amulecmd, il supporto a C++17 e la notifica al termine dei download. La versione 2.3.2 era invece principalmente un rilascio di correzione bug, noto per un problema di crash alla chiusura dei tab di ricerca che aveva dato origine al suo soprannome informale. Tre anni e mezzo dopo quella release, il gap tecnologico accumulato era evidente; aMule 3.0.0 lo colma in modo sostanziale, riposizionando il client come alternativa concreta per chi ancora utilizza la rete eD2k.

eMule, il client che rivoluzionò il P2P

La storia del file sharing peer-to-peer è una delle narrazioni tecnologiche più affascinanti degli ultimi trent’anni, un racconto che intreccia innovazione, battaglie legali e cambiamenti radicali nelle abitudini di milioni di persone. Prima che esistessero i servizi di streaming, prima che le piattaforme digitali ridisegnassero il concetto stesso di distribuzione dei contenuti, la rete eD2k rappresentava per molti utenti l’unico modo pratico di accedere a grandi quantità di dati. eMule, il client originale su cui aMule si basa, nacque nel maggio 2002 come reazione alla lentezza percepita di eDonkey2000, il software che aveva dato vita all’omonima rete. Laddove eDonkey era un prodotto commerciale, eMule nacque come progetto open source, e questa scelta si rivelò determinante per la sua longevità.

aMule — acronimo di Another eMule — comparve sulla scena nel 2003, derivando direttamente dal codice di xMule, a sua volta una fork multipiattaforma di eMule. L’obiettivo era dichiarato sin dall’inizio: portare l’esperienza del client eD2k su Linux e macOS, sistemi operativi che eMule, scritto esclusivamente per Windows, ignorava completamente. In quegli anni il mondo del software libero viveva una stagione di grande fervore, e l’idea che un client di rete potesse girare su qualsiasi sistema operativo senza dipendere da un’unica piattaforma commerciale aveva un valore quasi ideologico, oltre che pratico.

La rete eD2k stessa aveva una storia particolare. Fondata da Jed McCaleb — lo stesso informatico che avrebbe poi creato Mt. Gox e co-fondato Ripple e Stellar — la rete si distingueva dalle sue contemporanee per un meccanismo di distribuzione dei file basato su chunk, ovvero segmenti di dati scaricabili in parallelo da sorgenti multiple. Questo approccio, oggi dato per scontato in qualsiasi protocollo di trasferimento moderno, era all’epoca una novità che garantiva resilienza e velocità anche in presenza di connessioni instabili. Il sistema di crediti di eMule, ereditato e adattato da aMule, introduceva poi un meccanismo reputazionale: chi condivideva di più riceveva priorità nelle code di download, incentivando comportamenti collaborativi all’interno della rete.

Il periodo d’oro del peer-to-peer coincise con una stagione di grande incertezza giuridica. Le major discografiche e cinematografiche combatterono battaglie legali estenuanti contro servizi come Napster, che chiuse definitivamente nel 2001, e Kazaa. La rete eD2k, decentralizzata per natura, si rivelò molto più difficile da colpire legalmente: non esisteva un’entità centrale da citare in giudizio, non c’era un server unico da spegnere. Questa caratteristica architetturale — la stessa che oggi rende ancora vitale il protocollo Kad integrato in aMule — fu pensata non per eludere le leggi, ma come soluzione tecnica ai problemi di affidabilità dei server centralizzati. La robustezza come principio di design finì per diventare, accidentalmente, anche un meccanismo di sopravvivenza.

Nel corso degli anni, la comunità di sviluppatori attorno ad aMule attraversò fasi alterne di intensa attività e lunghi silenzi. Non è un fenomeno insolito nel mondo del software open source, dove i contributori lavorano su base volontaria e i ritmi di sviluppo seguono le disponibilità personali più che le scadenze di mercato. Progetti come VideoLAN, GIMP o LibreOffice hanno conosciuto periodi simili, salvo poi rinascere grazie all’arrivo di nuovi sviluppatori o al rinnovato interesse della comunità. La scomparsa di un manutentore chiave, con la conseguente perdita di accesso ai repository, è anch’essa una situazione documentata nella storia dell’open source: un problema di governance che il mondo del software libero ha affrontato in modi diversi, dall’adozione di licenze specifiche alla creazione di fondazioni che garantiscano continuità indipendentemente dalle sorti dei singoli individui.

Curiosamente, mentre aMule dormiva, la rete eD2k non si è mai completamente estinta. A differenza di Napster o dei network Gnutella nella loro forma originale, eD2k ha resistito per ragioni legate alla natura stessa dei suoi utenti: persone che cercavano file di grandi dimensioni, spesso rari, non disponibili altrove, e che avevano investito tempo nella costruzione di cataloghi condivisi enormi. Centinaia di migliaia di file condivisi per singolo utente non sono rari in questa comunità, e proprio la gestione di tali volumi ha rappresentato nel tempo uno dei limiti tecnici più evidenti del software. Il fatto che la versione 3.0.0 abbia affrontato specificamente questo collo di bottiglia racconta molto sulle esigenze concrete di chi ancora frequenta quella rete.

Il protocollo eD2k ha anche una dimensione culturale che merita una riflessione. In molti paesi, specialmente nell’Europa orientale e in alcune regioni dell’Asia, il peer-to-peer è rimasto a lungo l’unico strumento pratico per accedere a contenuti che i mercati locali non distribuivano, o li distribuivano con ritardi inaccettabili. Questa realtà ha alimentato comunità vivaci attorno a server eD2k regionali, con una cultura della condivisione molto radicata. Non è un caso che alcuni dei principali contributori storici di aMule provenissero proprio da quelle aree geografiche. La tecnologia, in questo senso, ha spesso risposto a bisogni che il mercato non sapeva o non voleva soddisfare.

Sul piano strettamente tecnico, vale la pena notare che i problemi di throttling corretti in questa versione hanno radici comuni a molti software di rete scritti negli anni Duemila. Il meccanismo del token bucket, oggi considerato uno standard per la gestione del traffico, non era allora così diffuso nella pratica implementativa dei progetti open source. Molti sviluppatori ricorrevano a soluzioni proporzionali o incrementali che funzionavano bene sulle connessioni lente dell’epoca — quando 512 kbit/s era considerata una buona ADSL — ma che rivelavano le loro debolezze strutturali con le velocità odierne, dove una connessione domestica può tranquillamente raggiungere il gigabit. Il codice scritto per un mondo diverso porta con sé i presupposti di quel mondo, e aggiornarli richiede spesso di ripensare l’architettura da zero, non semplicemente di correggere i valori numerici.

La transizione da autotools a CMake, infine, segna simbolicamente il passaggio da un’epoca a un’altra. Gli autotools — la suite composta da autoconf, automake e libtool — furono per decenni la soluzione canonica per gestire la compilazione dei programmi su sistemi Unix-like. Potenti ma notoriamente ostici da configurare e mantenere, hanno ceduto progressivamente il passo a sistemi più moderni. CMake, pur non essendo privo di difetti propri, offre un’integrazione molto più fluida con gli ambienti di sviluppo contemporanei e con le piattaforme non Unix. Aggiornare il sistema di build è spesso il lavoro meno visibile e meno celebrato di un progetto software, eppure è quello che determina se nuovi sviluppatori riusciranno ad avvicinarsi al codice senza scoraggiarsi prima ancora di compilarlo.