I feel so used ...

[nicke2323]

I've been downloading a 14 GB torrent off a public tracker for a week-and-a-half, and I'm at 35% completed. There are 10 peers and 1 seed (pretty much the same guys have been on all the time). I'm the only one using µtorrent, everyone else is on Bitcomet. My ratio for the torrent is about 3.5. Individual ratios for the peers are all above 2, even though almost everyone has completed significantly more than I have.

This is a bit unfair, but I can live with it I suppose. However, I'm getting concerned that these guys will drop out once they complete and leave me stranded. I wish there was something I could do to speed things up.

But there's one guy who really pisses me off. My ratio with him is about 2000 (no, I don't mean 2.00). He is taking up a large part of my upload bandwidth and giving nothing back in return, even though he has completed 70%. Is there nothing I can do to shut him out, but still stay connected to the rest?

Many private trackers have banned Bitcomet, but these leechers remain at large on the public trackers. I understand and support the notion that µtorrent should stay clean and never play nasty. I know this is a long shot, but perhaps it would be possible to reach an agreement with developers of other bittorrent clients to adopt mild anti-Bitcomet measures? Nothing serious, just discourage them enough so that cheating doesn't pay.

[Moody]

Nick I know how you feel. When I compare uploads and downloads I sometimes wish uTorrent didn't play with such a straight bat, uploads are nearly always higher than downloads.

If I were you on that particular torrent I would even things up a little and fire up Bitcomet .60

Edited typo

[splintax]

Well, kickbanning won't happen. You can however, take that peer's IP and add it to PG/similar IPfilter software or ipfilter.dat.

As for the anti-BC measures, read these threads:

http://forum.utorrent.com/viewtopic.php?id=3531

http://forum.utorrent.com/viewtopic.php?id=3162

[Switeck]

Neither banning all the BitComets (who would you download from then?) nor de-priortizing your upload to them (since they're all BitComet, your upload to them would be relatively equal as it was before!) would help.

However my other idea might -- snub hostile behavior regardless of client id. Then the 1 super-leechy BitComet would get snubbed and STAY snubbed. The other BitComets might get snubbed for cheating from time-to-time but their optimistic unchoke and regular upload slots would get them unsnubbed pretty quickly since the torrent has only 10 peers. (1 bad one, you, and 8 others.) Unfortunately, my idea is only a pipe-dream now.

Banning the 1 super-leechy BitComet client is a must if you want to complete that torrent at all!

The 8 other BitComet clients are going to be VASTLY less likely to upload to you if the majority of your upload bandwidth is going to that 1 badguy.

We shouldn't HAVE to micromanage µTorrent or cheat via another program to get fair results.

[Harry Poppins]

If you're using a software firewall, you could just block his IP if you don't want to upload to him.

[Dark Shroud]

I would have started using BitComet, that's what I keep it installed for. }=)

Anyway, just ban his IP through your firewall as Harry said. This is why I like BitComet's temporary peer banning options. "5 minutes," "15 minutes," 30, 45, etc..

Hmm, maybe instead of an option to ban a peers for a period of time µTorrent should give an option to "manually choke" a peer for periods of time.

[Ultima]

Choking would be more-or-less the same thing as banning... you end up not uploading to the selected peer, and that can and will lead to wider abuse than without.

[splintax]

Manually choking leechers hey? Sounds like fun...

[Firon]

Azureus had an option once, and they removed it. Too much abuse.

[Switeck]

Manually choking leechers hey?

i just realized...this seems like a serious failure. Shouldn't the AUTOMATIC choker in µTorrent already prevent this.

(I've heard the automatic choker kicks in if someone's uploading less than 0.5 KB/sec to you and/or ignores your upload requests.)

[Nefarious]

0.5kB/s ? i dont like the sound of that, 0.5kB/s could be a lot for a lot of people

[Switeck]

0.5 KB/sec is as low as an upload slot should go.

Any lower and it's violating BitTorrent's protocol.

MTU / packet sizes are typically 1300-1500 bytes on broadband connections. So an upload slot running at 0.5 KB/sec is sending less than 1 packet per second.

This is why µTorrent started ignoring too-high upload slot settings...even though with too many torrents running at once it's still possible to cause overloads.

[Firon]

you don't have to send a packet that's the same size as the MTU, you can send a smaller one

[Switeck]

Yes, smaller packets are not only probable but also preferable with lower speeds.

However it gets stupid to send file piece packets that are >25% overheads.

[anoxan]

still though, it sounds like the auto-choker isn't working right..

.5kB/s is low for a 28.8 connection, nevermind a 56k+ connection

I've had this happen to me numerous times, and I don't think the auto-choker ever kicked in..

so does it really work?

[habibalby]

Even me having the same problem I beleive. I was downloading a file that has got many seed, Now the Seed is 0 of 0 (0 in Swarm). Peers 15 of 25 (35 in Swarm).

What to do in order to complete the file? It stopes @ 88.1 % .

Any idea ?

Thanks,

habibalby

[Firon]

That means there's no seeders in the swarm. Gotta wait for one to hop back on.

[habibalby]

Now this happening since almost 1 Week

[Dark Shroud]

Wait and hope, maybe see if the tracker has a forum that you can request a re-seed on.

[habibalby]

Thanks mate, gonna check this out.

[Switeck]

I've had this happen to me numerous times, and I don't think the auto-choker ever kicked in..

If there even is a working auto-choker... I think this BitComet is cheating it using the fast-reconnection trick. µTorrent repeatedly treats it like a "new peer" that needs to be uploaded to so it has something to share.

That's my best guess.

Only Firon or better yet ludde can answer the cause of this mystery.

[anoxan]

well, if that's the case, I'm gonna have to re-enable my ipfilter and do things the old-fashioned way.

any chance of an auto-ban (maybe temp ban) for clients that do that fast-reconnection trick? if someone disconnects and reconnects 3 or more times a second, it's happening for a reason and should be stopped.

it's not selective, but it could help.

[linx05]

I've had this happen to me numerous times' date=' and I don't think the auto-choker ever kicked in..[/quote']

If there even is a working auto-choker... I think this BitComet is cheating it using the fast-reconnection trick. µTorrent repeatedly treats it like a "new peer" that needs to be uploaded to so it has something to share.

That explained that trick to me. Thanks mate.

[Switeck]

any chance of an auto-ban (maybe temp ban) for clients that do that fast-reconnection trick? if someone disconnects and reconnects 3 or more times a second, it's happening for a reason and should be stopped.

I suggested this awhile back:

BitComet cheats, so µTorrent should IGNORE it!

http://forum.utorrent.com/viewtopic.php?id=3531

it doesn't even ban the reconnecters, just snubs them...and unsnubs them when they upload anything to you. Far as I can tell the idea was shot down as "cheating".

[chaosblade]

Some kind of anti-flooding measure could be done, indeed. But i dont think it reconnects THAT fast, so its not easy to diffrenciate it from other connects.

Maybe something along the lines of temp banning if the same IP reconnecting a few times in the same 1mins\2mins\5mins (delete the unneccesery) after at least one of the attempts was succesful (so we wont ignore people with some network problems mistakengly).