Jump to content

BitComet cheats, so µTorrent should IGNORE it!


Switeck

Recommended Posts

  • Replies 146
  • Created
  • Last Reply

To prove my point about at least 1 of BitComet's cheats...

This is BitComet's own message forums:

http://www.p2pforums.com/viewtopic.php?t=17442

[bUG] DHT connecting on private torrents

Ximp Posted: Tue Sep 27, 2005 12:09 am: "When I was seed a torrent on a private tracker I saw that there were people connected too the torrent that was not connecting from the site. When I clicked on the Tab "trackers" I saw that there were the sites tracker and DHT network. Why is this one activated when it shouldn't be?"

cjei Posted: Fri Nov 11, 2005 12:47 pm: "I'm using Bitcomet 0.60, I'm also having this problem...

DHT and peer exchange are disabled in the client and cannot be re-enabled (the check boxes are un-checked and greyed out).

But DHT is still returning peers and i'm still connecting to them !!"

sy5t3m Posted: Fri Dec 16, 2005 8:48 pm: "As for BitComet not connecting to DHT when it gets rejected by the [PRIVATE] tracker, that's nonsense. I just did it in under 2 minutes without even changing my hosts file. Tracker response: invalid passkey, connected peers: 2."

This problem has been known to the developers of BitComet as far back as March...yet still remains. BitComet is simply not trustworthy.

Link to comment
Share on other sites

After reading another thread where Switeck mentioned this, I think this is what he really means:

Instead of ban/ignore, he means that BitComet should get less bandwidth priority,

and I think he only means upload to BitComet client, not download from a BitComet.

Lets says your upload is caped on 24kb/s, while uploading to 4 peers,

3 are azureus and 1 is BitComet, µTorrent should do this:

Instead of uploading to 100%(6kb/s (24/4)) to BitComet,

µTorrent should instead upload to BitComet in 80%(4.8kb/s) for example,

then give the little remaning upload speed to the 3 azureus clients(1,2kb/s, 0,4kb/s per peer (1,2/3))

By doing this, maybe the idea of this feature isn't so bad :P

Link to comment
Share on other sites

That's why BitComet is banned from the private trackers now. And it's not a reason to make µTorrent specialized since those issues are to be fixed by the trackeradmins.

I'm still doing research on the other cheats BitComet is purported to doing. I'm finding so much it's hard to condense it down to something you can read quick.

Ok, here's something that confirms another cheat by BitComet:

http://azureus.aelitis.com/wiki/index.php/Super_Seeding

Comment: BitComet interferes with SuperSeeding?

It looks like BitComet doesn't play nice. BitComet clients disconnect and reconnect as soon as they have a piece downloaded from the Azureus superseed. Thus, Azureuse never gets a chance to determine whether the client is a big uploader. To make matters worse, for some reason Azureus will upload to the "new" peers before uploading to known big uploaders. It appears to me this has a pretty bad effect on the effectiveness of superseeding.

I get much better performance if I regularly kick and ban all BitComets manually.

Link to comment
Share on other sites

Looking through the forum listings for the BitComet user does explain why people are coming here to ask for BitComet features to be included in µTorrent.

Few of their requests for fixes are being addressed and it appears that BitComet's developer is content to leave the mods in that forum "swinging in the wind"

There were even posts saying that emails to the developer of BitComet are bouncing as his Gmail account is full. 1G of love letters perhaps?

Link to comment
Share on other sites

.... (It's also possible to fill it up oneself to *make* the messages bounce, though one could more easily just delete the account.)

That would be explicit indifference to user issues, instead of only the percieved one that seems to exist now.

I kind of feel sorry for many BitComet users.

Being kicked from their forum homes or forced to change clients.

Accused (and many see this as just accusation) of running a cheat client.

Ignored by their "God".

Forced to beg for feature changes here so they can still feel a sense of belonging.

Drop your shackles and chains, oh fettered and unwashed users.

Let your system resources run free. :)

Link to comment
Share on other sites

