BitTornado Bans All BitComet Users

[bgmnt]

Story : http://torrentfreak.com/bittornado-bans-all-bitcomet-users/

http://forums.degreez.net/viewtopic.php?t=7078

http://forums.degreez.net/viewtopic.php?t=7079

Now if more clients would follow ...

Rest in peace BitVomet.

[Alpha-Toxic]

finaly...

[dAbReAkA]

pasted that in the irc channel yesterday.. no one responded though

and what's utorrent doing?!

bitvomit wont rest in peace until all the other major bittorrent clients do that..

[Ultima]

Heh and Firon's proposed that idea to ludde before... ;D

[bgmnt]

Well Azureus have plugin Stuffer http://sourceforge.net/forum/forum.php?thread_id=1376095&forum_id=377614 to do something similar. Now if only utorrent...

[Dark Shroud]

Now that the fanboy comments are over lets look at the bigger issue here. A client is banning other clients without the user's permission or a way to turn it off. This will harm swarms in a lot of ways.

The super seed issue is a joke. The DHT & PEX issues were corrected. And a lot of work has been done on other aspects of the client. So now it comes down to what the user does, and they can do the same abusive crap on other clients as well. What if they switched to µTorrent and that was also banned? Or they goto BitThief, a real enemy of swarms.

[Switeck]

Now you may think the super seed issue is a joke, but some of us here are still pretty frustrated that the reason why it doesn't work very well in µTorrent is intentional cheating and sabotage by BitComet.

BitComet is simply not supporting or not properly supporting important parts of the BitTorrent protocol. The authors are aware that they are cheating and doing it specifically for that reason.

I have posted what I think is a fair solution, as banning does not solve the issues...due to client id spoofing.

[Game90]

Im not sure if shadow's actions would have any effect at all.

btw, there are some torrents out there whos 99% peers use bitcomet. Especially chinese torrents, mainly because of proxies within proxies in china. They rely on NAT transveral, and the only "Good" client out there that has NAT trans is bitcomet. If only utorrent has NAT trans...

[Dark Shroud]

Switeck, where is proof that it even does cheat ss? Most of the information on how bitcomet cheats is impossible because super-seed doesn't work that way. I'll just post this guote since its very well written.

The way super-seed works is it discovers which peers are sharing data the most efficiently

That's a fascinating remark. How could it possibly discover that? How could one client know what all the other clients are doing, who they're connecting to, and how they're distributing data?

It can't. There's no mechanism for demanding status reports from other clients, and if there were, I'd want it disabled STAT, not least because it's wasting my bandwidth. And who would bother to write all the code to do that, for no benefit?

That might be what super-seed wishes it could do, but that's not what it actually does. The reality falls far short.

A super-seed sends you one piece, then it waits and won't send you a second piece until somebody ELSE offers it that first piece it sent to you. This establishes that you did share the piece, since somebody else now has it and is offering it.

That's all it does, because that's all that it CAN do, and all the rest is wishful thinking. "Most efficient data-sharer?" In a perfect, homogenous network, MAYBE that's equivalent. I don't know. Nobody's every seen a perfect, homogenous network on the Internet.

But the basic idea is still, "I'll give you another piece when I see that you shared the last one." Now, if you've done that, and done it correctly, then it's not possible to "game" it or "cheat". Not unless whoever actually implemented it screwed up badly. Let's look. He says,

When BitComet games super-seed, it induces the seed into thinking that the BitComet peer is very efficient at spreading data.

How? How can any client induce another into thinking that? The SS either was offered piece X by another peer, or was not. There's no middle ground, no third state, here.

We have three clients. Sigma is the super-seeder, while alpha and beta are peers.

Sigma gives a piece to alpha, and won't give alpha another piece until alpha has shared the first one. So alpha sends the piece to beta. Beta offers that piece to sigma, who now knows that alpha has shared it, so allows alpha another piece.

How can alpha somehow "induce" sigma into thinking that piece X has been shared when it has not? The system simply does not contain any way to do that, unless the ss algorithm or its implementation is horribly flawed. Sigma is not relying on alpha to say "I've shared piece X" -- BT has no mechanism for doing that, and we don't ever want it to have a mechanism for doing that -- sigma is waiting for somebody else, in this case beta, to say "I've got piece X, do you want it?" -- part of a normal BT peer negotiation-- as evidence that alpha has shared piece X. If beta doesn't say that, then sigma thinks alpha has not shared, and won't give alpha another piece.

This isn't difficult or technical. If someone can't explain, simply and clearly, how this gaming is being accomplished, you know they're blowing smoke in your eyes.

I said that the network was not homogenous. There are "clumps" of peers who are connected to each other, but only one or two of them are connected to any of the peers in that other clump over there. The members of one clump share pretty efficiently among themselves, but diffusion between one clump and the other clump is much less efficient.

