2015-08-10 1 views
2

Est-ce que quelqu'un a créé des fichiers de remplissage pour torrent? Combien de clients utilisent ce genre de choses de nos jours? Les "fichiers de remplissage" sont-ils complets?Fichiers de bourrage Torrent

Je ne l'ai pas trouvé cette fonctionnalité dans de nouveaux clients tels que ctorrent, ttorent, etc. trasmission

Avez-vous implementaions de cette fonctionnalité ou une théorie ou l'histoire à ce sujet?

Je serai apprécié pour les réponses!

Répondre

3

Cette fonctionnalité a été initialement implémentée par BitComet (avec une qualité d'implémentation plutôt médiocre à mon avis) afin de simplifier la désélection de certains fichiers à télécharger. Depuis bittorrent télécharge des pièces, et les morceaux peuvent s'étendre sur plusieurs fichiers. Sinon, lorsque vous désélectionnez certains fichiers, vous pouvez toujours obtenir le premier et le dernier bit (car il chevauche les morceaux dont vous avez besoin pour d'autres fichiers).

L'introduction des fichiers de tampons garantit que les fichiers sont alignés en morceaux et que ce problème disparaît. Notamment, uTorrent collerait plutôt ces morceaux restants dans un fichier séparé, appelé fichier de pièce. Dans les temps modernes, quelques années plus tard, libtorrent et uTorrent prenaient en charge les fichiers pad, pour une raison différente. Principalement ces deux:

  1. uTorrent mis en œuvre pour le soutien « torrents mutables », la possibilité de remplacer un torrent avec une nouvelle version et la transition/dupliquer efficacement tout le contenu commun au nouveau torrent. Pour utiliser efficacement cette fonctionnalité à grande échelle, vous devez aligner les gros fichiers afin d'éviter d'avoir à refondre tout le contenu (c'est-à-dire que vous ne voulez que hacher le nouveau contenu, pas le contenu resté le même). Pour cette raison, les fichiers pad étaient utiles.

  2. L'accès au système de fichiers à des décalages alignés sur des clusters est potentiellement beaucoup moins cher qu'un accès non aligné. Il permet également l'utilisation de certaines API plus sophistiquées qui peuvent restreindre les décalages de fichiers (asynchrone E/S). Cela est également vrai pour les fichiers mappés en mémoire.

La principale critique des fichiers pad (pour autant que je peux dire) est sorti de la mise en œuvre de ce qui était assez Bitcomet intrusive pour les clients ne pas l'appliquer. Il créerait des fichiers proéminents avec de longs noms de fichiers suggérant le téléchargement d'une nouvelle version de BitComet. Au moins dans le camp d'uTorrent cela a dérangé beaucoup d'utilisateurs, au point où certains fichiers .torrent ont été créés pour viser délibérément avec cette fonctionnalité dans bitcomet (où les fichiers pad n'étaient pas tous zéro, quel bitcomet assumerait, donc il a échoué hashes).

Il existe des façons plus élégantes d'implémenter des fichiers pad, et je pense que libtorrent et uTorrent le font mieux. Par exemple, vous pouvez consolider tous les fichiers pad dans un répertoire (caché) lors de la création du torrent. uTorrent mettra également des fichiers de tampons partiels dans son fichier de pièce.

Comme pour les clients supportant les fichiers pad, voici quelques-uns que je peux penser à du haut de ma tête (étant donné la version suffisamment récente):

  1. uTorrent
  2. BitTorrent
  3. Déluge
  4. qbittorrent
  5. BitComet (Je suppose qu'il le supporte toujours)
  6. tout autre client utilisant libtorrent (rasterbar)