BitTornado Bans All BitComet Users
Written by Ernesto on January 07, 2007BitTornado developer John Hoffman, better known as Shad0w, decided to ban BitComet users from accessing his client. Shad0w says that BitComet is gaming the system and stealing precious bandwidth, which results in slower speeds for all non-Bitcomet users.
BitComet is known to be a BitTorrent bully, similar to the recently introduced BitThief and BitTyrant. What makes this problem serious is the fact that BitComet is far more popular than the other two clients, so its effect on other peers is more serious.
Recently, BitComet started to exploit the super-seeding procedure, an invention by Shad0w that is also implemented in other popular clients like uTorrent. A super-seed detects peers that efficiently distribute data to other peers, and rewards them by sending them more data. This technique speeds up the overall speed of the swarm, and all other users benefit from it. However, not if it was up to the BitComet developers.
Shad0w explains, “When BitComet games super-seed, it induces the seed into thinking that the BitComet peer is very efficient at spreading data. As a result, the peer downloads faster than the rest of the peers, and typically doesn’t share that data as efficiently, costing the rest of the peers a lot of download time.”
The continuous efforts of the BitComet developers to cheat the system made Shad0w decide to ban all BitComet users. “Since BitComet has proven itself to be a harmful codebase, and since they have forced me to take steps I’d rather not have, I will also be banning connections from that client to my own client and tracker codebases. Should the BitComet developers decide to remove the exploitation code from their client, I will reconsider this decision.”
People may question whether it is a good decision to ban all BitComet users, but I think it is a wise one. In general, BitComet users are not the sharing type, so my prediction would be that it is more likely to speed up downloads, than to slow them down.
I’m with Shad0w on this, and I seriously hope that BitComet stops cheating, and will become more BitTorrent friendly in the future. I’ve used Shadow’s BitTorrent client for quite a while myself, and Shad0w is one of the most dedicated BitTorrent client developers around.
Previously: 24 Season 6 Leaked on BitTorrent
Next: Mininova Reaches 1 Billion Downloads
109 Responses
Not only is BitComet slowing everyone else down, but they’re also stupidly shooting themselves in the foot. http://forums.degreez.net/viewtopic.php?t=7079
This is not the first time BitComet has annoyed the rest of the torrent community:
http://www.slyck.com/news.php?story=1021
Man that shadow needs to wise up man there has been no compliants about this so what is his problem just because his client is old and outdate he ahould keep with the times. GRADE A WANKER GOES TO SHADOW
Cry more N00b
ZeroN00B, cry me a cheat river will ya?
bitcomet does indeed suck but there are 2 problems with this:
1. how can bitcomet game superseeding? as i’ve always seen it explained, a superseed judges a client’s upload by seeing how fast its pieces appear in the swarm. how can bitcomet make other clients lie about what they’ve recieved?
2. don’t lump bittyrant in with bitthief and bitcomet. it basically does the same thing as superseeding by prioritizing upload to other clients that upload fast.
Frank Castle you really know how to hit rock bottom don’t you…
I still prefer BitComet and even with the ban will continue to use it.
Does anyone even use that client? Bitcomet was fixed a long time ago, and I can’t think of anyone in the world who would agree with you. You suck
lol poor baby shad0w, BitComet users wont let him leech their bandwidth to support his shitty user base. By dividing the bittorrent community into private fiefdoms he damages EVERYONE including his own users! He can go fuck himself! While he lives in lalaland the rest of us will continue to use and support BitComet and all the other clients that don’t condescendingly decide who its users can and can not trade packets with or how. What he forgets is that the bandwidth is ours, the files are ours, and he has just one of many clients (and not nearly the best).
To shad0wsuck3rs:
From the perspective of a Bittornado user, this is bad news. a large number of people on any given torrent will now not be accessible to the client, and totally ignored. This will lead to less speed rather than more. Shad0w assumes every person on BitComet is obviously a thief, spoofing his super-special “super-seeding” and cheating the system to steal from him saying, they “typically doesn’t share that data as efficiently” . So he bans them. The Nazi’s were efficient too - at banning Jews! The real “democratic nature” of bittorrent is its ability to allow the people to decide both their commitment (upstream) and reward (downstream) on an individual and communal level. The more people that participate in any one torrent the faster the speeds. That doesn’t mean every person must saturate their connection with upstream packets at all times. If a feature is going to be added to an individual client, it shouldn’t require a ban of other users of the same basic system to work.
This is like trying to require a certain user agent to view a web site. BitComet will just add a setting to report that it is some other client.
Well done. We have had it banned on our tracker for a long time now because of this exact factor and because it not reporting stats correctly. I know many other private sites have done similar. Its great that another developer also see’s this and has also taken a stand. Congratulations and WELL DONE :)
You are going to dictate to me what peers I can connect too? I don’t think so. Goodbye BitTornado.
Its about time. The public tracker idiots will whine and complain, but everyone knows all the good stuff is on private trackers, and Bit Comet screws everyone else in the swarm, hurting the community, and reducing the numbers of people who want to upload new content. Shad0w is brave enough to take a stance against a shitty cheat client, unlike uTorrent’s whimpy developer (who recently sold out to hollywood). I’ve used the original ‘epxerimental client’ from shadow for years before switching to uTorrent a year or so ago. I needed a client that can schedule bandwidth and show all torrents in a single window. I might switch back, though, and start using Bit Tornado when the new version is released with the BC ban implemented.
I have played around with Azureus and the stuffit plugin, but Az is too much to deal with, it eats up way too much of my resources. Bit Tornado would be perfect if it had an updated GUI.
I have to wonder… is the MPAA/RIIAA employing boiler rooms of temps to sabotage P2P?
[quote comment="37005"]lol poor baby shad0w, BitComet users wont let him leech their bandwidth to support his shitty user base. By dividing the bittorrent community into private fiefdoms he damages EVERYONE including his own users! He can go fuck himself! While he lives in lalaland the rest of us will continue to use and support BitComet and all the other clients that don’t condescendingly decide who its users can and can not trade packets with or how. What he forgets is that the bandwidth is ours, the files are ours, and he has just one of many clients (and not nearly the best).
To shad0wsuck3rs:
From the perspective of a Bittornado user, this is bad news. a large number of people on any given torrent will now not be accessible to the client, and totally ignored. This will lead to less speed rather than more. Shad0w assumes every person on BitComet is obviously a thief, spoofing his super-special “super-seeding” and cheating the system to steal from him saying, they “typically doesn’t share that data as efficiently” . So he bans them. The Nazi’s were efficient too - at banning Jews! The real “democratic nature” of bittorrent is its ability to allow the people to decide both their commitment (upstream) and reward (downstream) on an individual and communal level. The more people that participate in any one torrent the faster the speeds. That doesn’t mean every person must saturate their connection with upstream packets at all times. If a feature is going to be added to an individual client, it shouldn’t require a ban of other users of the same basic system to work.[/quote]
BUWHAHAHAHA Dude you seriously made me laugh. More than Half of the Bit Torrent community HATES BitComet. I think what he did is good and this could result in others doing this and maybe ending the crappy hunk of Programing call”BitComet”.
Too bad bitcomet has such a stellar user interface, and is actually easy to use…
how do I ban people with the client bitcomet on utorrent?
[quote comment="37025"]how do I ban people with the client bitcomet on utorrent?[/quote]
You cant, µTorrent always plays nice, even with bitcomets.
[quote comment="37033"][quote comment="37025"]how do I ban people with the client bitcomet on utorrent?[/quote]
You cant, µTorrent always plays nice, even with bitcomets.[/quote]
You could just bann thier IP
@shad0wh@t3r
Hey dumbass. Seriously, dont take this ban on bitcomet personally.
We all saw this one coming, just change client.
And if you haven’t noticed: many, I mean many, seedboxes are running bittornado.
Im with Shad0w at this one.
I’m using bitcomet because I don’t have any other alternative!!
My pc is a bit outdated and Azureus is too heavy to run on it. uTorrent is an excellent program but lacks the NAT Traversal feature, and since I’m behind a router I can’t get good speeds with it neither connect to many peers (I’ve tried the guide available on their to port forwarding but with no results).
The thing is, I seed a lot, I often let my computer on all day just to seed! And now someone decided to ban me from whatever just because I’m using bitcomet!
I’d change my torrent client, but to which one? I need something with NAT Traversal, and the only one left that occurs to me is BitSpirit, but I really don’t like that client….
[quote comment="37038"]I’m using bitcomet because I don’t have any other alternative!!
My pc is a bit outdated and Azureus is too heavy to run on it. uTorrent is an excellent program but lacks the NAT Traversal feature, and since I’m behind a router I can’t get good speeds with it neither connect to many peers (I’ve tried the guide available on their to port forwarding but with no results).
The thing is, I seed a lot, I often let my computer on all day just to seed! And now someone decided to ban me from whatever just because I’m using bitcomet!
I’d change my torrent client, but to which one? I need something with NAT Traversal, and the only one left that occurs to me is BitSpirit, but I really don’t like that client….[/quote]
OK. What to do is forward the Port in your router to use utorrent. Also the reasons why you may get super Speeds With BitVomit is because it abuses Trackers and suchs.
[quote comment="37040"][quote comment="37038"]I’m using bitcomet because I don’t have any other alternative!!
My pc is a bit outdated and Azureus is too heavy to run on it. uTorrent is an excellent program but lacks the NAT Traversal feature, and since I’m behind a router I can’t get good speeds with it neither connect to many peers (I’ve tried the guide available on their to port forwarding but with no results).
The thing is, I seed a lot, I often let my computer on all day just to seed! And now someone decided to ban me from whatever just because I’m using bitcomet!
I’d change my torrent client, but to which one? I need something with NAT Traversal, and the only one left that occurs to me is BitSpirit, but I really don’t like that client….[/quote]
OK. What to do is forward the Port in your router to use utorrent. Also the reasons why you may get super Speeds With BitVomit is because it abuses Trackers and suchs.[/quote]
http://torrentfreak.com/bitcomet-the-bittorrent-bully/
Check there to see. Sorry for Double posting.
Shad0w is right; Bitcomet games the system and that sucks. Banning Bitcomet is the right thing to do. More sites should do the same!
you guys are LaME.
BitComet RULES!
[quote comment="37045"]you guys are LaME.
BitComet RULES![/quote]
XD
Wow another BitVomit Fan. Why is it so much better? Oh yeah the way it over works the hell out of Tracker sis so cool.
Here’s my dilema…I’m behind a nat which I don’t control (it’s a college campus). I can’t just go up to my IT guy and ask him to forward my port or open up any ports. I use BC because it allows me to download faster…I’d love to seed if I could. Don’t get me wrong I think it’s shitty that leechers like me damage the torrent system. However not all of us have a choice in that matter and regardless as to what anyone says not all leechers wanna be leechers. If it was up to me I’d be seeding several torrents on another machine (gotta keep my main one open for gaming ;-).
IMO it’s Shad0w’s program and he can do with it what he wants…but assuming it’s not already he should’ve just made it an option instead of hardcoding it in. Fairness works both ways.
[quote comment="37050"]I use BC because it allows me to download faster…I’d love to seed if I could. Don’t get me wrong I think it’s shitty that leechers like me damage the torrent system. However not all of us have a choice in that matter and regardless as to what anyone says not all leechers wanna be leechers.[/quote]
you made a choice, and it’s to download as fast as possible. you chose your personal speeds over the interests of the bittorrent community.
anyway, as has been stated, most private trackers ban BitComet already, so shad0w’s just taking it one step further. anyone who is really disappointed by it should ask for your money back … oh wait
Good to see Shadow still kicking… As for BitComet… This has been coming for awhile has it not?
Granted, Bitcomet games the system … but not all bitcomet users are “evil leechers who want to destroy the system.” I run WinXP 64bit … bitcomet is the only client I’ve been able to use that won’t blue-screen my machine within 5 minutes. It sucks that it doesn’t play nice, but don’t assume people are trying to cheat everyone out of a few kb/mb/gb of bandwidth just because they’re using that client.
so basicly BitComet is being banned cuz of some retarded users r abuseing it?
i been useing Bitcomey for year and i have no prob with it i seed my torrents
unlike the other clients i used i get better DL speeds from Bitcomet
bittorrent: i didit like download speeds sucked even if i dl from a torrent with over 2000 seeders i shouldnt get anything under 100
azures:
Nice step!
[quote comment="37069"]so basicly BitComet is being banned cuz of some retarded users r abuseing it?
i been useing Bitcomey for year and i have no prob with it i seed my torrents
unlike the other clients i used i get better DL speeds from Bitcomet
bittorrent: i didit like download speeds sucked even if i dl from a torrent with over 2000 seeders i shouldnt get anything under 100
azures:[/quote]
No, BitComet is not being banned because of retarded users abusing it. It’s being banned because the client itself is written to be abusive out of the box.
Yes, you are getting better speeds with BitComet __because__ BitComet abuses the system, but everyone else is paying the price because BitComet the client is being selfish.
O well i called a noob o well dont matter because I aint but really come on bitcomet is a class client but shadows client has gone and doesnt have basic torrent features now like DHT if he updated his client nice GUI and more now basic cleint feature i could possibleably understand but he has gone for ages and first thing he doesn o yeah lets ban bitcomet
all the words is crap. Everybody make their own decetion. You can ban it. They lose nothing. Maybe you will get better maybe not. If you want to have a finnal way to getoff all the XXX, please ban Chinese IP. After do that, your world is clearing, but too clearing.
So if you get faster downloads with Bitcomet, why don’t we all use it? I thought that was the whole f***** point with this protocol. I have been following this case for a while and the only ones that cries about it is the “private tracker” people. Weeeell, guess what, you’re no good for the torrent community anyway are you? Because you want to invite all the good seeders with your registration and invite bullcrap, away from the public trackers. So when Bitcomet doesnt help you in dividing the community, you use all you creativity to come up with the very clever “bitvomet”, and spam the good piece of software that Bitcomet is? Mommy ruined you little boysclub? We all agree that bitcomet downloads faster, so all logic tells use to use it! And this discussion has nothing to do with the seeder issue.
Thats another thing. It’s ok to stop seeding if there is 200 other seeders, it’s a bigger problem that people dont keep torrents alive. The popular torrent are gonna survive anyway…..
The BitTorrent protocol is designed to inherently limit damage from peers which don’t contribute, so up until now I didn’t bother with trying to police the protocol. The problem is that BitComet’s new theft methods don’t just take bandwidth from a point where it’s bottlenecked, and they aren’t just slowing everyone else down, they’re actually slowing THEMSELVES down too. It’s a truly asinine thing to do.
ZeroCool: Of course I’ve had complaints, otherwise I wouldn’t've known about the problem.
jonston: I’ll write more about it later.
CryCryCry wrote: “We all agree that bitcomet downloads faster, so all logic tells use to use it! And this discussion has nothing to do with the seeder issue”
oviously you have absolutely no idea about logic!
there isn’t one magic fast 10GE seeder somewhere that feeds us all with stuff. Its the whole of a swarm that makes the speed.
And BitComet downloads faster because it gives a shit about the health of the overall swarm. 1 seeder has UL capacity X. This X is devided among his leeching peers. so you can only download fast if there are more people in the swarm that GIVE to it in a decent speed. Of everyone would use BC then the speed with which the content is sucked from the swarm would run the cloud of available pieces dry.
Picture a water tank where you with your BitComet take the water from faster then the RainGod can fill it up. (But i’m afraid your logical abilities aren’t developed enough to even imagine such a simple comparison between how a BTswarm works and some real life example!)
P.S.
CryCryCry also wrote:
“I thought that was the whole f***** point with this protocol.”
maybe you should not try to think! either you are unable to do that, or you haven’t understand what BT is all about. It was not intended to get something the fastest possible way, it was invented and its intention was to take the stress off of a server when huge amounts of clients asking him for the same content to serve to them!
Fastest possible speed to get content was never a design goal if I understand the specifications of BT correctly.
maybe you should read them too!
well i’m a bitcomer user. and not for the non sharing reasons suggested in the article. for the simple reason i tried loads and liked the way it workd and the interface. i’ve bbeen using it for many versions. though this information surpriused me. can anyone recommend a client thats like it, but isnt trying the cheat the swarm?
What gaming mode are you talking about?
Now where’s the proof to warrant this ban? BitComet has had a lot of versions, more so than any other client. So what versions of the client are doing this as well? And I’d like some real responses not crap like “everyone knows BitComet cheats” or “BitComet cheats deal with it.”
And since TheSHADOW seem to actually be reading this how about you help those of use who never got the confimation emails from your forums. You have a lot of members listed who never posted once because they did/could not finish regsitering.
Dark Shroud you want an example?
I just at this very moment hit the “log peer traffic” button, and one of the first things that almost instantly came up was:
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Request while choked: 451:114688->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:49152->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:65536->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:81920->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:98304->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:114688->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Request while choked: 451:49152->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Request while choked: 451:65536->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Request while choked: 451:81920->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Request while choked: 451:98304->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Request while choked: 451:114688->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:49152->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:65536->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:81920->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:98304->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:114688->16384
Bit comet is not cheating the swarm.
I will keep an open mind till I see something more then wild accusations ranted in a blog, but every other “rumor” regarding Bit Comet has proved to be half truths, or complete fabrications.
Now, consider this, two BT clients. Bit comet that is being accused of acting hostile to other clients, but with NO proof of any kind, and Bit tornado, which IS hostile to other clients, and bans them without any proof.
I have always recommended Bit Tornado as one of the four best, along with Utorrent, Bit Comet, and Azureus, but now we have one that is Hostile (Bit Tornado), one that “could be”, but probably isn’t.
Bit comet has never banned any other clients. In fact, the only thing you can say bad about bit comet is regarding a very old version, and how some hackers were able to force it to enable DHT. However the record of FACTS is clear regarding this, as its developers mediately correct the issue.
In fact, DHT didn’t even have any set rules at the time, since it wasn’t even part of BT protocol, so there were no rules to break, but this didn’t stop people from spreading the rumors.
I am looking forward to hearing Bit Comets official response to this latest attack on it, but since no real facts are included with this accusation, it is impossible to defend. This attack reminds me of a little kid crying that another doesn’t play nice. So, do we ask Bit Comet to prove that is does “play nice”, or ask Shadow to prove it doesn’t???
The former could never be proven by any client, and I sure hope for shadows sake, that he can prove this, cause if he cannot, then his client has become what he accuses bit comet of becoming.
D
On the other hand, if a torrent is spreading slowly, this may be quite useful, as it will be available for a longer time.
[quote comment="37259"]Dark Shroud you want an example?
I just at this very moment hit the “log peer traffic” button, and one of the first things that almost instantly came up was:[/quote]
How about a little more information. Like what client you were using, were you using Super-seed mode? Instead of 16 listed items in one second that are not the same client. Why you ask? Because BitComet only uses one port. For all of that to be the same person he’d have to be hitting the randomize button and then manuel connect all within the span of a second. And that’s not acounting firewall adjustment.
Here are 2 full seconds of peer traffic from a Naruto torrent in µTorrent:
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Got Piece: 185:131072->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 185:212992->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 185:229376->16384
[19:31:41] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1097728->16384
[19:31:41] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1114112->16384
[19:31:41] 84.204.194.100 : [µTorrent/1600 ]: Sending Piece 441:1081344->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Got Piece: 185:147456->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 185:245760->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 662:0->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 662:16384->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 662:32768->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 662:49152->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 662:65536->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 662:81920->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 662:98304->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 662:114688->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 662:131072->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 662:147456->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 662:163840->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 662:180224->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 662:196608->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 662:212992->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 662:229376->16384
[19:31:41] 67.10.254.129 : [Mainline 5.0.4 ]: Requesting 662:245760->16384
[19:31:42] 67.10.254.129 : [Mainline 5.0.4 ]: Got Piece: 185:163840->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Sending Piece 441:1097728->16384
[19:31:42] 67.10.254.129 : [Mainline 5.0.4 ]: Got Piece: 185:180224->16384
[19:31:42] 195.39.129.88 : Disconnect: Peer error: offline (timed out)
[19:31:42] 218.212.223.23 : Connecting: port 22808
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1130496->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1146880->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1163264->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1179648->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1196032->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1212416->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1228800->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1245184->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1261568->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1277952->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1294336->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1310720->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1327104->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1343488->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1359872->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1376256->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1392640->16384
[19:31:42] 84.204.194.100 : [µTorrent/1600 ]: Got Request: 441:1409024->16384
[19:31:42] 67.10.254.129 : [Mainline 5.0.4 ]: Got Piece: 185:196608->16384
[19:31:42] 24.86.115.21 : Disconnect: Connection closed
Now out of the 49 (1085) seeds & 20 (311) leeches I’m connected to only 15 are BitComet; 8 of the 15 are seeders.
But guess what, I can do like all newbs/noobs do and pound away on the Mannuel Announce button hammering peers, the tracker & DHT in both BitComet and BitTornado. Since they both have that same option.
Round One, to Dark Shrould
bitcomet is a cheat end of ,its not for me to prove its for you to prove it doesn’t.
i just hope clients like Azureus do the same thing and ban.it
this is not aimed at bitcomet users.
but at the end of the day non bitcomet users suffer and have done for some time now.
something needs to be done. and ive got to say this is a great start.
im looking forward to the new bit tornado release.im all for it ,saves me having to ban it myself.
good on ya shadow top man
Wow, Godwin’s Law fulfilled before ten comments. That might be a new record.
dark shroud what are you talking about? And why do you post a logexcerpt that shows totally normal peer behaviour?
to answer your questions:
me using µt latest beta ,no, i’m not super seeding here, i’m just a leeching peer on that torrent like he was, and what I posted is one single BC client (I just Xed the last segment of this IP).
And what you can see in this tiny cutout is BC’s behaviour when he gets choked after getting his turn from one of my uploadslots; Instead of waiting till it is his turn in the choke/unchoke cycle again, he drops all his pending requests just to ask for the dropped pieces right away again. (and no, this here is not endgame mode related since he was only in the 70% range with hundrets of outstanding pieces till completion!) He was so smart to kill himself due to BC’s behaviour to drop connections just to try to reconnect with more then one connection after that. Thanks to BC’s agressive behaviour, µT’s swarmfriendly ipfilter.dat that does not terminate established connections right away can then archive its purpose by blocking such rough peers like BitComets. :-)
@donb
If you have no clue about interpreting posted data, why don’t you just try to educate yourself before posting?!
Don’t you love people who just insult people, instead of stating their case?
Did you see me insult you Kdsde?
I was only showing my support for dark shroud, but you had to turn this personal.
The facts are that people making unfounded statements regarding bit comet are nothing new, and even when they are found to be completely unfounded, the rumors just continue to spread.
Unlike you, and some others here, I am keeping my mind open, and for you to assume I know nothing about BT, well those here that I have helped resolve issues in the furums I run will differ with you.
Now, consider this, If it was bit comet that announced it was going to ban another client, using only language like “Bit Tornado users are not the sharing type”, Then that would make Bit Comet the hostile client that shadow claims it is. I personally take offense that he can categorize Bit Comet users as “not the sharing type”.
Unless There is more then these vague claims offered, then Bit Tornado should and will be reclassified as a hostile client.
History has shown us that Bit Comet’s developers have been quick to fix any exploits in its client, so demonstrate one, and see what they say, its that simple.
Until I see some evidence to support these claims, I’m giving B/C the benefit of the doubt.
D
donb, I did not insult you. I told you to read because your statement makes no sense.
How come you claim something is “unfounded” if people will offer you hundrets of logs that show how hostile BC behave?
Why are you still claiming there is no prove?
Oh, I think I know why; you might want to accuse those that are willing to present you detailed logs that show BC swarmhostile behaviour that they are BitTornado fan boys that doctor logs!
To come to the conclusion that “Bit Comet users aren’t the sharing type” is unfounded.
To claim that the client is hostile and harms the “swarm” would require a lot of evidence, not a lot of rumor.
I can tell you that alot of the big uploaders I see on my torrents are Bit Comet users. I don’t think Bit Comet is hostile to other peers, and most of what I have read regarding this is not true. Regarding your log, this alone is meaningless. Without testing in a controlled environment, no conclusions can be drawn.
Another factor that I don’t see addressed is motive. Why would Bit Comet design its client to be hostile, and to what end?
I think it is far more likely that this is more of the same, people read something about bit comet and continue to repeat it, without any evidence.
Until I see some unbiased, and (in detail) testing comparing BT clients, I will put these claims in the same category as all the other rumors regarding B/C.
If there is infact problems with Bitcomet, then I’m sure they will fix the problems, like the dht exploit was corrected.
Peers that ban Bit Comet (or use a client that does) are going to be disconnecting from some of the biggest shares (in my opinion). I do my part to help Bit comet users to learn the importance of sharing, and I see, few to none, who are trying to download without sharing.
D
ok donb, lets rephrase “Bit Comet users aren’t the sharing type” to “Bit Comet users clients aren’t the sharing type”, everybody happy now ;)
noone insults the users, its their client that is a problem, so you dont have to take it personelly ;)
“Why would Bit Comet design its client to be hostile, and to what end?”
well to make it more popular cause it downloades faster, maybe? :)
That is true over half the BitCOmets I get dont seed. I am not saying all dont share but most dont and it is a very abusive client to the trackers.
Saying “Bit Comet users don’t seed so we should ban them” is idiotic. Even if you do manage to squash the client, the users will pick up a new one. What will you do then? Ban that one as well? What happens when they all start using Bit Tornado?
Not that this change has anything to do with whether or not Bit Comet shares data (it shares as much as the user tells it to), it’s to do with Bit Comet’s alleged approach to super seeding.
As Jonston put it,
“how can bitcomet game superseeding? as i’ve always seen it explained, a superseed judges a client’s upload by seeing how fast its pieces appear in the swarm. how can bitcomet make other clients lie about what they’ve recieved?”
As someone who has no idea about super seeding, would anyone care to explain why this is or is not relevant?
WHAT A LOAD OF B****CKS SOME PEOPLE COME OUT WITH
revro,
Shadow didn’t say “Bit Comet users clients aren’t the sharing type”.
also…
“Why would Bit Comet design its client to be hostile, and to what end?”
well to make it more popular cause it downloades faster, maybe?
If this was a commercial product, this theory might be sound, but its not, and this theory is not.
D
what little cry babies you tossers are its ok to cheat from others but nobody must
cheat from you think you are little gods defending your apllication what ever it may be
all you do is harm to others Bittornado in 2 years of downloading i’ve only seem it on the stats 9-10 times 2 torrent currently being downloaded at pressent 50% of seeds are bitcmet and i don’t use it so what does that say tossers
This quote sums it up nicely:
“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.
At last someone smart here! Hooray for BC!
lol Dark Shroud thinks he/she smart.
stop talking bollocks
bitcomet is very smart because if a superseed send person A data then we would expect for person A to pass on to person B but that doesn’t happen.
why you ask ,ill tell you
because as soon as a superseed sends person A data person A drops out of the swarm then reconnects posing as a new peer then it wants more data and gets it.
meaning that superseeder has to work even harder now because person A wants more data but now theres a problem because person B want data also data that it didn’t get off person A .
do you see a pattern here
even in normal seed mode this can happen bittcomet loves to disconnect from the swarm every time it recieves a piece of data.
erm any non bitcomet user ever wounded about why the connections are bouncing blaim bitcomet.
on off on off on off it never flaiming sits still for a minuate lol
so there you go maybe im not smart but hay, im honnest and it does happen simple as
to sum it up;
in 59 Dark Shroud explaines quite good how Initial (aka. super) Seeding works.
so it is NOT utter bollocks what he explaines.
BUT 59 does not consider BitComets specific behaviour which is as good explained in 61 by cars.
For “Person A” read “Bitcomet A”! There is no need to call people names because they just lack the knowledge/intellect to understand how bad their choosen client behaves (but if someone willfully uses BitComet even after neutral technical experts educate them about their client…)
ok, but still there was no answer about the users who cannot forward ports. so if BitComet is, by the rumour, so bad, why nobody can propose a different client to do the Nat Traversal well?
i’m just wondering if there is a possibility to ban BitComet client but only used by people who do not need Nat Traversal? in that case users behind Nat would not be banned while using BitComet. what do you say?
hmmm…this shit looks like revenge of nerdz
Who cares about bittornado it sucks. Look at torrents the majority of the users that are connceted to trackers are bitcommet, Azureus, utorrent, and offical. By banning bitcommet your killing bittornado even more since 1/3 of the seeders will be gone. Bitcommet really isnt a leacherware test it for yourself your download rate still is affected by your uploadrate. Most people claiming bitcommet is a leacherware have probally never use it before and thye are just trying to pin the answer to why they get such low download rates. Part of the reason is the recent rise in bittorrent users and all these double, triple torrents of the same file so the seeders are spread all over the place.
Yesterday I’ve check’ed some torrent clients (BitSpirit,uTorrent,BitLord,Azerus and BitTornado) giving them the same torrents to download for same period of time and what I found is that even though effects of banning Bitcomet can be already seen (similar number of available but lower number of connected peers and seeds)it still beats other programs as far as speed is concerned. In fact, banning this client did no harm to it so far…..
Cars explains:
================================
bitcomet is very smart because if a superseed send person A data then we would expect for person A to pass on to person B but that doesn’t happen…because as soon as a superseed sends person A data person A drops out of the swarm then reconnects posing as a new peer then it wants more data and gets it.
=================================
This begs the question of how BitComet can “pose as a new peer”? There isn’t any such concept as “new peer” in the protocol, or in the super=seeding extension. All peers are basically equal. There’s no status code that means, “I’m a new peer”.
Interoperability requires that all clients adhere to rigidly defined protocol specifications, which cannot be unilaterally changed. If anyone tries, the remainder of the clients out there will not know how to respond to it. Therefore the list of messages that one client can send to another is exclusively specified in the protocol. Any others are not allowed and will be rejected as invalid arguments.
None of them include anything like the concept of “I’m a new peer”.
Since BitComet can’t send any such message and expect to be understood, BitComet cannot “pose” as anything. The protocol does not allow it.
Back to Cars:
============================
(…)meaning that superseeder has to work even harder now because person A wants more data but now theres a problem because person B want data also data that it didn’t get off person A .
============================
Let’s clean this up a bit, with Sigma as the superseeding client, and alpha and beta as peers.
Sigma sends alpha a piece X. Now according to Cars, Alpha did something unspecified that induces Sigma to give it another piece, and Sigma gives Alpha piece Y.
But, says Cars, here is Beta, and it is requesting piece X from Sigma because it didn’t get it from Alpha. Um, wait a second… how can this be? On any level?
Sigma is a super-seeder. It “doesn’t have” any pieces except the ones it decides to “reveal”. Alpha and Beta don’t drive this process, Sigma does. Alpha doesn’t ask, Sigma tells. Beta doesn’t ask for piece Z, Sigma says it’s got piece Z now and does Beta want it?
The rest of the time, Sigma claim it is just another peer, and doesn’t have any pieces Alpha and Beta don’t have.
But Sigma is a super-seeder. It already sent out piece X, and isn’t going to send it again until it has sent all the rest of the torrent. (That’s its brief: send out each piece only once.) So Beta can’t effectively ask, and Sigma won’t itself offer Beta piece X.
In the meantime, the (unproven, unestablished, unjustified and falsifiable) assumption is made that alpha isn’t sharing any of the pieces it gets. But Sigma is sending out pieces one at a time, each one only once, according to its own schedule, whether alpha is sharing, not sharing, or even present.
How then, is Sigma “working harder” if it’s doing the same thing it would be doing, according to the same schedule in any case?
But perhaps Sigma isn’t? That would mean that Sigma is sitting idle for long periods, sending nothing. And then it’s a claim that Sigma is being deceived into taking action and sending a piece, that it otherwise would not send.
Oops! If Sigma is sitting idle, that pretty much finishes the notion that super-seeding is faster, or more efficient at distributing torrents than regular seeding. If it could be sending but isn’t, then that’s just wasted time it could be using to send out the rarest piece of the moment. It’s hard to see why anyone would ever want to use this. It would be far slower than regular seeding.
————————————-
BitComet has no way to say, “I’m new to the swarm”. Neither does any other client. There’s no protocol for that.
It might be, though, that a superseeder stops tracking BitComet for whatever reason. But since BitComet predates super-seeding by years, and behaves the same way it always has, this would be the super-seeder’s failure to cope with the existing ecology. If the SS is misinterpreting BC’s actions, then it’s up to the SS to stop doing that instead of blaming everyone else.
If the superseeder is making assumptions about the existence of behaviors that are not required by the protocol, then it was very badly designed. That’s its fault, nobody else’s. It needs to fix its own shortcomings, not start banning anything that doesn’t conform to its whimsical decrees.
————————————–
In sum, Cars has explained absolutely nothing. There is still no clear idea of how BC is or can game the system, while there is some suggestion here that the system failed to account for pre-existing behavior due to faulty design.
do you see a pattern here
even in normal seed mode this can happen bittcomet loves to disconnect from the swarm every time it recieves a piece of data.
Among the other messages like “new peer” that there aren’t, one of them that there isn’t is “disconnect”. Since there’s no such message, no other client would understand it or honor it. So how does BitComet do this disconnecting?
All of the TCP connections are one-on-one. Alpha to beta, alpha to gamma, alpha to delta. There is no “swarm”, in this sense, there are only the individual connections. There is no way to “disconnect from the swarm”, since the swarm is nothing more than the aggregate of all individual connections interested in a particular torrent. It’s an abstraction that has no real existence.
A swarm is not a packet network, or really any kind of a network — no client accepts and forwards messages to another client. For contrast, DHT *is* a network and does forward data up and down the “line”, for the benefit of other nodes.
You cannot “disconnect from the swarm”. Neither can you connect to it. It doesn’t exist in a sense where this would be possible.
So what does this mean? Is it a claim that BitComet drops its connection with any peer that it just received a piece of data from? If so, then anyone can observe that this is false simply by running BitComet and observing its behavior.
When is a client supposed to connect; remain connected; permissibly disconnect from another peer? The protocol is silent on the subject. There is no specification, and no standard. If someone wishes to establish a standard by inference, then they do need to include the normal behavior of one of the most popular bittorent clients out there: BitComet.
If there is no standard, then no one can violate it. There are merely differences in opinion, in approach, in execution. New systems that cannot cope with existing and permissible behavior, are broken.
——————-
There is still an unanswered question: WHY would BitComet or any other client do this? What does it gain from whatever it supposedly does? Will it download the torrent faster? No. The torrent will finish according to the timetable that the super-seeder sets, and nothing external can affect that.
Pragmatically, all this would mean that if you use BitComet on a super-seeded swarm, and all this is supposed to get you an “unfair” advantage, then you should finish the download sooner than all the other clients.
Good, this is a testable result, a doable experiment. So try it yourself. Fire up BitComet, find a swarm that’s being super-seeded, and have at it. You can see how fast it’s going for all the other peers, since you’re all reporting the percentage completed to each other.
Hmm. You will proceed at the same pace, at the same time, with all of the other clients in this swarm, all of the Azurei, and the µtorrents, and the mainlines. You all finish at the same time, as close as makes no difference. There’s no net advantage to BitComet at all.
Which is utterly predictable.
We are not a noticeably altruistic bunch, we bittorrenters. Considering that most of the material we deal with is infringing someone’s copyright, it’s not exactly a shock. Staunch moralists, forthright do-gooders, we ain’t.
So if one client actually had hit on a method to download faster or grab an “unfair share”, then we would all enlighten our self-interest, jump on that client and use it. Yes, even if it’s “wrong”. Just about everything we do is pretty dubious from a strict ethical standpoint, and that’s never stopped any of us.
The bad or exceptional behaviour would quickly become the norm. If there were any edge to be had in doing things that way, all clients would soon do them that way. Then everything would stabilize at the new norm. Everything would be right back where it was/is. The system ecology’s feedback, positive and negative, self-stabilizes it.
Where are we?
- Still no explanation of how the SS system can be gamed in any way. This attempt isn’t plausible.
- Still no explanation of whatever it is that BC is supposedly doing that it shouldn’t do, or how it does that, or why that matters.
- No apparent advantage to BC in doing whatever-that-is. Since it’s not faster, there’s no evident reason to do it. If BC is gaming the system, it sure ain’t doing that too well.
We got sound and we got fury. Answers, we don’t got.
Cars explains:
bitcomet is very smart because if a superseed send person A data then we would expect for person A to pass on to person B but that doesn’t happen…because as soon as a superseed sends person A data person A drops out of the swarm then reconnects posing as a new peer then it wants more data and gets it.
This begs the question of how BitComet can “pose as a new peer”? There isn’t any such concept as “new peer” in the protocol, or in the super=seeding extension. All peers are basically equal. There’s no status code that means, “I’m a new peer”.
Interoperability requires that all clients adhere to rigidly defined protocol specifications, which cannot be unilaterally changed. If anyone tries, the remainder of the clients out there will not know how to respond to it. Therefore the list of messages that one client can send to another is clearly specified in the protocol. Any others are not allowed and will be rejected as invalid arguments.
None of them include anything like the concept of “I’m a new peer”.
Since BitComet can’t send any such message and expect to be understood, BitComet cannot “pose” as anything. The protocol does not allow it.
Back to Cars:
meaning that superseeder has to work even harder now because person A wants more data but now theres a problem because person B want data also data that it didn’t get off person A .
Let’s clean this up a bit, with Sigma as the superseeding client, and alpha and beta as peers.
Sigma sends alpha a piece X. Now according to Cars, Alpha did something unspecified that induces Sigma to give it another piece, and Sigma gives Alpha piece Y.
But, says Cars, here is Beta, and it is requesting piece X from Sigma because it didn’t get it from Alpha. Um, wait a second… how can this be? On any level?
Sigma is a super-seeder. It “doesn’t have” any pieces except the ones it decides to “reveal”. Alpha and Beta don’t drive this process, Sigma does. Alpha doesn’t ask, Sigma tells. Beta doesn’t ask for piece Z, Sigma says it’s got piece Z now and does Beta want it?
The rest of the time, Sigma says it is a peer that doesn’t have any pieces Alpha and Beta don’t have.
But Sigma is a super-seeder. It already sent out piece X, and isn’t going to send it again until it has sent all the rest of the torrent. (That’s its brief: send out each piece only once.)
In the meantime, the (unproven, unestablished, unjustified and falsifiable) assumption is made that alpha isn’t sharing any of the pieces it gets. But Sigma is sending out pieces one at a time, each one only once, according to its own schedule, whether alpha is sharing, not sharing, or even present.
How then, is Sigma “working harder” if it’s doing the same thing it would be doing, according to the same schedule in any case?
But perhaps Sigma isn’t? That would mean that Sigma is sitting idle for long periods, sending nothing. And then it’s a claim that Sigma is being deceived into taking action and sending a piece, that it otherwise would not send.
Oops! If Sigma is sitting idle, that pretty much finishes the notion that super-seeding is faster, or more efficient at distributing torrents than regular seeding. If it could be sending but isn’t, then that’s just wasted time it could be using to send out the rarest piece of the moment. It’s hard to see why anyone would ever want to use this. It would have to be slower than regular seeding.
————————————-
BitComet has no way to say, “I’m new to the swarm”. Neither does any other client. There’s no protocol for that.
It might be, though, that a superseeder stops tracking BitComet for whatever reason. But since BitComet predates super-seeding by years, and behaves the same way it always has, this would be the super-seeder’s failure to cope with the existing ecology. If the SS is misinterpreting BC’s actions, then it’s up to the SS to stop doing that instead of blaming everyone else.
If the superseeder is making assumptions about the existence of behaviors that are not required by the protocol, then it was very badly designed. That’s its fault, nobody else’s. It needs to fix its own shortcomings, not start banning anything that doesn’t conform to its whimsical decrees.
————————————–
In sum, Cars has explained absolutely nothing. There is still no clear idea of how BC is or can game the system, while there is some suggeston here that the system failed to account for pre-existing behavior due to faulty design.
do you see a pattern here
even in normal seed mode this can happen bittcomet loves to disconnect from the swarm every time it recieves a piece of data.
Among the other messages like “new peer” that there aren’t, one of them that there isn’t is “disconnect”. Since there’s no such message, no other client would understand it or honor it. So how does BitComet do this disconnecting?
All of the TCP connections are one-on-one. Alpha to beta, alpha to gamma, alpha to delta. There is no “swarm”, in this sense, there are only the individual connections. There is no way to “disconnect from the swarm”, since the swarm is nothing more than the aggregate of all individual connections interested in a particular torrent. It’s an abstraction that has no real existence.
A swarm is not a packet network, or really any kind of a network — no client accepts and forwards messages to another client. For contrast, DHT *is* a network and does forward data up and down the “line”, for the benefit of other nodes.
You cannot “disconnect from the swarm”. Neither can you connect to it. It doesn’t exist in a sense where this would be possible.
So what does this mean? Is it claiming that BitComet drops its connection with any peer that it just received a piece of data from? If so, then anyone can observe that this is false simply by running the BitComet and observing its behavior.
When is a client supposed to connect; remain connected; permissably disconnect? The protcol is silent on the subject. There is no specification, and no standard. If someone wishes to establish a standard by inference, then they do need to include the normal behavior of one of the most popular bittorent clients out there: BitComet.
If there is no standard, then no one can violate it. There are merely differences in opinion, in approach, in execution. New systems that cannott cope with existing and permissible behavior, are broken.
——————-
There is still an unanswered question: WHY would BitComet or any other client do this? What does it gain from whatever it supposedly does? Will it download the torrent faster? No. THe torrent will finish according to the timetable that the super-seeder sets, and nothing external can affect that.
Pragmatically, all this would mean that if you use BitComet on a super-seeded swarm, and all this is supposed to get you an “unfair” advantage, then you should finish the download sooner than all the other clients.
Good, this is a testable result, a doable experiment. So try it yourself. Fire up BitComet, find a swarm that’s being super-seeded, and have at it. You can see how fast it’s going for all the other peers, since you’re all reporting the percentage completed to each other.
Hmm. You will proceed at the same pace, at the same time, with all of the other clients in this swarm, all of the Azurei, and the µtorrents, and the mainlines. You all finish at the same time, as close as makes no difference. There’s no net advantage to BitComet at all.
Anyone of intelligence could have predicted that sight unseen.
We are not a noticeably altruistic bunch, we bittorrenters. Considering that most of the material we deal with is infringing someone’s copyright, it’s not exactly a shock. Staunch moralists, forthright do-gooders, we ain’t.
So if one client actually had hit on a method to download faster or grab an “unfair share”, then we would all enlighten our self-interest, jump on that client and use it. Yes, even if it’s “wrong”. Just about everthing we do is pretty dubious from a strict ethical standpoint, and that’s never stopped any of us.
The bad or exceptional behaviour would quickly become the norm. If there were any edge to be had in doing things that way, all clients would soon do them that way. Then everything would stabilize at the new norm. Everything would be right back where it was/is. Its feedback, positive and negative, self-stabilizes it.
Where are we?
- Still no explanation of how the SS system can be gamed in any way. This attempt isn’t plausible.
- Still no explanation of whatever it is that BC is supposedly doing that it shouldn’t do, or how it does that, or why that matters.
- No apparent advantage to BC in doing whatever-that-is. Since it’s not faster, there’s no reason to do it. If BC is gaming the system, it sure ain’t doing that too well.
We got sound and fury. But we got nothing more.
To be “new to the swarm” means to drop (disconnect) the TCP connection to the seeder. Then reestablish. That simple.
Except that will not work. Even if Alpha drops his connection from Beta, Alpha is still in Beta’s IP list. And the swarms IP list as well and still reporting statics to the tracker.
The tracker has nothing to do with superseeding. Beta may or may not keep the ip in it’s list, that is an assumption. Some clients do and some clients don’t. Also, depending on the implementation, some data may be kept but not all. (uTorrent is an example of a client that will save stats for a while (minutes) but not for too long .) Since I don’t have access to BitTornados code I can’t say one way or another. A way to avoid the described superseed abuse would be to keep dropped peer data for a short while.
That being said, if it is true that BitComet drops, then reconnects, as a design feature, then that is bad behavior and shouldn’t have to be programmed around. One would hope that Bitcomet would be fixed.
[quote comment="37259"]Dark Shroud you want an example?
I just at this very moment hit the “log peer traffic” button, and one of the first things that almost instantly came up was:
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Request while choked: 451:114688->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:49152->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:65536->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:81920->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:98304->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:114688->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Request while choked: 451:49152->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Request while choked: 451:65536->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Request while choked: 451:81920->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Request while choked: 451:98304->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Request while choked: 451:114688->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:49152->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:65536->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:81920->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:98304->16384
[01:25:01] 85.166.206.x : [BitComet/0070 ]: Got Cancel Unrequested: 451:114688->16384[/quote]
I know that this is a bit late, but I have been checking out my torrent behavior and wanted to point out that the Request While Choked message is normal behavior. The process to send data, i.e. unchoke, get request, send data, get, send, get, send,…., choke. Will often result in a final get causing this message. It is normal. Still investigating.
Hey guys,
I use bitcomet just for the features and GUI. I have switched over to utorrent. But I dont feel comfortable with it.
What if I get fast downloads, but seed till the ratio is 2.0 (which I normally do). Am I still cheating? I mean, bitcomet might not be so efficient there, but ultimately, sooner or later, I am sending out what I should be sending out.
BTW, utorrent seems to be a bit slow. I am downloading Opensuse 10.2
“To be “new to the swarm” means to drop (disconnect) the TCP connection to the seeder. Then reestablish. That simple.”
This becomes interesting. Has super-seeding created the very problem it’s blaming others for? It appears so. Consider:
On one torrent I saw not long ago, the tracker returned a list of something like 128 seeds and 1,500 peers. A largish swarm, but not really unusual. (Obviously not being super-seeded, but that’s not relevant at the moment.)
It is, I hope, evident to all that no single client is going to connect to all hundred–plus seeds and all thousand-plus peers. They don’t all have spare connections and a client can’t maintain that many connections at once. The point being, you connect to SOME, not ALL, of the swarm members. Just as some, but not all of them connect to you.
Since you are choosing only some, how is the choice made? What’s the basis for selection? It’s simple greed. This is our so-called “greedy algorithm”. Each client tries for the best connections it can find, bearing in mind that connection is a mutual agreement.(The reason you have all those half-open connections is because you or the other party haven’t mutually agreed yet. Maybe you will, maybe you won’t.)
In order for this finding process to go forward, a client must rotate its connections — it must drop some and try new ones, to fulfill its mandate of finding the best it can get. This IS mandated behavior, not least in order to prevent peers from locking each other in and to allow new peers a way to get into the swarm, though the details like timing are not specified.
Those peers that respond, that offer pieces it does not have, and that send those pieces timely, are good connections and should be kept. Those that don’t respond, have no pieces of interest or don’t send them timely, are bad connections and should be dropped. We’re not talking about BitComet here, we’re talking about all clients.
This is the normal case. Let’s apply it to super-seeding.
Suppose we have a super-seed, working normally. You connect to it. It claims to be just another peer, but from time to time it says that it has a new piece. What about all the other times? The rest of the time, it says it doesn’t have anything new.
Does that make it a good connection? Or does reporting that most of the time, it doesn’t have any new pieces it’s willing to offer, make it one of the poorer connections in your list, and a good candidate for replacement with another, hopefully better connection? Keeping in mind that you don’t know it’s a seeder, it says it’s just another peer?
Which do you think?
So, having invited, if not caused this by its own behavior, it now claims that anyone who opts to look for a better connection is suddenly doing something wrong.
This is all clients, not just BitComet. But if the BC algorithm is so much sharper and more efficient at spotting and pruning the poorly-performing connections, well, you can understand why other clients would be envious of that.
——————
Does the protocol mandate, or even address when connections are to be maintained, started, stopped? It does not. Any assumptions you make about that are erroneous.
——————–
BitComet’s behavior has not changed. It has always acted the way it acts now. When super-seeding was introduced, it was added to a pool that already included this behavior. In other words, Shadow KNEW or should have known, at the time he did it, that some bittorrent clients did not maintain connections with poorly performing peers for very long. It was up to him to allow for that, to write his code to compensate for and deal with it. If he did not, then he dropped the ball. It was and is his own error, nobody else’s. He compounded the error by failing to note that his change would make his client appear to be an undesirable connection to others, liable to be dropped by them, and to allow for that.
It is his job to maintain state information for as long as it turns out to be necessary. He’s the one introducing this, after all. If he doesn’t persist his own data or maintain it for long enough to deal with the known behavior of existing clients, that’s also his mistake. If he just assumed that every client would have the same pattern and timing as his own, in the complete absence of standards, then he fumbled badly.
If he drops the state information prematurely, he’s gaming his own client, then looking for somebody else to blame. Somebody hand the guy a mirror.
[quote comment="41057"]Cars explains:
================================
bitcomet is very smart because if a superseed send person A data then we would expect for person A to pass on to person B but that doesn’t happen…because as soon as a superseed sends person A data person A drops out of the swarm then reconnects posing as a new peer then it wants more data and gets it.
=================================
[/quote]
So what ? finally a good client you moron.
No one even uses BitTornado anyways. I doubt it would make ANY difference.
I used to use Bitcomet and I would seed good with it too, but then I decided to use utorrent because it seemed like the nice thing to do, it didn’t slow down that much and I still seed with it. Blocking a good client with an inferior one will not do anything.
I’m pretty sure if you recconect to a new swarm you are considered ‘new’. So does BC connect to a new swarm each time?
oh god does it have to be this big fight about which stupid thing to use i use bitcomet i leave it on all day and all night to seed but for some reason it stoped working now i know why crappy people that just want to harm others decided they want to fight over software its a free client people what do u expect now days u cant get anything for free theres always fighting and some type of price to pay thats life get used to it
I’ll stick with utorrent. Tried others, but I’ll stick with what works best for me.
wow bitcomet is grimey. so stop using it u fricken noobs. also bitcomet guy and bittornado guy should join forces. they could probably make some kick ass stuff.
demonoid
Bit Comet is slow and crappy. uTorrent dl’d what Bit Comet struggled to get in 3-4days in less than 24hrs and the entire file in 48. Why people use a constricting client like Bit Comet is just beyond all signs of intelligence. It is slow to dl, it is on most GOOD trackers ban list and it has retarded little file type extensions that make it so you can’t resume a download with another client which is absolutly retarded.
Bit Comet is the worst Torrent client I’ve ever seen, and I’ve been torrenting since the first one was released by Cohen.
As well, Shad0w, just suck it up. Your client sucks just like your RO server sucked back in the day. Cry more n00b (And if you’re not the Shad0w that ran the Shad0wRO, well then, someone took credit for your client when it was first released, either way, the client sucked then and it sucks now)
åšæŒç”¨bitcomet。
[quote comment="41057"]Cars explains:
================================
bitcomet is very smart because if a superseed send person A data then we would expect for person A to pass on to person B but that doesn’t happen…because as soon as a superseed sends person A data person A drops out of the swarm then reconnects posing as a new peer then it wants more data and gets it.
=================================
This begs the question of how BitComet can “pose as a new peer”? There isn’t any such concept as “new peer” in the protocol, or in the super=seeding extension. All peers are basically equal. There’s no status code that means, “I’m a new peer”.
Interoperability requires that all clients adhere to rigidly defined protocol specifications, which cannot be unilaterally changed. If anyone tries, the remainder of the clients out there will not know how to respond to it. Therefore the list of messages that one client can send to another is exclusively specified in the protocol. Any others are not allowed and will be rejected as invalid arguments.
None of them include anything like the concept of “I’m a new peer”.
Since BitComet can’t send any such message and expect to be understood, BitComet cannot “pose” as anything. The protocol does not allow it.
Back to Cars:
============================
(…)meaning that superseeder has to work even harder now because person A wants more data but now theres a problem because person B want data also data that it didn’t get off person A .
============================
Let’s clean this up a bit, with Sigma as the superseeding client, and alpha and beta as peers.
Sigma sends alpha a piece X. Now according to Cars, Alpha did something unspecified that induces Sigma to give it another piece, and Sigma gives Alpha piece Y.
But, says Cars, here is Beta, and it is requesting piece X from Sigma because it didn’t get it from Alpha. Um, wait a second… how can this be? On any level?
Sigma is a super-seeder. It “doesn’t have” any pieces except the ones it decides to “reveal”. Alpha and Beta don’t drive this process, Sigma does. Alpha doesn’t ask, Sigma tells. Beta doesn’t ask for piece Z, Sigma says it’s got piece Z now and does Beta want it?
The rest of the time, Sigma claim it is just another peer, and doesn’t have any pieces Alpha and Beta don’t have.
But Sigma is a super-seeder. It already sent out piece X, and isn’t going to send it again until it has sent all the rest of the torrent. (That’s its brief: send out each piece only once.) So Beta can’t effectively ask, and Sigma won’t itself offer Beta piece X.
In the meantime, the (unproven, unestablished, unjustified and falsifiable) assumption is made that alpha isn’t sharing any of the pieces it gets. But Sigma is sending out pieces one at a time, each one only once, according to its own schedule, whether alpha is sharing, not sharing, or even present.
How then, is Sigma “working harder” if it’s doing the same thing it would be doing, according to the same schedule in any case?
But perhaps Sigma isn’t? That would mean that Sigma is sitting idle for long periods, sending nothing. And then it’s a claim that Sigma is being deceived into taking action and sending a piece, that it otherwise would not send.
Oops! If Sigma is sitting idle, that pretty much finishes the notion that super-seeding is faster, or more efficient at distributing torrents than regular seeding. If it could be sending but isn’t, then that’s just wasted time it could be using to send out the rarest piece of the moment. It’s hard to see why anyone would ever want to use this. It would be far slower than regular seeding.
————————————-
BitComet has no way to say, “I’m new to the swarm”. Neither does any other client. There’s no protocol for that.
It might be, though, that a superseeder stops tracking BitComet for whatever reason. But since BitComet predates super-seeding by years, and behaves the same way it always has, this would be the super-seeder’s failure to cope with the existing ecology. If the SS is misinterpreting BC’s actions, then it’s up to the SS to stop doing that instead of blaming everyone else.
If the superseeder is making assumptions about the existence of behaviors that are not required by the protocol, then it was very badly designed. That’s its fault, nobody else’s. It needs to fix its own shortcomings, not start banning anything that doesn’t conform to its whimsical decrees.
————————————–
In sum, Cars has explained absolutely nothing. There is still no clear idea of how BC is or can game the system, while there is some suggestion here that the system failed to account for pre-existing behavior due to faulty design.
do you see a pattern here
even in normal seed mode this can happen bittcomet loves to disconnect from the swarm every time it recieves a piece of data.
Among the other messages like “new peer” that there aren’t, one of them that there isn’t is “disconnect”. Since there’s no such message, no other client would understand it or honor it. So how does BitComet do this disconnecting?
All of the TCP connections are one-on-one. Alpha to beta, alpha to gamma, alpha to delta. There is no “swarm”, in this sense, there are only the individual connections. There is no way to “disconnect from the swarm”, since the swarm is nothing more than the aggregate of all individual connections interested in a particular torrent. It’s an abstraction that has no real existence.
A swarm is not a packet network, or really any kind of a network — no client accepts and forwards messages to another client. For contrast, DHT *is* a network and does forward data up and down the “line”, for the benefit of other nodes.
You cannot “disconnect from the swarm”. Neither can you connect to it. It doesn’t exist in a sense where this would be possible.
So what does this mean? Is it a claim that BitComet drops its connection with any peer that it just received a piece of data from? If so, then anyone can observe that this is false simply by running BitComet and observing its behavior.
When is a client supposed to connect; remain connected; permissibly disconnect from another peer? The protocol is silent on the subject. There is no specification, and no standard. If someone wishes to establish a standard by inference, then they do need to include the normal behavior of one of the most popular bittorent clients out there: BitComet.
If there is no standard, then no one can violate it. There are merely differences in opinion, in approach, in execution. New systems that cannot cope with existing and permissible behavior, are broken.
——————-
There is still an unanswered question: WHY would BitComet or any other client do this? What does it gain from whatever it supposedly does? Will it download the torrent faster? No. The torrent will finish according to the timetable that the super-seeder sets, and nothing external can affect that.
Pragmatically, all this would mean that if you use BitComet on a super-seeded swarm, and all this is supposed to get you an “unfair” advantage, then you should finish the download sooner than all the other clients.
Good, this is a testable result, a doable experiment. So try it yourself. Fire up BitComet, find a swarm that’s being super-seeded, and have at it. You can see how fast it’s going for all the other peers, since you’re all reporting the percentage completed to each other.
Hmm. You will proceed at the same pace, at the same time, with all of the other clients in this swarm, all of the Azurei, and the µtorrents, and the mainlines. You all finish at the same time, as close as makes no difference. There’s no net advantage to BitComet at all.
Which is utterly predictable.
We are not a noticeably altruistic bunch, we bittorrenters. Considering that most of the material we deal with is infringing someone’s copyright, it’s not exactly a shock. Staunch moralists, forthright do-gooders, we ain’t.
So if one client actually had hit on a method to download faster or grab an “unfair share”, then we would all enlighten our self-interest, jump on that client and use it. Yes, even if it’s “wrong”. Just about everything we do is pretty dubious from a strict ethical standpoint, and that’s never stopped any of us.
The bad or exceptional behaviour would quickly become the norm. If there were any edge to be had in doing things that way, all clients would soon do them that way. Then everything would stabilize at the new norm. Everything would be right back where it was/is. The system ecology’s feedback, positive and negative, self-stabilizes it.
Where are we?
- Still no explanation of how the SS system can be gamed in any way. This attempt isn’t plausible.
- Still no explanation of whatever it is that BC is supposedly doing that it shouldn’t do, or how it does that, or why that matters.
- No apparent advantage to BC in doing whatever-that-is. Since it’s not faster, there’s no evident reason to do it. If BC is gaming the system, it sure ain’t doing that too well.
We got sound and we got fury. Answers, we don’t got.
Cars explains:
bitcomet is very smart because if a superseed send person A data then we would expect for person A to pass on to person B but that doesn’t happen…because as soon as a superseed sends person A data person A drops out of the swarm then reconnects posing as a new peer then it wants more data and gets it.
This begs the question of how BitComet can “pose as a new peer”? There isn’t any such concept as “new peer” in the protocol, or in the super=seeding extension. All peers are basically equal. There’s no status code that means, “I’m a new peer”.
Interoperability requires that all clients adhere to rigidly defined protocol specifications, which cannot be unilaterally changed. If anyone tries, the remainder of the clients out there will not know how to respond to it. Therefore the list of messages that one client can send to another is clearly specified in the protocol. Any others are not allowed and will be rejected as invalid arguments.
None of them include anything like the concept of “I’m a new peer”.
Since BitComet can’t send any such message and expect to be understood, BitComet cannot “pose” as anything. The protocol does not allow it.
Back to Cars:
meaning that superseeder has to work even harder now because person A wants more data but now theres a problem because person B want data also data that it didn’t get off person A .
Let’s clean this up a bit, with Sigma as the superseeding client, and alpha and beta as peers.
Sigma sends alpha a piece X. Now according to Cars, Alpha did something unspecified that induces Sigma to give it another piece, and Sigma gives Alpha piece Y.
But, says Cars, here is Beta, and it is requesting piece X from Sigma because it didn’t get it from Alpha. Um, wait a second… how can this be? On any level?
Sigma is a super-seeder. It “doesn’t have” any pieces except the ones it decides to “reveal”. Alpha and Beta don’t drive this process, Sigma does. Alpha doesn’t ask, Sigma tells. Beta doesn’t ask for piece Z, Sigma says it’s got piece Z now and does Beta want it?
The rest of the time, Sigma says it is a peer that doesn’t have any pieces Alpha and Beta don’t have.
But Sigma is a super-seeder. It already sent out piece X, and isn’t going to send it again until it has sent all the rest of the torrent. (That’s its brief: send out each piece only once.)
In the meantime, the (unproven, unestablished, unjustified and falsifiable) assumption is made that alpha isn’t sharing any of the pieces it gets. But Sigma is sending out pieces one at a time, each one only once, according to its own schedule, whether alpha is sharing, not sharing, or even present.
How then, is Sigma “working harder” if it’s doing the same thing it would be doing, according to the same schedule in any case?
But perhaps Sigma isn’t? That would mean that Sigma is sitting idle for long periods, sending nothing. And then it’s a claim that Sigma is being deceived into taking action and sending a piece, that it otherwise would not send.
Oops! If Sigma is sitting idle, that pretty much finishes the notion that super-seeding is faster, or more efficient at distributing torrents than regular seeding. If it could be sending but isn’t, then that’s just wasted time it could be using to send out the rarest piece of the moment. It’s hard to see why anyone would ever want to use this. It would have to be slower than regular seeding.
————————————-
BitComet has no way to say, “I’m new to the swarm”. Neither does any other client. There’s no protocol for that.
It might be, though, that a superseeder stops tracking BitComet for whatever reason. But since BitComet predates super-seeding by years, and behaves the same way it always has, this would be the super-seeder’s failure to cope with the existing ecology. If the SS is misinterpreting BC’s actions, then it’s up to the SS to stop doing that instead of blaming everyone else.
If the superseeder is making assumptions about the existence of behaviors that are not required by the protocol, then it was very badly designed. That’s its fault, nobody else’s. It needs to fix its own shortcomings, not start banning anything that doesn’t conform to its whimsical decrees.
————————————–
In sum, Cars has explained absolutely nothing. There is still no clear idea of how BC is or can game the system, while there is some suggeston here that the system failed to account for pre-existing behavior due to faulty design.
do you see a pattern here
even in normal seed mode this can happen bittcomet loves to disconnect from the swarm every time it recieves a piece of data.
Among the other messages like “new peer” that there aren’t, one of them that there isn’t is “disconnect”. Since there’s no such message, no other client would understand it or honor it. So how does BitComet do this disconnecting?
All of the TCP connections are one-on-one. Alpha to beta, alpha to gamma, alpha to delta. There is no “swarm”, in this sense, there are only the individual connections. There is no way to “disconnect from the swarm”, since the swarm is nothing more than the aggregate of all individual connections interested in a particular torrent. It’s an abstraction that has no real existence.
A swarm is not a packet network, or really any kind of a network — no client accepts and forwards messages to another client. For contrast, DHT *is* a network and does forward data up and down the “line”, for the benefit of other nodes.
You cannot “disconnect from the swarm”. Neither can you connect to it. It doesn’t exist in a sense where this would be possible.
So what does this mean? Is it claiming that BitComet drops its connection with any peer that it just received a piece of data from? If so, then anyone can observe that this is false simply by running the BitComet and observing its behavior.
When is a client supposed to connect; remain connected; permissably disconnect? The protcol is silent on the subject. There is no specification, and no standard. If someone wishes to establish a standard by inference, then they do need to include the normal behavior of one of the most popular bittorent clients out there: BitComet.
If there is no standard, then no one can violate it. There are merely differences in opinion, in approach, in execution. New systems that cannott cope with existing and permissible behavior, are broken.
——————-
There is still an unanswered question: WHY would BitComet or any other client do this? What does it gain from whatever it supposedly does? Will it download the torrent faster? No. THe torrent will finish according to the timetable that the super-seeder sets, and nothing external can affect that.
Pragmatically, all this would mean that if you use BitComet on a super-seeded swarm, and all this is supposed to get you an “unfair” advantage, then you should finish the download sooner than all the other clients.
Good, this is a testable result, a doable experiment. So try it yourself. Fire up BitComet, find a swarm that’s being super-seeded, and have at it. You can see how fast it’s going for all the other peers, since you’re all reporting the percentage completed to each other.
Hmm. You will proceed at the same pace, at the same time, with all of the other clients in this swarm, all of the Azurei, and the µtorrents, and the mainlines. You all finish at the same time, as close as makes no difference. There’s no net advantage to BitComet at all.
Anyone of intelligence could have predicted that sight unseen.
We are not a noticeably altruistic bunch, we bittorrenters. Considering that most of the material we deal with is infringing someone’s copyright, it’s not exactly a shock. Staunch moralists, forthright do-gooders, we ain’t.
So if one client actually had hit on a method to download faster or grab an “unfair share”, then we would all enlighten our self-interest, jump on that client and use it. Yes, even if it’s “wrong”. Just about everthing we do is pretty dubious from a strict ethical standpoint, and that’s never stopped any of us.
The bad or exceptional behaviour would quickly become the norm. If there were any edge to be had in doing things that way, all clients would soon do them that way. Then everything would stabilize at the new norm. Everything would be right back where it was/is. Its feedback, positive and negative, self-stabilizes it.
Where are we?
- Still no explanation of how the SS system can be gamed in any way. This attempt isn’t plausible.
- Still no explanation of whatever it is that BC is supposedly doing that it shouldn’t do, or how it does that, or why that matters.
- No apparent advantage to BC in doing whatever-that-is. Since it’s not faster, there’s no reason to do it. If BC is gaming the system, it sure ain’t doing that too well.
We got sound and fury. But we got nothing more.[/quote]
Bitcomet adds .bc extensions to every file, to distiguish those incomplete files. Easy to turn off in options though.
I have had some problems with bitcomet newer than .70. But it’s easy to find .70 on the forums and what not.
Anyhow, one day AT&T will own all computers, and they will ban bitcomet and you will all be happy. THERE.
Everyone should keep an eye on the Wikipedia entry for BitComet, as there appears to be a bad-faith effort to keep criticism of that client out of the entry.
(And someone also create an entry for John Hoffman.)
Some of u guys realy sucks.
BC is a realy good pogram cuz its running on allmost every computer, it has no spam or banners and they don’t send u stupid junkmail.
I’m a student and i come home about 4 o clock. I don’t care if my DL speed is slow or fast with “super seed” I don’t care if my new cd is ready by 1 or 2 o’clock, as long as i can listen to my new cd! Wenn u guys are banning BC u doing a lot of damage to P2P community. I mean u get all those games/cd’s/movies for free so be happy with it.
Don’t start a whole war about this! U guys r realy a bunch of kids!!
Grz Henk, Holland
Well, I see that you Gentleman have answered all your own questions. 1. I see that BC is faster and now is made to appear slower by being banned and not allowed to seed, FOOLISH. The reason you see the requests is because it is faster and with a speedy system you can refresh faster. But in anycase the peer or the SS can not be made to lie unless you introduce a mini virus which would be counter productive. I say lets get programming instead of bitching and we will all receive the benefit of the faster peer to peer and SS functions that at least BC is trying to accomplish. “The man who rows the boat, Generally does not have time to rock it”!
Let’s embrase this technologies that is allowing us to steal peoples stuff and share i, instead of bitching.
if you say that BitComet is not good
,wat is the best bittorrent client?
What do you sugest?
LOL! These anti-BitComet people always give me such a laugh with their sanctimonious rants. I know it’s not considered polite to laugh “at” other people, but these people set themselves up for it and deserve it! Thanks for the chuckle!
That is a lie, i’ve seen that its acually sharing alot, every file i’ve tested downloading with it has sent up a lot of kbps to other torrent users… so whats the big deal? -.-
Lol @64
Well said my brain is hurting already and I still have more to read!!
This BANNING crap is a stupid thing, dont solve anything. The health of torrents is mainly depend on seeders. Unfortunately the most of torrent users logging off/stopping the stream ,when them file downloaded fully/100 percently. This is the main (99.9%) reason, why downloading speeds r usually not the bests.
Bitcomet is an easy to use,comfortable client, and can help to peers and can be for seed as gud as any other torrent clients,the sharing is depend on peeps stay online after them file sucesfully downloaded or closeing the session and stopping the share while for em not necessary.
The problem is not abt BITCOMET, the problems made by b00bs and egoist n00bs.
serpens
[quote comment="36993"]bitcomet does indeed suck but there are 2 problems with this:
1. how can bitcomet game superseeding? as i’ve always seen it explained, a superseed judges a client’s upload by seeing how fast its pieces appear in the swarm. how can bitcomet make other clients lie about what they’ve recieved?
2. don’t lump bittyrant in with bitthief and bitcomet. it basically does the same thing as superseeding by prioritizing upload to other clients that upload fast.[/quote]
WANKER
Okay, nobody might care about my input, but I just checked a random torrent in my BitComet, and like 90% of the uploaders are actually running BitComet (yeah yeah, could be coincidence). I think all this criticism is a load of bull.
read this….
http://forums.bitcomet.com/index.php?showtopic=6675
dont talk about this “Bitcomet is cheating” thing… its been over for a long time.
Just a few words bout Bitcommet,
look for BuRnT1 on Demonoid or BuRnT on Darksiderg,TPB or torrentbox.Ive uploaded all my stuff with BitCommet 070 without problems and i always upload more than i download so go ahead ban my client and you get non of my ups,
Both Bitcommet and UTorrent can be configured to limit upload speed..
It is this and Hit and Run downloaders that hurt the community
and with BitCommet limiting you uploads also limit your downloads
Seed like MoFos… BuRnT.
thanks but i need a high speed
I use bit comet and its not right to ban all the users becose for example I seed at 80 and only load at 50 so bannig all the users won’t do just ban those who upload around10 and load around 200k
We All Choose The P2p Managers that best suit us. We Make an informed choice on whether or not to get slower clients or fast clients or clients that divides upload/download time. Therefore, the choice is to us not the developers on how we use our bandwidth. If we let people choose how we use our bandwidth, then the music industries and the movie industries have already won, you FUCKING IDIOTs. These people watch these pages and see how they can help to destroy the little freedom we have left.All of us Don’t live in Canada Away from prosecution
I ban BitComet/BitLord,Tyrant,Thief users on Azureus with the stuffer program as well as “Unknown” or clients who appear as some gibberish string of letters (usually individuals who’ve modified one of the clients for nefarious outcomes).
If only Utorrent had a similar function. ipfilter.dat is not really of much use for this.
Looking over all the posts the responses by the Bitcomet supporters are all well thought out and respond to the complaints of the BitTornado users, the replies to those thought out posts are the basically the hooting of monkeys. Loud but lacking any actual content. They don’t bother to actually form intelligent replies but just state that the well thought out explainations are just wrong but give no reason why.
I’m not sure it actually matters at all though. Looking at several of my torrents there are over 80 users with BitComet and 5 with BitTornado out of about 400 clients that I am connected to. The vast majority of clients are µTorrent or Azureus. I personally would not care in the slightest if BitTornado banned a client I was using. I would not miss the 1-2 peers out of every 100 that would lead to.
EXAMINING THE MYTHS AND FACTS CONCERNING BITCOMET BEHAVIOR
By Robb Topolski, July 31, 2007
FORWARD
The purpose of this paper is to provide independent data to the BitTorrent community about several persistent concerns regarding the BitComet client.
I am posting this information to the BitComet forum, and I will be notifying certain purveyors of P2P news and information about it.
My name is Robb Topolski, and I’ve been on the Internet since before the World-Wide-Web! I am a networking and protocol expert, with more than 25 years of experience. I have been recognized as a Certified Software Quality Engineer by the American Society for Quality, and I have been recognized as a Microsoft Most-Valued Professional in Networking. I consider myself an ever-learning expert in software quality, security, testing, and networking.
I was not asked by anyone to do this testing and analysis. I have approached the managers of the BitComet forum in an attempt to get information, but they have not been notified in advance of my testing results. This work is independent and is without the permission or direction of anyone on the BitComet team.
I have been studying the BitTorrent protocol for over a year, and grew curious about these accusations concerning BitComet. I decided to test some of the most popular “accusations.” In some cases, I applied direct testing, using popular analysis tools such as Wireshark to observe the “wire” behaviors of BitComet. In some cases, I determined that the protocol itself lent either credit or discredit to a particular accusation.
I found that my ISP was interfering with my tests — even showing some of the “quick disconnect” behaviors frequently associated with BitComet (although the behaviors were seen across all clients). My ISP frequently “shapes” or redirects P2P traffic using several methods. To avoid this, all of my testing was either performed on my own LAN or on the public Internet using a secure VPN tunnel. Through the VPN, these interferences disappeared.
I am currently having long-term medical issues that leave me homebound, and a full day’s work is impossible. But it has given me the time to be able to study this closely, and keep my skills current, and this paper has slowly come together as a result.
My examination of these accusations and of the behavior of the BitComet client indicates that the raised concerns are consistently false. BitComet’s reputation has suffered due to a December 2005 DHT “leak” bug and a false perception that response to that bug was slow. Banned on many trackers since that bug, several other observed or imagined issues have been “piled on” to further tarnish the reputation of BitComet. Tracker admins reading this paper should conclude that BitComet is not the detestable client it is perceived to be.
Note: I did not go back to early versions — so my results are limited only to the versions that I tested (which are listed below).
ISSUE #1: BitComet abuses or ignores the DHT flag on private torrents.
CONCLUSION: TRUE ONLY FOR VERSION 0.60
SUMMATION: A bug existed that allowed the addition of DHT to existing “private” download tasks. The bug was found in version 0.60 in early December 2005, and the version was withdrawn two weeks later. The bug fixed in version 0.61 in January 2006 (http://www.slyck.com/story1094.html). Several private trackers banned BitComet as a result of this bug.
ISSUE #2: BitComet’s developer, RnySmile, failed to acknowledge or act upon the DHT bug (ISSUE #1) for several months.
CONCLUSION: FALSE (WAS NEVER TRUE)
SUMMATION: The timeline of the DHT bug shows that the buggy version (0.60) was replaced with the previous stable version of BitComet (0.59) within two weeks of the initial report. Three weeks later, version 0.61 was released which did not contain the DHT bug.
ISSUE #3: BitComet disconnects and immediately reconnects (approximately 10 times per second) in an attempt to be unchoked by the peer.
CONCLUSION: FALSE IN TESTED VERSIONS 0.70 (JUNE 2006) AND LATER
SUMMATION: If true, such reconnecting might give BitComet a 33% better chance in being unchoked sooner than if it remained connected. This provision in the BitTorrent protocol is intended to give new clients in a swarm some piece data to share. It is not intended for clients that return to a swarm. In numerous test runs, several versions of BitComet were observed. Indeed, they do frequently disconnect from their peers. However, it is clear that such disconnections are not an attempt to gain an advantage. Specifically, on the 0.70 through the current 0.90 versions, BitComet does stay connected for a short while (60-90 seconds) after being CHOKED by a peer. After it disconnects, it DOES NOT immediately try to reconnect. In all but one occasion, it waited more than a minute before trying to reconnect to the swarm. The delay before disconnecting and the delay before reconnecting would erase any advantage that BitComet would get if it intended to exploit the BitTorrent protocol’s unchoke rules.
NOTE: I was unable to get a specific answer from anyone as to exactly why BitComet chooses to disconnect from peers after being choked for 60-90 seconds. This behavior is allowed by the protocol, but the reason for doing so is not clear. It may help users with weak routers as such disconnections from idle clients would reduce the number of simultaneous connections. Other than that, there is very little disadvantage that I can see to remaining connected and idle. However, this is clearly a design choice and is simply a question of efficiency. BitComet’s behavior is neither incorrect nor damaging.
ISSUE #4: BitComet abuses Super-Seeding clients by failing to inform the sending peer that it successfully downloaded a piece.
CONCLUSION: FALSE (WAS NEVER TRUE)
SUMMATION: Many different BitTorrent client developers have been experimenting with withholding HAVE messages from seeding clients. The theory is that such messages are unnecessary overhead, and that debatable theory still holds even if the seeding client is using the Super-Seeding (unofficial extension to the BitTorrent protocol) feature. Super-Seeders are looking for confirmation that a unique piece that was sent to a specific peer has been shared with a third peer in the swarm. For the unique piece that was just sent to a client, Super-Seeders DO NOT depend on the HAVE message from that receiving client to confirm receipt. On the contrary, the Super-Seeder only needs the HAVE message for the unique piece from ANY OTHER CLIENT as an indicator that the peer has shared the piece to others. (Note: I did not test whether BitComet sent HAVE messages for received pieces or not. This accusation is confirmed as false based on the Seeding and Super-Seeding behaviors themselves, and the fact that the seeder never relies on the HAVE message of the receiver.)
ISSUE #5: BitComet abuses Super-Seeding clients by immediately disconnecting from and reconnecting to the Super-Seeder rather than sharing the pieces it has received.
CONCLUSION: FALSE IN TESTED VERSIONS 0.70 (JUNE 2006) AND LATER
SUMMATION: By Super-Seeding a torrent and observing BitComet client behavior in the swarm, there is no trend toward BitComet clients “holding” unique pieces , which would be the case if this issue was true. Furthermore, there is no BitComet feature, or combination of settings unique to BitComet, that would produce this behavior. As noted in ISSUE #3, BitComet does disconnect from peers more frequently than most clients. However, in the versions tested and observed, BitComet waits 60-90 seconds after being choked to disconnect and then waits 60 seconds or more to reconnect (http://forums.bitcomet.com/index.php?s=&showtopic=12787782&view=findpost&p=31159).
NOTE: Even though this is verified as false for BitComet specifically, most clients (including BitComet) and network stacks can be hacked or adjusted to create a poor sharer. BitTorrent client developers implementing Super-Seeding should take care to prevent a possible exploit to Super-Seeding by poor-sharing clients that may attempt to evade accounting for unique pieces by disconnecting and reconnecting.
ISSUE #6: BitComet announces too frequently, “hammers” the tracker, and ignores the Tracker’s “reannounce” interval.
CONCLUSION: FALSE IN TESTED VERSIONS 0.90 and 0.91
SUMMATION: It is common practice among BitTorrent clients to reannounce when the client deems that it has too-few peers. In my own experience using several BitTorrent clients, such reannouncing generally occurs between two and five minutes. BitComet seems to wait 20 minutes. In using BitComet, I found myself using the “Manual Connect” (manual reannounce) feature because I felt like BitComet was waiting too long before asking the tracker for more peers.
ISSUE #7: BitComet has an abusive multi-tracker implementation (announces to all trackers in all tier always)
CONCLUSION: FALSE IN TESTED VERSIONS 0.90 and 0.91
SUMMATION: BitComet follows the recommended practices for multi-tracker torrents. One tracker in each tier is contacted, and other trackers within a tier are not contacted unless the originally-tried tracker failed to respond.
ISSUE #8: BitComet deliberately misreports upload and download amounts to trackers and seeds in order to get the more upload bandwidth from seeders.
CONCLUSION: FALSE ACCUSATION
SUMMATION: Simply put, the BitTorrent protocol does not work that way. The tracker does not inform seeders that certain peers have preference or priority. BitComet user XSTREM suggested to me that BitComet may send a “Completed” announce message when the user elects to download only a few files from a torrent. He suggests that some tracker managers may be using that message in performing user-accounting. If that is true, then the tracker managers are applying meaning to the “Completed” message that is not supported by the specification (http://forums.bitcomet.com/index.php?s=&showtopic=12787870&view=findpost&p=32101 and http://wiki.theory.org/BitTorrentSpecifica…est_Parameters). The Completed message cannot be used as some kind of “checksum” to look for malicious users.
ISSUE #9: After reconnecting, BitComet reports having fewer pieces of the file than it had before disconnecting.
CONCLUSION: FALSE IN TESTED VERSIONS 0.70 (JUNE 2006) AND LATER
SUMMATION: This concern was raised by TheSHAD0W, the developer of the BitTornado client and the inventor of the popular Super-Seeding behavior used by many BitTorrent clients. After several carefully observed sessions and controlled test runs spanning many versions of BitComet, this reported behavior was still not seen (http://forums.bitcomet.com/index.php?s=&showtopic=12787870&view=findpost&p=30879). It is very possible that TheSHAD0W’s testing or development tools are faulty, or that there is some network problem that caused him to see this behavior. (Indeed, my own ISP is doing P2P “management” that has raised some problems in my own testing , I had to eliminate those problems by testing through a VPN).
ISSUE #10: BitComet seems to favor uploading to other BitComet clients, even when getting faster download speeds from other clients.
CONCLUSION: FALSE IN TESTED VERSIONS 0.90 and 0.91
SUMMATION: In dozens of observed sessions using BitComet, I see no such preference being given to BitComet peers.
ISSUE #11: BitComet is a poor peer due to no upload slot control. Upload bandwidth is stretched too thin.
CONCLUSION: TRUE WHEN ONLY INITIAL SEEDING, FALSE WHEN DOWNLOADING, NON-ISSUE WHEN SEEDING AN ALREADY-SEEDED TORRENT (IN TESTED VERSIONS 0.90 and 0.91)
SUMMATION:
This concern was raised by TheSHAD0W, as an issue affecting Super-Seeding. However, BitComet’s slot control is only too thin if the BitComet client is a passive seeder. As a downloader in the “Tit-for-Tat” mode, BitComet’s behavior does not spread upload slots too thin. As a result, TheSHAD0W’s concerns (which I also initially shared) are not warranted after testing and observation.
When BitComet is simply seeding, nearly every peer in the peer list is UNCHOKED and the amount of upload bandwidth given to each is often less than 1 KB/s. This is inefficient because it takes an exceptionally long time to send any one complete piece to a peer (in BitTorrent, incomplete pieces held by a peer cannot be spread). This becomes an issue when the BitComet client is holding unique pieces (such as acting as the first seeder or initial seeder to a swarm).
If the BitComet user is the initial seeder, that user will take more time and bandwidth to seed a torrent than any other BitTorrent client I have ever used. (Tests: BitComet 200% to 255%, MainLine 145% to 175%, uTorrent with Super-Seeding 105% to 115%).
However, when BitComet is a non-seeding peer, it has exceptionally intelligent slot control. BitComet adjusts the speed of each upload slot individually, providing more upload bandwidth to peers that reciprocate with more upload bandwidth of their own.
This practice tends to reward more good peers in a swarm than the traditional “slot and unchoke” BitTorrent behavior. It also allows BitComet to automatically and efficiently handle more download tasks at once. (Available in other typical BitTorrent clients only by knowledgeable use of the “Force” functions.)
BitComet uses all surplus upload bandwith first to try to find either other additional reciprocating peers or to get additional download speed from existing reciprocating peers; and second to seed to non-reciprocating peers. As a result, BitComet downloaders will perform somewhat better in swarms that have poor peers, and they may complete downloads with somewhat better ratios. (Because all available upload bandwidth is always used, BitComet is not considered a “greedy” client as described by the BitTyrant paper.)
CONCLUSIONS AND RECOMMENDATIONS:
BitComet is a worthy download client, providing some advantageous features not found in any other current BitTorrent client. Some of these features are confusing and are poorly implemented, but they are not detrimental to a BitTorrent swarm, nor do they take unfair advantage. It is a moderate user of resources. BitComet provides very little technical feedback (such as logs and other real-time indications of activity. As a result, it is less “Geek-friendly” as most other clients, it seems to attempt to be more “user-friendly” instead).
BitComet is an exceptionally poor upload client and should be avoided if the user will be the initial uploader to a swarm (see ISSUE #11 above). This is not an issue if the BitComet user is a seeder in an already-seeded swarm.
None of the typical accusations against BitComet, those that are provided as reasons for trackers or users to “Ban BitComet,” have held true. It is my professional opinion that the bans of BitComet are based on misunderstandings and falsehoods, and not on good data. Now that tracker admins are equipped with my objective and independent data and analysis, it is my hope that they reconsider their bans against this client.
Respectfully submitted to the BitTorrent community.
/s/ Robb Topolski
robb@funchords.com
BitComet sucks, BitTornado 4 ever!
I’m a bitcomet user since day 2 and I think that shadow’s generalization of bitcomet users not being the sharing type is such a bad generalization. Just to let you know, I’m a member of some private torrent sites that are strict in their ratio policy, so far I have never been banned from any of these sites, definitely not from leeching. My upload rate as well as my download rate has always been set to no limit. And no, I don’t think I’m an exception.
There’s also this bitcomet rule that for torrents that has 2 seeds or less, you cannot automatically stop seeding. You need to manually stop it. That’s the opposite of being a “harmful” codebase if you asked me. Right now, most of the files I’m downloading have a ratio of more than 1.2 and up.
Anyway, a whole lot of torrent users use bitcomet. I think shadow is essentially cutting his own arm as well as any other who would ban a big chunk of torrent users.
By the way, the founder of supernova, the pioneer of torrent sites, said that he is using bitcomet. According to the plenty of 7331 here, He falls into the category of noob. morons.
I take great offence to being judged because I joined bitcomet. I seed at least if not more than I download. I am not & never been selfish. Please don’t judge us all on what you see from some
To whom it may concern,
Many people seek fast download speeds and blame several sources for any issues. Some know how to properly set up setting in their client, some do not. Some actually figure out port forwarding, some do not. Some understand Throttling of ISP, some do not. Some blame the client they use, some blame other clients.
The attack on BitComet is unfounded. There was an issue in coding that inadvertently created it to ignore the private flag, but was fixed quickly.
I did a study on the share ratio and bitcomet eficacy rated amongst the highest. Furthermore, it rates higher than all the others reguardless of the anti bitcomet measures in place. It seems that Bitcomet manages information bits better, thus, speeding the overall flow greatly. This is exemplified by a 3 month data flow monitoring of trackers that ban Bitcomet with “leaching forbidden” tag Vs Trackers open to the whole torrent community. The study was done at the Cox cable ISP At hub 19VS.
Just stop with all this shit you stupid little creatures users of other clients than BitComet.shadowshit is just trying to manipulate you ,you stupids.Just use what you like and don’t cry like bitches here.We live in a free democratic world you mother fuckin’ nazzi.It’s like you were rasists.FUCK YOU!!If you think you are cheated by BitComet then use it too.Just don’t say you are not pleased by your other torrent client.Every client is good in it’s way.Sorry for my bad english :D
shadow is just a noob. His silly new invention broke the protocol not bitcoment. I woun’t stop using bitcomet because I like it. Nobody will convince me otherwise. By the way I’m banning bittornado from our private trackers….if it doesn’t share with everybody then we don’t want it.
Why should I be forced to upload at a high rate just so I can download? My ISP enforces an extremely small upload cap. If I go over that then I won’t be able to seed anything at all and I’ll be off the Internet altogether.
>> Why should I be forced to upload at a high rate just so I can download?
.. sigh. Yet more proof that the Torrent technology must really be ingenious, because so few people seem to have any understanding how it works, or why they benefit from it.
To answer your question: There is nothing wrong with being a pure leech on a torrent. Just don’t expect to always have better overall download speeds as someone with a good upload pipe. But wait, this is actually GOOD THING, because for every byte of data sent to that super-seeding connection, that means there’ll be that much more data available to be sent to you and other leeching clients!
… because *TA-DA* now your client can connect to that faster seeder and download from him too, along with others.
In an ideal world, where people with good upload pipes willingly seed their share of a torrent, giving priority to them first means the entire torrent will be much healthier and much faster — to the point where your own downloads will be faster too. Unfortunately, so few people understand the concept of torrents that the ideal rarely happens.
On the topic of BitComet! I’ve noticed something lately on a couple of the low-activity torrents that I help seed, that I can’t explain: Normally there are only 4-6 seeds and 3-6 peers on my torrents but sometimes it’ll suddenly jump to 18 or 32 peers. The weird part is that when that spike happens I *always* have a BitComet client in my peers list (and only one, which is odd — since I’d expect several incoming connections from so many new peers).
And likewise, when the BitComet client drops off my peers list, the peers for the torrent go back to normal (3-6). Is this another form of BitComet gaming the torrent system?
4 references to this post
Responses are closed
All remaining responses will continue to be archived. Use the TorrentFreak forums if you want to discuss something.