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

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.

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.

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

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.

and with BitCommet limiting you uploads also limit your downloads

Seed like MoFos… BuRnT.

http://forums.bitcomet.com/index.php?showtopic=6675

dont talk about this “Bitcomet is cheating” thing… its been over for a long time.

Well said my brain is hurting already and I still have more to read!!

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

(And someone also create an entry for John Hoffman.)

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.

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

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 .

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]

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)

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?

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.

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

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.

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

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 .

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.

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?

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

so there you go maybe im not smart but hay, im honnest and it does happen simple as