Switeck, this still doesn't prove anything, yes the DHT issue is proven, and yes the client has been banned from a number of private trackers because of it. But as for the rest of your claims, they're still pretty much just hearsay.

I'd consider that bit about BitComet sabotaging super-seeds pretty cut-and-dried. And that is undeniably bad.

That bit about DHT issues with private trackers was very well explained at the link I gave -- most other places just post FUD because they misunderstand the concepts or results.

Even posters on this thread had stuff to add which even if PARTIALLY TRUE means BitComet threatens the stability of trackers and torrents.

nightshifted said BitComet hammers trackers -- I've read the same thing elsewhere at least twice.

mrbraindead claims to have tested that theory and found BitComet users connecting at 5-10 times per second to his µTorrent client while NO other client was connecting faster than 2x in 10 mins. That's right on up there with Denial-of-Service attacks in intensity!

The scariest thing I've read is that BitComet is to blame for the >10% failure rate of chunk hashes. Possibly that's when it's set to only upload at 1 KB/sec across all its torrents, the downloaders get corrupted chunks as a result. This would be far worse than a pure leech if true.

Link to comment
Share on other sites

I am the AnimeJanai over at Box; BitComet users are generally a problem over there. People mention that tracker admins should take care of it by banning it instead of having other clients have features to check for cheating. Well, many public sites "cannot" ban them without going against the mandate of serving all users (good and bad) such as Box. If you used that tracker, you know how open it is throughout its history since 2003 when it opened. In many ways, we depend on the users to not upload to "cheaters". Azureus users often use that kickban feature for the BitComet users with bad Swarm ratio (yes, Azureus can show stats for the Swarm) and you can also display the source of the peer such as DHT, Peer Sharing, Tracker, Other (plugin).

I suggest that uTorrent users have a display of the source of the peer. This would show whether the peer came from the Tracker, from DHT, Peer Sharing, or Other (hacks, plugins, etc).

Also, Azureus users have been able to use the STUFFER plugin which is rules based. You can even script out your own banning rules with the Stuffer plugin or simply make it ban all BitComet 0.60. Of course, many BitComet users also have hack patches. I "see" a lot of hacks used. It's rather disturbing this trend of the Many taking advantage of those Others who do not cheat.

Link to comment
Share on other sites

The fact that BitComet abuses super-seeding, does not implement the multi-tracker spec in any proper way (µT doesn't follow it to the letter but it's NOT abusive, unlike BitComet), and does the DHT thing is reason enough to ban it. And these things are 100% proven. Everything else just hurts BitComet's case.

Link to comment
Share on other sites

@AJ: Doesn't µTorrent already show whether a peer came from a tracker or from DHT? If by Peer Sharing you mean the same thing as Peer Exchange, I believe µTorrent doesn't support that.

@Firon: How does BitComet screw up the multi-tracker spec? Here's a guess: does it announce to all trackers in all groups instead of picking one per group?

Link to comment
Share on other sites

Yeah, it announces to every single tracker regardless of if its in a group (which is what µT did many versions ago, got it banned from Oinks).

I believe it ignores the update interval set by the tracker too. And .59 reports stats incorrectly to the tracker. :rolleyes: the rollback to .59 on the BC site was worthless...

Link to comment
Share on other sites

Firstly a correction of this:

The scariest thing I've read is that BitComet is to blame for the >10% failure rate of chunk hashes. Possibly that's when it's set to only upload at 1 KB/sec across all its torrents, the downloaders get corrupted chunks as a result.

It's probably just duplicate data, not failed hashes. The slow uploaders take SO long to upload that fast uploaders upload over top of them. You get duplicate data but you don't have to wait for that slow uploader to upload whole chunks alone.

In many ways, we depend on the users to not upload to "cheaters". Azureus users often use that kickban feature for the BitComet users with bad Swarm ratio

And yet, I am suggesting doing the opposite -- instead of banning them we should upload to "cheaters" when we have any spare upload bandwidth.

