BitCometの英語フォーラムにおいて、以下のような投稿がありました。

EXAMINING THE MYTHS AND FACTS CONCERNING BITCOMET BEHAVIOR
By Robb Topolski, July 31, 2007

この投稿は、英語フォーラムの Main Admin の The UnUsual Suspect によって投稿されています。

まえがき

本稿の目的は、いくつかの持続的な懸念についてBitCometクライアントに関して独立したデータをBitTorrentコミュニティに提供することです。
私はBitCometフォーラムにこの情報を掲示しています、そして、私は特定のP2Pニュースとそれに関する情報の提供者にも知らせています。
私の名前はロブ・トポルスキーです、そして、私は、WWWの時代が到来する前から、インターネットに取り組んでいました！
私は、25年以上の経験を持つ、ネットワークとプロトコルの専門家です。
私は American Society for Quality により Certified Software Quality Engineer と認定されました、そして、私はネットワーク技術に関して、Microsoft よりMost-Valued Professional と認められています。
私は、私自身をソフトウェアの品質、セキュリティ、テストとネットワークについて常に学び続けている専門家と考えています。
私は、このテストと分析を、誰からも依頼されませんでした。
私はBitCometフォーラムのマネージャーに情報を得ようとして接近しました 、しかし、彼らは私のテスト結果を前もって通知されませんでした。
この仕事は独立していて、BitCometチームの誰の許可または指導なしで実施されました。
私は1年以上の間BitTorrentプロトコルを研究していて、BitCometに関してこれらの懸念事項に興味を持ちはじめました。
私は、最も一般的な「懸念事項」のいくらかをテストすることに決めました。BitCometの「ワイヤー」的性質を観察するために、ある場合には、私は Wireshark のようなポピュラーな分析ツールを用いて、直接のテストを実施しました。
場合によっては、このプロトコルそのものが特定の懸念事項に対し、信用や不信を与えていることが判定しました。
しばしばBitCometと関連していると見られていた「即、切断する」という振る舞いはのいくつかは、ISPが私のテストのじゃまをしていることがわかりました（この性質はすべてのクライアント全体で見られたのです）。
私のISPは、しばしば、いくつかの方法を使用しているP2Pトラフィックを「シェイプアップする」か、リダイレクトします。
これを避けるために、私のテストの全ては、私自身のLAN上で、または、安全なVPNトンネルを使っている公共インターネット上で実行されました。
VPNによって、これらの干渉は消えました。
私には私を家に閉じ籠もったままにする長期の医学的問題を抱えているため、フルタイムの勤務は不可能です。
しかし、それにより私は密接にこれを勉強することができて、私の技術を通用するものにしておく時間を得ることができました。そして、本論文はゆっくりと一つのものとなったのです。
BitCometクライアントの振る舞いについての私の検査結果は、これらの「懸念事項」が一貫して間違っていることを示しています。
BitCometの評判は、2005年12月のDHT「リーク」のバグと、その対応が遅れていたという間違った認識によって損なわれました。
そのバグ以来多くのトラッカーで禁止されるようになり、いくつかの他の観察されたか想像された問題は、さらにBitCometの評判を傷つけるために「積み重ねられました」。
本稿を読んでいるトラッカーの管理者は、BitCometが、言われているほど嫌悪すべきクライアントでないと認識を改めるべきです。
注：
私は過去のバージョンに遡らなかったので、テスト結果は私がテストしたバージョンに限られます（バージョンは以下に記します）。

結論：バージョン0.60だけに限り真実。

既存の「Privateな」フラグの立てられたダウンロード・タスクをDHTへ追加してしまうバグが存在していました。
このバグは2005年12月の初めにバージョン0.60で見つかりました、そして、このバージョンは2週後には撤回されました。
このバグは、2006年1月のバージョン0.61で修正されました（http://www.slyck.com/story1094.html）。
いくつかの民間のトラッカーは、このバグの結果としてBitCometを禁止しました。

