[bittorrent] structure of multifile bittorrent file

Song Zhang songzhang2008 at gmail.com
Sat Apr 10 11:38:09 EDT 2010


thanks for the reply,

you mentioned that if I want to download one specific file from a large
torrent, it is easily accomplished with the current specification.

could you tell me which BEP ? and is it accomplished by current mainline
bittorrent ? which version ?

2010/4/10 Alan McGovern <alan.mcgovern at gmail.com>

> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20100410/5717d168/attachment.html 


More information about the BitTorrent mailing list