Differences between revisions 1 and 2
Revision 1 as of 2013-01-27 11:15:27
Size: 17041
Comment: first draft - partial translation. to be completed later today
Revision 2 as of 2013-01-27 13:16:40
Size: 18268
Comment: first translated version
Deletions are marked like this. Additions are marked like this.
Line 66: Line 66:
 * '''comunicazione con apt:'''  * '''comunicazione con apt: '''
Line 81: Line 81:
=== Soluzioni del protocollo === === Soluzioni per il protocollo ===
Line 83: Line 83:
 * '''a lot of packages are too small:'''
   * pieces could be made a variable size, so that a piece could be for a single small package, even if the package size is very small.
 * '''there are too many packages to create individual torrents for each''' and '''the archive is too large to track efficiently as a single torrent:'''
   * create a torrent for each Packages file, or 2 if the Architecture:all packages are split out.
   * create a torrent representing subdirectories: map the concept of a hierarchical filesystem on top of torrents.
 * '''all downloaders of a package need to be aware of all other downloaders:'''
   * keep torrent boundaries consistent so that users in a torrent are only interested in users in the same torrent
 * '''the archive is frequently updated:'''
   * This issue is common to all update methods - ftp, http, rsync, debtorrent, and is being solved in a manner common to all update methods, by debian. Package update diffs are now generated on a daily basis. -- lkml
     * The frequently updated archive problem that debtorrent has is not the same. Since all files must be gathered together into a large torrent file, every time the archive is updated so will the torrent. This is not ideal. Updates to Packages.gz files with diffs are an unrelated issue. -- CameronDale
 * '''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
Line 94: Line 94:
=== Implementation Solutions === === Soluzioni per l'i'Implementazione ===
Line 96: Line 96:
 * '''starting point:'''
   * BitTornado
 * '''communication with apt:'''
   * implement a proxy, such as apt-proxy does, for apt to download through
   * integrate with apt as a new downloading protocol bt:// (like current http:// and ftp://)
 * '''archive updates:'''
 * '''mirror updates:'''
 * '''punto di partenza:'''
   * [[it/BitTornado|BitTornado]]
 * '''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:'''
Line 104: Line 104:
== Full Proposal == == Proposta completa ==
Line 106: Line 106:
Here are the details of how the DebTorrent program solves the problems above. Ecco alcuni dettagli su come il programma !DebTorrent risolve i problemi descritti sopra.
Line 108: Line 108:
 * create a torrent for every combination of suite (stable/testing/unstable) and architecture, (possibly including separate ones for architecture:all and source)
 * communicate almost all torrent information in the Packages file
 * use a variable number of pieces and size of pieces
 * small packages are in their own single piece, hashed by their SHA1 value
 * large packages have multiple pieces, with the hashes stored separately (for now)
 * new/updated packages get new piece(s) which are automatically added to the torrent
 * pieces use unique numbers that are never reused over the life of the torrent
   * if a package is updated, the piece number larger than the current maximum one is assigned to it
      * [lkcl]: why?? packages are never updated. an archive is an archive! it is never "updated"! a package will have a new dpkg-allocated version number if it is updated.
        * while a specific version of the package is not updated, the package itself is, and a new .deb file is generated
        * in order for new .deb files to be downloaded, they need to be included in the torrent
        * the new .deb file can't reuse the old piece number(s), as the content is different and will hash differently
        * so to be included in the same torrent, which is the entire purpose of unique piece numbers, new piece numbers are added to the end of the torrent for the new .deb file -- CameronDale
   * allows for the use of bitfields along with updates
   * peers that don't have these new pieces will transmit shorter bitfields (receiving peers assume the peer doesn't have the pieces)
   * peers that aren't aware of the new pieces will get longer bitfields, and will ignore the new piece numbers they aren't aware of
   * see the [[/UniquePieces|proposal for maintaining unique piece numbers]] for more details
 * Interested state now indicates wanting pieces the other peer has
 * uninteresting connections are dropped to find interesting ones
 * new communication added: LOSTHAVE, indicating that the peer has lost the piece (due to cleaning or replacement with a new version)
 * seeding now means not currently downloading, and a peer can return to the downloading state later (when a new package is requested)
 * 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 [[/UniquePieces|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)
Line 130: Line 130:
==== Implementation Steps ==== ==== Fasi dell'implementazione ====
Line 132: Line 132:
The initial implementation steps proceeded in this order: Le fasi iniziali dell'implementazione si sono succedute in questo ordine:
Line 134: Line 134:
 1. Version 0.1.0: Implement a single variable size piece for each package and add parsing of current Packages files so they can be used unmodified as torrent files.
 2. Version 0.1.1: Use data from dpkg-status to determine which packages/pieces to download.
 3. Version 0.1.2: Implement proxy functionality to receive input from apt about which packages to download, break up large packages into multiple pieces, and download rare pieces using a backup HTTP downloader.
 4. Version 0.1.3: Automate the process to run as a daemon started from /etc/init.d, and package the program as a debian binary package.
 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.
Line 139: Line 139:
Future steps could then be: Le fasi future potranno quindi essre:
Line 141: Line 141:
 * Improve the interaction between apt and debtorrent to make the downloading more efficient and user-friendly
   * download all desired packages in parallel
   * send status information from debtorrent to apt about the progress of the download
   * requires a new debtorrent:// apt method
 * Use unique piece numbering for testing/unstable so a new torrent isn't created every day
  * use a new file that contains unique piece numbers for packages
   * info hash will be set differently, so it doesn't change
   * peers will accept incomplete/extra large bitfields and ignore pieces they don't know about
   * see the [[/UniquePieces|proposal for maintaining unique piece numbers]] for more details
 * Modifications to the Debian archive management software to allow for further enhancements to the client
   * add info to break up large packages into a number of pieces to the Packages files
   * add files for unique piece numbering
   * add torrent names to the Release files
 * Add communication protocols, such as LostHave or compressed BitFields, or the ability to drop uninteresting connections
 * Determine usage patterns from the public beta.
 * Based on measured usage patterns analyze ways to optimize sharing amongst different Packages files (arch:all, different versions, testing/unstable, testing/stable at release, etc ...)
==== Pros ====
 * 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 [[/UniquePieces|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)
Line 159: Line 158:
 * solves the small package problem
 * solves the large number of torrents and large archive problem
 * mostly solves the communication between downloaders of the same package
   * if the same package version exists in more than one suites, communication between the downloaders will not occur
==== Pro ====
Line 164: Line 160:
==== Cons ====  * 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 ====
Line 168: Line 169:
== Links to More Information == == Collegamenti ad ulteriori informazioni ==
Line 170: Line 171:
 * [[http://www.bittorrent.org/protocol.html|a description of the BitTorrent protocol]]
 * [[http://wiki.theory.org/BitTorrentSpecification|another protocol description]]
 * [[http://dessent.net/btf
aq/|the BitTorrent FAQ]]
 * [[http://www.debian.org/doc/manuals/apt-howto/|the Apt howto]]
 * [[http://www.debian.org/mirror/|information on Debian mirrors]]
 * [[http://ftp-master.debian.org/size-quarter.png|the amount of data updated each day in the archive]]
 * [[http://www.bittorrent.org/protocol.html|Una descrizione del protocollo BitTorrent]]
 * [[http://wiki.theory.org/BitTorrentSpeci
fication|Un'altra descrizione del protocollo]]
 * [[http://dessent.net/btfaq/|La FAQ di BitTorrent]]
 * [[http://www.debian.org/doc/manuals/apt-howto/|L'HOWTO di Apt]]
 * [[http://www.debian.org/mirror/|Informazioni sui mirror Debian]]
 * [[http://ftp-master.debian.org/size-quarter.png|La quantità di dati aggiornata ogni giorno nell'archivio]]

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

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