Translation(s): English - Italiano
Questa pagina è pensata per raccogliere informazioni, idee e commenti relativi all'aggiunta ad Apt della funzionalità BitTorrent per lo scaricamento dei file di pacchetto.
Altre pagine:
Motivazione
I benefici di questo progetto sono chiari, sia per il progetto Debian che per i suoi mirror, così come per ogni altro sviluppatore che voglia fare da host per un archivio popolare, ma che si preoccupi dei costi della banda. Una volta che il servizio sarà completato e adottato su larga scala, i costi di banda e hardware relativi al fornire un archivio Debian molto vasto a centinaia di migliaia di utenti saranno drammaticamente ridotti.
Questi costi vengono attualmente ridotti dal sistema dei mirror volontari che Debian usa per aiutarsi nella distribuzione dei pacchetti. Questo sistema ha però alcuni lati negativi, specialmente con l'aumentare della dimensione dell'archivio. Alcuni mirror stanno già soffrendo il peso della dimensione, e ciò ha portato alla creazione di mirror parziali. Questo crea anche molti punti centrali di errore per gli utenti, dato che la maggior parte dipende da un singolo mirror e non viene fatto un buon lavoro di distribuzione eguale del carico, dato che alcuni mirror possono essere scelti più frequentemente di altri. Da ultimo, i mirror non primari possono essere lenti nell'aggiornarsi alle nuove versioni dei pacchetti e i cambiamenti avvengono lentamente dato che gli elenchi delle fonti devono essere aggiornati manualmente dagli utenti.
Tuttavia, usando un sistema in stile BitTorrent, questi mirror volontari potrebbero semplicemente unirsi all'insieme dei peer per l'archivio, facendo da mirror solo per la quantità di dati che desiderano e contribuendo solo con la quantità di banda che preferiscono; in questo fornirebbero dati ridondanti multipli con un carico che verrebbe automaticamente bilanciato dal sistema e userebbero la banda risparmiata per aggiornare i loro pacchetti più spesso. Questo inoltre permettere un ulteriore crescita futura, sia in termini di dimensioni dell'archivio sia nella popolarità di Debian.
Storia e lavori correlati
Questo è stato originariamente proposto e accettato come un progetto Google Summer of Code nel 2006. Sfortunatamente il progetto non ha avuto successo a causa dei tempi ristretti e alla complessità del progetto, ma ne sono scaturite alcune buone idee.
Un progetto simile è stato accettato per il Google Summer of Code del 2007 e il codice risultante può essere trovato qui.
Un programma simile per l'idea di base a questo, apt-torrent, è stato creato da Arnaud Kyheng ed è disponibile online: http://sianka.free.fr/. apt-torrent è diverso per il fatto che non fa alcun cambiamento al protocollo BitTorrent, ma fornisce piuttosto un wrapper per il pacchetto BitTornado che viene quindi usato per scaricare i file di pacchetto.
Un altro protocollo derivato da BitTorrent è gittorrent. Certamente si è discusso dei modi di usare gittorrent per ottenere gli stessi risultati suggeriti da questa proposta, ma è probabilmente una buona idea che entrambi gli sforzi procedano in parallelo.
Problemi
Benché l'idea di implementare una soluzione in stile BitTorrent per la distribuzione dei pacchetti sembri buona, ci sono alcuni problemi con il modo attuale in cui BitTorrent distribuisce i file e che lo rendono inadatto per un archivio Debian. Queste limitazione degli attuali sistemi BitTorrent quasi certamente richiederanno modifiche per migliorare il client e il protocollo. Il progetto Google SoC 2006 aveva identificato alcune di queste preoccupazioni e da allora se ne sono aggiunte altre (se si conoscono altri problemi, aggiungerli qui di seguito).
Il protocollo
molti pacchetti sono troppo piccoli:
un archivio è composto di una vasta gamma di dimensioni di file, molte delle quali sono più piccole del frammento più piccolo usato da BitTorrent (attualmente 32 kB).
- se in un singolo frammento sono presenti più pacchetti, allora un peer potrebbe sprecare molta banda solo per ottenere dal frammento il singolo pacchetto di cui ha bisogno
- se i frammenti sono troppo piccoli, lo scaricamento diventa inefficiente dato che una crescente percentuale della banda viene sprecata in carico non utile
ci sono troppi pacchetti per creare torrent individuali per ciascuno:
- un utente dovrebbe partecipare in teoricamente migliaia di torrent contemporaneamente, sprecando risorse
- la comunicazione tra gli stessi utenti in molti torrent diversi sarebbe uno spreco e sarebbe difficile tenere traccia delle cose per permettere scaricamenti giusti
l'archivio è troppo grande per tenerne traccia in modo efficiente come un unico torrent:
- un archivio Debian è potenzialmente un archivio estremamente grande di pacchetti, che include più versioni e architetture
- un utente normale desidera scaricare solamente un piccolo sottoinsieme dell'intero archivio
in BitTorrent è normale scaricare l'intero torrent, tuttavia è possibile scaricare un sottoinsieme dei file
tutti coloro che scaricano un pacchetto devono essere a conoscenza di tutti gli altri che lo fanno:
- potrebbero esistere più torrent che contengono lo stesso pacchetto (es. pacchetti architecture:all o la stessa versione di un pacchetto in testing e unstable)
- per essere più efficiente, tra gli utenti di torrent diversi contenenti lo stesso pacchetto deve esserci della comunicazione
l'archivio viene aggiornato spesso:
- sebbene venga aggiornata solo una porzione molto piccola alla volta, questi aggiornamenti avvengono su base giornaliera
BitTorrent non è attualmente progettato per gestire aggiornamenti ai file, né versioni multiple dei file
- può essere possibile informare il client dell'aggiornamento di un pacchetto quando cerca di scaricarne uno sorpassato
la posizione dei trasferimenti non viene considerata:
la localizzazione dei trasferimenti è un altro problema che non è risolto nell'attuale protocollo BitTorrent. Si ipotizzi un unico torrent con più di un milione di persone che lo scaricano distribuite in tutto il mondo. Quando un client BitTorrent vuole scaricare un frammento dei dati, non può richiederlo da tutto il milione e più di peer, perciò seleziona in un modo semi-casuale un peer da cui richiedere un frammento. Questa strategia è semplice dal punto di vista dell'algoritmo, ma può facilmente creare situazioni in cui un peer negli Stati Uniti richiede un frammento di dati da un peer in Australia nonostante il fatto che un altro peer nello stesso stato potrebbe fornire lo stesso frammento con un minore uso globale della rete. Ciò crea una situazione per cui gli stessi dati vengono trasferiti ripetutamente attraverso le occupatissime linee intercontinentali. Per risolvere questo problema deve essere introdotta una qualche misura della posizione nell'elenco degli utenti e quelli più prossimi devono essere usati per primi.
[lkcl]: la posizione dei trasferimenti non è un problema di cui si deve far carico debtorrent. Può occuparsene Internet stessa. Di fatto, cercare di risolvere i problemi di posizione equivale a cercare di indovinare la disposizione di Internet e non fidarsi del fatto che il protocollo BitTorrent faccia il suo lavoro. Il protocollo BitTorrent seleziona i punti migliori da cui scaricare. Gli ISP hanno creato proxy, blocchi e rallentatori (che abbattono il traffico del 50%) per "affrontare" il "problema" di BitTorrent e cercare di indovinare cosa avverrà nel futuro rende solo il compito estremamente più complesso. In definitiva credo che il problema di carico su Internet non dovrebbe essere confuso con il problema del carico sui mirror. I mirror stessi dovrebbero eseguire debtorrent (il client) pubblicando i loro contenuti mirror (http) come loro cache debtorrent
Dettagli dell'implementazione
punto di partenza:
come buon punto di partenza, quale dei client BitTorrent attualmente disponibili dovrebbe essere usato?
comunicazione con apt:
- come farà apt a dire al programma di scaricare un pacchetto?
- come farà il programma a restituire un pacchetto ad apt?
gli scaricamenti BitTorrent avvengono più lentamente, perciò più scaricamenti di pacchetto possono avvenire contemporaneamente
- l'utente deve essere al corrente che sta avvenendo uno scaricamento (ad esempio con una barra di avanzamento)
- duplicazione dei file scaricati
aggiornamenti dell'archivio:
- come avvengono gli aggiornamenti dell'archivio?
aggiornamenti dei mirror:
- quando sono disponibili i nuovi pacchetti, come vengono informati i mirror in modo che possano automaticamente recuperarli?
La soluzione
Ecco alcuni dettagli su come i problemi elencati prima sono risolti nell'attuale implementazione del programma DebTorrent.
Soluzioni per il protocollo
molti pacchetti sono troppo piccoli:
- si potrebbero creare frammenti di dimensione variabile, in modo che ci possa essere un frammento per un singolo pacchetto piccolo, anche se la dimensione del pacchetto è estremamente ridotta.
ci sono troppi pacchetti per creare torrent singoli per ciascuno di essi e l'archivio è troppo grande per tenerne traccia in modo efficiente con un singolo torrent::
creare un torrent per ogni file Packages, o 2 se vengono separati i pacchetti Architecture:all.
- creare un torrent che rappresenta sottodirectory: mappare il concetto di file system gerarchico sopra i torrent.
tutti coloro che scaricano un pacchetto devono essere a conoscenza di tutti gli altri che lo fanno:
- mantenere i confini dei torrent coerenti in modo che gli utenti in un torrent siano interessati solo dagli utenti nello stesso torrent
l'archivio è aggiornato di frequente:
- questo problema è comune a tutti i metodi di aggiornamento, ftp, http, rsync, debtorrent, e viene risolto da Debian nello stesso modo per tutti i metodi di aggiornamento: diff di aggiornamento dei pacchetti vengono ora generati quotidianamento. -- lkml
Il problema di aggiornamento frequente dell'archivio che ha debtorrent non è lo stesso. Dato che tutti i file devono essere raggruppati insieme in un grosso file torrent, ogni volta che l'archivio viene aggiornato lo deve essere anche il torrent. Questa non è una situazione ideale. Gli aggiornamenti dei file Packages.gz usando diff sono una cosa non correlata. -- CameronDale
- questo problema è comune a tutti i metodi di aggiornamento, ftp, http, rsync, debtorrent, e viene risolto da Debian nello stesso modo per tutti i metodi di aggiornamento: diff di aggiornamento dei pacchetti vengono ora generati quotidianamento. -- lkml
Soluzioni per l'i'Implementazione
punto di partenza:
comunicazione con apt:
aggiornamenti dell'archivio:
aggiornamenti dei mirror:
Proposta completa
Ecco alcuni dettagli su come il programma DebTorrent risolve i problemi descritti sopra.
- Creazione di un torrent per ogni combinazione di suite (stable/testing/unstable) e architettura, (inclusi eventualmente alcuni separati per architecture:all e sorgenti)
- Comunicare quasi tutte le informazioni sul torrent nel file Packages
- Usare un numero e una dimensione variabili per i frammenti
- I pacchetti piccoli sono in un proprio frammento singolo, con il loro valore SHA1 come hash
- I pacchetti grandi hanno frammenti miltipli, con gli hash memorizzati separatamente (per adesso)
- I pacchetti nuovi o aggiornati ottengono nuovi frammenti che vengono automaticamente aggiunti al torrent
- I frammenti usano numeri univoci che non vengono mai riutilizzati durante tutta la vita del torrent
- se un pacchetto viene aggiornato, gli viene assegnato il numero di frammento più grande dell'attuale numero massimo
- [lkcl]: perché?? i pacchetti non sono mai aggiornati. Un archivio è un archivio! Non viene mai "aggiornato"! Un pacchetto avrà un nuovo numero di versione allocato da dpkg se viene aggiornato.
- benché una specifica versione del pacchetto non venga aggiornata, il pacchetto in sé lo è e viene generato un nuovo file .deb
- per poter scaricare i nuovi file .deb, essi devono essere inclusi nel torrent
- il nuovo file .deb non può riutilizzare i vecchi numeri dei frammenti, dato che il contenuto è diverso e avrà hash diversi
perciò, per essere incluso nello stesso torrent, che è proprio lo scopo dei numeri di frammento univoci, i nuovi numeri dei frammenti per i nuovi file .deb vengono aggiunti alla fine del torrent -- CameronDale
- [lkcl]: perché?? i pacchetti non sono mai aggiornati. Un archivio è un archivio! Non viene mai "aggiornato"! Un pacchetto avrà un nuovo numero di versione allocato da dpkg se viene aggiornato.
- permette l'uso di bitfield insieme con gli aggiornamenti
- i peer che non hanno questi nuovi frammenti trasmetteranno bitfield più corti (i peer che ricevono suppongono che il peer non abbia tali frammenti)
- i peer che conoscono l'esistenza dei nuovi frammenti otterranno bitfield più lunghi e ignoreranno i nuovi numeri di frammento di cui non sono al corrente
per maggiori dettagli vedere la ?proposta per il mantenimento di numeri di frammento univoci
- se un pacchetto viene aggiornato, gli viene assegnato il numero di frammento più grande dell'attuale numero massimo
- Lo stato "interessato" ora indica che si desiderano i frammenti che ha l'altro peer
- Le connessioni non interessanti vengono scartate per trovare quelle interessanti
- Aggiunta di una nuova comunicazione: LOSTHAVE, che indica che il peer ha perso il frammento (a causa di una pulizia o perché rimpiazzato con una nuova versione)
- Seeding ora significa che non si sta attualmente scaricando e un peer può ritornare nello stato di scaricamento in seguito (quando è richiesto un nuovo pacchetto)
Fasi dell'implementazione
Le fasi iniziali dell'implementazione si sono succedute in questo ordine:
- Versione 0.1.0: implementazione di un singolo frammento di dimensione variabile per ciascun pacchetto e aggiunge l'analisi degli attuali file Packages in modo che possano essere usati immutati come file torrent.
- Versione 0.1.1: uso dei dati da dpkg-status per determinare quali pacchetti o frammenti scaricare.
- Versione 0.1.2: implementazione di una funzionalità proxy per ricevere input da apt riguardo quali pacchetti scaricare, suddividere pacchetti grandi in frammenti multipli, e scaricare i frammenti rari usando uno scaricatore HTTP di ripiego.
- Versione 0.1.3: automatizzazione del processo da eseguire come demone e avviato da /etc/init.d, e pacchettizzazione del programma come pacchetto Debian binario.
Le fasi future potranno quindi essre:
- Migliorare l'interazione tra apt e debtorrent in modo da rendere lo scaricamento più efficiente e facile da usare
- scaricare tutti i pacchetti desiderati in parallelo
- invio delle informazioni di stato riguardanti il progresso dello scaricamento da debtorrent ad apt
- richiesta di un nuovo metodo apt debtorrent://
- Uso di una numerazione univoca dei frammenti per testing/unstable in modo da non creare un nuovo torrent ogni giorno
- uso di un nuovo file che contiene numeri univoci di frammento per i pacchetti
- gli hash verranno impostati in modo diverso, in modo da non cambiare
- i peer accetteranno bitfield incompleti o extra e ignoreranno i frammenti di cui non sono a conoscenza
per maggiori dettagli vedere la ?proposta per mantenere numeri univoci per i frammenti
- uso di un nuovo file che contiene numeri univoci di frammento per i pacchetti
- Modifiche al software di gestione degli archivi Debian per permettere ulteriori miglioramenti al client
- aggiunta di informazioni nei file Packages per suddividere pacchetti grandi in diversi frammenti
- aggiunta di file per la numerazione univoca dei frammenti
- aggiunta dei nomi dei torrent ai file Release
Aggiunta ai protocolli di comunicazione, come ?LostHave o ?BitFields compressi, oppure la capacità di ignorare le connessioni non interessanti
- Determinare i modelli d'uso a partire da una versione beta pubblica.
- Sulla base dei modelli d'uso osservati, analizzare i modi per ottimizzare la condivisione tra file Packages diversi (arch:all, versioni differenti, testing/unstable, testing/stable al momento del rilascio, ecc)
Pro
- risolve tutti i problemi relativi ai pacchetti piccoli
- risolve il problema del grande numero di torrent e degli archivi grandi
- risolve in gran parte la comunicazione tra coloro che scaricano lo stesso pacchetto
- se la stessa versione di pacchetto esiste in più di una suite, la comunicazione tra chi la scarica non avviene
Contro