XFS BOT Entra nel pannello
🧲

Un torrent che non ha bisogno
di nessuno.

Web seed · Seeder solo-metadati · Magnet

Il problema dei torrent non è mai stata la velocità. È che dipendono dalle persone: quando l’ultima spegne il computer, il file sparisce e non torna più.

Qui i byte non li dà nessuno che deve restare acceso per te: li dà un server web, alimentato da un archivio che non scade. Se poi c’è anche uno sciame di persone, tanto di guadagnato — ma non serve.

Il difetto di nascita

Perché i torrent muoiono

BitTorrent è una delle idee migliori mai avute su come spostare file. Ha però un presupposto che dopo vent’anni si vede benissimo: che qualcuno, da qualche parte, tenga acceso il computer per te.

Un torrent non è un file: è un appuntamento. Il file .torrent dice come si chiamano i pezzi e che impronta devono avere, ma non contiene un solo byte del contenuto. Quei byte stanno sui computer delle persone che lo condividono.

Finché almeno una di quelle persone è collegata, il torrent vive. Quando l’ultima chiude il portatile, va in vacanza o cambia computer, il torrent non rallenta: si ferma e basta, per sempre. Resta lì, con la sua barra a zero, e nessuno può farci niente.

Il paradosso è che questo colpisce esattamente le cose che meriterebbero di essere conservate: più una cosa è rara, meno gente la tiene su. I film dell’anno hanno migliaia di fonti; un documentario del 2003, la scansione di un manuale fuori catalogo, la discografia di un gruppo che non esiste più ne hanno zero. E il torrent che ti serve davvero è sempre quello morto.

A questo si aggiunge una cosa che quasi nessuno dice: fare il seeder è faticoso. Vuol dire tenere i file sul disco, tenere il computer acceso, tenere una porta aperta sul router, regalare la propria banda in salita — che sulle linee di casa è sempre la metà o un decimo di quella in discesa. Chiedere a un utente normale di essere l’infrastruttura di qualcun altro funziona per qualche settimana, non per dieci anni.

L’idea

Separare i due mestieri

Quando si guarda da vicino, un seeder BitTorrent fa in realtà due lavori diversi, che per abitudine facciamo fare alla stessa macchina. E non c’è nessuna legge che dica che debbano stare insieme.

📋

Dire cosa c’è dentro

i metadati

L’elenco dei file, le dimensioni, la lunghezza dei pezzi, le impronte. In tutto qualche decina di chilobyte. È quello che manca a un magnet: un magnet è solo un’impronta, e la prima cosa che fa il tuo programma è cercare qualcuno che gli racconti il resto.

Serve pochissima banda, ma serve qualcuno che risponda. E questo qualcuno deve parlare la lingua di BitTorrent, non l’HTTP.

📦

Dare i byte

i dati

I gigabyte veri. È il 99,99% del lavoro, ed è anche l’unica parte che ha bisogno di banda, di disco e di pazienza.

Ma per questa parte BitTorrent non è obbligatorio. Esiste dal 2008 un’estensione poco usata, il web seed, che dice: i pezzi puoi anche prenderteli da un normale indirizzo HTTP, come scaricheresti qualsiasi cosa dal web.

Da qui in poi è tutto conseguenza di una frase sola: i metadati li dà un seeder, i byte li dà un server web.

Il seeder non ha bisogno di avere i file: deve solo saper recitare l’indice. Il server web non ha bisogno di parlare BitTorrent: deve solo saper rispondere «dammi i byte dal 75.386.583 al 92.163.798», che è la cosa più banale che un server web sappia fare.

E allora la domanda diventa un’altra, molto più interessante: dove teniamo i byte?

La parte che sorprende

Il server web non ha i file

Questo è il punto che di solito bisogna rileggere due volte. L’indirizzo che sta scritto dentro il torrent serve gigabyte a chiunque li chieda, ma sul disco di quella macchina quei gigabyte non ci sono.

I file stanno su Telegram, nel canale-archivio della tua installazione. Ci finiscono quando scarichi qualcosa o quando carichi qualcosa dal pannello, e lì restano: non scadono, non hanno un limite di spazio, non vengono cancellati perché nessuno li richiede da un po’. È un magazzino che non chiede l’affitto.

Quando un programma torrent chiede un pezzo al web seed, succede questo:

     il tuo qBittorrent                    il dominio XFS Bot                Telegram
     ──────────────────                    ──────────────────                ────────

     «dammi i byte             ──>   apre lo sfilatoio         ──>   tira giù solo
      dal 75 al 92 MB»               verso il canale               quel tratto
                                                                     <──
                                    <──   li rigira così                 (a fette
     riceve 16 MiB                        come arrivano                da 8 MiB,
     verifica l’impronta                                            tre alla volta)
     pezzo valido

