Differences between revisions 2 and 3
Revision 2 as of 2013-01-27 13:16:40
Size: 18268
Comment: first translated version
Revision 3 as of 2013-08-04 16:59:14
Size: 18667
Comment: sync with English master
Deletions are marked like this. Additions are marked like this.
Line 31: Line 31:

Esiste un altro programma chiamato apt-metalink [[https://github.com/tatsuhiro-t/apt-metalink]]. Usa DebianPkg:aria2 per scaricare pacchetti da più fonti. Aria2 gestisce anche bittorrent.
Line 85: Line 87:
   * usando apt-metalink e aria2 si potrebbero scaricare alcuni file usando http/ftp e i più grandi usando bittorrent, basta creare un metalink per ogni pacchetto deb e mettere URL multipli http/ftp o bt.

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.

Esiste un altro programma chiamato apt-metalink https://github.com/tatsuhiro-t/apt-metalink. Usa aria2 per scaricare pacchetti da più fonti. Aria2 gestisce anche bittorrent.

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.
    • usando apt-metalink e aria2 si potrebbero scaricare alcuni file usando http/ftp e i più grandi usando bittorrent, basta creare un metalink per ogni pacchetto deb e mettere URL multipli http/ftp o bt.
  • 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

Soluzioni per l'i'Implementazione

  • punto di partenza:

  • comunicazione con apt:

    • implementare un proxy, come fa apt-proxy, attraverso il quale apt fa gli scaricamenti
    • integrarsi con apt come nuovo protocollo di scaricamento bt:// (come gli attuali http:// e ftp://)

  • 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

    • 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

  • 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:

  1. 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.
  2. Versione 0.1.1: uso dei dati da dpkg-status per determinare quali pacchetti o frammenti scaricare.
  3. 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.
  4. 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

  • 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

Collegamenti ad ulteriori informazioni