(This is the very issue that plagues PEX, the alternative to DHT.)

It means that alpha might be sharing its little heart out among members of its own clump, but none of them happen to connect to sigma. So even though alpha is sharing all that anyone could wish for, sigma does not, can not, become aware of any of that traffic. This is where the nice theory meets the ugly reality. This is where "knowing who is sharing data most efficiently" becomes an impossibility.

The persistent notion that BitComet doesn't share, is just plain stupid. All BT clients choose their connections and their trading based on whoever gives them the most pieces, the fastest and most reliably. It's a mutual agreement, continuously renegotiated. If your client doesn't share with mine, you go to the bottom of my list, and mine won't share with yours. If you don't give, you don't get. So if BC really behaved like that, downloads would be far faster with any other client, and nobody would use BC. It would have died out long ago.

All we can hope for is that someday, Shadow pulls his head out.

[Ultima]

I'm not sure if I'm in agreement with TheShad0w's decision (TBH, I'd be torn as to what I'd do), but I find it difficult to swallow the fact that many people have had similar experiences in swarms dominated by BitComet peers (myself included) and still be able to say that BitComet doesn't abuse the protocol. Sure, there's always the occasional BitComet peer who is genuinely interested in sharing (I've downloaded from many BitComet peers at blazing speeds), but that doesn't apply to most of those that I've seen. So what are the possibilities? That BitComet is a client used mostly by leechers? I tend not to think of that to be the case. The only other possibility I can see is that BitComet itself is built with abusive and aggressive behaviorial tendencies by default.

FWIW, I've no personal agenda against BitComet -- I was once a BitComet user before switching to µTorrent, and TBH, was decently satisfied by the client (µTorrent simply more suited my tastes). The bottom line is that many users have fallen victim to BitComet's aggressive nature, so TheShad0w's actions aren't totally unfounded. Honestly, what else could he have to gain by banning a client if it isn't as he's explained?

[Dark Shroud]

To over simplify, the real problem with BitComet are the user settings. Once people configure BitComet to work with their connection everything is fine. Many of these peers/newbies/noobs shoot themselves in the foot so to say because their settings are so screwed up. If you go to the BitComet forums you'll see tons of people having various problems because they never configured the client or compleatly misconfigured and/or just run to many .torrents at once.

[Ultima]

Maybe, but that doesn't explain why, on mostly-BitComet-dominated swarms, only the BitComet peers appear to be actually downloading at any decent rate, and have the greatest percentage progress. Even those BitComet peers with (initially) lower percentage progress than myself were able to surpass me, and I was stuck downloading next to nothing.

[Switeck]

Haven't I posted enough at least anecdotal evidence here?:

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

The way it was determined to be cheating swarms/seeds in the past was not the method Shad0w mentioned but a method mentioned on an Azureus wiki site. I think we can consider this one proven.

BitComet not only ALLOWS bad settings, many settings that qualify as violating the BitTorrent protocol are that way by default. Users don't have to be evil or newbies to have evil settings.

BitComet's default upload slot behavior is especially bad, as I myself typically see BitComet clients uploading to me at 0.3 KB/sec or less. That's nearly worthless to the swarm! This actually violates the BitTorrent protocol, as uploading very slowly can be worse to the swarm than leeching and always saying you have nothing.

The now-taken-care-of handling of the private flags/DHT by BitComet was a problem known for over 6 months before the author bothered to fix it. His email would bounce messages to it because it was full (and at 1 or 2 GB size for a gmail account, I can guess it's not all love letters). There wasn't an offical statement on the BitComet website concerning these problems either. This is not someone who seems terribly concerned about major problems in their BitTorrent client or public relations.

[knives_out]

I dont see why everyone hates bitcomet, all of the torrents i download on it - I force the upload to at least 25kb/s minimum out of my 1mbit broadband my share ratio is always 1.0 or more. If all bitcomet users did this there'd be no problems right? The problem with bitcomet is many a time it by default allows you to get away with 0kb/s upload whilst giving you 120+kb/s. If people configure there settings so that they are sharing more it should be ok. Loads of bitcomet users have share ratios around 0.0 or 0.1 and they are where the problem lies but that doesn't mean they should ban it for the rest of us

[dAbReAkA]

a ratio above 1 doesnt mean anything.. it still cheats.. it stills tries to get around initial-seeding..

[Switeck]

Extremely hostile settings shouldn't be allowed. Since these are default settings, that makes the situation severe enough that a ban may be warrented...though a ban is not an effective means of solving the problem.

A ban will not be effective long-term because BitComet will probably start using Client ID spoofing by default...however BitTornado is banning by behavior (presumeably tied to their cheating somehow) rather than client id. Also, even if BitComet's makers quit their (worst) cheating tactics...BitTornado may still be banning them, or at least older versions will be.