Hostile clients can be EXPECTED in greater numbers as time goes on in spite of bans if there's any way for them to gain from our loss. So it is VERY important for µTorrent to be able to adapt to hostile clients and still follow the BitTorrent protocol.

After reading another thread where Switeck mentioned this, I think this is what he really means:

Instead of ban/ignore, he means that BitComet should get less bandwidth priority,

and I think he only means upload to BitComet client, not download from a BitComet.

Uploads to BitComet would be THROTTLED and BitComet's protcol-breaking upload requests would be IGNORED via 2 separate methods:

The 1st method THROTTLES BitComet by reducing its priority by 1. It would be almost unnoticeable -- as someone who bothered to do the math pointed out. This method to make many seeds quickly (by concentrating upload bandwidth on more swarm-friendly clients) is an upload 'end game' strategy just like 'super-seeding'.

The 2nd method IGNORES BitComet by AUTOMATICLY SNUBBING it for cheating. Since snubbing is based on behavior, changing BitComet's name wouldn't prevent it. The cheat is exploiting this often poorly-implimented part of the BitTorrent protocol:

"For optimistic unchoking, at any one time there is a single peer which is unchoked regardless of it's upload rate (if interested, it counts as one of the four allowed downloaders). Which peer is optimistically unchoked rotates every 30 seconds. Newly connected peers are three times as likely to start as the current optimistic unchoke as anywhere else in the rotation. This gives them a decent chance of getting a complete piece to upload."

By disconnecting and reconnecting, they get your BT client to cancel 1 upload (to someone who WAS uploading to you) and instead upload to them via optimistic unchoke with a 3 times likelyhood over ALL other peers. Your connection will probably continue that upload until they have "a complete piece to upload". (Note: a complete piece would be 1 chunk or 256kb-2mb.) Then if you don't CONTINUE uploading to them, they disconnect and reconnect again! The saddest part about this cheat: Because your BT client is cancelling its uploads to others, those others may snub your client and upload nothing to you in return, all the while you are uploading like crazy to BitComet clients!

However the PURPOSE of optimistic unchoking is to give "newly connected peers"..."a decent chance of getting a complete piece to upload". That would NOT apply to a reconnecting peer that you already know has rare pieces to upload! This is why it is important to retain disconnected peer info -- it prevents them from disconnecting and reconnecting and saying they're a new peer.

So ignoring (snubbing) a reconnecting peer is actually following the protocol spec precisely in purpose and to the letter -- as they are technically not new peers to the torrent and will no doubt be downloading from others who incorrectly treat them as new peers. The snubbing ends when they upload to you, via a regular optimistic unchoke (but even then you only upload to them for 30 seconds, possibly at reduced rate), or antisnub routine if there's nobody else to upload to. This is neccessary when operating as a seed, as they cannot upload to you.

Link to comment
Share on other sites

Before someone chimes in and says it's been asked before' date=' 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 ?[/quote']

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.

Hello. I have read a lot of the discussion so far on this forum about "stuffers", "ignoring" and "kicking and banning". But I've chosen to reply to your comment, Chaosblade, because it struck a nerve. You see you actually must to give users the option to administer the swarm, as they see fit, on some level.

Failure to do so is a system with no security, as we have seen. Worse, if you make the protocol responsible, really, and have everyone sending data on everyone else to a centralized area, you slow the system down significantly.

The claim that the protocol (program) will handle it ... doesen't this just mean that the control of administrating the swarm is simply in the hands of *different* users, not yours? Frankly, the way you describe things is counter to how the internet is supposed to work. Please, please, authors of uTorrent, integrate this feature. Don't force me to find outside software that is bulky and crappy. I am relying on you. I'm not an idiot, and if other people are, thats fine, i'll ban them too. This is America.

Secondly (and this is the important part) the only real way to administrate the swarm in a way which prevents clients like bitvomet from cheating is to centralize the administration of the protocol. This is obvious from the way in bitvomet cheats, by misrepresenting itself to a large number of blind peers. This is, unfortunately, yet another reason why you have to give users more power to "administrate the swarm", or at least include features which allow users to set the criteria by which other clients are banned.