Non c’è nessuna copia locale che cresce: il tratto di file scaricato da Telegram viene rimandato al client mentre arriva e buttato poco dopo. Il che vuol dire che un dominio con dieci terabyte di archivio può girare su un disco da cinquanta gigabyte, e continuare a fare da seeder per tutto quanto.

🧩
E i file da otto gigabyte, che su Telegram non ci starebbero? Vengono spezzati in parti al momento del caricamento, ma questo resta un fatto privato dell’archivio. Il web seed le ricuce al volo: chi scarica vede un file solo della sua dimensione giusta, e il torrent lo descrive come tale. La cucitura avviene mentre i byte passano, non prima.
Cosa cambia davvero

Nessun peer richiesto

Messe insieme, queste due scelte risolvono di netto il difetto di nascita. Non lo attenuano: lo tolgono.

Non muore

Finché il dominio è acceso, quel torrent ha almeno una fonte a banda piena. Non «probabilmente», non «di solito la sera»: sempre. Un torrent di cinque anni fa che nessuno ha mai riscaricato riparte identico a oggi.

🚀

Parte subito

Niente l’attesa iniziale in cui il programma cerca peer e la barra sta a zero. Il web seed risponde al primo colpo, come un qualsiasi scaricamento diretto: la prima percentuale arriva in un paio di secondi.

🏠

Nessuno deve sacrificarsi

Chi condivide non deve tenere il computer acceso, non deve aprire porte sul router, non deve regalare la propria linea in salita. Il magazzino non è casa sua.

🔗

E i peer restano

Il web seed non esclude lo sciame: si sommano. Se altri stanno scaricando la stessa cosa, il tuo programma prende pezzi da loro e dal web seed contemporaneamente. Più siete, più va forte.

Il modo più onesto di dirlo è questo: abbiamo trasformato il seeder da volontario a infrastruttura. Lo sciame di persone smette di essere la condizione perché la cosa funzioni, e torna a essere quello che avrebbe sempre dovuto essere — un acceleratore quando c’è, niente di grave quando non c’è.

La parte difficile

Il magnet, e perché serviva comunque un seeder

Con il solo web seed, il file .torrent funziona da solo: ha i metadati dentro e sa dove prendere i byte. Il magnet no — e per un motivo che vale la pena raccontare, perché ci ha fatto sbattere la testa per giorni.

Un magnet è poco più di un’impronta. Prima di poter scaricare qualsiasi cosa, il tuo programma deve procurarsi i metadati — e il modo di procurarseli, nello standard, è chiederli a un altro peer. Non a un server web: a un peer, parlando BitTorrent. Il web seed può servire tutti i gigabyte del mondo, ma non sa dire cosa sono.

Risultato, prima che ci mettessimo mano: il .torrent partiva sempre, il magnet restava fermo su «recupero metadati» all’infinito. Non era un guasto: era la specifica che funzionava esattamente come è scritta.

La soluzione è un secondo pezzo, che gira accanto al pannello: un seeder solo-metadati. Si annuncia sulla rete DHT e ai tracker come un seeder qualunque, risponde a chi gli chiede l’indice — e non ha e non scarica un solo byte del contenuto. Pesa niente, non consuma banda, e sta acceso insieme al resto.

💥
La trappola in cui siamo caduti, raccontata per intero. La prima versione del seeder si è mangiata settantadue gigabyte di disco senza che nessuno capisse perché. Il motivo, una volta trovato, è quasi comico: il seeder leggeva il torrent, ci trovava dentro l’indirizzo del nostro web seed, e diligentemente si scaricava tutto il contenuto da noi stessi. La modalità «solo metadati» impedisce di scaricare dai peer, ma non da un indirizzo HTTP. Ora, appena prende in carico un torrent, il seeder si toglie di mano i propri web seed: non ha più nessun posto da cui scaricare, che è esattamente quello che volevamo.

Il telefono, e l’UDP che non passa

Restava un ultimo sintomo, di quelli che fanno impazzire perché sono intermittenti: dal computer il magnet si agganciava quasi sempre, dal telefono quasi mai al primo tentativo. Al secondo o al terzo sì.

La causa: per trovare il nostro seeder, il tuo programma usa la rete DHT o i tracker — e sono entrambi su UDP. Le reti mobili l’UDP lo limitano o lo buttano. Non era un problema di raggiungibilità: era la fase di ricerca che falliva.

