[bittorrent] How should .torrent files with unsorted info dictionary keys be handled

arvid at cs.umu.se arvid at cs.umu.se
Wed Jan 20 15:34:34 EST 2010


Quoting Alan McGovern <alan.mcgovern at gmail.com>:

> [...]
> So pros and cons:
> Approach 1:
> Pro: This approach implies that if an invalid bencoded dictionary is found
> it should be converted into a valid representation and used.
> 
> Pro: This should be relatively trivial for most clients to implement.
> 
> Con: The letter of the spec [2] says that we should always use a substring
> of the .torrent metadata. Strictly speaking this approach goes against the
> spec. However, we have to assume that when the spec refers to ".torrent
> metadata' it refers to *specification compliant* .torrent metadata. i.e. the
> keys in the metadata must be sorted for it to be considered valid .torrent
> metadata. Conversely, if the keys are *not* sorted then the data should not
> be considered valid .torrent metadata. If that's the case, then why are you
> generating a valid infohash from invalid metadata?
> 
> Con: You need a non-spec compliant way of decoding bencoded data.
> 
> Approach 2:
> Pro: You follow the letter of the bittorrent specification but still break
> the BEncoding specification.
> 
> Con: I'd argue that this is slightly more complex to implement as you may
> now need to double parse the .torrent file in order to generate the
> infohash. The first time you pass it through your bencoded data decoder to
> generate your in-memory representation. Then you have to parse the file
> manually a second time to find the start and end of the info dictionary and
> extract that substring.
> 
> Con: I'd argue that you're breaking the spirit of the specification again as
> you're now running under the assumption that invalid bencoded data is valid
> .torrent metadata and the spec doesn't explicitly allow this ;)
> 
> Approach 3:
> 
> Pro: Simplest to implement as you just have to make your bencoded data
> decoder spec compliant. Once this happens, the .torrent won't be loadable so
> that question of how to generate the infohash never has to be answered.
> 
> Con: It will render some torrents unloadable but those should be a very
> small percentage.

If you're talking about modifying the spec. Why not add:

Approach 4:

Modify the spec to allow unordered keys in dictionaries.

Con: All torrents will work as intended (presumably the unordered keys are
probably a mistake, and not a clever trick to make clients generate different
info-hashes).

Pro: some clients would have to be updated to be less strict on their input.

-- 
Arvid Norberg



More information about the BitTorrent mailing list