BitComet cheats, so µTorrent should IGNORE it!

[Switeck]

Firstly, BitComet cheats:

1.BitComet incorrectly uses DHT on private torrents/trackers, even ignoring BitComet's user's settings NOT to if the tracker briefly goes down!

2.BitComet deliberately misreports upload and download amounts to trackers and seeds in order to get the "lion's share" of upload bandwidth from seeders.

(Others have said that using super-seed as a seeder often takes >200% of the torrent's size to create other seeds due to BitComet's cheating-by-default.)

3.BitComet disconnects and reconnects to download more than is fair via optimistic unchoke -- (which is meant to give new arrivals something to share. Sadly, Azereus is reported to do this too. Automatically droping working connections is hostile activity -- it creates lots of churn which costs extra bandwidth for trackers and peers alike.

4.BitComet seems to favor uploading to other BitComet clients, even when getting faster download speeds from other clients. The most extreme case was a private tracker/torrent on a huge college lan with "100mbps" connections -- the person who did this could download at >5mbps if using BitComet but only ~5-15 KB/sec if using µTorrent.

A ban on a particular BitComet version won't affect a new BitComet version that doesn't fix the problems, or client id hacks which spoof different client+version messages. It'd be an arms race of sorts, just like AV software having to identify ever-changing viruses.

A total BitComet ban would limit BitComet's author's incentive to remove the cheating, because even a noncheating BitComet version would still be partially banned till EVERYONE on µTorrent upgrades to a non-banning version.

Instead of banning BitComet clients, ignore them!

...by µTorrent doing a little "tit-for-tat": uploads from µTorrent to BitComet clients will always get upload bandwidth priority (High, Normal, Low) 1 setting lower than everyone else.

Also retain information about ALL connected and disconnected peers in a torrent. Then, don't treat reconnecters like "new peers" which deserve optimistic unchoke. Instead, snub them! The disconnected peer list could even be used by firewalled peers to quickly retry disconnected unfirewalled peers. (It does no good to try to connect to a disconnected firewalled peer.)

By targetting BAD BEHAVIOR, µTorrent could handle any client which does the same without additional code.

[DrS]

Before someone chimes in and says it's been asked before, it's not. It's not peer banning, and not client banning either.

Would this be an optional feature ?

If so, what would be its default setting, on or off ?

Would this be configurable, having the option to put in ID strings ?

[mrbraindead]

These BitComet users really start to anoy me.

I think the disconnects, reconnects und wrong upload/download ratio lead to the fact, that my utorrent client nearly uploads to bitcomet users only - 100 connects: 10 BitComet users.

Not a big problem, but i often get only half of the upload i gave as download back. This behaviour just started with version 0.6 of BitComet.

In Torrent-boards I read that many users just switched to bitcomet because of this "cheating" and in result better download speeds.

I hope a solution is allready in progress, dont want to lose any more upload to "cheaters".

Or in the worst case have to switch to bitcomet myself

sry for my bad english

[chaosblade]

Before someone chimes in and says it's been asked before, it's not. It's not peer banning, and not client banning either.

Would this be an optional feature ?

If so, what would be its default setting, on or off ?

Would this be configurable, having the option to put in ID strings ?

1) Probably, But i dont see this as ever getting implemented.

2) Off by default, one would reckon. Refer to point #1.

3) Not in a million years. Users should NOT have the option to 'administer' the swarm as they see fit.

[boo]

I can understand why people want to do this,

but ludde and the rest of us want people to choose µTorrent because its great,

not that they have been forced because µTorrent users are blocking Bitcomet for example.

[HoochieMamma]

The best thing we can do is convert all of our friends to use µTorrent (from BitComet) and tell them to convert all of their friends

[1c3d0g]

Yeah, once you start descriminating who should connect and who shouldn't, you're going down the wrong path. Leave that to private tracker admins to slug it out. Some of us still use public trackers, you know, and really don't care who is connected to us or not. :|

[dAbReAkA]

i use 3-4 trackers and till now 99% of who i've seen is a bitcomet or azureus user.. on the private tracker i use from total of 600 users (for now..) no more than 5-6 are using µtorrent, the others - bitcomet (all of them), azureus is only used on a linux based system

banning bitcomet will prevent me from using torrents.. who would i seed to? who would i leech from? bitcomet has taken over the world and that should change.. developing features which the user wants and other clients don't have will make them use µtorrent.. not just the small size. people say "my hard disk is big.. bitcomet wont be a problem, or i've got a solid amount of ram 40 mb wont be a problem too". keep working (there will be a huge effect soon)

