Is this peer leeching from me?

[ady4um]

So here is my situation. I am seeding a multi-file torrent for several hours now. This is the only active torrent, and I have 100% of it (not just uploading, but actually seeding). So my whole upload bandwidth available for ut is currently dedicated to this job.

After several hours, I see 1 peer in the peers tab who received from me at least 13% of the whole torrent's size. This peer has received more than 90% of my upload since I started seeding this torrent. Since the time I started seeding, the % of the torrent (in peers tab) this peer has, hasn't changed more than 1%, while as I said I already transfered more than 13% of the torrent size to him.

In other words,

% he had when I started seeding: about 6%

% he has now: about 7%

% I sent him: about 13% of the torrent size

while most of my seeding goes to him (more than 90%).

Shouldn't I be seeing about 19% (6+13) *at least* in the % column in the peers tab?

I wonder if he is doing something with the pieces he receives, or actually he is not receiving anything even when my ut sees like he is?

[kurahashi]

If this is multi-file torrent, then I bet this "leecher" is downloading and consuming files more or less sequentially.

[ady4um]

Well, it may be so, but I can't prove it with my peers tab. Moreover, for the purpose of knowing if he is a leecher or not, his sequential downloading should be more or less irrelevant. I mean, if he is downloading 1 file of the torrent and leaving it there for others to seed while downloading another file from the same torrent, the % I see in my peers tab should be growing anyway. The fact (?) that he is hurting the swarm by dl'ing sequentialy - as you suppose - is close to irrelevant to this issue. I would expect ut (and the protocol) to "know" he is not the "best" peer to share with.