結論： 全くの間違い

DHTのバグのスケジュールは、バグ有り版（0.60）が最初のバグレポートの2週間以内に前の安定したバージョンのBitComet（0.59）と入れ替えられたことを示しています。
3週後には、DHTのバグを含まないバージョン0.61がリリースされていました。

結論： テストされたバージョン0.70（2006年6月）以降で間違い

もしそれが真実であるならば、接続したまま非チョークされるのを待つより、そのように再接続することで33%以上、BitCometとってすぐに非チョークされるチャンスを与えるかもしれないません。
BitTorrentプロトコルのこの仕組みは、スウォームの新しいクライアントに若干の共有するためのデータのピースを供給することを目的としています。
それは、スウォームに戻ってくるクライアントを対象としていません。
多数の試運転において、BitCometのいくつかのバージョンでは、観察されました。
本当に、彼らは彼らのピアからしばしば切断します。
しかし、そのような切断が、再接続による利点を狙った試みでないことは明らかです。
具体的には、0.70から現在の0.90のバージョンを通して、BitCometはピアからチョークされたあと、短い時間（60-90秒）接続したままで待機します。
そして、切断します。ですが、すぐには再接続しません。
ある一点を除いて、スウォームに再接続を試みるまで、1分以上待機していました。
もし、BitCometがBitTorrentの非チョークルールを悪用するつもりであるなら、切断してから、再度接続するまでの時間差が、その悪用によりBitCometが得るであろうメリットを全て打ち消してしまいます。
注：
どうして BitCometが、60-90秒の間チョークされると、ピアから切断することを選ぶのか、その理由については特定することも、誰からか明確な答えを得ることもできませんでした。
このふるまいはプロトコルによって許されていますが、そのようにする理由は明白でありません。
それはデータを送ってこないクライアントからの同時接続数を減らすことにより貧弱なルータを使用しているユーザーにとって役立つかもしません。
それ以外には、私は接続してなにもしないままでいることに対して、ごくわずかな不利しか思いつきません。
しかし、これは明らかに設計上の選択で、単に効率の問題です。
BitCometのふるまいは、誤ってもいなく有害でもありません。

結論： 間違い（決して真実であったことはありません）

多くの異なるBitTorrentクライアント開発者は、シードするクライアントにHAVEメッセージを差し控えさせる実験をしていました。
理論的にそのようなメッセージは不必要なオーバーヘッドです、この議論は、たとえシードしているクライアントがスーパーシード（BitTorrentプロトコルへの非公式の拡張）機能を働かせているとしても同様です。
スーパーシードは、特定のピアに送信された部分がスウォームの他の第三のピアに共有された確証を探しています。
あるピースを特定のクライアントに送信したら、スーパーシードはそのクライアントがちゃんと受け取ったかどうかの確証を得るために、その受け入れクライアントからのHAVEメッセージに依存したりしません。
それどころか、スーパーシードはピアがそのピースを他のピアに共有したかどうかを確認するために「他の別のクライアント」から、あるピースのHAVEメッセージが戻ってくることを必要とするだけです。
（注：
私は、BitCometが受け取った部分のためにHAVEにメッセージを送るか調べませんでした。
なぜなら、この懸念事項はスーパーシードが相手からのHAVEメッセージに決して頼らない、という事実に基づいて間違っているということが確認できます。）

結論： テストされたバージョン0.70（2006年6月）以降で間違い

