p2pnet news special | p2p:- Robb Topolski says he’s been surfing the Net since before Tim Berners-Lee developed the World Wide Web.

“I’m a networking and protocol expert, with more than 25 years of experience, and I’ve been recognized as a Certified Software Quality Engineer by the American Society for Quality, and I’ve been recognized as a Microsoft Most-Valued Professional in Networking,” he tells p2pnet in an email.

“I consider myself an ever-learning expert in software quality, security, testing, and networking.”

Why did he get in touch? Because he wants to provide independent data to the BitTorrent community about, “persistent concerns” centering on the BitComet client.

A December, 2005 ,DHT “leak” bug”and a false perception that response to that bug was slow” have damaged BitComet’s reputation, he says, going on, “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’s perceived to be.”

So he decided to examine some of the most popular “accusations” in some cases applying direct testing using popular analysis tools such as Wireshark to observe the “wire” behaviors of BitComet, and in others, determining, “the protocol itself lent either credit or discredit to a particular accusation”.

And, “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),” he says. “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.”

Topolski says he’s currently suffering from long-term medical problems, “that leave me homebound, and a full day’s work is impossible”.

But they’ve given him time to, “study this closely, and keep my skills current, and this paper has slowly come together as a result” and he’s decided accusations about the alleged bad behavior of the BitComet client are unfounded.

He says he’s posting the information the results of his studies to the BitComet forum and, “I’ll be notifying certain purveyors of P2P news and information about it,” he promises, emphasising, “I wasn’t asked by anyone to do this testing and analysis. I’ve approached the managers of the BitComet forum in an attempt to get information, but they haven’t been notified in advance of my testing results.”

He also stresses his analysis is completely independent and was developed, “without the permission or direction of anyone on the BitComet team,” going on he’d been studying the BitTorrent protocol for more than a year and, “grew curious about these accusations concerning BitComet”.

“Note,” Topolski adds, “I didn’t 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 didn’t 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’s 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’s 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 didn’t 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’s 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/BitTorrentSpecification#Tracker_Request_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’s 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’ve 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’s 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’s 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’s 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’s my hope that they reconsider their bans against this client.

Slashdot it!

---

Use free p2pnet newsfeeds for your site. It’s really easy!
Subscribe to p2pnet.net | | rss feed: http://p2pnet.net/p2p.rss | | Mobile – http://p2pnet.net/index-wml.php

---

Net access blocked by government restrictions? Use Psiphon from the Citizen Lab at the University of Toronto. Go here for details. Download here.

This entry was posted on Wednesday, August 1st, 2007 at 9:11 am and is filed under P2P. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

HOME

Viewed 5223 times