But, if he is downloading 1 file of the torrent at a time, and somehow not leaving it to upload, then he is indeed a pure and simple leecher (selective dl'ing AND not sharing).

Kurahashi, I really appreciate your response, but I would like to get something more than "a bet". I am trying to know what this differences in the % means, not just for this specific peer but also to next possible cases.

Should I let him leech, if indeed this is what he is doing?

Could be another explanation for the difference in expected %?

[kurahashi]

I said he is probably downloading and consuming these files. Typical case are TV series packs. To consume I mean - to watch it and then delete it. Does doing so make you automatically a leecher? Not necessarily. All depends if you keep your ratio high enough (at least 1.00).

And the reason he gets almost 90% of your upload is because there is good network connection between you, while other peers got worse.

[Switeck]

If there's more than 4 connected peers to you for that torrent...that are trying to download from you...

add this "leech" peer to your ipfilter.dat.

Not for leeching, but for misreporting percentage complete.

And if he is watching then deleting the files, he's burning your bandwidth but not propagating the files to everyone else because he's deleting them! Hard to be a nastier leecher than that.

He wants those files, he can download from other peers where he's forced to tit-for-tat instead of something-for-nothing from the seed.

Delete that ip about a week later. He should be done by then.

BTW, is this peer perhaps using BitComet, BitLord, or BitSpirit?

Those wannabe BitTorrent clients have sequential download ability.

If they're older, they DON'T support encryption either (check flags).

[ady4um]

Strickly speaking, I think you are right. If he is mantaining his ratio over 1, then I shouldn't think of him as a leecher.

In practice, if he is "consuming" those files so fast that his % is not even raising more than 1%, and he is dl'ing sequentially, then I think (or assume) he is mostly not really sharing "as much as he is receiving". I mean, I think the swarm would be better without him, in the sense of average speed and other parameters. I'm not saying slow peers shouldn't be part of the swarm, but every peer should at least *try* to give back. According to the supposition of sequential dl'ing, he is not necessarily a low speed peer, but he *is* making the swarm slower. Additionally, if he is just leaving 6 or 7% of the torrent intact, he is sharing not *the torrent*, but just some specific pieces, most probably just the first file.

But this is just an assumption. I think I can't really say much about him just from seeing his % not growing, even if I uploading to him more and more.

I stopped ut for several hours. When I started ut again, I went back to seed and he is still there, this time with 13%. So now I have the same questions I had before, plus 1.

Could this be some kind of bug in ut 1.8? I don't think every little thing that doesn't work as the user expects is a bug, but asking doesn't hurt, right? Since I've been seeing other strange things in ut 1.8 (e.i., things I couldn't figure out), this could be also just one of those, couldn't be?

I'm still not sure if he is a leecher, and if I should ban him.

[dbc]

There are some clients (such as Opera) that don't always seem to update their percent complete unless you stop/start (reconnect to) them.

I believe that other clients (such as azureus) have the ability to block clients of a particular type if that's what you chose to do. Personally I think it's a waste of time.

I believe that everything is probably working fine and that there's no reason to over-analyze what uTorrent is doing -- just let it run and seed.

[Firon]

µTorrent can also not send have messages to seeds, giving you behavior like this. Just ignore it.

[ady4um]

Thank you all for your answers. I really appreciate it.

@Switeck, I didn't see your post when I wrote my last one. I banned him and now I'm seeding to others. Yes, I have more than 4 peers connected. His client was Azureus 2.5."some-number-I-don't remember".

@dbc, I don't want to exclude anyone just because his choice of client. Even if they use clients as the ones Switeck mentioned, I don't think I know/understand enough to select good-behaviour peers. I don't want to micromanage, but this case was too "shiny" not to see. About over-analize, well, I'm just trying to lern. It is not so easy nor fast for me to download and complete a torrent because of my ISP throttling, so when I get to seed, I would prefer to upload to peers who would tit-for-tat. If by some miracle I get to download much faster than my upload speed, I even have to wait until I get to my seeding goal, so I can start dl'ing a new torrent. Not all users are doing this tit-for-tat. Before this case, I even didn't use ipfilter.dat. And, most of all, I'm trying to lern for future reference, as I said.

BTW, Is there any way to *discover* if a peer is misreporting his complete %? I don't know how they do it using a "regular" client - and I'd prefer this kind of tricks not being published

@Firon, if I stop and start seeding the torrent (i.e., disconnect from the swarm and reconnect again), is it possible for me to discover if your suggested behaviour is actually the one happening?

Oh, and about ut 1.8, I thought it might remotely be some strange display behaviour because I am seeing different numbers displayed, e.g. sometimes the peers column in the jobs list doesn't match with the peers reported in the trackers tab (currently, I'm not using PEX, Local Discovery, nor DHT in the torrent where this mismatch occurs).

Again, thank you for your feedbacks.

[Firon]

Yeah, stopping and starting the torrent should show you an updated value from the client.

[Switeck]

It is a good idea to use Peer Exchange whenever you can. This allows peers and seeds to discover each other quicker, ESPECIALLY important when dealing with high firewall percentages.

Of course Peer Exchange won't work on private torrents, but that's no reason to have it disabled all the time. It doesn't "cost" anything to have it enabled if it's not being used...unlike DHT.

[ady4um]

@Switeck, what do you mean with "use Peer Exchange whenever you can"? I mean, is there any rule or some suggested situation where you *can't* use it?

In my case, I have severe problems to mantain a steady connection - even though I already tried tweaking almost any combination of parameters -, so usually I disable everything that generates overhead, so to make real data bandwidth more effective. Sometimes I just try Peer Exchange to see if I can improve my speed, or at least to make it steady. Usually after several hours of using it I can't see an improvement. I don't really know if this is wise, but I couldn't find anything to improve my situation. In my case, not using PEX has nothing to do with private tracker (the torrent we are talking about is not from a private tracker).

I just mention not using those methods because of my comment about "strange" discrepancies in 1.8 display. The same example I wrote about (peers number in the jobs list does not match the peers number in the tracker tab) was also mention in the announcements 1.8 beta thread by "emc", and Firon said one is the tracker's scrape, the other is ut's estimates. Well, as I said, this sounds strange to me - a simple user, not an expert - because I would have thought ut receives the info from the tracker. I would understand such a discrepancy if I were using PEX, DHT or any method besides the tracker, which I didn't. That's why I mentioned it.

About this thread's topic, was this peer leeching from me? Well, according to Firon's answer, I can't really say. If I re-connect to him, I can see his % higher than before, but still less than what I myself sent him already. It's hard for me to believe that so much data is not really getting to him inspite my ut says I sent it, but since he is using a "good-behaviour" client, I just can't really *prove* if he is a leecher or not.

[thelittlefire]

Peer Exchange and DHT are disabled in the client when private=1 exists in the torrent. Number discrepancies will happen time-to-time mainly due to the fact that even if a tracker purged data in the peerlists minute-ly there would be stale clients in the list. uTorrent's window keeps track of peers it KNOWS about... the only time it's not "realtime" data would be when you have bt.scrape_stopped enabled in the Advanced screen.

If you're worried about your client's behaviour you could always try setting up a second "testing" client with /RECOVER on a different port and see if the 2nd client says YOUR FIRST client is sending bad data :/ There are options in many clients (including uTorrent) which allow the client to NOT tell the seeder what pieces you have (send_have_to_seed) which is likely responsible for the discrepancy if you're not sending bad data yourself.

[ady4um]

@Thelitlefire, thanks for the info. I don't see the need of not sending the %. If this can save some bandwidth, how much could it be? Does this setting benefits someone? I suppose it also influence on the estimation of the swarm's availability.

About setting up a second client, it could be helpful to know if my ISP is having something to do. I know I have good data - forecing a re-check - but something (e.g. my or his ISP?) could be interfering. Since other peers are receiving the data fine (according to their % and the amount of data I'm sending), then I suppose both, my client and this other peer's one, are better without connecting to each other. In case he was receiving bad data from me, it would be better for him to receive it from others in the swarm.

Generally speaking, it would be interesting testing if I can send pieces to myself in an efficiently manner. This could be a way to test if my ISP is throttling by making good pieces turn into bad ones. Sadly, I have a contract with them for some more several months, so even this test won't be really solving my connections' problems. In time, it could help me decide leaving for another ISP though.