Torrentがスーパーシードされているのであれば、群れの中の油断ならないBitCometクライアントは、ユニークな部分を「保持している」他のBitCometクライアントに接続しにいく傾向があるべきではありませんか？ この問題が真実であるならば。
さらにまた、BitCometには、このような振る舞いを発生させる独特の設定の組合せがありません。
ISSUE #3にみられるように、BitCometは他の大多数のクライアントより頻繁にピアから切断します。
しかしテストされて、観察されたバージョンのBitCometでは、チョークされて切断するまで60-90秒待ちます、そして再接続まで60秒以上待ちます。（http://forums.bitcomet.com/index.php?s=&showtopic=12787782&view=findpost&p=31159）
注：
たとえこれがBitCometだけが間違えていると確認されたとしても、大部分のクライアント（BitCometを含む）とネットワーク・スタックはハックされたり、調整されることで、貧弱な共有者とすることができます。
スーパーシードを実装しようとしているBitTorrentクライアントの開発者は、スーパーシードが貧弱な共有能力のクライアントの接続要求を、遮断することと再接続することによって忌避することのないように注意しなければなりません。

結論： テストされたバージョン0.90と0.91で間違い

BitTorrentクライアントがまだピアの数が少ないと見なしているときにreannounceすることは、よくあることです。
いくつかのBitTorrentクライアントを使用している私自身の経験において、reannounce間隔は、2〜5分の間でした。
BitCometは、20分待つようです。
BitCometを使う際に、私は私自身が「マニュアル接続」（手動reannounce）機能を働かせているのに気づきました。トラッカーへより多くのピアを求める前にBitCometがあまりに長く待っているように感じたからです。

結論： テストされたバージョン0.90と0.91で間違い

BitCometは、マルチ・トラッカーTorrentのために推薦された手順に従います。
各々の段の中の1つのトラッカーは接続をします、そして、段の中の他のトラッカーには接続をしません。最初に接続しようとしたトラッカーが応答を返している限り。

結論： 冤罪

簡単に言えば、BitTorrentプロトコルは、そのように動作することはありません。
トラッカーは、シードに特定のピアが選択または優先権があることを知らせません。
BitCometユーザーXSTREMは私に示唆しました。ユーザーがバッチTorrentからほんの少しのファイルだけをダウンロードするとき、BitCometが送るかもしれないように「Completed（完了）」メッセージをアナウンスするかもしれないことを。
彼は示唆しました。一部のトラッカー・マネージャがユーザーの管理のためにそのメッセージを使っているかもしれないことを。
それが真実であるならば、そのトラッカー・マネージャはBitTorrentの仕様でサポートされていない「Completed」メッセージを適用していることになります（http://forums.bitcomet.com/index.php?s=&showtopic=12787870&view=findpost&p=32101とhttp://wiki.theory.org/BitTorrentSpecifica...est_Parameters）。
Completedメッセージは、悪意のあるユーザーを探すための何らかの「チェックサム」として使われることはできません。

結論： テストされたバージョン0.70（2006年6月）以降で間違い

この懸案事項は、TheSHAD0W（BitTornadoクライアントの開発者で、多くのBitTorrentクライアントにより用いられるポピュラーなスーパーシードの発明者）よりあげられました。
BitCometの多くのバージョンにわたっているいくつかの慎重に観察されたセッションと制御された試運転の後、この報告されたようなふるまいは、まったく見られませんでした（http://forums.bitcomet.com/index.php?s=&showtopic=12787870&view=findpost&p=30879）。
TheSHAD0Wのテストまたは開発ツールが不完全であったか、あるいは、若干のネットワーク問題が彼にこのふるまいを見せた可能性は非常にあり得ます。
（事実、私自身のISPは、P2P「管理」をすることにより、私自身のテストにおいて若干の問題を起こしました。
私は、VPN経由でのテストによってそれらの影響を除かなければなりませんでした）。

結論： テストされたバージョン0.90と0.91で間違い

BitCometを使っている何十もの観察されたセッションには、私はそのような優先度がBitCometのピアに与えられるのは見受けられませんでした。

結論： 最初のシードの場合に真実。ダウンロードの場合に間違い。すでにシードされたTorrentであれば問題ではない（テストされたバージョン0.90と0.91で）