[chaosblade]

And i guess they dont care it cheats to their benefit either ;]

[Switeck]

I am >*NOT*< asking for BitComet to be banned by µTorrent !

I am asking for BitComet to be treated not quite as badly by µTorrent as BitComet treats us!

Specifically, I am asking for 2 special things:

1.µTorrent doing a little "tit-for-tat": uploads from µTorrent to BitComet clients will always get upload bandwidth priority (High, Normal, Low) 1 setting lower than everyone else. This would mean if there is EVER any unused upload bandwidth and BitComet clients want to download from you, they get *ALL* the unused upload bandwidth. Even if there is a mixture of BitComet and other clients, BitComet clients that request torrent pieces can and will get upload bandwidth from you -- but only roughly 40-80% as much bandwidth as another other client all other things held equal. This "discouraging" of BitComet clients can be discontinued in future µTorrent versions once BitComet works in a less hostile and unfair manner. This would IMPROVE piece availability of torrents, (before BitComet clients were getting far more pieces than they could quickly share to others) thus benefiting all -- even ironically BitComet clients!

2.Also retain information about ALL connected and disconnected peers in a torrent. Then, don't treat reconnecters like "new peers" which deserve optimistic unchoke. Instead, snub them! Snubbing them would *ONLY* last till they upload to us. If they upload to us, then we can start treating them like any other BitTorrent client. As it is, every time a BitComet disconnects and reconnects, µTorrent feels "obligated" to drop a lot of its uploads to feed this "new peer" so the new peer will have something to share to others. But after retaining the information about peers, this "new peer" will be shown to already have plenty to share and µTorrent can concentrate on getting rare pieces of the file swapped. Most of this request is a fair interpretation of the BitTorrent protocol and need not even be viewed as an extension of it. If this is NOT done, BitComet could sabotage poorly-seeded torrents -- which is fair to NO ONE, not even other BitComet users!

By targetting BAD BEHAVIOR, µTorrent could handle any client which does the same without additional code.

I want to point out that BitComet is so HOSTILE that doing nothing causes many torrents to hopelessly die far sooner than they would otherwise. I do not see how that's good for anyone, EVEN OTHER BITCOMET USERS!

That is why I don't think request #2 should be optional, but it is ok if request #1 is optional.

[Animorc]

What wrong with having a perfectly clean client that treats everyone the same? There are assholes in the BitTorrent network and there will always be. Don't make all of us the same by treating some users "almost" as badly.

It's these arguments that started the whole thing about BitComet discriminating non-BitComet clients and I don't want to see µTorrent doing the same.

[Switeck]

I have already pointed out that BitComet is disobeying BitTorrent protocols ON PURPOSE to cheat. It should not benefit excessively from it at the expense of others. What's more, it benefits only the 'early arrivals' to a torrent that are running BitComet -- possibly at the price of killing the torrent when they leave.

Even though my request #1 does disfavor BitComet, my request #2 does NOTHING to it that is unfair.

So if you don't agree the NEED for my request #2, what you're saying is it's fair to cheat everyone in a torrent -- even if it means people after you cannot download the torrent to completion.

My request #2 does not specifically target BitComet, instead it targets ACTION taken by a bittorrent client. Any client that does that behavior will get the same fair treatment.

[Animorc]

I know what you're saying. I took the time to read through the thread.

I just find µTorrent to be a nice and clean client. Making it cheat in a way similar to BitComet's is no solution. I never said it's fair to cheat, I said there are assholes that will keep using the clients that fits their needs, and noone can stop them from doing so.

Cheating only brings further cheating, and it's not going to stop because one client implements a forced "bitiqette"-feature.

[Switeck]

Ok, I'll say it again:

forget request #1, as it is a cheat.

request #2 is not asking it to cheat, just to follow CLOSELY the BitTorrent protocol.

[cTn]

i never now this about bitcomet... FU bitcomet

[Animorc]

request #2 is not asking it to cheat, just to follow CLOSELY the BitTorrent protocol.

My definition of strictly following the BitTorrent protocol is treating everyone the same way without thinking about how much this or that peer has downloaded/uploaded.

The part about only connecting to open peers (not firewalled) might be good for those who are behind an uncontrollable NAT/firewall though.