-leaf

Link to comment
Share on other sites

You see you actually must to give users the option to administer the swarm, as they see fit, on some level.

Failure to do so is a system with no security, as we have seen. Worse, if you make the protocol responsible, really, and have everyone sending data on everyone else to a centralized area, you slow the system down significantly.

The claim that the protocol (program) will handle it ... doesen't this just mean that the control of administrating the swarm is simply in the hands of *different* users, not yours? Frankly, the way you describe things is counter to how the internet is supposed to work.

[...]

the only real way to administrate the swarm in a way which prevents clients like bitvomet from cheating is to centralize the administration of the protocol.

The administration of the protocol is already mostly centralized. This thread is at least anecdotal evidence that didn't work. The central authority, the tracker, gets lied to left-and-right by numerous clients (not just BitComet) that claim BitTorrent compatibility. Private trackers (even with automatic client bans and ip blocking) cannot police their own premises effectively without considerable administrator+user intervention. The more popular or desireable they are, the worse it gets.

When things are out of control, users HAVE to manage things themselves. But with high-speed connections and long-running torrents, you cannot expect people to "babysit" a BitTorrent program to get it to work well. They just want the files they're after and won't tolerate a poor tool (the file-sharing program) to get them. So that means unless some forces correct them, many will CHEAT through whatever file-sharing program cheats best.

Sure, the geek in me loves to "babysit" µTorrent to see if I can get another 10% download speed -- but even I won't tolerate needing to do that constantly to have good results.

The BitTorrent protocol has built-in checks-and-balances to reduce 1 client being able to dominate a torrent and out-download others without also uploading back. But it has holes in its logic and cannot be draconian in enforcing all of its rules or everyone would likely suffer. Better to upload to leeches at a reduced rate than ban them.

My 1st proposal tries to balance BitComet's ongoing cheating by de-priotizing it slightly. It's nothing more than a band-aid for a hemorrhage. And it might as well be optional, because ultimately if that's all that's done...nothing really changes. Read how well Azureus automatically handles super-seeding because of problems:

http://azureus.aelitis.com/wiki/index.php/Super_Seeding

The writer figured out what is happening: BitComet disconnecting and reconnecting to get extra download speed. But not why Azureus is reacting the way it does. As such, he can only play whack-a-mole with innumerable bans-by-ip of BitComets users or flat-out ban "BitComet" by using the Stuffer add-on...which they can bypass with their own hacked id changers.

My 2nd proposal, seeks to correct a glaring error in current interpretations of the BitTorrent Protocol and seeks to adapt to clients that try to take advantage of that glaring error. It neither singles out BitComet nor any other client but is designed to react to hostile activity and automatically "forgive" (remove the snub) easily. Having to "babysit" to do something similar manually is beyond the capabilities of the average user. Their methods would be forced into an all-or-nothing scenario of continually ip banning or throttling a possible hostile client via something like netlimiter. Manually reacting on a small scale is one thing, but what about on torrents with 1,000's of peers and 100's of seeds?

Link to comment
Share on other sites

Please. Fixing this problem is the responsibility of tracker admins. By making µTorrent do it, all you achieve is µTorrent separating from the BitTorrent spec and becoming a "cheating" client itself. It doesn't treat BC users fairly. Even if they treat us with low priority, two wrongs don't make a right.

I kind of feel sorry for many BitComet users.

[...]

Ignored by their "God".

wow, you like your torrent client ;)

Link to comment
Share on other sites

The first I agree is bad, I would consider a band-aid and misguided vigilante justice.

The second is not in the BT spec, it's just a custom the clients have adopted to help the swarm that some clients have begun abusing to the detriment of the swarm, so the custom needs revisiting. Fortunately, the custom can be upheld with absolutely no negative effects to the old philosophy behind it by simply retaining a list of recently-seen IPs (and perhaps their known uploading strength?) and not prioritizing or penalizing their uploads any more than if they'd stayed connected.