この懸念は、TheSHAD0Wにより、スーパーシードに影響を及ぼしている問題として提起されました。
しかし、BitCometのスロット支配は本当に細いです ― BitCometクライアントが受動的なシードであるならば。
「Tit-for-Tat（お互いさま）」モードのダウンローダーとしては、BitCometのふるまいは、あまり細いアップロード・スロットを広げません。
その結果、TheSHAD0Wの懸念（それを私も、まず最初に共有しました）は、テストと観察の後、正当化されません。
BitCometが単にシードであるとき、ピアリストのほとんどすべてのピアはUNCHOKEDです、そして、各々に与えられるアップロード帯域幅の量はしばしば1KB/s未満です。
これは能率が悪いです ― ピアにどんな唯一の完全な部分でも送るために、とても長い時間かかるので（BitTorrentにおいて、ピアが持っている不完全なピースは、広げられることができません）。
これはBitCometクライアントがユニークなピースを保持しているとき（例えば、スウォームへの最初のシードをしているとき）に問題になります。
BitCometユーザーが最初のシードであるならば、そのユーザーはTorrentにシードするために私がこれまでに使用した他のどのBitTorrentクライアントよりも多くの時間と帯域幅を必要とします。
（テストの結果：
BitComet 200%〜255% 、通常のクライアント 145%〜175%、uTorrentのスーパーシード 105%〜115% ）。
ですが、BitCometがシードでないピアのとき、それは例外的に高度なスロットコントロールをします。
BitCometは個々にそれぞれのアップロード・スロットの速度を調節します。そして、ピア自身のアップロード帯域幅に応じて、より多くのアップロード帯域幅を提供します。
この実行はスウォームで、伝統的な「スロットと非チョーク」のBitTorrentのふるまいより、より良いピアに報いる傾向があります。
BitCometが同時により多くのダウンロード・タスクを自動的に、そして、能率的に取り扱うことも認められます。
（「Force（力）」機能の知的な利用ができる特定のBitTorrentクライアントでのみ利用できる。）
BitCometは、最初にすべての余剰アップロード帯域を使って、他の更なる往復運動しているピアでも見つけようとするか、ピアに返礼して存在することでさらなるダウンロード速度を得るために;
そして、次に非往復運動のピアにシードします。
その結果、BitCometは貧弱なピアがいるスウォームでダウンロードをいくぶんより上手に行い、そして、彼らはいくぶんより良い比率でダウンロードを完了するかもしれません。
（すべての利用できるアップロード帯域幅が常に使われるので、BitCometはBitTyrantの記事によって解説されるような「貪欲な」クライアントと考えられません。）

結論： 初期シードの効率の悪さを除けばBitCometは価値のあるクライアント

BitCometは、価値があるダウンロード・クライアントです、他のどの現在のBitTorrentクライアントでも見つからない若干の有利な特徴を提供する。
これらの特徴のいくらかは混乱されて、十分にインプリメントされていません、しかし、彼らはBitTorrentスウォームに有害でありませんし、彼らは不公平な有利さをとりません。
それは、資源の適度なユーザーです。
BitCometは、ごくわずかな技術的なフィードバックしか提供しません（ログや活動状態のインジケーターのような。
その結果、それは大部分の他のクライアントより「おたくフレンドリーでない」代わりにより「ユーザーフレンドリーにする」試みのようです）。
BitCometは例外的に劣ったアップロード・クライアントで、ユーザーが群れ（上のISSUE #11を見ます）への最初のアップローダーであるならば利用を避けられなければなりません。
BitCometユーザーがすでにシードされたスウォームに対するシードであるならばこれは問題でありません。
BitCometに対してトラッカーまたはユーザーが「BitCometを禁止する」理由として提供されるそれらの典型的な懸案事項のいずれも、有効なものではありませんでした。
私は専門家として、 BitCometの禁止が誤解と嘘と、そして、良くないデータに基づいているという意見です。
トラッカーの管理者が、私の独立したデータと分析をもって、このクライアントに対しての禁止を再考することが私のねらいです。
謹んで、BitTorrentコミュニティに提出します。
/s/ロブ・トポルスキーrobb@funchords.com