Relax metadata size check for magnet links & I2PSnark peers

[mlt]

It seems that I2PSnark is broken ❔ as it sends total_size equal to size and not to overall metadata size declared in extended handshake.
Ditching corresponding check makes everything work.
I don't know if there are other clients with this behavior.

[arvidn]

hm.. using the metadata-extension with such peer seems suspicious. How would libtorrent know how many metadata blocks to request if it doesn't know the size of the metadata? which scenarios work exactly when you remove that check?

[mlt]

It seems redundant to send overall metadata size along with a piece. We do know the total metadata size from extension handshake.
It works in client_test when hitting m and pasting i2p magnet link. 99% of clients are I2PSnark. I think Vuze uses same libraries.
It looks like I2PSnark flipped around enforcement checks 😱

[str4d]

Reply by zzz (I2PSnark maintainer) from our corresponding ticket:

easy fix, will sneak it into .21, awaiting confirmation from parg re: vuze over on zzz.i2p

(Awaiting confirmation that Vuze agrees I2PSnark is broken, and that Vuze can handle it if I2PSnark's behavior is changed.)

99% of clients are I2PSnark. I think Vuze uses same libraries.

vuze is over half the clients, and it doesn't use the snark libs

[mlt]

There are still clients out there with such behavior and probably they'll stay around for a long while. I'm not sure what are the odds of waiting for a natural migration. It is not that many i2p peers anyway. There is a very good chance that those in a particular swarm would use an outdated version. I'd still remove that return statement while adding a todo entry like "reintroduce me in mid. 2016" :-)

[arvidn]

is there any way to identify the version(s) of snark that has this behavior and just disable the check for those clients perhaps? There are a few other examples of hard coded behavior to deal with BitComet for instance. if I2PSnark sends a client name and version for instance, that could be used. Or if it sets the peer_id prefix.

[user2p]

qutoing i2p's lead developer:

Over at ​#36 there's questions about version fields and how fast snark clients will upgrade. We don't include a snark version for anonymity reasons. I2P users update pretty quickly due to automatic update; approximately 90% will be on the latest release within 6-8 weeks. But if Vuze ignores the value maybe libtorrent should too...

Anyway, very happy to see the recent activity on libtorrent i2p support.

[Falcosc]

Maybe we should close the ticket because I guess we don't want to put to much effort into the support of over 1 year old clients.