Link to comment
Share on other sites

Please. Fixing this problem is the responsibility of tracker admins. By making µTorrent do it, all you achieve is µTorrent separating from the BitTorrent spec and becoming a "cheating" client itself. It doesn't treat BC users fairly. Even if they treat us with low priority, two wrongs don't make a right.

Please! :rolleyes:

Tracker admins CAN'T fix a problem caused by a flawed interpretation of the BitTorrent Protocol!

All they can do is play a never-ending war of kick-ban with cheating clients.

(I'd also prefer some of the battle be fought and won by the protocol BEFORE having to fight-it-out with leechers and cheaters in a public torrent.)

What you're saying is:

1.Other clients not following the BitTorrent Protocol should not be banned or ignored by BitTorrent clients...regardless how detrimental the cheating is to ALL parties involved!

2.You don't believe in a fair and level playing field. (corollary of 1 - others may not follow the BitTorrent Protocol, but µTorrent shouldn't even try to work within the protocol if it has an 'unfair' effect on the cheaters.)

3.Also, individual users don't need or deserve the tools to fight this serious abuse -- instead "tracker admins" are somehow supposed to be able to deal with this cheating with no appropriate tools themselves.

My proposal treats BitComet users fairly by not banning them and instead giving them any spare upload bandwidth µTorrent has -- despite the fact they use a client that cheats.

I want µTorrent to give any halfway-supported BT client a fair and reasonable chance of completing a torrent. This does not mean I think the poorly supported clients should even get the same amount of bandwidth as others. Not everyone is guarenteed lots of download speed -- only that enough virtual+distributed copies are created that everyone can share what they have and get a completed torrent.

Super-seeding is unfair to fast-uploading peers. It is not part of the original BitTorrent protocol. It is in violation of these parts of the BT Protocol:

1.When a peer finishes downloading a piece and checks that the hash matches, it announces that it has that piece to all of its peers.

2.Peers which have a better upload rate but aren't interested get unchoked and if they become interested the worst uploader gets choked. If a downloader has a complete file, it uses its upload rate rather than its download rate to decide who to unchoke.

Super-seeding benefits BitComet clients even more than regular seeds or peers. µTorrent should not support such cheating (super-seeding) according to the logic used by others here.

The first I agree is bad, I would consider a band-aid and misguided vigilante justice.

The 1st method was a middle-of-the-road approach to attempt to balance the lopsided results.

I'd think banning BitComet entirely on many private trackers would closer describe "misguided vigilante justice". :lol:

The second is not in the BT spec, it's just a custom the clients have adopted to help the swarm that some clients have begun abusing to the detriment of the swarm, so the custom needs revisiting.

Preferential uploading to newly connected peers is not a "custom", that is a literal and precise following of the BitTorrent Protocol:

"For optimistic unchoking, at any one time there is a single peer which is unchoked regardless of it's upload rate (if interested, it counts as one of the four allowed downloaders). Which peer is optimistically unchoked rotates every 30 seconds. Newly connected peers are three times as likely to start as the current optimistic unchoke as anywhere else in the rotation. This gives them a decent chance of getting a complete piece to upload."

If a BitTorrent client does not retain information on disconnected peers, it is left NO "wiggle-room" on what it's supposed to do with ANY AND ALL connecting peers:

1.It should be three times as likely to optimistically unchoke them.

2.It should give them a decent chance of getting a complete piece to upload.

3.(unstated in protocol, but direct corollary of 1+2) Since a large torrent has lots of peers, any given peer would normally get optimistic unchoke rarely. A typical broadband connection will not normally upload a whole torrent chunk in 30 seconds. Therefore, optimistic unchoke alone is not a decent chance to give them a complete piece to upload.

