Change Details

The extension protocol handshake packet (BEP-0010) contains a dictionary with data like this: { 'm': {'ut_pex': 1, 'ut_metadata': 2}, 'p': 12345, 'reqq': 250, 'metadata_size': 12542, 'upload_only': '0', 'v': 'KTorrent' } The code that sends this packet (sendExtProtHandshake) is creating a bencoded dictionary with the keys in the order shown above. However, all bencoded dictionaries must have the keys *sorted*. For example ut_metadata *must* come before ut_pex. This happens to work because BitTorrent clients are liberal in what they accept, but a client strictly implementing the spec would likely refuse KTorrent connections. A known consequence is that RTorrent was unable to get .torrent files from KTorrent when given a magnet link (BEP-0009). Strangely, RTorrent doesn't like the unsorted dictionary when it's getting torrent metadata files and drops the connection after the handshake, yet it accepts the same handshake when doing a normal BitTorrent connection to exchange data. This bug was introduced with the first part of the magnet implementation (ktorrent.git d57e8ed869, SVN 1052409, nov 2009). This commit manually puts the dictionary entries in order, fixing the incompatibility with RTorrent.

The extension protocol handshake packet (BEP-0010) contains a dictionary with data like this: ``` { 'm': {'ut_pex': 1, 'ut_metadata': 2}, 'p': 12345, 'reqq': 250, 'metadata_size': 12542, 'upload_only': '0', 'v': 'KTorrent' } ``` The code that sends this packet (sendExtProtHandshake) is creating a bencoded dictionary with the keys in the order shown above. However, all bencoded dictionaries must have the keys *sorted*. For example ut_metadata *must* come before ut_pex. This happens to work because BitTorrent clients are liberal in what they accept, but a client strictly implementing the spec would likely refuse KTorrent connections. A known consequence is that RTorrent was unable to get .torrent files from KTorrent when given a magnet link (BEP-0009). Strangely, RTorrent doesn't like the unsorted dictionary when it's getting torrent metadata files and drops the connection after the handshake, yet it accepts the same handshake when doing a normal BitTorrent connection to exchange data. This bug was introduced with the first part of the magnet implementation (ktorrent.git d57e8ed869, SVN 1052409, nov 2009). This commit manually puts the dictionary entries in order, fixing the incompatibility with RTorrent.

The extension protocol handshake packet (BEP-0010) contains a dictionary with data like this: ``` { 'm': {'ut_pex': 1, 'ut_metadata': 2}, 'p': 12345, 'reqq': 250, 'metadata_size': 12542, 'upload_only': '0', 'v': 'KTorrent' } ``` The code that sends this packet (sendExtProtHandshake) is creating a bencoded dictionary with the keys in the order shown above. However, all bencoded dictionaries must have the keys *sorted*. For example ut_metadata *must* come before ut_pex. This happens to work because BitTorrent clients are liberal in what they accept, but a client strictly implementing the spec would likely refuse KTorrent connections. A known consequence is that RTorrent was unable to get .torrent files from KTorrent when given a magnet link (BEP-0009). Strangely, RTorrent doesn't like the unsorted dictionary when it's getting torrent metadata files and drops the connection after the handshake, yet it accepts the same handshake when doing a normal BitTorrent connection to exchange data. This bug was introduced with the first part of the magnet implementation (ktorrent.git d57e8ed869, SVN 1052409, nov 2009). This commit manually puts the dictionary entries in order, fixing the incompatibility with RTorrent.