On 6月22日, 午前5:59, Anthony Bryan <[email protected]> wrote: > On Wed, Jun 17, 2009 at 7:45 AM, Tatsuhiro <[email protected]> wrote: > > > On Jun 15, 6:24 am, Anthony Bryan <[email protected]> wrote: > > > from what I remember when this came up before, the filename in a > > > multi-file torrent should match the filename in the metalink (here > > > <file name="example.file">). I know this isn't too flexible but I > > > think it can be made to work for most cases now. > > > > Tatsuhiro, any ideas for improvements? perhaps a file or files > > > attribute for bittorrent URLs? > > > Yeah, if all file under files element matches to the content of > > torrent file, adding torrent attribute to files element might make > > things clear. But that seems very torrent specific. > > Personally, I don't like the way of multi-file torrent which treats > > many files as a single and hashing it into pieces. As said earlier in > > this thread, it requires that to checking a piece hash, more than 1 > > file is needed sometimes. It makes things unnecessarily complicated. > > here's what I think would work: > > 1) use a single file torrent. > > 2) the filename in a multi-file torrent should match the filename in > the metalink (here <file name="example.file">). > > 3) add a file attribute to <url>s of type="bittorrent" so you can > select one file out of a multi-file torrent > > <url type="bittorrent" file="Fedora-11-i386-disc1.iso" > preference="100">http://torrent.fedoraproject.org/torrents//Fedora-11-i386-CDs.torrent</url> >
If many files are listed in this way, same torrent URL is scattered in metalink file and this also requires an extra work for BitTorrent capable client: The client has to look url element under every file element and gather files which have same torrent file , because usually multi file torrent is handled in the one torrent session. > > > > > "The verification section is ignored if torrent is specified, either > > > single- or multi- file torrent, because .torrent file has piece hash > > > and they are enough to validate the integrity of file. > > > I'm not sure this behavior is documented or not." > > > > this becomes tricky - which is "authoritative", the metalink or the > > > torrent? linux distros probably roll their own, both torrents & > > > metalinks, so this isn't a problem. but others might not have control > > > over both. > > > > then, basically all metalink clients will do full file checksum > > > verification. but few do chunk checksums, few do mirrors and torrents, > > > even fewer do both. > > > > for instance, if DTA did chunk checksums, it still probably won't > > > support torrents any time soon. > > > This is very difficult and I have no good idea at the moment. > > I think checking all available checksums are waste of the time. > > If we check chunk checksum, we don't need to check whole checksum. > > I admit the possibility of replaced torrent file. So I think hashing > > for the whole torrent is a good idea. > > > On Jun 15, 6:24 am, Anthony Bryan <[email protected]> wrote: > > > On Mon, May 11, 2009 at 8:45 AM, Matt Domsch<[email protected]> wrote: > > > > > I'm trying to understand common practice for including bittorrent URLs > > > > in a metalink, either with version 3.0 or the IETF draft. > > > > > <file name="example.file"> > > > > <size>XXXX</size> > > > > <verification> > > > > <hash .../> > > > > </verification> > > > > <resources> > > > > <url type="bittorrent">http://www.example.com/example.torrent</url> > > > > </resources> > > > > </file> > > > > > This makes sense, if each file has its own torrent. However, Fedora > > > > and other torrent generator persons don't always do this. Instead, > > > > they will have multiple files inside the torrent: > > > > > {'path': ['Fedora-10-x86_64-DVD.iso'], 'length': 4172283904L} > > > > {'path': ['SHA1SUM'], 'length': 788} > > > > > In this instance, the metalink for the Fedora-10-x86_64-DVD.iso that > > > > MirrorManager publishes has direct FTP/HTTP URLs to that ISO, and the > > > > <verification> section has info on this single file. > > > > > But this single file isn't published in its own torrent, it's in a > > > > torrent with those multiple pieces. The whole <verification> section > > > > then is either meaningless, or would provide incorrect information, as > > > > compared to the torrent URL. > > > > > Likewise, the CD downloads for the multi-CD set includes direct > > > > HTTP/FTP URLs to each of the CDs, but the torrent includes all of them > > > > in a single torrent. > > > > from what I remember when this came up before, the filename in a > > > multi-file torrent should match the filename in the metalink (here > > > <file name="example.file">). I know this isn't too flexible but I > > > think it can be made to work for most cases now. > > > > Tatsuhiro, any ideas for improvements? perhaps a file or files > > > attribute for bittorrent URLs? > > > > > Is the <verification> section completely ignored when torrents are > > > > used, and instead the torrent metadata used? If so, can that be > > > > documented in the specification? > > > > Tatsuhiro said aria2 behaves in this way: > > > > "The verification section is ignored if torrent is specified, either > > > single- or multi- file torrent, because .torrent file has piece hash > > > and they are enough to validate the integrity of file. > > > I'm not sure this behavior is documented or not." > > > > this becomes tricky - which is "authoritative", the metalink or the > > > torrent? linux distros probably roll their own, both torrents & > > > metalinks, so this isn't a problem. but others might not have control > > > over both. > > > > then, basically all metalink clients will do full file checksum > > > verification. but few do chunk checksums, few do mirrors and torrents, > > > even fewer do both. > > > > for instance, if DTA did chunk checksums, it still probably won't > > > support torrents any time soon. > > -- > (( Anthony Bryan ... Metalink [http://www.metalinker.org] > )) Easier, More Reliable, Self Healing Downloads --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Metalink Discussion" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/metalink-discussion?hl=en -~----------~----~----~----~------~----~------~--~---
