Metainfo File Structure - Parameters Influencing The Torrent Hash #

A topic for the (few?) people out there which would like to avoid as much as possible splitting swarms (and saving bandwith) when updating a *.torrent file...

The basic idea behind my question is how to best organize the data before creating a new metainfo file (the *.torrent file) so it may in the future be updated with (additional) data, without obliging the peers who had already downloaded a big chunk of it to have to redownload all again from scratch. Besides this information could also be very useful if someone wants to revive an almost dead torrent (swarm) by modifiying / updating and re-announcing the *.torrent file without changing the torrent hash in this procedure.

During the new torrent creation with uT (1.8.3) the hash will not be the same whether the option 'Preserve file order' is checked or not. I could not find any mention about this option in the help. What order exactly will be preserved or not? Why is the hash being modified based on this option? What are the parameters which must remain indentical to generate identical hashs?

The parameters I know already which will definitely modify / influence the hash number:

[ul][li]file name[/li][li]file (or directory) length[/li][li]piece size[/li][li]private torrent settings[/li][li]file order[/li][/ul]Thanks for any good input.

PS: Here a link which gives some information about this topic.

Thanks for the link DWK. I read the whole paper before already and I did NOT find the answer to my questions and that's why I posted here...

[EDIT]

I just did a little test and the result was interesting...

I created a metainfo file of the same directory with uT (with and without preserved order) and with Vuze and guess what... I became 3 different torrent hashes!! Looks like there are strongly enforced specifications...

The info IS in that link if you read carefully:

"info_hash: urlencoded 20-byte SHA1 hash of the value of the info key from the Metainfo file."

Fields of the info key are also listed. For multi-file torrents its: piece length, piece count, private flag, dirname, filenames, filesizes, filepaths and filemd5s (optional)

If any of these items is different (or in different order) between two torrents then the info_hash is different.

The only thing that would force users to redownload existing data is if you modify the source files, or intersperse new files with old files in the .torrent files (though this would only cause edge pieces to be redownloaded for those pieces shared by both old and new data).