NOTE: (math behind #3)

A typical broadband connection has somewhere between 20 KB/sec and 60 KB/sec upload bandwidth useable by µTorrent.

Each torrent is assumed to have 4 uploads.

Even assuming only 1 torrent running, the most available bandwidth to devote on average to 1 upload is 60 KB/sec / 4 uploads = 15 KB/sec PER upload.

15 KB/sec * 30 seconds (optimistic unchoke period) = 450 KB -- enough for the smaller chunksize of 256 KB, but not even half the larger chunksize of 1 MB.

This means a BitTorrent client (with no retained disconnected peer information) not highly favoring reconnecting clients would be breaking the BitTorrent Protocol.

This is a catch-all in the BitTorrent protocol about new extensions and upload/download strategies:

"The choking algorithm described below is the currently deployed one. It is very important that all new algorithms work well both in a network consisting entirely of themselves and in a network consisting mostly of this one."

It is very important that µTorrent work well in a network of hacked and cheating clients.

Getting disconnected and reconnecting in a torrent is not cheating. Everyone has to do that from time to time. It is VERY important that new peers (presumeably with nothing to share) aren't mistaken for reconnecters. Also, even reconnecters with little to share shouldn't be treated the same as reconnecters with lots to share. It is only the specific category of hostile reconnecters with plenty to share which deserves the "harsh treatment" of a temporary snub.

Looking at it another way, the actual cheating is the cancellation of uploads to fast uploaders to instead upload to already-seen clients that automatically disconnect and reconnect when they are not being uploaded to. And that cheating was being done by µTorrent.

Link to comment
Share on other sites

hi guys,

I never know how my bt client works and didnt think i need to,

I chanjd my mind after learning how bitcomet behav.

I am drafting a short article trying to perswade peer to know it as wel,

I think u would alow me to quote your words.

see if I get it wrong or not:

Why do BitComet get so obnosious?

- the most hostile and unfair BT client ever

Background

(I am not sure where to start...)

Cheat & Leech

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

This goes together with hammering trackers with multiple announcements, overloading them, demanding more than their share of tracker attention, and pulling attention away from users of other clients.

2. BitComet connects 5 - 10 times per SECOND to other clients while no other client connects more than 2 times in 10 minutes.

3. BitComet disconnects working connections and reconnects to download more than is fair via optimistic unchoke - which is meant to give new arrivals something to share. In this way, BitComet competes unfairly for connections with other clients when it has downloaded a lot from the same peer, which is particularly unfriendly to new arrivals. Besides, that creates lots of churn which costs extra bandwidth for trackers and peers alike.

Neglect distributors' will

4. BitComet misuses DHT on private torrents/trackers, even ignoring BitComet's user's settings NOT to if the tracker briefly goes down.

Sabotage torrent sustainability

5. With the above means, BitComet benefits excessively at the expense of others. What's more, ironically, it benefits only the early arrivals that are running BitComet. Corollary of 3: BitComet is getting far more pieces than they could quickly redistribute. BitComet can finish earlier and leave earlier without getting rare pieces shared (with sabotaged piece availability left for other peers). Torrents die easier and sooner.

Switch to other BT clients with "bitiqette" today.

Link to comment
Share on other sites

see if I get it wrong or not:

You seem to have it all right, though the bit about extremely fast connecting is unconfirmed. I do see BitComet connections often reconnecting, but I cannot tell how fast they are doing this using my 'snapshot' tools. My guess is they wouldn't be reconnecting very often unless you're not uploading to them.

Here's another CONFIRMED problem of BitComet:

BitComet is known to often 'forget' to inform other peers that it just downloaded a file chunk. This is especially bad for super-seeds, as they do not know if BitComet clients actually got (and will share) very rare torrent chunks.

An unconfirmed problem:

BitComet creates incompatible torrent files, or just plain unreadable (even by BitComet!) torrent files, sometimes. Incompatibility is known to exist at least because of BitComet's strange way of handling unicode characters in filenames, but I've heard there's other incompatibilites as well -- possibly due to a pure program bug in BitComet.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...