Interpersonal Relationship of I2PSnark is not upto the mark

[reverb]

Interpersonal Relationship of I2PSnark is not up-to the mark.

I have crossed 3.5 ratio in qBitorrent & 2.5 ratio in BiglyBT from a total of 12 peers.

This should not have happened!!

Had this ratio [total of 6] happened on clear-net, I would have definitely shared the torrent to more than 40 people [partly] at the very least.

I think that all I2PSnarks are just leeching from a "singular seeder" and not sharing files amongst themselves, as efficiently as they should do.

I think this is the reason that I2PSnark feels very heavy, slow or clunky on resources/computer & torrent clients like qBittorrent, Tixati feel very light & efficient in comparison to I2PSnark when torrenting done on I2P Only-mode. Heck, even BiglyBT which is world famous resource hog, has always been better in efficiently torrenting over I2P since long.

And NO, it is not about having or not having I2P DHT/PeX in your torrent client. BiglyBT has had both of them since long & still outperforms I2PSnark.

I am not a developer so I cannot pin-point the exact issue in code, but this has been my observation - torrenting over I2P over the years.

Please, look into it. Thanks.

[cumlord]

snark follows a basic tit-for-tat, if it's receiving a lot from a seeder it seems to just take it and doesn't spread around as much as it should. It follows bep in the sense that the logic is very basic, zzz is the one to ask probably. Think some of it came from klomp https://www.klomp.org/snark/

i've reduced ratio a lot with super seed mode in bigly to sort of shepherd the snarks, especially for large initial swarms. you pretend to be a normal peer and trick the snarks to download more rare pieces by informing them you only have that piece, then wait to see it was actually distributed to other peers. I've also done some throttling because i know if snark is downloading super fast like if someone is using less hops, they're just greedily taking it without uploading much and could just as likely hit and run (honestly more likely, imo) so that all becomes waste

another strategy i've been using more often is to use many snark instances to attempt to saturate a larger swarm and then stop them as seeders become available so it shifts to them. the automation on it is glitchy though.

but, all just workarounds. i think it's something that could take a lot of work

[anikey]

I've noticed a similar thing before, except that there was a single (snark) downloader in my case.

http://i2pforum.i2p/viewtopic.php?t=1289

I was thinking - maybe snark requests the same piece from multiple seeders?

[reverb]

but, all just workarounds.

That is what I am saying, we can have multiple work around, but these workarounds should not needed because all torrent clients have solved these minor issues.

Either way, I'm hopeful that developers will investigate resolving minor BitTorrent and torrent client bugs as a result of increased public knowledge and renewed interest in I2P following lock-down.

[reverb]

I've noticed a similar thing before, except that there was a single (snark) downloader in my case.

http://i2pforum.i2p/viewtopic.php?t=1289

I was thinking - maybe snark requests the same piece from multiple seeders?

When it comes to download - I have another issue with I2PSnark, specifically, in the case of a single downloader.

It just does not maintain peer connections for more than 30 seconds or more. Goes into oblivion >> comes back >> rejoins >> downloads for 30 seconds >> goes into oblivion again.

This continues and the file that should have been downloaded within few hours [even with slow I2P speeds] takes days or weeks.

Here, comes the more irritating thing :- the moment the another leecher joins the torrent swarm >> the first leecher suddenly starts to behave like a good student in front of a strict teacher >> maintains connections for hours >> downloads with decent speeds.

But the moment, new leecher is gone then this student again starts to become a delinquent again. Very irritating.

[cumlord]

i'm suggesting that i don't know if this is a trivial/easy fix for snark. the source code is kind of scary, and it has some very old parts

[reverb]

i'm suggesting that i don't know if this is a trivial/easy fix for snark. the source code is kind of scary, and it has some very old parts

Yes, I understand & I am patient with I2PSnark. That is why I said, I am optimistic about future developments.

[zzz]

I don't think there's anything fundamentally broken about i2psnark, but it doesn't do superseeding.

Appreciate the feedback but there's nothing actionable above, just handwaving about how it seems like it should be faster or better. I work on snark when I can but of course router things take higher priority. We do have some good stuff coming later this year, including integrated postman search and UDP announces.