Edit: I didn't know that new peers automatically get optimistic unchoked, but yes, continously reconnecting peers don't deserve that then.

[dAbReAkA]

that's not a problem of µTorrent.. it's a problem of the tracker admin.. if he thinks that bitcomet is disobeying bittorrent protocols on purpose he should ban bitcomet..

[Switeck]

My definition of strictly following the BitTorrent protocol is treating everyone the same way without thinking about how much this or that peer has downloaded/uploaded.

That is not following BitTorrent protocol, because BitTorrent protocol uses a 'tit-for-tat' like behavior BASED ON whether a peer has uploaded/downloaded from you. There is some flexibility in this, because you can increase or decrease your upload slots and upload bandwidth manually -- without causing an equal ratio change in download speeds. If a client repeatedly reports uploading far more than others, then it will be given a bigger chunk of a seed's upload bandwidth in return. It doesn't take more than a couple hit-and-run downloaders using BitComet to sabotage a slow+small torrent. I cannot see how this helps anyone other than the leecher.

that's not a problem of µTorrent.. it's a problem of the tracker admin..

It become everyone who is in a torrent's problem when a torrent loses seeds due to BitComet cheating. Since BitComet is so popular, this is too commonplace to ignore.

Also, since the results are so hostile to others on a torrent, it doesn't even MATTER if BitComet is cheating on purpose or accident.

A GOOD BitTorrent client has to be able to handle hostile activity automatically WITHOUT user or tracker admin intervention. We shouldn't HAVE to micromanage µTorrent or cheat via another program to get fair results.

[nightshifted]

Switeck, you didn't mention that BitComet hammers trackers with multiple announcements, overloading them, demanding more than their share of tracker attention, and pulling attention away from users of other clients. Let's not leave that out.

[Firon]

I love BitComet. It's the best client ever.

[BlackLion]

Yeah, once you start descriminating who should connect and who shouldn't, you're going down the wrong path. Leave that to private tracker admins to slug it out. Some of us still use public trackers, you know, and really don't care who is connected to us or not. :|

Very true. And well said.

Switeck, you didn't mention that BitComet hammers trackers with multiple announcements, overloading them, demanding more than their share of tracker attention, and pulling attention away from users of other clients. Let's not leave that out.

But that is what made the Comet so GOOD!!

[jroc]

2.Also retain information about ALL connected and disconnected peers in a torrent. Then, don't treat reconnecters like "new peers" which deserve optimistic unchoke.

I always wondered about this feature in Az. It was called "save peer connections for quick reconnects" and u can put in how many peers to save. I always thought it was about me keeping fast speeds. Never knew it coulda been used as security for cheating clients.....

[mrbraindead]

Yeah I tested on open torrent trackers today, and on some trackers (I think they just are fast enough) BitComet users connect 5 - 10 times per SECOND to my utorrent client(shown in log).

Every BitCoemt client does so, while no other client connects more than 2 times in 10 minutes.

The ability to take any advantage of reconnects should really be stoped imediatly. Not absolut, but in a not disadvantaging way to other clients, if possible.

[bleh]

It's interesting to note, that both Switeck and DrS seem to be sharing the same ideas, and apparently sees fit to create two threads that deal with the same issue.

(read the stuffer thread)

But, let's jump into the fray once again then!

Switeck, do you have any substanstial proof that verifies your claims? Because if you don't,

I don't see any reason I should trust your words.

You seem to hate bitcomet with a passion even I don't have, sure I'd love a line of code that would screw up every leechers life, but *not* at the cost of my favourite client becoming banned aswell!

Because, you see ..adding specific rules per client will most likely get this client banned from any major trackers, as the tracker owners would think that it's not treating every peer equally!

Do we want µTorrent to become banned aswell?

[sixshot]

Pasting my words over to here... should people only keep tabs on this thread...

While idealistically it's not a bad idea to do so, it's generally not a good one considering how BT works. Do note that BitComet does work fine on a basic level, provided the users configure the client perfectly -- keyword 'perfectly'. So ignoring Comet users on a limited scale would be bad for the BT network as a whole. The main thing regarding BitComet is to get the devs to fix the client and make it adhere to formal and informal standards. Otherwise, in all fair game, BitComet is as good as a client as the next one (of which it all boils down to user preferences). Peer banning based on client criteria shouldn't be there on any level, no matter how bad a client is. If on a basic level that the client works, so be it. And no client should discriminate against others who have a different client, even if the client is broken in many ways.