Hi,

I've been making a few test and I've found, that if I create a trackerless torrent with KTorrent, then I can't open it with the mainline bt client - error pops out sayng that it's "not a valid bencoded string", so I've wrote a little Python script using modified by me (added printing debug info) bencoding decoder shipped with mainline and this is result (those strings before exception is my dbg info):

Code: Select all

athantor@athantor:~$ ./be.py test.torrent
None >= nodes = False
nodes >= comments = True
Traceback (most recent call last):
  File "./be.py", line 38, in ?
    main()
  File "./be.py", line 34, in main
    decode()
  File "./be.py", line 27, in decode
    print Bu.bdecode(open(fs, "rb").read())
  File "/usr/lib/python2.4/site-packages/BTL/bencode.py", line 74, in bdecode
    raise BTFailure("not a valid bencoded string")
BTL.BTFailure: not a valid bencoded string
athantor@athantor:~$


we see that string 'nodes' is bigger than 'comments' (btw, in quoted below spec there is no "comments" defined, only "comment" - is this ok?), but:

spec wrote:Keys must be strings and appear in sorted order (sorted as raw strings, not alphanumerics). The strings should be compared using a binary comparison, not a culture-specific "natural" comparison.

and I think that this is the cause of the error.

I'm using BT 5.0.3 and KTorrent SVN614340.
Sample torrent.

Best regards,

One of those stupid requirements for bencoded stuff (don't see much use in sorting it)

Anyway, we'll fix it.

Theres one small, SMALL reason to have the keys sorted, using a binary search on the keys.

But thats pretty silly, might as well load it into a proper hash type variable/class and let it deal with the data.

The requirement for the sort is there primarily for calculating a proper infohash for the torrent consistently. Enough information that is used in the bittorrent protocol is sort-sensitive enough that requiring the sort be a specific order does make sense.

You don't want two otherwise identical torrents with the "pieces" and "piece length" values swapped within the info dictionary, because that would generate two separated swarms.

There was a discussion about a bug in the sorting algorithms in VB.Net and C# in relation to bencoding on the ibiblio bittorrent mailing list. (Starting message in the discussion thread)

Ah yes.. I had forgotten about that. Back when I wrote some bencode/torrent code I had to figure it out.

DreadWingKnight wrote:You don't want two otherwise identical torrents with the "pieces" and "piece length" values swapped within the info dictionary, because that would generate two separated swarms.

I guess that's a valid reason, but they could have just done it only for the info part of the bittorrent files,

they could have just done it only for the info part of the bittorrent files

Then you get messy special cased code. Might as well just generate the entire file the same way.

Tomasu wrote:

they could have just done it only for the info part of the bittorrent files

Then you get messy special cased code. Might as well just generate the entire file the same way.

Still, it was rather annoying when I added DHT, and nobody was responding to my pings.

I have to admit, the protocol and format wern't the best thought out...