[bittorrent] structure of multifile bittorrent file

Alan McGovern alan.mcgovern at gmail.com
Sat Apr 10 07:01:43 EDT 2010


To be honest, there's very little benefit to doing so. You'll download
at the absolute most about 2xPieceLength bytes too much. This is a
tiny fraction of the total torrent size if PieceLength is chosen
properly. The on-disk usage can also be as little as 2xPieceLength
bytes too much depending on how you store the data. With that in mind,
it's not worth the hassle the junk files or incompatibilities would
cause.

If you want to download one specific file from a large torrent, this
is easily accomplished with the current specification.

Alan.

On Sat, Apr 10, 2010 at 10:13 AM, Harold Feit <dwknight at depthstrike.com> wrote:
> Such a procedure was attempted using bitcomet, and was not met well
> within the torrent community. It is a kludge that breaks compatibility.
>
> Song Zhang wrote:
>> I wonder if I change the torrent file format for (a+b) files with the
>> modification of btmakemetafile.py. The final piece in file a does not
>> overlap with file b which means that file a hash and file b hash have
>> clear boundary in torrent file. Can I still download smoothly with
>> current bittorrent program ?
>>
>> thanks a lot !
>>
>> 2010/4/9 Alan McGovern <alan.mcgovern at gmail.com
>> <mailto:alan.mcgovern at gmail.com>>
>>
>>     In the bittorrent protocol you treat all the files in your torrent as
>>     if they were one continuous file. This single continous file is split
>>     into pieces (in your case of size 256kb) and hashed. The final piece
>>     will be <= 256kB. It has no special handling except for the fact that
>>     it is not guaranteed to be exactly 'PieceLength' bytes in size as all
>>     other pieces are. In all other ways, the last piece is identical to
>>     every other piece.
>>
>>     Blocks are always 16kB (as per defacto standard) except for the very
>>     last block which will be <= 16kB. As before, this has no special
>>     handling except for the fact its size may be less than 16kB whereas
>>     all other blocks are guaranteed to be 16kB in length. In all other
>>     ways it is identical to other blocks
>>
>>     Hope that helps.
>>
>>     Alan.
>>
>>     On Fri, Apr 9, 2010 at 10:51 PM, Song Zhang <songzhang2008 at gmail.com
>>     <mailto:songzhang2008 at gmail.com>> wrote:
>>     > Hi,
>>     > I have a question about the structure of multifile torrent file
>>     > for example, I have two files a and b, and put them into one
>>     directory. I am
>>     > trying to create one torrent file including the contents of these
>>     two files.
>>     > I am wondering how the system handling the last piece less than
>>     256k for
>>     > each file of a and b,
>>     > size(a) = n * 256k + a1
>>     > size(b) = m * 256k + b1
>>     > a1 and b1 above all less than 256k
>>     > the question is:
>>     > 1. when generating torrent files, for the ”pieces“ part of info
>>     dictionary
>>     > of torrent file, there should be two SHA1 value from pieces less
>>     than 256k,
>>     > right ?  Although the SHA1 value of each piece (no matter greater
>>     or less
>>     > than 256k) is always 20bytes.
>>     > 2. but I don't understand during the data transfer period, the
>>     pieces are
>>     > divided into blocks and how to handle these pieces less than 256k ?
>>     > thanks a lot for the help !!
>>     > _______________________________________________
>>     > BitTorrent mailing list
>>     > BitTorrent at lists.ibiblio.org <mailto:BitTorrent at lists.ibiblio.org>
>>     > http://lists.ibiblio.org/mailman/listinfo/bittorrent
>>     >
>>     >
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> BitTorrent mailing list
>> BitTorrent at lists.ibiblio.org
>> http://lists.ibiblio.org/mailman/listinfo/bittorrent
>



More information about the BitTorrent mailing list