Il rimedio sta scritto dentro il magnet stesso. Ogni magnet che generiamo porta con sé l’indirizzo esatto del nostro seeder, così il programma non deve cercare nessuno: si collega direttamente, in TCP, e chiede l’indice. Il DHT e i tracker restano lì, ma come seconda strada.

Misurato, non stimato

  • Da un server esterno, con DHT e tracker spenti apposta per simulare una rete mobile che filtra tutto: metadati risolti in 1,0 secondi. Prima, nelle stesse condizioni, non arrivavano mai.
  • Scaricamento completo di una cartella da 38 file usando solo il web seed, con peer, DHT e tracker disattivati: 147 MiB in 8,9 secondi, tutte le impronte verificate, nessun pezzo rifiutato.
  • Il web seed verso un server ben collegato regge fra 285 e 571 MB/s. Il collo di bottiglia, quando c’è, sta nella linea di chi scarica, non qui.
  • Dalla versione 2.1.16, un file da 32 GB chiesto pezzo per pezzo come fa davvero un programma torrent — un pezzo da 16 MiB alla volta, su una connessione sola — è passato da 5-7 MB/s a 24-33 MB/s. Con quattro connessioni in parallelo 48 MB/s, con otto 67 MB/s. Non è una regolazione fortunata: sono tre cose distinte, misurate una per una, spiegate qui sotto.
  • Dalla versione 2.1.17 il torrent elenca lo stesso contenuto sotto quattro indirizzi invece di uno. Un programma torrent apre una connessione per ogni indirizzo che trova, e su una connessione sola chiede un pezzo alla volta: è quello, non la linea, il tetto vero. Misurato sullo stesso file da 32 GB con il motore di qBittorrent, peer e DHT spenti: una corsia 38 MB/s, due 55, quattro 80, otto 84. Da quattro in su il guadagno si spegne, quindi quattro. Non serve fare niente: chi ha già un magnet vecchio può tenerlo, perché gli indirizzi stanno fuori dall’impronta e l’impronta non cambia.
  • Onestà sui numeri: la velocità dipende da quanti bot di streaming ha configurato chi ospita l’archivio. Uno solo vale circa 10 MB/s, due 20, da quattro in su 25-30 su un singolo collegamento. Chi non ne ha configurato nessuno non deve fare niente: funziona come prima, semplicemente senza il guadagno.
Le cose imparate a spese nostre

Tre dettagli che sembrano niente

Fra «funziona sulla mia macchina» e «funziona per chiunque» ci sono tre inciampi che, presi singolarmente, sembrano dettagli da nulla. Ognuno di questi, da solo, rendeva i download lentissimi o fermi senza nessun messaggio d’errore.

  1. Un web seed deve servire tutto quello che gli chiedi Il nostro server aveva un’ottimizzazione pensata per lo streaming video: non rispondere mai con più di 8 MiB alla volta, per far partire il filmato prima. Sensatissima per un lettore video, disastrosa per un torrent: il client chiedeva 16 MiB, ne riceveva 8, e non ricuciva mai il buco. Risultato, la barra si piantava intorno al 5% e restava lì. La regola è secca: un web seed serve l’intero tratto richiesto, come farebbe un server di file statici.
  2. Una cartella con un file solo non è una cartella Nello standard, quando un torrent contiene esattamente un file i programmi calcolano l’indirizzo del web seed in un modo completamente diverso. Noi trattavamo «cartella con un file» come una cartella, il client chiedeva un indirizzo che non esisteva, prendeva 404 e marcava il web seed come morto. Una cartella con due file funzionava, con uno no.
  3. L’indirizzo dev’essere quello pubblico, sempre Generando il torrent dal pannello aperto in locale, il web seed finiva scritto come 127.0.0.1. Perfetto per chi lo generava, irraggiungibile per chiunque altro al mondo. Ora l’indirizzo del web seed viene sempre dal dominio pubblico dell’istanza, mai da come ci si è collegati al pannello.

C’è poi una quarta cosa, meno drammatica ma molto più visibile: le richieste a Telegram vanno in parallelo. Ogni pezzo da 16 MiB che il programma torrent chiede viene spezzato in quattro fette da 4 MiB affidate a quattro bot diversi, che scaricano nello stesso momento; le fette vengono ricucite in ordine e consegnate come una risposta sola.

