Wiki

• FrontPage
• RecentChanges
• FindPage
• HelpContents
• it/DebTorrent

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:

• l'attuale protocollo DebTorrent

• proposta per mantenere numeri univoci per i frammenti

• modifiche proposte per apt-ftparchive

• protocollo proposto per interagire con APT

• le soluzioni originali proposte per i problemi descritti in seguito

• modifiche proposte per l'interfaccia utente

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

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

Full Proposal

Here are the details of how the DebTorrent program solves the problems above.

• 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 ?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)

Implementation Steps

The initial implementation steps proceeded in this order:

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.

Future steps could then be:

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

• 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

Cons

Links to More Information

• a description of the BitTorrent protocol

• another protocol description

• the BitTorrent FAQ

• the Apt howto

• information on Debian mirrors

• the amount of data updated each day in the archive