TorrentFreak

113 Responses

Pages: « 1 2 [3] 4 5 » Show All

51 Jan 09, 2007 at 03:25 by Heliologue

Originally posted by a twit
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!

Wow, Godwin’s Law fulfilled before ten comments. That might be a new record.

52 Jan 09, 2007 at 03:57 by kdsde

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?!

53 Jan 09, 2007 at 11:50 by donb

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

54 Jan 09, 2007 at 14:36 by kdsde

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!

55 Jan 09, 2007 at 16:22 by donb

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

56 Jan 09, 2007 at 18:41 by revro

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? :)

57 Jan 09, 2007 at 22:24 by paperslug

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.

58 Jan 10, 2007 at 02:01 by Bomb Bloke

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?

59 Jan 10, 2007 at 05:44 by meverick

WHAT A LOAD OF B****CKS SOME PEOPLE COME OUT WITH

60 Jan 10, 2007 at 11:14 by donb

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

61 Jan 11, 2007 at 11:47 by mandog

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

62 Jan 11, 2007 at 19:14 by Dark Shroud

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.

63 Jan 15, 2007 at 22:26 by Blitzar

At last someone smart here! Hooray for BC!

64 Jan 16, 2007 at 07:28 by cars

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

65 Jan 16, 2007 at 14:14 by kdsde

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…)

66 Jan 16, 2007 at 14:52 by Superseed

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?

67 Jan 16, 2007 at 23:11 by Legion

hmmm…this shit looks like revenge of nerdz

68 Jan 17, 2007 at 04:19 by Flux

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.

69 Jan 17, 2007 at 08:37 by Superseed

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…..

70 Jan 17, 2007 at 11:06 by insectivore

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.

71 Jan 18, 2007 at 00:58 by MDD

To be “new to the swarm” means to drop (disconnect) the TCP connection to the seeder. Then reestablish. That simple.

72 Jan 18, 2007 at 10:31 by Dark Shroud

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.

73 Jan 18, 2007 at 13:27 by MDD

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.

74 Jan 18, 2007 at 13:55 by MDD

[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.

75 Jan 18, 2007 at 14:42 by hellow

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

Pages: « 1 2 [3] 4 5 » Show All

Responses are closed

All remaining responses will continue to be archived. Use the TorrentFreak forums if you want to discuss something.