Che serva per forza più di un bot non è un dettaglio implementativo: Telegram concede a ogni collegamento una sola posizione di lettura per file. Con un bot solo le fette si rimettono in fila indiana e il parallelismo diventa finto — era esattamente questo il motivo per cui, per mesi, aggiungere «più richieste insieme» non cambiava niente. E il bot non viene scelto a rotazione, ma in base a quale tratto di file è richiesto: così richiedere due volte gli stessi byte ricade sullo stesso bot, che li ha ancora in memoria. Con la rotazione semplice le riletture erano crollate da 400 a 27 MB/s.

Le altre due, meno vistose e altrettanto costose. La prima: a ogni richiesta il server ricostruiva da capo l’elenco completo dei file del proprietario — quasi quattordicimila righe di archivio — solo per capire a quale file corrispondesse il percorso chiesto: 282 millisecondi buttati, ogni volta, per ottenere sempre lo stesso risultato. Adesso la risposta resta da parte per un minuto e costa zero. La seconda: la risposta non poteva partire finché non arrivava il primo pezzo da Telegram, perché era da lì che si scopriva la lunghezza del file — una lunghezza che era già scritta nell’archivio. Ora l’intestazione parte subito. Chi scarica non vede niente di tutto questo: vede solo che va veloce.

Fianco a fianco

Torrent classico e torrent ibrido

Stesso file .torrent, stesso protocollo, stessi programmi: qBittorrent, Transmission, aria2, quello che usi già. Cambia solo da dove arrivano i byte.

 Torrent classicoTorrent ibrido XFS Bot
Chi dà i byte Le persone collegate in quel momento Un server web, sempre acceso — più le persone, se ci sono
Se nessuno condivide Non scarica. Mai. Scarica lo stesso, a banda piena
Dopo cinque anni Quasi sempre morto Identico al primo giorno
Chi condivide deve… Tenere il computer acceso, i file sul disco, una porta aperta, e regalare banda in salita Niente. Il magazzino non è casa sua
Spazio su disco Quanto pesa tutto quello che condividi Praticamente zero: i byte passano, non si fermano
Il magnet Funziona se qualcuno è collegato Porta con sé l’indirizzo del seeder: si aggancia anche da rete mobile
Serve un programma speciale No No. È BitTorrent standard, dal 2008
Per onestà, cosa NON fa. Se il dominio che ha generato il torrent viene spento e non c’è nessuno nello sciame, il torrent si ferma come qualsiasi altro: il web seed sposta la dipendenza da «tante persone volenterose» a «una macchina che sta su», e una macchina è molto più affidabile di una folla, ma non è eterna. Dalla 2.1.17 ogni torrent porta quattro indirizzi di web seed, ma sono quattro corsie dello stesso dominio: servono a far scaricare più in fretta, non a sopravvivere allo spegnimento. Il passo successivo — quattro domini diversi che si conoscono fra loro e servono lo stesso contenuto, così che spegnerne uno non fermi niente — lo standard lo permette già, e la federazione ne ha tutti i pezzi. Non c’è ancora.
In pratica

Dove si preme

Tutta questa macchina, dal lato di chi la usa, è una voce di menu. Non c’è niente da configurare e niente da capire: il torrent esce già fatto, con il suo magnet.

📄

Un file

Nel gestore file, tasto destro su un file → «Condividi come .torrent». Se il file è già stato misurato al momento del caricamento, il torrent esce istantaneamente: le impronte sono già in archivio, non c’è niente da ricalcolare.

📁

Una cartella intera

Stessa voce sul menu di una cartella: prende tutto il sottoalbero, sottocartelle comprese, e ne fa un torrent solo. Qui i pezzi attraversano i confini fra un file e l’altro, quindi va misurato tutto insieme: la prima volta ci mette un momento, poi resta in cache.

📥

Mentre carichi

Nella finestra di caricamento c’è una casella: «Genera torrent e inviamelo in DM». A caricamento finito ricevi .torrent e magnet nella chat col bot, senza aver premuto altro.

🗜

Da un archivio compresso

Quando il bot scompatta un .rar in più file, le impronte le calcola sui byte che ha già in mano, prima di caricarli. Zero lavoro in più: il torrent è pronto praticamente prima dell’archivio.

🔐
Chi può scaricarlo. Il web seed è pubblico — deve esserlo, altrimenti nessun programma torrent potrebbe leggerlo: non hanno modo di fare il login da nessuna parte. Quello che è pubblico è però solo quel contenuto, tramite una chiave lunga e casuale che vale per quella condivisione e basta. Le condivisioni protette da password non generano torrent, di proposito: sarebbe un modo elegante per aggirare la password che tu hai messo.

Un file che si condivide non dovrebbe dipendere da chi si ricorda di tenere acceso il computer.
Dovrebbe semplicemente esserci.