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. > > "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 -~----------~----~----~----~------~----~------~--~---
